When it’s bad to be a good developer

Yaniv Preiss
6 min readMay 5, 2019

You’ve always loved computers, programming, technology, engineering, creating and bringing value.

You bought programming books as a kid, before the internet existed, and built cool tools and games. You found a tutor to extend and speed up the learning. In high school you took programming lessons.

You knew you would study computer science in university. You enjoyed it. You were astonished by math and the theoretical ideas as well as the practical aspects. You loved doing the tasks and studying for tests.

You set out to be the greatest professional you could be. You are a true believer in Kaizen — continuous improvement.

After graduation, you started working as a developer, excited. You were hungry and passionate. You worked overtime at your own choice, learned everything you could. You found mentors, learned techniques, languages and principles. You went to meetups and read book after book about development methodologies, theoretical problems, programming, best practices, databases, management and the history of the field.

You worked for different companies, did enterprise, consumer and web development. You developed features, suggested design and architecture, estimated time and effort, solved bugs and resolved incidents.
You paired with other developers, mentored others yourself, held workshops, conducted code reviews, introduced techniques and did presentations. You were always humble, you optimized for the benefit of the company and were proud of your work ethics, accountability and high standards.
You became proactive and self reliant, with good time management and ability to determine what is important and urgent and set priorities. You’re not dogmatic and use common sense.

After years of rigorously doing that, you bring a lot of value to any organization you work for, don’t you?

Or is it not a fact but rather subjective?

Early adopter

As an early adopter, you might get into uncomfortable situations. You want to start using new techniques that are better in some way — save time, are more predictable, result in higher quality, etc.

Examples include:

  • agile methodology
  • automated tests
  • a build server with build status
  • continuous integration
  • releasing features without QA engineers manually testing it
  • having 1:1s

But there is no interest. By definition, you’re an early adopter and most people are not. They prefer to continue to work the way they have been so far.

You will be perceived as disruptive, in the negative way. You’re nagging with your ideas and people resent as they have to reject. They optimize for stability and inertia, not for innovation or improvement.

Knowledge gap

You use terms like cyclomatic complexity and ubiquitous language, you know the importance of abstractions, decoupling and pragmatism.

While your only concern is the benefit of the company, for example, to write readable code that can be easily changed in order to reduce development costs, often people turn to think with their ego. You’re perceived as patronizing, want to sound smart. Most don’t like to feel ignorant and reject a learning opportunity.

Your high standards can be a constant source of bitterness. For example, you conduct thorough code reviews every time, but most of the comments are replied with “I think it’s fine” or “we don’t have time to do it properly”, instead of being disciplined and do the hard work.

Pointing out improvement opportunities

When suggesting improvements, people might feel they failed in some way.
For example, you know that working on four different features simultaneously is worse than finishing them one by one. Raising the issue after seeing that focus is lost and each of them is dragged is answered with excuses or “I can do it”. Not everybody has the same goals. Some like to show how much they’re doing in every given moment. Maybe they are right in the end, because they are perceived as obedient and competent.

Another example: imagine you introduce a build server with a realtime status of some sort. The team lead and the rest of the team refuse to use it and ignore broken builds as they are not aware of them at all (this could mean a code that failed to compile, or broken tests). Because you need a passing build all the time, you either ask the person who broke it to fix, or more vaguely suggest that the build is broken and needs to be fixed. This might cause resentment from the team lead and the team, because you’re nagging and waste their time with requests to fix a build that it not important to anyone else. Moreover, the personal request to fix carries implicit blame and an obvious failure.

Unsolicited mentoring

Another point of frustration for both you and colleagues, is when you try to explain something specific, teach a concept or mentor in general, but this is considered a waste of time. Just deliver features and stop the babbling. Some are not interested in growing, just in delivering, and again, if this is what they are measured for, they might be right. And if you were coding now instead of lecturing, we’d have more done.

Reminder

As an accountable professional, you keep notes and follow up. You also do it for others, because they don’t. You don’t interfere with their business, only regarding things that you’re involved in, and in a polite way. They are not as accountable and must be constantly be reminded, and most of the time the answer is “ah, not yet”, which makes them feel bad.

Future telling

You’ve seen so many cases and read about so many, that so many situations feel like déjà vu, and you how they will end. You want to save time and money, so you point out the potential issues and give arguments and alternatives, but cannot defeat the optimism and lack of responsibility for the company’s time and budget.

As Einstein said: “A clever person solves a problem. A wise person avoids it.” In this case, it’s not that you’re smarter than others, just more experienced and caring.

Why?

Questioning. One of the biggest problems.

You know that by questioning you will find the real reasons, context and motivation, and may be able to suggest other solutions, which are cheaper or are better in another way.

But questioning makes people feel interrogated, you challenge their ideas and opinions and they have to make an effort to come up with answers. No matter how nicely you do it.

On top of that, people sometimes think you’re asking just in order to ask, to be heard in a meeting or even worse — you’re asking because you have no idea how to handle the situation.

Heroes

“…and as always, kudos to Joey for delivering so many features this sprint!”

You know this developer who writes extremely fast code and delivers many features? But you also know that the reason is, his code is unreadable, has no engineering standards, no coding conventions and is not covered by automated tests.
This is of course a huge problem, as bugs are introduced, the code is hard to change, and is never refactored. Responsible colleagues like yourself are the ones putting the effort in refactoring, covering with tests and making the code readable. All the unsexy work.

Joey will continue to be regarded as the 10x developer and a great performance review, salary increase and bonuses, while actually slowing the entire company down. You never behave this unprofessionally as you don’t optimize for self glory, but for the company’s results.

To summarize, the time that you save your company is unnoticed. People cannot judge what didn’t happen.

Your efforts and availability are taken for granted.

The value you bring is not perceived as great. You’re just a developer, and not a fast one. You waste time one some vague best practices.

Despite the fact that you never want to hurt or offend anyone, or to be a jerk, you can be annoying to others, no matter how diplomatic and empathetic you are.

You’re demotivated as almost nothing you do gets a recognition. You optimize for the benefit of the company, not for yourself. You’re also demotivated as others don’t seem to have the same altruistic views and behavior.
You enable others to do better work in several ways, but you’re also slower because of that.

For others, ego plays a major role. At least bigger than knowledge, reason or the will to experiment. You’re never afraid to take the blame, ask for forgiveness or to be proven wrong, but it’s rare.

When other always get the credit, good performance reviews, raises and promotions — who is right here?

Assuming that karma is not real, is it stupid to be good?
Is being politician the real important thing?
Is it better to stop doing the right thing, lower the bar and optimize for oneself? Is it really the expectation?
Even if you wanted to, could you betray your conscience?

Effective leadership is learned
To learn more or reach out, visit my website or LinkedIn

--

--

Yaniv Preiss

Coaching managers to become effective | Head Of Engineering | I write about management, leadership and tech