How to Hire

We recently hired a new developer for our team. I think we need at least one more senior guy. Yes I said guy. We have yet to have hardly any female candidates. Today I read an article on how best to hire a tester who will automate scripting. This seemed to apply to regular developers as well.

The first thing to do is to not choose the cheapest guy. A candidate who costs less will most likely produce less. You also have to make sure that a technical rep from your team is part of the interview. That way the candidate cannot fake his technical skills.

If you do happen to hire somebody who is cheap and does not have the best skills, then make sure you do not put them on the most important tasks. We did that a couple years ago for a new system we were writing. The result was that the plug got pulled and the code got put in the trash can (or on the shelf).

One would prefer a candidate that was adaptable and could learn new stuff quickly. We have technology that spans a decade or two in our system. There is also a lot about the business to learn. If you cannot keep up, you cannot produce for us. You need to also be able to handle complex stuff. At times our employees are called on to produce work arounds.

Like any job, there are politics to maneuver around. So you need to know how to communicate effectively without stepping on people's toes. Otherwise you may find yourself back in the unemployment line. So in summary, if you know a female that is a rock star programmer, send her our way. And if you yourself are looking for a job and have what it takes, drop me a line.

Simulation is Key

One guy who went on a long vacation from our work came back a week later than expected. Then he found out that his computer was not working. These two facts threw a wrench into our already busy schedule.

While this developer was away, my boss asked if we could use a member of another team. I said, "Sure." We can use all the help we can get. That may not have been a smart move. The guy needed a lot of help figuring things out. That time took away from other tasks.

The result of all of this was that we were not going to make a delivery date for some software changes. As soon as the customer realized this, the emergency lights came on. The boss called me up and said we would have to work through the weekend. I told him that was not acceptable. This was no surprise that we were not going to make our deliveries. There is no magic that makes a late delivery get delivered on time. Our team triaged to get the new software out. We took a lot of shortcuts. I have found that shortcuts only delay the pain. A high degree of risk is being put on this decision. But hey, I don't want to work all night and all weekend. That would only set up the wrong precedent. You know?

Customer Presentation

Today we were scheduled to walk through the design of a new piece of software. I was a little worried as the design documentation took a lot of work to produce. We had four people working on this task. They are all located in different offices sometimes. So I feared the worst.

All of us got to the customer site early. At least that was a good sign. We showed up to the presentation room 15 minutes early. Everyone got a little nervous when nobody was there 5 minutes before the meeting. But the people showed up. And many dialed in to the conference call.

The leader of our team was late due to a flat tire. Luckily our manager opened up the meeting, and I took it from there. There were a number of questions about the small piece I started with. However once I heard our customer's technical advisor say he wanted this meeting to move along, I pressed on. The rest of the developers followed suit. We actually ended the meeting 15 minutes early.

Good job team. Now comes the hard part. We need to implement all this stuff while there are still some uncertainties on some of the technologies to use. Does anybody have experience with PDF file generation? Inquiring minds want to know.

Lack of Process

Apparently we have a process for fixing defects in our software. The team allegedly worked on this process before I started on the project. I have asked the software development manager for the documented process a few times. All I get are promises. But I never seem to get a copy of the process. To me that means that the process is not important. Or maybe this means the process does not exist, but people say it does.

There are many times when we run into problems that can be traced back to a bad process. To me these problems are more due to a lack of process. I have an idea in my mind as to how the process should be. I follow that mental process. To me, I think this is a reasonable process to follow. However other people are marching to a different process. Everybody might even have their own variation.

Our project is supposed to be operating at a CMMi level 3 maturity. But if your key people do not know where the process documentation is located, then you are really at a CMMi level 1. Often times I joke that we are actually at a CMMi level 0. The real impact is that we might lose our contact with the customer if this is true. What do I have to do to bring this problem into the light? I guess I could make some noise about it. I could escalate the problem up the management chain.

The last guy who made some noise got fired. I am not sure whether his dismissal was due to his “noise making”. I do know he was very vocal about the lack of documented processes. He also went further to state that the management was utterly incompetent. The suspicious thing is that nobody officially came out and said he was fired. He just disappeared. He called me up and spoke elusively about his departure. This is definitely not a good scene. What a developer like myself to do?

Problem Investigation

Users of out system complained about reports printing out multiple times erroneously. They also said other reports did not print out at all. We have a developer on our team who specializes in reports. However she asked me to look at the problem because she was at a loss. I told her we first needed to find out exactly what the user was doing. Then I said we should try to duplicate their actions and the system behavior.

I took the initiative and hunted down the users who were experiencing and reporting the problems. With the information gathered by talking with these users, I was able to have our reports developers to duplicate the problem. Normally once you can make the problem happen, you can fix the problem. Replicating the problem sometimes is 80% of the work.

The reports developer could still not figure out what was happening, even though they could make the problem happen. I said we should add some logging to determine what the heck was going on. The logging did not help the reports developer. I took a look at the logging. There was no clear way to tell which report was generating which output. I had the logging modified to have each report generate a unique ID. That ID would be included with each debug output message.

Once again our reports developer was confused. The unique ID did not appear to help them understand what was happening. I took and look and recommended that she sort the debug out by the order in which the stuff was logged. That helped clarify that two reports were running at the same time. That spoke a lot to me. We have a whole scheduling program which is supposed to prevent any two reports from running at the same time. The reports developer was happy because she does not deal with the scheduler program.

I took a quick look at the scheduler. It was written in Visual BASIC by a guy who could or would only code in VB. To start I needed to get VB installed. Then I ran a debug version of the code. That is where I found that this little VB program was a bit complex. In fact, it was overly complex. It was creating multiple threads to spawn reports at the same time in parallel. That defeated the purpose of the whole app.