At the intersection of two worlds
For a long time now I’ve had a habit of railing about “incompetence.” People who were “incompetent” made no sense to me. How could you consistently underperform at a task without improving? Last week, I realized I’ve been thinking about it entirely the wrong way. It’s not incompetence per se that upsets me, it’s carelessness. People who don’t care about things are completely inscrutable to me. How do you live if you don’t care? What gets you up in the morning if things don’t matter to you? Passion is what drives me day in and day out. Doesn’t it drive everybody?
I don’t think I’m alone in the software world when I say that. Most of the great developers I know are driven by passion, and when I asked on OnStartups Answers “What drives you?” a lot of people came back with passion. It seems to be a common theme, from Getting Real to education, that people who are passionate are more successful. My confusion of carelessness with incompetence wasn’t completely wrong: people who are passionate improve over time. People who aren’t can be comfortable staying at the same level of ability without significant improvement. Over time the two groups diverge, with the passionate people getting better and better.
I think software engineering runs the risk of losing the passionate people. What I love most about the Ruby community is its consistent theme of passion and experimentation. We have great characters like _why (or had him) and fun frameworks like Sinatra, where the web server tells you that “Sinatra has left the stage (applause).” Ruby people are clearly passionate about what they do, and that makes me feel like I’ve found my people. Passion drives me, and passionate people make sense to me. No wonder Ruby has so quickly become my favorite language to code in.
It’s hard to get passionate about something you’re no good at. Every time I’ve gone into a new field and tried to learn it, there’s a period I call bootstrapping. I know so little about the topic that I struggle even to figure out what I should be learning, much less actually learning it. It’s often not very fun, and I’m rarely that passionate about it. Getting over that hump, though, is so worth it. When you’re just starting out, you may not be passionate, but you’re not going to get there without caring.
Jacob Rothstein just wrote a great piece about Pair Programming in the context of the Hacker vs. Engineer debate. I’m suspicious that the “engineering” folks are the ones pushing pair programming, though. It seems to me more like a workaround for the inability of some hackers to produce cohesive, bug-free code alone. Put two people together and they’re far less likely to do stupid/crazy things. I don’t think the engineers suffer the same issue.
Getting it right is easy. What you do when things go wrong shows real talent.
I was in lab last week with my two lab partners working on a Computer Hardware Design project. They’re two of the top students in my department, seniors, and they even hold down part-time consulting gigs during school. By virtually every measure available, these guys are amazingly good.
Yet they can’t debug. We hit a number of snags during our lab, and they just started freaking out. Was the oscilloscope bad? It must be, let’s run calibration. Try the circuit on another ‘scope. Different results. Curse some more at the equipment. Rip out half the circuit and replace it with a pulse generator (which caused its own family of problems). Blame the “bad” equipment some more. Eventually, we went home with no results.
These guys are used to getting it right the first time, and that cockiness hindered them when things went wrong. They’re fast, sure, when they already know how to do it and nothing goes wrong, but how often does that happen? Frankly, if I were a hiring manager, I would be hard pressed to hire either one. From what I’ve seen, things rarely go according to plan.
How you handle things when they don’t go according to plan is when real talent emerges. Maintaining a calm manner, having patience, and methodically isolating the problem are critical to being a good developer of anything, especially software.
Most engineers have physical limitations. A civil engineer has gravity, tension, compression, etc. An electrical engineer has Ohm’s law, Maxwell’s laws, and other laws of physics. From what I’ve learned, Chemical Engineering is almost all about limitations, since much of what you’re doing is dealing with the elements nature has given you. Software isn’t like that. Software Engineers don’t really have physical limits beyond compute power and memory, both of which are growing exponentially.
Without the limits of other engineering fields, Software Engineering is a class of its own. Our limits are mostly our own abilities, so the discipline spends much of its energy dealing with the limitations of human programmers. There’s always the dream that someday computers will program themselves based on natural-language instructions, but that reality is still far away. Some human limitations are easy to correct: syntax errors, obvious bugs, and the like. The more insidious problem, though, is technical debt.
As a piece of software builds up over time, small mistakes accumulate. Bugs are introduced that can’t be easily reproduced. Architectural decisions make seemingly arbitrary requests nearly impossible, and the features that do get written end up hacking around those decisions. This is no big deal in the moment, but as time goes on, more and more of these little things accumulate. If ignored, they build up at such a rate that they can sink an otherwise healthy business. Thus, we software engineers must be constantly vigilant for the accumulation of technical debt, and management needs to be made aware of the issue.
I call it “technical debt” because this mass of mistakes ends up behaving much like financial debt. Like a teenager swiping a credit card without a second thought, some programmers never realize they’re creating it. After it has been created, it constantly takes time away from new features by forcing programmers to go back and correct or work around it. This diversion of resources can eat a big chunk of developer time if left ignored, much like “just paying the bills” is a struggle for people. Finally, paying technical debt off can be a huge challenge, because you must divert resources away from moving forward into what seems like a black hole. I see so many parallels between financial debt and technical debt that I would like to see a line item on financial statements for the technical portion of a software company’s debt.
Treating technical debt like financial debt gives business people a solid handle on how it works and what to do with it. If the engineering team can just provide reasonable estimates (and I think most programmers can do that), the executives of software companies will have a much better understanding of how to allocate resources. Why does it take you twice as long to get anything built this year compared to five years ago? Because we built up so much technical debt that we’re spending half our time dealing with it. Communication between business and engineering in the software world is notoriously bad, and introducing the concept of technical debt could go a long way towards facilitating that communication.
