11/03/2015 17:28:53

The other day I got asked by my boss' boss to share the "secret sauce" behind my productivity at work. This was an odd moment for me as over the last 17 years of my of professional life, nobody has ever asked me to do that. But it did get me thinking about it and that has led to me making a few notes on the subject that I've decided to share with the world.

1. Get intimate with your code base. All too often the developers I work with only have a skin deep knowledge of the product they are tasked with augmenting and supporting. This will only hurt your productivity in the long run. One of the reasons I like to take on as much work as I do when I start some place new is so that I can get familiar with the code base that I'm going to be working with. The bigger the code base is, the more commitment you'll need to come to terms with it.

   Nevertheless, developing an understanding of how things work in a code base will heighten your ability to change how things work in that code base. It will also allow you to fix bugs in a more efficient manner as well as reduce the risk of you creating new bugs. Take the time to explore and dig deep when you are working on something in an unfamiliar section of code. Don't get hung up on the "could haves", "would haves" and the "should haves". The code base is what it is. Bitching won't fix it. Only good old fashioned incremental hard work has a snowball's chance of pulling it off.

2. Your customer expects timely results. In my experience those results usually manifest in the form of releases and updates. On a longer running project you may fall back to demos and test environments as a way of showcasing progress. Nevertheless, every day should result in measurable progress on any problem you are spending time solving. Remember we are business software developers and business isn't content to wait for the "nerdery" to get its shit together.

   This advice becomes even more prudent when faced with bugs. Bugs are defects in the prior work you have delivered to a customer. Defects cannot be tolerated. If you receive a bug report for software that is in production or software that is about to go to production, resolving that bug report should be your absolute highest priority. Co-workers have marveled at and criticized the zeal I display when I get into bug hunting mode. The truth is that I consider bugs to be a sign of failure and wiping them from existence is vital for my mental health, at least for me. Obviously your mileage may vary here.

3. Don't get caught up in ivory tower bullshit. In our industry it is all too common to hear people rattle on about the latest "design pattern", "testing framework" or "development methodology". Here's a bit of truth for you: I don't know a single design pattern. I simply don't give a shit. As far as automation goes, I believe that at best it offers some limited value in particular situations, but I'm by no means a convert. My only development methodology is this: "Release good software in a timely manner".

   Obviously this advice flies in the face of certain principles that guide our profession. But you aren't going to stand out by following the herd like some kind of sheep. If you want to be a better developer, you've got to focus on the results. The best way to do that is to stay focused on the problem that your customer has tasked you with solving. Be sure you have taken the time to properly define that problem up front. Remember that regardless of what new technology or concept comes along, software developers were solving business problems long before it came along. While we scoff at ancient languages like COBOL or even old fashioned procedural programming concepts, the reality is that "It's a poor craftsman that blames his tools" or so the old adage goes.

   To summarize: If your approach doesn't directly benefit the customer, you are likely doing it wrong.

4. You are the customer's last resort. In other words, treat every issue as if it was something that either you yourself fix or it doesn't get fixed at all. I've spent a substantial portion of my career billing people by the hour for my coding services both directly and indirectly. I've legitimately found myself in this situation many times. This mentality is something that a lot of developers lack in my experience as deep down they know they can just call in the Calvary and get them deal with it. I say that with the full realization that I'm usually the Calvary.

   There is real value in conditioning yourself to rely upon yourself. This doesn't mean you shouldn't ask for help in certain situations but my expectation is that a seasoned/senior developer should be able to produce a viable solution for every single problem they are presented with. It might not always be the absolute best solution, but then again, the job of the rest of us is to lend a helping hand when that situation arises. If you at least take a real crack at the problem and produce a proposed solution before asking for help, you are definitely on the right path here.

5. Locally test. Does this one seem kind of obvious? Good. It should. I've worked with a lot of developers over the years and the dirty little secret that most of them share is that they don't locally test their work. They just code and deploy. Once I had a co-worker at a previous job compliment me on the motivation I displayed for getting our application running locally because "nobody else here has it setup locally". I was literally floored. That means all of the other developers aren't testing their work before they push it. That's absolutely ludicrous in my mind.

   This extends to bug fixing as well. When I receive a bug report, the first order of business in my mind is to try and replicate that bug in my local environment. Once I can replicate the failure, I can verify the fix. None of this is rocket science. When it comes to quality in software development I've found over the years that you either put in the time up front, or you'll put ten times as much effort into fixing the bugs after the code goes into production. Do you really want to skimp on this up front? I sure as hell don't.

To finish up, I'd like to offer up a caveat of sorts. Regardless of the advice that I provided, at the end of the day practice makes perfect. My father handed me my first software development book at the impressionable age of six and let me goof around on the family Apple IIe with it. That's where I got my start. If you do the math, since I just turned 36, that means I've been writing code for around 30 years now. It started off as a hobby but for the last 17 years it's put bread on my table. The long and short of it is that I've been doing this a very long time. Longer than most people seem to realize. I'm a firm believer that when children are taught skills and consistently develop those skills throughout the course of their life, they typically become masters of those skills.

In any event, I've found that the best way to improve a particular skill is to keep using that skill and employing a reasonable level of self criticism. Given enough time and effort, your skills and productivity will only improve short of a severe mental blockade of some sort. Bottom line: Keep on keeping on.