A Difficult Software Developer so obsessed with achieving architectural elegance and code perfection that they forget their job is to add business value.
- Can mutate into: “The Extreme Underestimator” or “The Diva” Difficult Developer
- Dangerous when coupled with: “The Technology Enamored” Difficult Developer
- Often confused with: “The Sage” Underappreciated Developer
- Likelihood of fixing: None
- Danger to project: Extremely High
Relevant Podcast
Problem
Being a professional software engineer requires a constant balance of two competing forces:
- The desire to add business value (and get paid).
- The desire to write great software (and be proud).
The Idealist has completely ignored the goal of adding business value, and is instead exclusively focused on writing great software.
The Idealist Developer is normally highly intelligent, experienced, and professional. They do – in fact – know what they are talking about. They do actually know how to write great software, and if given enough time, they can create the perfect system. Their downfall is that they believe they have all the time in the world and are completely unconstrained, when this could not be farther from the truth.
Rather than making smart compromises based on business objectives and constraints, they instead focus on building a perfect system that they believe is best for the business. Do not mistake them with academics out to design something that they think would be “neat” or “cool”: they genuinely believe that the system they are building is best for the company’s future. It is the steadfastness of this belief that makes them so hard to fix.
They are particularly dangerous to a project because they normally hold sway over other key developers, as they are a developer’s developer: they represent ideal that developers strive for, and so easily gather other developers to their cause, as all developers want to be proud of the software that they write. In this way, they take the entire software development team hostage, and you are at their mercy. If you are lucky, they may begin to provide business value, but it will only be incidental to the goal of crafting great software. Essentially, you will only get business value when they are done, and they cannot tell you when they will be done, or how much business value you will truly receive. In truth, they are not concerned with being done at all, as it is the process itself – rather than the goal – that is fulfilling to them.
Solution
To recap on the characteristics of an Idealist developer:
- Highly intelligent, experienced, and professional.
- Genuinely believe that the system they are building is best for the company’s future.
In many ways, this is a very good employee, and if you look at the most innovative companies on earth, they will tend to have many Idealists on staff in their research and development departments. However, the best companies on earth tend to have three things most companies do not:
- A management staff just as competent as The Idealist, offering checks and balances against their technical decisions.
- An expectation that a certain number of projects will fail, which is just a cost of doing business.
- A large budget to continue to fund projects that are unprofitable.
If your company has these three things, leave The Idealist alone to do their work. However, if you – like most companies – do not have these luxurious accommodations, you have a real problem on your hands, as almost everything you do will result in disaster:
- If you outright fire them, the developers who were loyal to their vision may quickly follow them out the door.
- If you lay down the law, you may cause them to mentally disengage from the project leaving you without any technical leadership.
- If you leave them alone, your stakeholders will eventually get fed up with the lack of tangible progress.
To get The Idealist to change their behavior, you have to find someone who can convince them to change it. This person will need to demonstrate to The Idealist that they, too, know how to build a great system. This is important, as someone without technical credibility will simply be disregarded as not being capable of understand the genius of The Idealist’s design.
If someone with this credibility can be located, they will then need to slowly and methodically coach the idealist out of their idealistic way of thinking. This requires that a highly intelligent, experienced professional is willing to be coached out of doing what they know to be right. There is little chance of that, and therefore little chance of fixing The Idealist.
Being almost cured from being the idealist developer myself, I claim there is another possible solution. The catch is right between the concepts of “great software” and “best for the company”.
In The Idealist’s head the “best for the company” is defined through the “great software”. He strongly believes that creating a great software will automagically provide all sorts of good for the company. The “great software” in its turn The Idealist defines through his very own opinion on how things should be done from the technical side of view. Having him wired in such a way, it can be quite a struggle to convince him that a software made in some other ways can be great too.
Why is he wired like this? Well, if you hold a hammer, everything around you looks like a nail. As a developer, he solves problems by writing code. If it doesn’t help then the code is not great enough and he should write it harder.
How do you deal with such a mindset? You give him a broader view on what the “best for the company” is and how it can be achieved. You open his eyes on what’s going on with the company from the business point of view, you communicate company’s problems and priorities to him. You give him a greater picture, you carefully guide him through that picture, you show him a place that the software takes in that picture and you explain him how the software does (or does not) affect the picture.
What you are really trying to achieve here is The Idealist coming (by himself, this is very important) to the following conclusions:
1. The “best for the company” and the “great software” are not the same thing
2. Making a “great software” is not always the best way of providing “the best for the company”
3. Sometimes it is actually a “bad software” that the company is craving the most
4. If a “bad software” provides the “best for a company” then it is actually a “great software”
5. Every software is great if it provides the “best for the company”
If you do this right, you will mitigate the danger to the project and get a noticeable boost to the busines value you get from this developer.
My idea: I would suggest to NOT hire idealist full-time.
If there is no way an idealist can do anything “his way” in your company, yet he is a vital dev for your project, renegotiate and hire him for part-time. That way, he will have more time to focus on his side-projects, where he will be able to pursue his idealistic targets.
Working full-time as a dev is mentally taxing, and it’s even more taxing if you are perfectionist who tries to curb his strive for perfection.
In my opinion, it’s also a type of person who should never get any overhours, as it won’t push your project further. He will just use this time to tweak his code even more instead of focusing on tasks that bring your project closer to business needs.
As the article mentioned, The Idealist is a skilled developer. I’ve been a tech leader on a developmnent team, and I’ve had The Idealist on board, he was entirely manageable, and for the best – he was providing value to the software as his ideas were really great and were perfectly fitting software architecture that we were working on. The key to keep him at position that he couldn’t create too much danger to team productiveness was that I’m very experienced developer with many years of experience and I’ve been respected by the team I was leading, whenever I’ve seen any danger of losing productiveness caused by getting too focused on quality, I just pointed it. It wasn’t needed to argue on technical level, whole team was able to understand that we need to deliver and The Idealist was left alone with his pursue, he had no other choice but to get in line. Also “democratic” code review helped a lot forcing him to follow the arrangements made with the team.
As an idealist, I declare that good software is what’s good for a company. Non-coding managers are idiots and don’t know good software from an unmanageable mess.
Being a past idealist, I learnt things after coming on the other side of the business (delivering value on time with right cost). I believe that works with an idealist. Show him the other side. Ask him to help you make choice within given constraints. Tell him the constraints cant be negotiated (if that’s the case). And during the process encourage him by assuring that you value his inputs and thought process. That is very important.
I think it can be a good idea to put pressure on The Idealist. Not by being The Tyrant, he probably knows what he is doing.
Make him work so that other developers are dependent of his work, so that he has to deliver value to the other developers. He will make the job done. The Idealist won’t accept his performance to be judged poorly. Until the next urge request from the other developers, he will have time to focus on improving the existing code base. Working this way, The Idealist will always tend to be ahead of the requirements from other developers.
The best position for The Idealist is to know that no one is gonna tell him that he is slowing down the team and that he can focus on improving the existing code base freely. Being working in a team, the release will come at some point. He won’t be responsible for it as the others will take this decision, which is hard for him. It’s even better if you can have multiple developers agreeing on releasing so that he won’t feel the presure to be alone of releasing a project he feels incomplete.
That’s my 2 cents.
I’m an Idealist, I admit! But not 100%, I left smells here and there when I felt time was up and the product was finished. However, I would like to point out 2 main things:
– One should strive to learn as well as deliver value in his career, more so as a developer where your biggest value is your experience. I would rather (egoistic, I know) spend 2 hours on a task and learn something new than spending 2 hours on 2 tasks. This is obviously only true if I’m not late for the release.
– While it is true that good software by itself does not produce “best value for the company”, lack of good design or attention to best practices and principles will destroy any project, especially if it’s big and long-lived. I’m not the right person to tell whether a 10-months refactor will do better or worse to the economy than 3 years of releases that cost double time due to technical debt, but a salesman isn’t either. Technical perfection isn’t achievable, but having a relatively good and modular codebase is something that I think should be seen as valuable (and weighted with the same standard as new features) by stakeholders as well as the technical team.
Nice description by the way 🙂
“Non-coding managers are idiots”, “End users are idiots” When I hear this the team is in trouble. If mangers and users or customers are idiots, then we are developing code for idiots. My users and clients are rarely idiots. I used to rant like most devs about end users or managers, until I started creating my own projects to sell and realized the customers may not always understand but are not idiots or fools.
I’ll admit I am an idealist, after reading this.
This article doesn’t mention any of the motivations for me (or someone like me) to prioritize writing great software and why I feel that it adds business value: namely, ease of maintenance, bug prevention (easy vs hard to misuse designs), security, and other nonfunctional requirements. In my experience, most companies prefer pumping out feature after feature, and never going back and fixing their tech debt.
I sometimes feel like I’m crazy for suggesting to my team that we should go back and clean stuff up, when its causing issues moving forward…
I’m an older idealist and simply prefer being in an environment where my voice is heard and some portion of budget is spent on future state. It doesn’t have to be 100% or even 50%, but it has to be enough to keep me interested. I’ve done the maintenance/feature thing for literally decades. I know too much. Forcing me to write code in a dying codeset feels like death to me.
I have encountered less efficient type of idealist/perfectionist which I could call an “Enthusiastic Yak Shaver”. It is the person who will go and fix every problem he notices on the way to implementing a feature, and then recursively expand to fix any problems noticed on the way to fixing those problems. For instance, when implementing a service they may notice a non-critical bug in the dependent API, proceed to investigate how the bug got shipped and find a problem in the CI testing system, which in turn leads them to discover problems in the developer email notification setup, and so on. When the estimated feature completion date arrives, you will find that they have fixed some non-critical problems unrelated to the feature, while the feature itself is not done.
Unlike a regular engineer engaging in yak-shaving as a last resort when options are limited, an Enthusiastic Yak Shaver prefers jumps into yak shaving even when there’s an obvious work-around.
A very large company, the kind that can support Idealist mindset, can also support Enthusiastic Yak Shavers. They survive by obtaining good peer feedback from co-workers in other departments, whose systems they helped fix, and therefore provide a semblance of cross-functional benefit.
Unfortunately I had a manager who was an idealist, everything was burning up and we were revising PRs over and over again until it was perfect in his eyes (only took a month). Eventually everything blew up because writing code over and over again and a month for a single code review is not reasonable.
My advice for idealist is don’t work with them.