Developer Efficiency

At the very essence of what we do as technical developer folk is take the needs of our business stake holders and turn those into 1's and 0's (and maybe in our lifetime we might figure out how to get 2 ) that business stake holder can run as software on our computers.  Any thing else is pure rubbish! 

So what are the attributes of an efficient coder?

Technical Aptitude

This is a baseline of becoming an efficient coder, when it's all said and done you must have a certain level of Technical Aptitude, that's not to say you need to be a "Rocket Scientist" however you should have certain skill such as problem solving, a general nature to ask "hmmm...I wonder how that actually works?" or "boy that sure is some cool technology, I wonder if I could build that?".  I think this is something you either have or you don't.  Not having it is not a bad thing it just means this type of work may not be a good fit.  I know any time I try to do something creative with any sort of graphics problem, I can spend 3-4 hours on trying new things and in the end it probably looks worse that when I started.  This isn't a bad thing, but the sooner you can recognize your weaknesses, the sooner you can find other people around that complement your strengths that make up for those weaknesses.

Memory

As a developer there are just too many different technologies that could be implemented to solve a problem, too many Languages and API's to learn, too many object models, too many command prompt arguments and keywords, you get the idea.  The more of these you can stash away and bring to the fore-front when necessary the quicker you can continue developing and not doing discovery.

Perceptiveness

Being able to read between the lines and think to a long term strategy is important when developing your solutions.  I see Software Development as chess match.  At any given time you are presented with a certain set of facts or knowledge, each time you sit down to design/code the moves you make have a major impact in how the pieces get moved and sets you up for your next designing/coding session.  I've just seen too many software efforts take the fundamentally wrong approach early on, and those projects never really recover.  Although an extreme example, let's say you wanted to write a simple contact manager, do you think you would start writing this in Assembler?  How about some sort of auditing function where a copy of all items was made into a database every 15 minutes, then a process was run to detect and report on changes, this was a real world scenario where a developer worked on getting this process working for about four weeks, and never did...the efficient coder made the correct chess moves and had implemented in an afternoon.  I see this is a very common problem in software development.  Do you start coding before you have a true understanding of the problem you are trying to solve?

Attention to Detail

This is a really hard one for me, coming up with creative solutions and looking at the big picture sometimes blurs some of the details.  What's interesting is that when I'm doing low-level programming such as embedded systems development, my eye for detail is very sharp...go figure...to be a efficient coder means developing system with little or no bugs.  The challenge here is that if you pay too much attention to the details, you may loose site of the big picture.  Coding something that implements the fundamentally wrong solution even if perfect and bug free is worth little to no value.  I think this is one of the bigger areas where we can use technologies, tool and processes to improve our efficiency.  After all computers aren't very good at creativity however they are extremely good at the details.

Experience Level

I think by far the biggest impact on this ratio is the experience of the person doing the development.  This experience is not just in the actual programming languages such as Java, C, C++, or the Software Development Life Cycle/methodologies, but to an even greater extent programming a wide variety of business processes.  Just as with software, certain things can be "abstracted" the same is true with business processes.  This experience also helps facilitate the conversations with the business stake holders, the more you understand about business in general, the more time you can more quickly get to the specifics of what makes this problem unique. 

Experience only comes with time.  You can do certain things that may not seem that important, but really are.  There is no substitute for spending time with the business stake holders even is you just sit in the room and not contribute anything.  That is not to say they should have a direct line or to influence your day-to-day scheduling.  But as a manager early on, I used any possible opportunity to get the developers in a room with the stake holder.  When doing embedded systems work it was always a good reminder going to the field and realizing that in the real world when my software is working it's not just a little LED that comes on at the right time but it's actually a 20 ton rock crusher that would be very bad if it came on at the wrong time.  It puts everything you do in a different perspective.  How often do you have actual conversations with your business stake holders?

Passion

What really differentiates you as an "efficient coder"?  Do you really just plain and simple love what you do?  Or are you just coding to pick up a paycheck?  Life is just too short to spend the majority of it working in a job just to pickup a paycheck.  If at a certain extent you have qualities mentioned above and your are passionate about taking the needs of the business stake holders and turning them into the 1's and 0's in exactly the right order as efficiently as possible (what ever that means on your particular effort) the chances of you being an "efficient coder" are pretty good!

Are you an "efficient coder"?

- ec