Developers Need Production Access

My old development team is hurting for resources. I got assigned to give them a hand. There were some production problems they could not replicate. They searched the source code, but could not come up with any definitive answers.

I spent the morning scanning the source code as well. However I have access to the production database. This allowed me to ensure the applications were behaving correctly. The other developers on the team did not have production access.

Now I can understand you don't want everybody looking at production data. But if you want your developers to be able to solve problems fast, give them read only access to production data. If can be the difference between solving a problem in a few hours, versus floundering around for a few weeks or a few months.

Going to UNIX

The big boss told me he wanted to me join another team on the project. They just lost a member and are hurting for help. There is just one problem with this plan. This team does C/UNIX programming. I am a C++/Windows developer.

Sure I guess I can figure things out. But it will be a slow process. I got my configuration management set up on my UNIX account. However I did not know the command to do a "find in files". I normally let my Visual Studio tool do that for me. Now I need to know the command line to accomplish that task.

Ok. I figured out how to search for a file. But now I cannot build a UNIX program. They even got a make file and I cannot get the darn thing to build. Must be some config settings that are missing in my environment. I don't want to waste the other team members' time. So I am slugging through it on my own. This is going to be painful.

Running Around in Circles

My boss told me to address a customer problem ASAP. I could not figure what was wrong. So I called the customer up directly. She said that they were following a manual work around process to load some configuration data. However the system administrator was running into some errors.

I investigated and found that the code required was commented out of the package. The fix seemed simple. I enable the code and gave it to my DBA. He had some trouble promoting the fix to other database schemas. I looked into those problems, made some code adjustments to the stored procedures, and again I thought we were good to go.

Another customer piped in and said that the whole manual work around was obsolete. Some new features in one of the applications had been made to take over the functionality. Doh! I had been running around for the last couple days to get this back end process running. But it turns out they did not really need that. Ouch. It even hurt more when I had to back out my changes. Let's hope the new functionality in the application takes care of our customer needs.

Programming Wisdom

I skimmed through a compendium of 100 things programmers need to know. There was some good stuff in there. I will summarize the top 10 or so right here.

The first is that technical debt may be inevitable in the short term. Sometimes you just got to ship. Be quick to remove it though.

Automatically format code. Do it as part of the build. I like the sound of that. We have some nasty formatting in most of our code. We normally try to fix this manually. Ouch.

The best methods are about 10 lines of code each. You should also limit the number of parameters passed in to a max of 4.

Good programmers care about the code they produce. Great ones care about the entire team's code. I am not sure I am ready to be one of the great ones. Honestly.

The best programmers are great because of hard work. There are normally not any shortcuts. No pain, no gain here. Once again I doubt I am ready for any more pain that I am already enduring.

Here is a tip I like. If you try to be productive doing code for more than 30 hours a week, you are working too hard. Try telling that one to the management team. Hehe.

Thou shalt learn to use the command line version of your tools. Period. All great UNIX hackers already know this. Time for the Microsoft crowd to catch up.

Testing should be done on the weekend. That is, you should automate your testing. If it takes too long to run, run it overnight. The weekend is a great opportunity to run the full suite of tests.

Too much logging is no good. We suffer from this ailment on our project. I try to cut back on the logging. However I find programmers just go in behind me and want to add the massive logging back in. You know we are in trouble when the database blows up due to massive logging.

Finally you should test your unit tests by injecting an error and seeing if it is caught. I tried pitching this idea once before. Management was actually receptive. Then I got real busy and dropped the ball. Time to reintroduce this one to the project.