Mysterious Double Instance Hampering Performance - I study the existing code base. Confer with a colleague. Then I determine the optimal plan to change the functionality to load only a slice of all the dat...
Here is the stickler. This is a long survey. And they want you to take it on your own time. That might work if you are chillin on your job. But me and my team are busy. I cannot justify spending any time on such a survey.
The local managers figured we were busy. So they cooked up some gamification techniques to encourage participation. They divided us up into teams. And they are pitting team against team. There is supposed to be a prize for the team that finishes the survey.
This gamification is encouraging some people to do the survey quick. They even try to get others on their team to do the survey too. I have a problem with this though. They said the winner will get some undisclosed prize. If you are going to wave a carrot in front of me, I need to know what the carrot is. Otherwise I will look a fool if I jump for some undisclosed prize.
I have some other ideas on how to motivate all employees to complete tasks such as this survey. But I will share those ideas at another time.
The problem was that every time you install our software, we uninstall any old copy that is already on the system. Normally that is the expected behavior. However the customer wants a specific version of the old software to stick around. The lead on my team decided that we wanted a multi-install capability turned on in our Installshield project.
Multi install sounded like a bad idea to me. Sure enough, the lead was having all kinds of trouble with it. In fact, he now had two problems. The customer's old versions were getting uninstalled. And he could not figure out how to get multi install to work in all scenarios.
So I backed the guy up. I told him the InstallShield and Windows theory is that a product knows what kind of product it is. And it we got it set up to remove all prior copies of itself. If you do not want to remove prior copies, you need to create a new product. For InstallShield, I had a hunch that this was some sort of unique string or number like a GUID that uniquely identified our product.
As soon as I led my team leader down that path, he found a Product GUID setting in InstallShield. With the click of a button, he was able to generate a new GUID and solve the customer problem. He backed out his multi install problem. The moral of the story is to first have a deep understanding of the problem. Then you can clearly see what it takes to resolve it.
Later I saw that developers specialized in languages and platforms. Back then Microsoft seemed hot. Therefore I learned the Microsoft stack. I became a Microsoft developer. My self proclaimed titled was a Windows Application Developer. Made for quite a few job opportunities.
When I started my current job, I got hired in as a Windows Application Developer. Perfect fit. But then I found that the database in use was Oracle. And our system is Oracle-heavy. No trouble. Remember that I am an engineer by training. I learned Oracle on the job. Even went and got Oracle certified.
Nowadays I don't seem to do as much Windows programming. It is mostly database development in Oracle. I thought I might need to morph into being an Oracle developer instead of a Microsoft developer. But lately I have been reading that it does not matter what stack you use. Your stack is not your value.
Patrick Kalzumeus says you should not even call yourself a programmer. And Andraž Bajt decribes the rise of the Nomad programmer. Time to sit back and think about my title in the work world.
Somehow I rose up to lead the team. I figured that my job was to coach the green developers. And I would try to protect them from the crazy antics of management who thought they knew better. We were busy. I figure we were working around 50 hours a week. I did my best to keep morale up. After polling the developers, I went out and bought food they liked. Hey. I was not a saint. I billed the company. But I made sure we had some nice food to eat.
One of the developers figured out this job was not for him. So he put in his two weeks notice. The managers asked me to help him wrap up what he was working on. I had a good rapport with all the developers. This one developer who was leaving confessed that since he was quitting anyway, he was just going to slack off during his last 2 weeks of work. Fair enough.
The thing that was disappointing was that this guy was really excited about his blog. And he wanted to see if I would read his blogging. I was busy trying to keep some disasters managed as best I could. And I was still on the ship that was rocking. The last thing I needed to do was read blog posts from a deoparting slacker. But I knew diplomacy. I let the guy know that I was a bit busy at the moment. So blog reading would have to wait for less busy times.
I never did check out his blog. Can't blame the guy for leaving a challenging work environment. But then again, I can't imagine he had much worthwhile to say in his blog.
Okay. I have the OCX files. I register the controls. Actually it is one control - the Microsoft FlexGrid. God knows why were are using it. But I register the control. Still get the error in Visual Studio. Come on Microsoft. These are your own controls. And I had our customer buy your Visual Studio. That cost some big bucks.
Well I google around. And I figure out what the problem is. These are VB6 controls from way back when. Visual Studio 2008 does not by default install licenses to use VB6 controls. Go figure. Microsoft's knowledge bases tells me to either (1) intall VB6 on my machine, or (2) find some hack on my VS2008 install media to update my registry.
I guess the real message that Microsoft is trying to send is for us to stop using the VB6 controls. Otherwise they will make it hard for developers to use them. Hey I would love to fool around and find the latest .NET controls and put them in our application. But my customer has real business needs that need to be solved. They don't want me wasting time updating controls that have no positive business impact to our system. Darn you Microsoft.
So you need to exit Visual Studio and restart it for it to pick up environment variable changes. Perhaps storing state in environment variables is not such a good idea. We could stash this stuff in the registry. Changes in the registry are immediately available to anyone who accesses the registry. We actually use the registry for a bit of run-time values in our app.