Beware Of Your Arrogance

Dear new developer,

I wrote this post years ago, but it still applies today.

Ah, the arrogance of software developers. (I’m a software developer myself, so I figure I have carte blanche to take aim at the foibles of my profession.) Why, just the other day, I reviewed a legal document, and pointed out several places where I thought it could be improved (wording, some incorrect references, and whatnot). Now, why do I think that I have any business looking over a legal document (a real lawyer will check it over too)? Well, why shouldn’t I? I think that most developers have a couple of the characteristics/behaviors listed below, and that these can lead to such arrogance.

Just because you are good at something valuable (development) doesn’t mean that you are good at everything. I was blinded in my youth because I was good at asking questions, paid attention to details, and was good at creating logical constructs in my head. That is helpful in so many contexts.

But it is also true that almost every profession has as long, if not a longer, sense of history and as big, if not a bigger, well of knowledge than software development. So beware that your ability to probe, ask questions and solve problems doesn’t inadvertently (or worse, intentionally) dismiss the learning of other professions.

On the flip side, domain expertise (through lived experience or study) and software development is a powerful combination. You can model software such that end users can speak in the domain. You’ll be closer to understanding their problems.

Another issue with arrogance is that when you’re sure you know the answers (or have the right way to find them), you don’t listen to other people as well.

I was very happy to charge forward with whatever solution I thought made sense, and that led to suboptimal solutions. Both in the coding sense and in the sense that you have to bring people along. The best coded solution in the world won’t work if people won’t use it. So listen to your users and make sure you fully understand their worldview as best as you can before you charge ahead implementing solutions.



Potential vs delivery

Dear new developer,

Early in your career you are judged on potential. Frankly, this is because when you are young in your career, you don’t have much of a track record, so there’s not much else to judge you on.

This means that you can take more risks early in your career. You can shift around and explore different niches, whether technology or business size or domain. Each time you shift, you’ll bring over some relevant experience, but you’ll also be high potential and indicate a willingness to learn.

Companies have to train you on their process and their technology stack, and don’t necessarily expect you to ship on day one.

The older you get, however, the less you are judged on your potential, and the more you are judged on your ability to deliver. This is typically done by looking at your past accomplishments, as what you’ve done in the past is treated as a harbinger of the future.

While there still is spin up time (and the bigger the company, the longer the period; I worked at a large software company where people were surprised I shipped code in the first week) there’s an expectation that you slot in and pick things up more quickly when you are a more senior developer.

As you gain more experience, you have more human capital and are expected to deploy that capital on behalf of your employer.

Does that mean that once you’re a senior developer you can’t switch domains, tech stacks or company size? Absolutely not. But it does mean that you’ll have a harder time doing so and you’ll need to convince the hiring managers that your skill sets apply to the new venture. (There’s an entire book about doing this called What Color is Your Parachute.) You can always press the reset button and re-enter as a junior developer, if you can afford it, and if you can convince the hiring manager that you won’t leave the job as soon as you can find another one.

Take risks early.