Interview Candidates

We need additional developers on staff to try to do more work for the customers. It has been difficult to attract qualified candidates to interview. However our recruiters recently found us some hot prospects. I made a trip to headquarters where they invited a number of candidates for our open requisitions. There were a number of interesting characters there.

The first guy I met seemed smart. He had a PhD with a high GPA. However I had some trouble communicating with him. He had this heavy accent. Luckily he worked for a company I previously worked for. I made some calls and verified that, apart from the communication barrier, this guy could get work done. I recommended a hire for him.

Next I talked with another guy with an accent that I could understand. However I was a bit surprised that the guy did not even have a tie on. He had a short sleeve shirt on. I saw that he had recently changed jobs, and was looking to switch again. The core problem he explained was that he was not working on something that was interesting and challenging. I was concerned that the guy would not be interested in our work. No hire for him.

I then interviewed another guy. He was adamant to show me his code samples. They contained some clean C++ code. He told me he was proud of that code. In fact, that was the culmination of his career so far. There was only one problem. He did not have the experience we need on our team. However he might be a good fit for another team at our company.

Finally I met with a guy I had already spoken with. He knew the answers to almost all the technical questions I posed. So I went even further and asked him a more difficult question. He was able to breeze through that as well. To me that screamed a must hire. My boss was concerned that the guy did not have experience with design. Who cares? We need hands-on guys like this.

Schedule and Design

My team lead told me we needed to start designing some big changes to our application. He said we needed a design document by the end of the month. Since I had been surprised before on such changes, I decided to consult our project schedule. That is where I found out we were one week late on this design work. And the design doc was not due at the end of the month. It was due in a week.

The requested changes affected a number of parts in our system. Many of these parts are the responsibility of other developers. Like any senior developer would do, I reached out to these developers and warned them of our upcoming deadline. Then I also took the lead and said I would come up with the first cut of an interface between our subsystems. I picked out those requirements which caused the application I manage and the other parts to need to communicate. Then I started making design decisions,.

Here is what I found. The design work is actually fun. We are in a maintenance mode. So we sometimes spend a lot of time fixing bugs. This was a nice break to actually work on something new. Sure it needs to work with the rest of the system. But it was still very fun work. The really good news is that I have established the design of the interfaces between the subsystems. Now I can concentrate on the parts that are specific to my application.

About Real Programmers

I read this opinion piece about "real programmers". Apparently real programmers write code in C++. Being a C++ programmer I could not argue about that. I also read that Java and COBOL programmers are just drones. That seemed a bit stereotypical.

Then I found out what this "real" label was about. It was not a language thing. It was more about the programming choices you make. Apparently a real programmer takes the difficult path.

Real programmers don't maintain code? Yeah right. Here is a funny quote. "Real programmers don't make mistakes." It sounds more like real programmers don't admit to making mistakes. That sounds real stupid. Yeah, the pun was intended.

Hey. I don't have any problem with some people thinking they are real programmers. Most programmers think they are the best anyway. But it is good to agree upon definitions in the software development world. I don't think we as a profession are going to be able to define which types of programmers are real or not.

Unemployment Numbers

Recently I saw a report stating that unemployment had risen to 8.5% here in the USA. Those are some depressing numbers. It may get a lot worse before it ever gets better. This is definitely a recession. If we get to 20 or 25 percent, we shall have crossed into depression.

What is the effect of the software development industry? One thing is for sure. Job listings for developer positions have been shrinking. Luckily my company is hiring. However it looks like we are being extra picky at the moment before we hire somebody.

Personally I would not want to be looking for a job at the moment. That is all the more reason to stick with my current project. It is also the basis for trying to ensure that even if there were some layoff, that I would be one of the last few to stay on board. This happened once before on my project when the prime contractor worked on slowly eliminating a subcontractor.

I keep my ear to the street to see what other developers are saying about the high unemployment numbers. Some say that companies will require less workers to do more work. There is talk about possible pay cuts in the industry. What are your options if you are laid off? You might try to go into another field. But that field is probably hurting as well. You could launch your own job search site. That reminds me of one important warning. Beware fake job sites.

Distractions

I have been working on my project for almost 10 years. There are a lot of people in my customer’s organization that I know. Having been here for a long time, I seem to have gotten onto a lot of email distribution lists. Most of the time, the information sent from these email lists is not required for my day to day operations.

Here is something I have found. Many of the emails from the customer are encrypted. They are slow to open. Some of that may be due to the fact that I am remotely connecting to our customer’s network over a VPN. Whatever the case, I find myself spending a lot of time opening these emails to find they have nothing to do with me.

My normal workload has been growing now that we have more work and less people on our team. Management says they are looking to add more people to our team. For the time being, things are chaotic. I did figure out a way to work smarter. In Microsoft Outlook, I just set up some rules to filter out the email coming from the mailing lists I am on.

My customer email rule just moves email automatically from my Inbox to another private folder. Nothing gets deleted automatically. However my Inbox is cleaner, and so is my schedule. Every once in a while I scan my private folder for subject lines which look like they are meant for me. If there was a true emergency, I would get a call.

Now the trick is to find out how I can identify and implement other time savers at work. A little change can go a long way, just like my custom email rule filter.

Disorganization

Some test personnel in our customer organization wanted to meet with development to review some changes to our design document. My manager called me and asked when would be a good time for me. I told him this morning would be fine. Then I went and studied up the most recent design document. I found some errors. Regardless, I was ready to go through it.

Right before I went home from the day, some weird things happened at work. First I got forwarded a meeting invite to a different meeting at the same time. I ignored it since I had just talked to my manager about meeting the testers in the customer organization. Then I got a call from my team lead. He said he would take over the tester discussion. I was supposed to go to the other meeting.

This all seemed wrong. I had no clue as to the topic of the other meeting. It was supposed to be a review of our design for some other new functionality. My team lead told me to call some of the other invitees. I called up another senior guy. He said he was just as clueless as me about it. Then I got an email from my manager stating that he expected us to lead the design discussions on this new change.

Now I understand that I need to be able to present material in front of the customer. This is not a problem. I am actually quite good at it. However the reason that I am good is that I am usually part of the team that makes the hard design decisions. Then I make sure I learn the material deeply and prepare for any customer presentations. This setup was nothing like this,

I had to call up my manager and tell him I was not comfortable with this. In fact, I had a good mind to escalate this up to the senior management in my company. Luckily my manager heard me, and said he had a lot of ideas about the design and what we needed to discuss with the customer. At that point, I got him to be the guy to present his ideas to the customer.

Another senior guy later joked, asking me whether I was going to lead the discussions with the customer. I told him that it would be a short presentation if that was the case. I would introduce myself, bring up a question or two, and quickly adjourn the meeting. As it turns out, the meeting lasted a long time. We only stopped because there was another meeting which people had to attend after ours.

Schedule Surprise

This morning we had our weekly project meeting. The upper management in attendance was surprised that we were not making our schedule software release today. I said the project release date was two days from now. I myself found it unusual that they did not know we were slipping the schedule. The top manager in the room wanted to know why we were not meeting the schedule. I volunteered that I did not know that today’s delivery date was critical. However I added that we knew that date was not feasible a long time ago.

After the meeting I went to the latest release of the schedule. All of the tasks related to the one I was working on did not match the dates on the schedule. They were all way late. I guess my delivery slippage was the first time some of the upper management was alerted to the problems since my task was a very visible one. I immediately called my manager and said we had a problem. And I told him was going to escalate the schedule problems I saw up to the top manager on the project.

Finally this afternoon I got to speak with the high level manager. I told him that the dates in the schedule did not match actual dates for anything. I asked him whether he needed me to do anything other than inform my team lead or manager when things get off schedule. He said I should also try to work with them to plan a way to get back on schedule. He also said that I could escalate any issues up to high levels of management if I do not get satisfied with the reaction from my immediate supervisors.

I learned one important lesson from this exercise. I need to be more cognizant about the published delivery schedule, especially when I am the guy on the line for a delivery. So from now on I will study the schedule, and alert people when things are slipping. The best I can do is follow a process like this.