Five Reasons Why You Should Hire an Old Programmer
You should hire an old programmer. It’s true! Sure.. older programmers are not going to work as many hours as someone fresh out of college. They have kids and spouses and mortgages and softball games to attend. They won't hang out at the office playing Xbox and ping-pong all night. They will not work 80 hour weeks and they will actually use their vacation time. And of course they cost more than young programmers. Despite all of those reasons not to hire an older programmer, you still should. For one simple reason: they are worth it. I know this, because I am one.
Old programmers may not be able to hold as much code in our heads as when we were twenty five but we have amazingly deep experience. We know that every system will grow to be bigger than one you can hold in your head — no matter how big your head is — so code holding isn’t as important as you might think. Instead, we know how to modularize. We are the mythical "10x programmers"; not because we code so much better but because we’ve already seen everything. We can pick up any new language because we’ve used so many over the years. We know the common features. Language concepts come into fashion over and over again. With enough years under our belts we can spot the similarities and highlight the differences.
“The bitterness of poor quality remains long after the sweetness of low price is forgotten.”— Benjamin Franklin
Old programmers have judgement. They know where to chop a system into modules that will be reliable and testable. They can tell from an architecture diagram where the likely bottlenecks will be. (Do you have big data or big data? It matters). They can tell you which technology to use for a particular project, and how to optimize for reliability, performance, or speed of development (pick any two). They know how to make good tradeoffs. Even if they never write a line of actual code for your project older programmers are worth their weight in gold. They understand how to build quality. And in the long run, quality means lower support costs.
“True knowledge comes with deep understanding of a topic and its inner workings.” —Albert Einstein
Old programmers have deep knowledge in specific areas. This knowledge helps them know where to look for bugs, and how to avoid bugs altogether. For example, I know GUI toolkits really well. I’ve used dozens of them over the years. I’ve been on the core engineering team of three (Swing, JavaFX, and SubArctic). I’ve built my own toolkits from scratch four times, just for fun! I know UI toolkits. I could write a detailed history of toolkits over the past 40 years (hmm.. perhaps I should write that up sometime).
When I work on a new GUI system I can immediately dive in. If I see three buttons shifted identically 68 pixels to the right, then I can immediately tell the bug is in one of three places (probably the global to local coordination transformation code). If you want to make a new component I can tell you exactly which extension points you’ll need. This deep knowledge of how UI toolkits work means I really can build apps many times faster than someone else. I have 25 years of muscle memory backing me up. My deep knowledge is about UI toolkits. For someone else it might be kernel drivers, or database indexing, or compilers. The point is that deep knowledge more than makes up for hours applied or raw coding ability.
A small team of A+ employees can easily out perform larger teams of B and C employees. — Steve Jobs
Old programmers are dabblers. While I’ve specialized in application and front-end development, I’ve messed around with the entire stack. I’ve written code for headless memory-constrained systems. I’ve built parsers, databases, and firmware; and even one really bad kernel driver. I’ve drawn graphics for demos and generated gigabytes of test data. I’m not the person you should hire to build a database or write firmware or illustrate your next website, but I’ve dabbled enough to understand how these systems work. This means I can talk to the people who are experts in databases and firmware. I know enough to communicate effectively with people in other areas. It is this communication skill which makes me a productive team member, not raw coding ability.
Anyone who is still a programmer in their 40s has to have developed some good communication skills. These abilities can be as valuable as their programming chops. A new API is worthless if it can’t be effectively communicated to the developers who will use it. Most large software projects fail not because of bad code, but because of communication issues.
So yes, we cost more and appear to work less, but we actually get more done. We can estimate properly and ship code on time. We build software with fewer bugs and the right amount of performance. We might build less code, but we produce more business value. And that's why we are worth it.
Speaking of which, why don't you hire me?
Posted July 2nd, 2017