Good Status

Every week our project sends a status report to our customer. This is a contractual requirement. The way status gets collected is that it is rolled up by team leads to managers to the status person. I am on the bottom of the totem pole. So I give my status to my team lead. It is actually quite simple. I send an email outlining what I did in the past week, and list percentage complete on long term scheduled tasks. This is simple right?
Here is what happens. Each week our team is stressed out with the emergency of the week. As a result, I don’t think anybody sends our team lead status. He then needs to make something up to send to his boss (the manager). Do this enough times and you get inaccurate status. Sooner or later you will get found out.

I make sure I am not part of this cycle. It does not matter the circumstances. I always send that status email on time every single week. Am I off for half the week? My team lead still gets my status. Is my e-mail broke down? I go home to my personal email and send off my status. It gets done. Why am I so adamant about this? I have been a team lead before who had to compile status. And it is such a simple and short task that gets a lot of bang for the buck. There is no excuse to not send status.

Now there are some tools I use to help me compile my status easily. Whenever I work on anything, I make a note in my “work done” system. Each day is a separate text file. To compile status, I look through the files from the last week. It is almost a copy and paste of the highlights. A good process makes status reporting a breeze instead of a chore. I highly recommend it.

Stick to Your Guns

Our customer’s test organization found a bug in our software. This happened during a week where the edict was to fix bugs ASAP. So a new guy shipped out a fix to the bug. Turns out the fix did not work. That usually makes us look bad. From the outside, suspicious customers think we are just trying to make it look like we are fixing stuff when we are not.

My manager asked me to step in and find out how long it would take me to recover from this situation. I gave him a date. This is where the madness began. My team lead had a lot of questions about the date. I told him it was simple. I would guarantee the fix could be in by the date I gave. My team lead kept asking questions about how I arrived at that date.

Later I was given the task to take over the work for this problem. However this was not the end of the story. My team lead had a lot of questions about the problem. It took a long time for him to understand the complexities of the problem and related problems caused by the bug. He still was trying to bring in the delivery date. He told me he was getting pressured by a VIP in our company.

In the end I got fed up. I told my team lead that he might have some insight into the problem, but getting him up to speed was slowing down the resolution. I told him to tell the VIP to trust me as I have a track record of delivering when I say I am going to. My team lead had to man up. He told the VIP that there was no way to make the delivery any earlier.

All my team lead had to do in the end was write a memo with the exact plan I had to fix the bug and make sure nothing else got broke in the process. I know it is hard to be a team leader or a middle manager. But if you have the job you need to actually lead. Don’t cave in every time somebody important tries to get you to commit to shorted delivery time frames. Fight that fight. Your whole team will benefit.

I think my goal for this year is to hold my team lead responsible for representing my interests in dealing with management from our company. Otherwise I will be working late every night, working through the weekends, and be perpetually late on my projects.

Getting Time Off

For the second week in a row, my team lead decided we would work into the weekend to fix a lot of bugs. I decided it was time to make sure I got something out of this effort. So I requested my manager approve some days off next week since I have already put in a lot of extra time this month.

My manager asked if my team lead approved. I called up my team lead. He said he would not approve this time off. I was shocked. This guy looked to me in the last couple weeks to make some big releases happen. That meant staying late every day, taking work home, and working on the weekends.

Well I decided I had enough of that nonsense. I informed my team lead that if that is the reward I get for putting in extra time, there would be an end to the extra time on my behalf. Thus I am unavailable for work this weekend. And I told him to stop calling me after hours for support. This story only gets worse. I will save some more details for next time.

Domain Expertise

A new guy on our team got a challenging bug to fix. He took a long time to get up to speed in the business of the trouble. Our team lead decided to take over the work. However there was just one problem. It was difficult for the lead to figure this stuff out as well. So what does he do? He called me up.

I told my team lead that it was a challenging problem. He would need to dig in there to figure out what was going on. Unfortunately he was directed to fix this problem ASAP. I advised him to just give up and declare the problem done. He was not happy with that idea. So I gave him some other hacks that might qualify as getting the problem masked for now.

Turns out our customer rejected the hack. This issue was starting to get a lot of visibility. Both my team lead and I got an email from the customer declaring that the fix did not fix anything. I ignored the e-mail since my team lead made the command decision to ship a hack.

I somehow got involved in a long conference call with the customer for some other business. During the meeting I saw a lot of emails about the failed fix. Then my phone was ringing off the hook. I ignored the calls since I was in a conference call. However when the lengthy meeting was over, I found my team lead in a bind.

Now I could have just told him that I told him so. But that would do nobody any good. So I gave him some ideas on how to proceed. We could have saved ourselves from the drama by just doing the hard work in the first place. Shoddy efforts like this will only make the customer mad. Let’s see how it all turns out. The only thing I do know is that I got the deep domain knowledge. That knowledge is power. I must wield the power wisely.

No Dup No Fix

I got a call from my team lead. He said another developer was having problems fixing a bug discovered by the customer. This other developer thought he found some code that was suspicious. So he made some changes hoping that would fix the problem. This scenario was easy for me to analyze. If the guy could not duplicate the problem, he sure as heck did not fix it. It is simple as that.

This problem got reassigned to me. Like everyone else who could not replicate the problem, I tried to check out the behavior. It seemed to work. But I know that is not the end of the story. I went to peek at the production data. Then I recreated records in development that matched production. Finally I followed the steps the production user was taking. I encountered the bug.

I will admit this was a tricky bug. The software seemed to work for the trivial case. But you had to have some certain properties set for the initial record, and you had to navigate to another record that was different than the initial one. We had a couple teams try to recreate the problem. They were unsuccessful. Once I determined the steps required to recreate the problem, the fix was just a couple lines of code away.

Here is the lesson learned for maintenance programmers. You must be able to recreate a problem before you can do any more work on it. If you cannot do this, you have no business making any code changes to fix the bug.

Working on a Sunday

The customer wants more bugs fixed. They informed management. Management informed team leads. Team leads informed developers. Now I am here working on a Sunday. Great. Well I better make the most of it. I caught up on some e-mail. Then I helped out a tester. However the latest build was not complete. This was the primary objective for the weekend. Verify the build. What am I going to do instead? I am going to work on writing some tools. Yeah.

We have some ambitious system administrators working for our customer. They have some scripts which detect if your source control views haven’t been used in a while. If not, they mark the views as inactive and you can’t use them. Furthermore there is something wrong with their scripts. When they run, they permanently screw up your scripts. You cannot recreate them with the assistance from an administrator.

My solution to the above problem was to write a program which simulates a developer using all of his views. It is cool. The thing checks out some files from every view, edits them, then checks the updated versions back into source control. It looks like I am working on each and every view to the system administrators. I updated this program to work with my latest views.

Our software ships with the ability to connect to our customer’s databases. However we use different databases for development and test. To point the applications to these dev/test databases requires some hacking of the Windows registry. I wrote a small program which does this for you automatically. This comes in handy because each time you install our software, it overwrites the registry and limits the applications to just our customer databases. Today I updated my program to work with the latest software for next year. All in a good days work.

Too Many Questions

The other night I got a call from a DBA on my team. He was trying to respond to some problems our users were having in a new database. This DBA had some ideas about what was causing the problem. But he could not determine the source for sure. He had a lot of questions for me.

The next day I responded to his questions. My response also went to all kinds of people in the customer organization. That's when I started getting all kinds of emails and phone calls. Then my sponsor in the customer organization called me up and started asking me whether some of the things he was talking about were the cause of the problem.

That is when I realized we were in trouble. We were not going about this in the right way. I had to be abrupt with my customer. I told him that we just needed to assign this problem to a developer. The developer could figure out for certain what the problem is. We were wasting a lot of time that development does not have chasing down theories and answering questions that have nothing to do with the problem at hand.

The bad news is that the problem got assigned to me. However once I was on a mission to solve the problem, I was able to concentrate on and zoom in on the source. I did not have to educate any users. I also did not need to explain a lot of the system to new users, or trace down false leads by smart people who just don't know the system well enough. The fix will go out in our next release. I learned a valuable lesson. Don't contribute to bad processes for problem resolution. It will only be a total waste of time.

How Much to Fix

Yesterday I fixed a bug found by our customer. However I realized that the same problem affected many other parts of our application. What was I do to? Should I just ship the specific fix and move on to other bugs? Or should I correct every instance of the problem?

I like to code. To research other bugs would be non-coding. Therefore I was inclined to fix the other instances of the first bug that I fixed. Plus it would look bad if the customer discovered the other instances. There would be a lot of questions and meetings to discuss why we did not fix all these other scenarios.

So I spent the rest of the day banging out some code to fix all the scenarios. This was really fun. In fact, when it was time to go home, I decided to keep coding. Unfortunately all good things come to an end. Now I just need to do a lot of unit testing. Got to make sure that I did not break anything.

Out of Order

I started working on a trouble ticket today. My team lead called me and wanted to know how long it would take to resolve the problem. I estimated a couple weeks since I did not know what the issue was. That was a worst case estimate.

Luckily I was able to duplicate the problem. The user interface called a Pro*C function to fill up a structure. The UI code looked like it was extracting the results correctly. So I went into the Pro*C. It was a bit confusing. A bunch of records were being summed up. Then the code tried to transfer the result of the SQL query into the structure required by the caller.

The code to copy results in the structure was convoluted. That was a sign that the error might be in there. There were multiple loops going on, coupled with a number of counters. The loops went through the query results. The counters identified where we were in filling up the output structure. That's when I spotted some disturbing logic. If the two did not match, the output got set to zeros. This was the exact behavior that was being reported in the bug.

It was then that I realized what was going on. The code assumed a specific order in the query results. But the SQL did not have an ORDER BY clause. I decided against adding the ORDER BY to the SQL. We might be querying a whole lot of code. I did not want to add extra overhead for the database to do the sort. I just wrote a quick routine to scan through the results while putting the answers in the output format. Problem solved. Now I need to fix all the other places where the code assumes a specific order coming back from the query. This was quite an exciting problem to solve. I even worked some extra hours to get this thing fixed today.

Fix Problems Faster

Today I heard two similar comments on my development team. The customer is concerned about the number of defects that are opened against our system. That is a valid concern. However the response from our management was for us to fix problems faster.

Yeah. What do they think? I have been sitting around all this time artificially slowing the pace at which I resolve bugs? LOL. From the outside I would have thought this was a joke. Knowing my project, it is no joke.

Ok. So how do you get problems to be fixed as a faster clip? Well you cannot will it into existence. And you just can't "try harder". You got to work smarter.

Here is the catch 22. There is no silver bullet for this problem. It will take some head down analysis to identify the process problems which are inhibiting bug fixing productivity. Who can tackle such a challenge? Yep. They need developers to do it. And if you spend time trying to fix the process, you bug resolution rate will be even lower.

There is only one decision I need to make. Do I just ignore the nonsense about the "try harder" speeches? Or do I step up and call them on this joke. I am going to have to meditate before making that decision.

Step Back

Today I found some e-mails asking me about the status of a particular trouble ticket from our customer. It was strange that somebody was asking me. Our bug tracker showed the ticket was assigned to another developer. Then it hit me. I was asked to join a trouble ticket conference call with the customer. Let me tell you about that debacle.

The customer had a list of outstanding trouble tickets. They started with the first ticket and asked the attendees what the specific problem was. This question was followed by silence. I thought this was a total waste of time. So I jumped in, quickly scanned that problem details, and explained the bug in normal English. I then proceeded to do the same for every other trouble ticket on the list.

Now that I spoke up about the myriad of trouble tickets, it seems that I have been associated with the tickets. We have a team of about 7 developers. All of us are working trouble tickets. However I was the only guy that stood up and spoke at the meeting. So now I get the benefit of being a point of contact for some of these that still have not been resolved.

To speak up at the meeting is the responsibility of the team lead. I am not the team lead. The team lead was actually pretty quiet during the meeting. This has happened a long time ago in the past. My reward for stepping up was becoming the team lead. It took a while to shed that responsibility. I don’t want it. Perhaps it is time to remain quiet during any more meetings I get invited to. Otherwise I will just have more work to do, along with more responsibilities. I am not looking for that. There is no financial benefit to it.

What's Hot

The Gartner Group has come out with a Top 10 list of hot technology for next year. It comes as no surprise that cloud computing tops the list. I find it interesting that security is right up there near the top as well. Long term I plan to beef up my knowledge in the security industry.

Mobile appliances ranked well too. I thought that only counted for iPhone apps. When I read that social computing ranked high, I could only elicit a yawn. In fact I would think that social computing may be hitting its peak.

Virtualization was listed in the Top 10. However it also seems like yesterday's news. I think I will give the future some thought and come out with my own Top 10 of tech for 2010. That has a nice ring to it. Here a is preview: Java and .NET will not be on my list even though I want to learn them well.

Unwilling Participant

Somebody asked me for some source code from our system. Luckily I no longer had access to the back end code. Therefore another developer on the e-mail responded with a copy. This caused the requester to determine that there were problems with the code. It was a set up if I ever say one.

So my manager asks if anybody knows about these problems. Like a fool I answered that yes, it appeared that our team did not do the yearly update we were supposed to do. Another team manages the code. They are supposed to make this happen on a yearly basis.

Much discussion ensued. The a plan was formed. I was tasked with doing some initial research so all the requirement could be gathered. I asked my boss about this research that had been assigned to me. Another bad move. After getting clarification, I found that I then needed to fix all the problems. I should learn to just stay quiet, even when I know some information. On this project you get the bonus of doing more work if you pipe up. Normally that would not be a problem if I were twiddling my thumbs. However I am oversubscribed. Now I just won myself some more unpaid overtime. Weak.

The Closer

Yesterday as I was leaving work my team lead called me. He directed me to focus on a certain customer problem that was about to be our project's high priority. I made a note and left anyway. That night two of our top guys started looking into the problem.

When I got in the next day, I put this problem at the top of my list. My team lead called me up. He said that some guys started working the problem, and that I should pick up where they left off. I told him that one guy should be assigned the problem and take it to closure. At that point I definitely became that guy.

So I called up the customer. I had some ideas. The customer gave me some information. So did one of the other guys who worked the problem. I had the customer runs some tests. Then I logged into their database and figured out what was going on. The customer wanted some more tests run. And they wanted details on how some new parts of the system worked. When that was done, the problem was solved. I am like your 9th inning relief pitcher in baseball. Call me in when your starter is worn out. I will close out your top priority problems with expertise.

Source of Failure

I just read an article in Software Development Times. It talked about the continual failure of big software projects. This article had some authority as it included quotes from Grady Booch. It called attention to the fact that despite all kinds of new technologies, projects continue to fail at a critical rate.

Failure is defined broadly. The project may be late. It may cost more than anticipated. Or it may not contain everything that was needed. Given this definition, most software projects are probably failures.

What are the causes of such failures? It might be requirements problems. Specifically teams are not validating requirements. There may be programmers who do not follow the designated architecture. Or there might be poor contingency planning. We continue to fail, and don’t learn from our mistakes. There is a lack of best practices being used in the industry.

Here is a pattern for disaster. Keep adding requirements piecemeal. Then try to deliver a system that implements them all. Fail. The overall source of software project failure is human communication errors. Here is how you tell whether your software project has high quality. Check whether the software does the job it was required to do. Furthermore, test whether it does this correctly. If not, you can add you software project to the list of failures.

Microsoft Tech

My customer has paid for some type of Microsoft membership. I think it might be an MSDN subscription. I have been so busy at work that I forget what I got. One of the benefits of this program is that I get a subscription to the print edition of MSDN magazine from Microsoft. My first issue came this week.

I have not been keeping up with Microsoft technologies for a number of years. Instead I am focusing on the business needs of my current customer. So it was tough to get through a lot of articles in the MSDN magazine. There were a boatload of acronyms – WCF, WPF, and WF. All I could say was WTF.

WCF stands for Windows Communication Foundation. This is a piece of the .NET framework. It is used for building SOA applications. WCF defines the communication of web apps. It uses XML as the protocol.

WPF stands for Windows Presentation Foundation. It is the graphics subsystem of Windows apps. This initially was shipped as part of the .NET framework. It is based on DirectX technology. Developers employ the XAML markup language to describe the UI.

WF stands for Windows Workflow Foundation. Like WPF, WF was first released as part of the .NET framework. It helps developers define how long running programs operate and store their state. Another similarity with WPF is that workflows in WF are defined in XAML.

If I want to get back to staying current with Microsoft technologies, it looks like I got a lot to learn. This is difficult as Microsoft is continually coming up with new technologies to learn. It will be like chasing a moving target.

Bitmap Filtering

Today I got a call from my team lead. He needed help. We have functionality in one of our apps to filter out spreadsheet rows based on values in the columns. He added a new column. But he could not get the filter working.

I got a couple files that were changed. However I could not get the software to build. There were additional files missing. I kept iterating between getting the new file changes, compiling, running, and finding I was lacking more files.

Isn't this what source control is for? By the end of the day I got the latest code. This was partly an exercise in assuring that all the file changes got checked in. The filtering was still not working.

I started to make some code changes to try to get it to work. No luck so far. After putting in a couple extra hours, I decided to give up. Normally I am focused on solving problems. But this task seemed boring. Some dude coded some stuff that did not work. It got reassigned to me. If we were not in such a hurry, I would have thrown out the broken code and started from scratch myself.

Bad Design

We are a little behind schedule on our latest software delivery at work. I told the management that we will not make the dates unless we get more help. It took a while for that to sink in. The managers kept coming back asking me how we could make the dates. I kept repeating that we needed more people or it was absolutely impossible. Finally we got another resource.

The extra guy is a proficient one. The team gave him some changes to an application he designed and built years ago. We figured he would be happy to work on his little baby. Today he called me up because he was confused about how to add some spreadsheet filtering. I reminded him that this was his creation. He remembered part of the crazy filter design. However he could not recall how the filter GUI worked.

Now if the designer cannot come in and figure out how the UI works, we have some big problems. He tried to check out the resources for the dialogs. They were missing. I guess he had implemented some kind on non-standard dialog generation on the fly. Well he has to eat his own dog food now. He is stressing due to the time lines. I told him I gave him plenty of time in the schedule to get the work done. Nobody figured that his own design would be tripping him up.

Out of Control

On Friday afternoon I had wrapped up my development tasks for the week. It was looking to be a good weekend. Then I got that dreaded call. Another developer was stuck on a customer problem. The customer said a new report implementation was not working. The customer had said the report did not match the application. Our developer needed help. I had no choice but to assist.

I told the developer it would take around 20 minutes to compare what the application and report were doing. She told me they needed to ship the software in an hour. I dove in, and found some discrepancies. So I called the developer back. She asked me to conference in a lot of people with that call. So I did. Then I explained what I found, and gave some recommendations.

The manager on the call said he thought the new report was not correct. Then he asked if the old and new reports were equivalent. The developer answered yes. He wanted a second opinion. All the other developers took a step back, leaving me holding the bag again. So I quickly printed out pages and pages of the old and new report queries. Wouldn't you know it? I found a subtle but important difference in the SQL.

We held another conference call. By the we were right at the point where we needed to ship the software. I provided my findings and helped everyone understand the implications. Our manager had more questions. I told him he should assign someone to go research the answers to those questions, and I told him it needed to be somebody other than me. He said he needed me to do it. Then I told him no. We later had a private conversation where I reiterated my position. He then got a VIP from our company to call us up. I told him no as well.

I don't mind working on customer problems. In fact, I enjoy them. However I don't like coming in at the last minute and cleaning up other peoples messes. If I keep doing that, I set a bad precedent. This just encourages sloppy work, bypassing processes, and making me stay late due to other people's incompetence. I figured it was time to take a stand. Perhaps some nice article I read about saying no helped me grow the courage to do so. Let us see how this turns out. So far I have not been fired. But it is still early in the weekend.

Order of Importance

I had a week to implement the latest new feature in our system. The coding got done in 4 days leaving one extra day. On that day I performed a number of tasks to make the code complete. It is interesting how I ranked the remaining tasks to be done. I made sure the most important things were done first.

The number one item on my agenda was to ensure the program was functionally correct. That is the main thing the customer cares about. Next I made sure my unit tests were documented. This is to meet CMMi standards.

I then went back to my code to ensure it was modular. This meant breaking up some bigger functions into smaller ones, and combining like functions together. In other words I refactored. Then I beefed up the user interface, making sure I put in controls that did not allow the user to make entry errors.

Next I went back and deleted any obsolete code that was still there but commented out or unused. Finally I did a round trip and updated the design documentation. I did not have time to do any performance tweaks. This task fell off the list due to time constraints. Get the most important things done first. You will not have time to come back later and fix things.

Interview Wrap Up

This time I wrap up the lessons learned by reading Programming Interviews Exposed. Although I have never personally be asked any drawing questions in an interview, I suppose you might get some if you are trying to get a game developer position. I can't go into a lot of details of computer drawing. But it is good to know that high performance drawing relies on using integer math.

I do know you will get asked about SQL in interviews. Most questions revolve around the INSERT or SELECT statements. Know them well. If you are faced with a brainteaser, try to solve a sub problems first. You may get the insight you require.

A general rule is to make sure you can talk deeply about every technology listed on your resume. This is basic. Finally don't paint yourself into a corner when answering to what your favorite programming language is. The chances are that the interviewer does not share your choice, and may count it against you. Provide a general answer to such a question.

Next time I am going to get back to some real life stories and intuition I have gained on the job as a software engineer.

About Graphs

A more complex data structure in computer science is the graph. Each node can point to many other nodes in the structure. If the edges of the graph only go in one direction, it is called a directed graph.

Next let me mention arrays. Specifically I want to tell you about dynamic arrays. These are arrays that can change size at run time. They are usually implemented with static arrays.

Recusion is an elegant solution for many problems. However the function call overhead means the recusive solution is often expensive. Iterative methods can use the stack to do recusive style solutions. In general you should try to find a correct solution to a problem first. Then you can come back and make it fast.

Next time I plan to wrap up my hints on interview techniques. I will cover drawing, SQL, brainteasers, and your resume. Then we can get back to discussing software maintenance in general.

All About Trees

Even though linked lists may be the most popular data structure for interview, trees are a close second. A tree is a structure where each element has some number of child nodes. A binary tree is a special kind where each element has at most two children. A further specialization is the binary search tree. Nodes on the left are less, while nodes on the right are greater.

A balanced tree has the same number of nodes on the left and right child subtrees. This makes for an optimal search if it is a binary search tree. If a tree gets too unbalanced, it starts to behave like a linked list (which has worse search performance).

If you get a question at an interview on trees, try to think about recursively solving the problem. Here are some more tree facts. Traversing the tree means to visit all the nodes in the tree. And a heap is a binary tree whereby each node has a value less its parent node.

Next time I will briefly mention graphs. Then I will cover arrays.

Linked Lists

When I applied to graduate school in Computer Science, I was told to learn data structures and give them a call back. Ouch. I did eventually pick up a whole class on data structures. It was actually quite fun. This knowledge can help you through a question during an interview which centers around common data structures.

The most basic and favorite data structures for interviewers is the linked list. Obviously there are different types of linked lists. But for all of them you should check for NULLS when traversing it. You also need to know that deleting a record in the list requires at least two pointers.

Oh snap. We are out of time. Next time I will talk about the types of tree data structures in computer science.

Big-O Notation

When you are in an interview, you might be asked how efficient an algorithm is. This is a case for Big-O analysis. An algorithm whose run time grows linearly with the number of records it processes is said to be on the order of O(n). That is good efficiency.

Other Big-O rates are O(1), O(nlogn), and O(n^2). In the Big-O system, you eliminate all but the highest order time factor. So if an algorithm has an efficiency of O(n^2) + O(n), we just call it O(n^2). The O(n) part of the equation is insignificant.

Some bonus tips for analyzing efficiency are to consider both the average and worst case times for an algorithm to complete. Next time I will briefly talk about data structures like linked lists. Say that fast 3 times.

Problem Solving

When you are in an interview trying to solve problems, it is you general problem solving skills that will come to your aid. It is fruitless to try to memorize answers to specific questions. The problems presented are selected to prevent any such rote memorization.

One trick is for you to work through a specific example with the the problem. That may give crucial insight to the general solution. You should focus on the algorithm you use for the specific example.

Don't be afraid to talk through your thought process. This is actually encouraged. The interviewer likes to hear this. Remember to check for special cases once you think you have arrived at the general solution to the problem.

Know this. The correct solution to a given interview problem is usually very short. Around 10 to 15 lines of code should be sufficient. Therefore if you run out of room on the whiteboard, you are probably headed in the wrong direction. Next time I will cover the basics of Big-O notation.

Interview Questions

This time I am going to delve into techniques to successfully answer questions during an interview. But first let's cover some background info. Companies make offers to less than 10% of the people they interview. So don't get discouraged if you do not get that job immediately.

You should code solutions during an interview in mainstream computer languages. Whether accurate or not, the mainstream opinion is that Visual Basic and JavaScript are considered lesser languages. I know my VB friend would disagree. However he is not the person making the hiring decision. Code your examples in C++ or Java during an interview. You could also safely resort to plain old C.

Let's get this out. Questions asked during interviews are hard. That is the point. You might even ask questions that you have no chance of answering correctly. This may just be a test to see how you handle such a stressful situation. Look for hidden assumptions in the questions. Ask your own questions to clarify the problem at hand.

I got a lot more to say about interview questions. Look for a follow-on post very soon.

More on Interviews

The national unemployment rate in the US is 9.8%. In a neighboring state, the local rate is over 11%. You are going to need every competitive advantage to get a job in this economy. Let's start with the in-person interview.

I have heard different opinions on what to wear to an interview. If you are a guy, I strongly recommend wearing a suit and tie. I don't care if you are going in to be the french fry guy at McDonald's. Put on that suit.

A recruiter is out to get as many people hired, and to get you to accept the lowest offer. You should focuses on getting job details from actual employees of the company who will hire you. Bypass the recruiter by getting business cards from the people you talk with during your interview.

When you complete an interview, you should never accept a job offer on the spot. Give it some time. Everything about the offer is usually negotiable. Why not get a couple more thousand in salary? As long as you are respectful and reasonable during negotiations, they will not bar you from getting the job once they offer it to you.

Programming Interviews

The other day I spoke with a developer on my team. I knew she was doing double duty each day, and working Saturdays/Sundays. So I asked how she was doing. She confided that she thinks about quitting every day. Ouch. I know the feeling.

Some time ago I read this book on programmings interviews. I think I actually bought the book. Just recently I checked a book out from the library with the same title. I think it was an earlier version of the book from the year 2000. It still had some good stuff in there.

I want to share some of the tricks here. With this economy, everyone needs to be prepared to ace in interview to get a job. The best preparation is to actually work through some coding examples on your own. It is hard to learn enough by just reading a book. You must learn by doing.

Programming in general is difficult. The best way to find a job is to network. If you get a recommendation from the inside, you move to the front of the line. You should avoid headhunters that want you to work with them exclusively. Know that headhunters look out for their own self interests.

The most important factor in getting a job is the on site interview. Succeeding there is what this book tries to teach you. I will be blogging about this topic for a little bit. Next time I will start on what you should wear to your tech interview.

Signs of Trouble

I came home from work Thursday afternoon. It had been a tough week. So I took a nap. When I woke up later Thursday night, I had voice mail messages from work. They were requests for help with the software being delivered next Monday. I was working on a different task. But people wanted me to come in at the last minute to assist with this other effort. One request came from an executive high up in the company. So of course my answer would be yes.

My charter was to come in and fix some bugs detected by the customer. That sounded reasonable. I am an expert at speedy bug resolution. The first sign of doom was that my team leader said he did not know what bugs I should fix. He said he did not have the time to go through the massive list of defects and assign them to people. So my first task was to identify some reported defects that I could correct.

I spent some time reviewing all the open defects against our system. There were quite a few of them. I then let my team lead know which ones I could work. He agreed and I got down to business. Then there was another developer who “needed help”. I agreed to look at their problems. It was plain and clear. Their SQL was defective. I guess they did not understand what they were trying to query. I got their query fixed soon enough.

Then the next big bomb was dropped. They were trying to code some new functionality. This was being done on the Friday before a Monday delivery. Oh oh. My team lead called me up and asked me what I thought about the design. I told him it was one way to do the task, but it would break a number of other functionality in the application. I pitched a different design. Then I got assigned the task of running forward with the design. Oh oh again.

Of course there is a lot more drama associated with this diversion on this troubled task. I will save that for a future post. One thing to look forward to are developers too tired to build their software. Another is the never ending “we need another hour to make some more changes”. Stay tuned.

Rise of the Duct Tape Programmer

I have been hearing a lot of noise in the blogosphere about opinions on The Duct Tape Programmer. This is a phrase coined by Joel Spolsky, of Joel on Software fame. He writes about his respect of such a programmer. Let's first define what such a programmer is.

These programmers roll up their sleeves and just do it. They do not get weird bugs in their code. Their work is completed quickly. These programmers skip unit tests. They also avoid "complex" techniques such as templates, multiple inheritance, multi-threading, COM, CORBA, and C++.

This list really isn't a list of difficult tech. Those are just areas where an Astronaut Architect might get tripped up and not be able to deliver working software quickly. There has been a backlash against the love of such a programmer. Many have come to the defense of unit tests. And developers should be willing to learn new technologies.

I think that a duct tape programmer can use C++. They just might not need to use templates for implementing every solution. I also agree that multiple inheritance is not needed. However there comes a time when you need to start a background thread to do some work and not hang up the user interface. It is all about moderation. More thought is needed on this topic as it often depends on the situation.

Killer Bugs

For a while now I have been taken on my main task at work to help with other emergencies. Just yesterday I wrapped up the last piece of extra work. Today I was happy. I finally got back to writing new code for my main project.

The piece I was adding was pretty simple. It was a dialog with choices initialized from a database table. I was integrating this with an old application. So I followed the pattern I found there. There is a C API to get to the database. Behind the API is Oracle Pro*C code that retrieves a big chunk of memory with the database data.

Here is the funny thing. I kept getting an empty dialog. No problem. I decided to step through the code. Something was wrong with my initial count of the records. I fixed a variable initialization and got the correct count. Still no data in the dialog. Stepping through again showed that my cursor was retrieving all the data correctly. Ooops. I was not passing back the structure properly. Doh. I got to keep up with my C programming, especially when dealing with multiple levels of indirection in pointers.

Requirements and Analysis

The customer on our project has their own software acceptance team. Recently they have been finding a lot of problems with our applications. A few recent problems got a lot of visibility. Some VIP from our company said we needed to fix these problems. My team lead called me up and asked if I had any extra time in my schedule. I just laughed.

In the end, my manager informed me I had to drop what I was doing and fix the problems. The first one was easy. I disregarded some of the information that had been collected so far on the problem. I honed into the specific facts that pointed to a certain module not working. There were some protests until I demonstrated that previous information about the problem was incorrect. Next I went to another problem. This second one had a lot of parts to it. The first two parts were easy. They were coding errors. I fixed them with little trouble. The last part was difficult.

Requirements were gathered on some changes to the system. A technical customer helped specify the requirements. Unfortunately he started getting into the design of the solution, and those specifics were documented as part of the design. We subsequently ignored this external design when we actually designed the system. The came back to bite us. The customer's test team validated our implementation based on the letter of the documented requirements (as they should be doing). The problem was that the system did not match those requirements. I thought this was no problem. We could just change the requirements to match the implemented design. This proved a lot harder than it sounds. More on that later.

How Does Google Do It?

Legend has it that Google employees get 20% of their time to work on personal projects. This is 20% of your 40 hours week. Awesome. I always figured that Google engineers would be writing games, working on cool utilities, or doing computer science research.

Old Cringely shed some light on what Google people do with that 20%. You have to first understand the culture at Google. They peer review everything. And the result is very clean high quality code. Developers don't go to meetings. They let the managers do that.

Of course peer review has a cost. Many companies skip this step because of the time it takes to perform. Well get this. Google developers do the peer review during their 20% personal project time. Go figure. It does not take away from their normal duties. But it does steal from their creative development time. In the end it is for a good cause. They are working to improve the quality of their code.

Resume Writing

A buddy of mine may be looking for work pretty soon. Things move fast in the world of government contracting. So what's a fellow to do? Well I have read some advice from people who are doing the hiring. There are changes you can make to your resume to make sure it does not immediately get discarded.

Make sure you list the things in your experience section that you actually did. Nobody cares what your team or company did. What did you do specifically. This also applies to the technology section. Don't listen random tech buzzwords. List specific versions of technologies, and tie in how exactly you used them.

Have an introduction at the top. Also try to quantify your experience with numbers. How many years did you use the technology? How much money did you make your company. Here is another hint. Match you skill set to the ones they need to the current opening.

Now I have heard somebody recommend some sample code. I have done some hiring. Sample code did not impress me. If you wrong something really great, maybe that might be a factor. I am Oracle certified. You should list certifications like this. It counts more if you were certified by the vendor instead of some arbitrary training company.

Finally don't say you are an expert unless you truly are. Good luck job hunters.

Finding Good Jobs

I read an interesting discussion on a message board today. The topic was how to find a good programming job. A number of people said that you need to create your own company to ensure that. This seems a bit extreme. There must be some good employers out there in the software development world.

There were also some cynics in on the discussion. They came out and said that good programming jobs just do not exist. But these people were in the minority. You want to figure out how good a company is before you start working there. After you are committed, it is too late. You could try to get a feel for the corporate culture during your interview. This might be tough as they don't want to scare you away.

Employees are the best way to find out what working at the company is really like. You can try to get in touch with actual company employees via social networking sites like Facebook. This angle really boils down to doing your networking. You can even talk with people you have worked with in the past and trust. They will give you the low down on a company.

Sometimes you just need to be willing to relocate to get the best job possible. That does not sound fun to me. I am too connected to the local area. Finally here is an interesting perspective. The lower paying jobs are usually the better ones. I can somewhat vouch for this. When I made low pay, I hardly ever put in any overtime. And when I did, I was actually paid extra. Unfortunately I don't want to go back to low pay. This might not be an option.

Employee Retention

How do you keep your top employees happy so they don't jump ship? It is not my job to answer this question for my company. But I still want the good guys to stick around on my project.

Consulting magazine has some ideas. Give your workers a better work/life balance. Yes I know that is easier said than done. But you will benefit in the long run. I read that the average big dog in a company works over 55 hours a week. That's just the average. Not too fun. I thought my weeks were bad at 48 to 50 hours worked average.

Workers on the front lines do not feel appreciated. You combine that with overwork, and you have disgruntled employees. They will go elsewhere if they can find jobs. A new trend is that workers in the trenches feel that their companies are cutting back on training. Luckily my company does not seem to be following that trend. I honestly worry that I spend too much of my company's training budget. If I leave, the policy is that I have to pay back any recent training. I guess they got me now.

Overwork and Outsourcing

I read a couple blog posts about overwork and also outsourcing. Then I put the two ideas together because they are related. This is very relevant stuff.

We somehow got committed to too much work on our project. They are trying to get us some more resources. That is, we want to hire more programmers. But that task has a very long lead time. We have deadlines now.

Management continues to have the same short term answer for our problems. Work late on weekdays, and work weekends. Of course this is leading to burn out of the whole development team. This is part of a general trend of customers wanted more for less money.

Is a possible answer to our problems a little bit of outsourcing? I am not talking about moving the whole project overseas. But how about we augment our existing staff. We could only outsource to experts in the domain or technology. They would not come cheaply. But it would mean I get to go home at quitting time. Sounds good to me.

The Winner is C

A company that make open source tools did a survey of open source code. The result was amazing. The majority of code in open source projects is written in C. This was very strange indeed.

You need to look into what this company was measuring. They counted lines of code. Now that makes more sense. If you are just counting the number of open source projects themselves, then Java and Perl come out on top.

This does give me some more faith in the good old C programming language. With all the new hot technologies and programming languages, you would have thought C would be falling behind.

Battle and War

Today my manager pitched a solution to my scheduling problem. He said we could add the new task after my current task is complete. There were a few loose ends that I needed clarified.

My team lead wanted me to work on a different task after my current task ends. We negotiated that I could get help on this second task, so that I could still work the new task.

Things will still be tight. But I think I can manage. I asked my team lead for a little more leniency. However he said we all need to pitch in more time. The downer is that this needs to continue for a few more months.

I am a salaried guy. There is no extra pay when I work extra hours. Occasional overtime is acceptable. But it is not right if this extends forever. There must be other opportunities where you don't have to kill yourself at work. I won this one battle, at a high cost. The war on work is far from over though.

Jammed

Me and the guys scheduled a meeting with another contracting team. We had to lay down the common design for the new stuff both our teams shall be implementing. We decided to meet at our customer's big facility. The customer has a lot of rooms. But there is minimal parking. I was worried that I would not get there in time for a parking place. Luckily there must be a lot of people on summer vacation. I got a parking spot even though it was late.

I called up a coworker when I got to the place. Somebody needs to sign us in. You don't get badges unless the customer facility is your regular workplace. I got lucky, and the guy I called was just coming in. All of us got to the meeting room in time, except for the new guy. I gave him a few minutes. When he did not show, I started the meeting without him. The show must go on. It was a productive meeting. We discussed a lot of scenarios that I had not thought about previously. We planned a tentative action on how to handle all those scenarios. Then we negotiated the details of the database changes to accommodate the new features.

Later I found out that the new guy got stuck in traffic. They closed down the road he tried to use to drive in. As a result, he was very late. By the time he got to the customer site, there was nobody available to sign him in. He proceeded to return to our company's office. Not a good sign. We got to get this new guy some more contacts in the customer facility.

Training Scam

An old friend of mine had been doing contract programming work this past year. However he lost his job as part of some downsizing. He is collecting unemployment. There was some sort of opportunity for the unemployment office to fund some retraining. My buddy wanted to learn web programming. That sounded like a good plan.

A local company won the bid to train my buddy. They had a great plan on paper to team my friend Dreamweaver and deep Flash animation. My buddy said the unemployment office spend a few thousand on this training. There was just one problem. This training was a scam. My friend got some second rate training material. But there was nobody to instruct him who knew anything. Perhaps this firm was preying on people who did not know HTML from their ABC's.

My buddy did not have a personal beef with the owner of the "training firm". He just wanted his training dollars to go toward some real training. He tried to work with his unemployment office to blow the whistle on this scam. However they were busy covering their own behinds. Nice. If it were not so evil, I would advise my buddy to join the scammers. He actually has got in good with some of the employees of the scamming organization. However that road leads nowhere good. I could only wish him the best at getting another development job. Maybe then he can get his new company to sponsor some real training. Until then, keep an eye out for training scammers. Go with firms that have been recommended by people you know.

Mismanagement

A month ago, my team got called to headquarters to discuss lateness in the schedule. We were behind. And upper management did not know why. I broke it down to them. We have the ability to accurately predict how long it takes to do stuff. You need to schedule that amount of time for developers to do the work. If you do not, guess what? You become behind schedule.

At this meeting we showed how our estimate put the current task way behind schedule. The big bosses said that was not acceptable. My team leader came up with some tricks to slice the work so it looked like we were not that far behind. But this was just smoke and mirrors. We were then signed up to meet an ambitious schedule. I took up the challenge. After all, I am not a slacker.

This week a lower level manager told me I needed to take on a lot of new stuff. I told him that would put us behind schedule. He said that was fine. I told him we needed the blessing of upper management. It took a while to schedule a conference call from the suits at headquarters. However they wanted to know how we were getting into this situation. The top dog directed me to project the time needed to do the new stuff, determine the impact to the current schedule, and let him know who else could help us make the current schedule.

I did my due diligence. After a while I had a list of tasks with expected durations for the new work. Then I showed how this would have a direct impact on the current schedule, slipping it to the right. Finally I gave suggestions on how adding new people to the task would help pull the schedule in. Do you know what the response from the top manager was? He asked what my plan was to meet the current schedule without adding resources. That was precious. He mentioned that I could extend work days and work weekends to make it so. I guess the reason why he gets paid the big bucks. Go figure. More on this crazy situation later.

New Changes

Today we met with our customer and pitched the design for the new changes. This is an opportunity to help them see how the system will look with new functionality built in. It also let's them validate that we got the ideas right.

In the middle of our presentation, our customer asked if some new fields would be shown on all the screens. Previously I had not thought about it. But it made sense. It would not take that much effort to add the new fields everywhere in the displays. That change got added.

Later in the pitch, a developer on our team asked whether we were going to implement a lot of business rules to prevent some new operations from taking place. I said we were not. Another tester asked if we would put confirmation dialogs in. Again I said no.

It is a fine line to decide whether to add extra features to the software. You do not want to say yes to everything. That will add risk to us not delivering on time. I do want to add those things we should have added, but did not. It is definitely an addition if those items are things the customer needs and it will not take long to implement. I will fight against additions that add risk to the schedule. And I don't think we should do anything just for the sake of it. There should be a customer benefit from anything we spend time on developing. That's my two cents.

Non Trademark Battle

Phil Bewig has a blog called Programming Praxis. To tell the truth, I had not heard of it until today. He had previously tried to work with Alex Papadimoulis of The Daily WTF. However the deal fell through. Phil's beef was that The Daily WTF continued to use his blog name after negotiations failed. Phil ended up sending a cease and desist letter to Alex.

At first I thought this was a big site (The Daily WTF) trying to muscle out the little guy which is Phil. However this is a little more tricky on the legal side. Phil does not have a trademark on his blog name. So legally he does not seem to have much leverage. Regardless it is no fun when a big company takes your name and uses it successfully.

I deliberated on whom to side with in this case. The deciding factor was when Alex conceded and decided to stop using the blog name in The Daily WTF. Good move Alex. And for that good move, whatever the motivation, I will give Alex some link love. Phil just gets a mention in passing. I think he might have just had his 15 minutes of fame.

Never Again

Last week we had a disaster with our production system. About a month prior, we had switched over from FTP to a more secure mechanism to transfer files. The secure mechanism was a proprietary one from our customer. There was one problem with this plan. We did not have an environment to test this. The production environment became our test bed.

The first transfer worked fine. Everybody thought the transition worked out ok. Then we all got busy with other work. After a few weeks, the customer realized that the transfers did not work after the first day. Doh. The end result was that the customer lost a lot of money. I am afraid heads may have to roll for this one.

The top brass from the customer organization want an investigation as to how this happened in the first place. They want to be sure that it never happens again. Our company is stating that we will need a test environment to simulate production, otherwise we cannot guarantee anything. Now might not be the time to be making demands. Otherwise we may be losing this big customer. I will let you know how this pans out.

Busy at Work

Today I got in and the two developers I was working with were engaged in design. That was good. Gave me some time to check my email and voice mail. Oh oh. Some tester said he was having problems with my code. So I called him up.

The tester read some requirements and came up with a test plan. That is a good start. However he did not understand how the system worked. Not good at all. He got confused and decided the software must not be working. I spent a good amount of time setting him straight. That prevented some bugs.

Later I had a slew of meetings. One such meeting was important. Had to meet with a developer from another company to talk about how our software would interface. The tester from the morning the got confused again. I did not have the time to hold his hand, so I had to blow him off. Now I have a bunch of defects I have to answer.

Then late in the afternoon a new developer cornered me. He knew I was going on vacation soon. The guy was not up to the task of doing some design. He had a lot of questions. I told him I could only give him a couple pointers. He wanted much more. I told him to dig into the code and reverse engineer the source to figure out what was going on. Even that eluded him. He asked what that meant. I walked him through one example. Then I think he got it. I tried to escape from this crazy work day, but people were running after me telling me not to leave. Insanity.

Developer or User

The guy who leads my team called me up today. He read a requirements document and could not figure out what the heck our software was supposed to do. Luckily I am a domain expert on our system. I kept answering his questions, correcting his model of the work, until he finally got it.

Later my team lead called me up saying he found a way to shortcut the developer time needed to do the new functionality. We would just implement a process where once a year a developer writes a script to implement the specifics for the users for the given year. I had flashbacks of the last time we did this. The result was years of agony.

So I walked my team lead through the scenario. I asked him who was going to do the actual script writing. He told me a DBA would do it. Then I asked him how the DBA would figure out the specifics of the data to put in the script. He did not know. I told him the answer. They would come to us. We don't want to have the job of tracking down the information necessary for each year. We want to provide the capability for the end user to enter the data. It is their job to figure out the specifics that relate to their business.

I cautioned my team lead against creating a solution that requires developer work every year. It is no big deal to knock out a script in 30 minutes. The problem is that it may take weeks and weeks to track down the data needed to put in that script. We are always too busy in development at the end of the year. I even volunteered to work overtime to design and code the automated solution which gives the user a GUI to do this. So you know I am serious about the right way to meet this need.

No Volunteers

Today our customer discovered a big problem in our production system. As usual I got called into a conference call to discuss the plan of attack. Our manager had drawn up a 6 phase plan, ranked in order of importance.

The problem occurred in the back end part of our system. The guy responsible for that piece would do most of the heavy lifting on the resolution. However our manager asked who was going to do what tasks. He first asked our lead DBA what he would do. Essentially the DBA said he would do nothing as it was somebody else's problem.

Then my manager came to me. I volunteered for the lowest priority task on the list. It also seemed like one that was fun. My team lead said he would help if needed, but he committed to nothing. I tell you. These leads are smart guys. They make it sound like they are team players while they slip out the door and go home.

It seems like I got tricked into doing more work for this problem. It was for a good cause. Our back end developer is overworked as it is. So I reluctantly agreed to take another one of the six tasks required for completion of the problem. Now I need to come up with my own plan to get some of the new guys to start doing production support. Then I won't be stuck in these conference calls and taking work home all the time. Time to start planning.

Difficulty in Design

Right now my team is engaged in the design of the new changes for next year. The team consists of me and two new guys. Luckily the new guys are experienced in software development. We also have a documented set of requirements. There is just one problem. The new guys can't make heads or tails of the requirements.

Here is how the requirements were collected. The customer sends us the experts in the business. These people have made a career out of their work. They know the current system inside out. And they have a vision of the new stuff and changes they must have. Somebody from our requirements team transcribes what these experts say. The result is a document which makes a lot of sense to an expert in the system domain. To anybody else, including our business analysts, this document is gibberish.

Luckily I have been working on this project for a very long time. My job is to translate the requirements documents to the developers. I fill in all the expected knowledge that you need to understand the document. For example I show the new guys how the data flows through the system. I also decipher the secret codes that the document refers to. And I show how competing requirements have to work together, assigning a priority to them based on outside knowledge. The new guys are a little apprehensive, but I think we will hit our design document delivery.