Software developers are a smart bunch. Smarter than average, I’d venture. (Patting myself on the back, here, cause I am one.) Seriously though, here’s my reasoning: computers are the most complex tools on earth, and we the software developers tell the computers what to do.
Despite being smart, however, we developers are sometimes frustrated in the business world. And I believe that, like almost all frustrations, this stems from feelings of being ineffective or misunderstood.
I think there is a simple explanation-a common set of flaws shaped by nature and environment-that explain why this is the case. The main theme is that we have developed one-dimensional work habits, and to solve this, we need to learn to think and work in different ways when the situation calls for it.
Here are our flaws:
Like mastering an instrument or writing a book, mastering the details of a computer requires a lot of time spent alone. As a result, we are trained to solve problems as follows:
This individualistic style of working isn’t always a bad thing. Being able to work by yourself on a task for a long time is a valuable skill. It is a problem, however, if this is the _only_ way that you know how to work. Why?
Business applications generally require a team of people to create. If you can only work alone, it means that you don’t trust a team.
Not all problems can be solved with a computer. This applies to even the most high-tech projects.
Too much “holing up” to solve problems does not exactly reinforce positive impressions to your coworkers. What to you may feel like dogged determination can look like avoidance or absentee-ism to everyone else.
How does a teacher know which students are the good ones? Tests. Teachers have a fair, objective, emotion-free way of measuring effort and intelligence. From kindergarten through 12th grade, school is structured so that an all-seeing judge awards you the exact credit that your work deserves. In school, all that mattered were results. Now, after many years of being in a system that focuses 100% on results, software developers jarringly enter a system that prizes effective communication of results as much as the results themselves.
It’s true that this is a transition through which every professional goes, but this transition is more difficult for software developers than other professions because the disparity between the work we produce and the results others see is large. Almost nobody sees the real work of a software developer except for other software developers. The hundreds of thousands of lines of code that form the results of a software developer’s time are paramount to his small circle of teammates, but they are gibberish to anyone outside of the circle.
What the rest of the business really cares about are the implications of the software developer’s work. What problem have you solved? What money have you saved? What problem will you solve next, how soon, and how certain are you that you will be able to solve it?
This flaw is painfully obvious to anyone who has left a conversation with a software developer thinking, “Are we talking about the same project? I’m more confused now than before.” For software developers in a business world, it’s no longer enough to study hard, keep your head down, and quietly put out good work, because the work is hidden. Whether you call it self-promotion or just effective communication, a software developer has to actively talk about their work in the context of the rest of the business.
You never have to convince or persuade a computer. It just does exactly what you tell it. Unless software is buggy, it should be deterministic: given the same input, it should function the same way every time. In fact, being deterministic is pretty much the main job of a computer.
As a result, there is a “best” solution for almost any computer problem, a specific lever to pull that will return the optimal result. Being a good software developer, to a certain point, means that you know how to pull a lot of levers. We create libraries and invent patterns to apply to common problems. There are so many prescripted solutions available that it’s considered foolish to invent one when there is already a well-known, pre-existing lever that solves problem.
People and teams, on the other hand, are inconsistent. Morale and mood are constantly swinging in orbit around every person and every team, propelled by accomplishments, criticism, and praise, and affecting happiness and productivity. Personal lives are an inestimable and uncontrollable line item on every project. With people, an effective approach one day can be useless the next.
For software developers who count on deterministic behavior, this can feel like lunacy.
The key is to understand that not everything is as precise as a computer. With people, the levers are less like levers and more like rudders. Pulling the lever won’t solve your problem, but (hopefully) it will at least point you a little more in the right direction. So the real work, and the fun, is to constantly try new approaches to solving the problems that you have. Maybe you will stumble across the right one, but more likely, your solution requires pulling a bunch of them and seeing what works in that moment.
Content © 2006-2021 Rusty Klophaus