This article is depressing, because it evokes a simplistic and dismissive management-style that I have found to be quite common.
Rather I find that people develop workplace behaviors that are rational responses to what they can see from their vantage point, and most of the time they have the organization's interests at heart, as well as their own, just as managers do. For example, sometimes, engineers procrastinate on releases and deliverables because they intuit negative consequences that will impact them more than others, once the release happens.
When workers are entrenched in workplace behaviors that are not aligned with the needs of the org as a whole, I believe it is important to start from a position that they have a good reason for behaving as they do. Then we walk them on the path from how they behave now, to how we agree they need to perform, by establishing a current routine that over time, shifts into a routine that is mutually aligned. It's a two way street of learning, where also bottom-up issues are addressed along the way, and incorporated into how the team functions as a whole.
Low-competence managers like to oversimplify the work of getting stuff done, because they want to feel like they have the answers, but in a serious endeavor that has domain experts in the team, insight-discovery does not happen primarily top-down.
I very much disagree with the premise that most of the time difficult engineers have the organization's best interests at heart. Most people (across any discipline) have very little regard for the "interests" of the organization that they're working for. Not because of incompetence or malice or organizational dysfunction but because most people just want to show up, do their time and get out to live their life with what little time they have left of their day. Maybe, at best, they care about the interests of some of their co-workers that they like.
Difficult engineers are difficult because they're difficult just like a difficult sales executive is difficult because they're difficult. I've worked in great companies and terrible companies with great people and difficult people. The reason difficult people don't survive as long at good companies is because the organization has the breathing room to get rid of them, whereas in a chaotic mismanaged organization there's still a framing in which a difficult engineer is valuable -- because mismanaged organizations aren't considering the long term implications of difficult employees, they're focused on answering "can this person help put out our current fire?".
Difficult engineers are given far too much room to be difficult because we're seen as geniuses who just need tending to. We should show employees kindness and support them in doing their best work and growing to benefit the organization, but we should not try to fix difficult people. If you're a manager dealing with a difficult engineer, you can be sure every one of their co-workers hates them and is making their life worse.
Terminate your difficult employees, don't change the number of points allocated to a sprint.
> Most people (across any discipline) have very little regard for the "interests" of the organization that they're working for. Not because of incompetence or malice or organizational dysfunction but because most people just want to show up, do their time and get out to live their life with what little time they have left of their day. Maybe, at best, they care about the interests of some of their co-workers that they like.
Why does fulfilling your contracted role not align with the "interests" of the organization?
If by "interests" you mean giving more than what you were contracted to do, then that does qualify as a dysfunctional organization in my book.
Short sighted decision making that doesn't account for the larger ecosystem. Sloppy code that barely meets the requirements. Zero coordination on a release that clearly left another team scrambling because it placed significant load on their service/ introduced a disruptive user story/ broke or delayed another team's clearly announced pending release.
The list goes on, but the bottom line is that many folks will be happy to optimize for their personal "local minima" but literally harm the organization in the process.
"local minima" is entirely a function of what processes and requirements are in place for code to be accepted. In a well designed engineering org, the "local minima" and "optimal" are indistinguishable from each other, because you only let through fully tested code that passes the hopefully many CI steps you have and has also been subjected to extensive code review, QA, etc.
If the reviewers and QA folks are doing their job, nothing like what you're describing should get through, and true "problem" engineers are simply those who are never able to get something through.
When this falls apart it is invariably leadership's fault for writing bad tickets or not implementing proper CI, quality control, or testing practices, or not allocating sufficient time and resources to the code review process.
And this stuff is only becoming more important as we integrate LLMs into our workflows...
All of that said, engineers are not static -- everyone is learning and changing all the time, so "problem" engineers after you've eliminated the above are simply people who have a ways to go before they change enough to become effective in your org (or, quite possibly, your org and its processes have a ways to go before more than an extremely specific type of engineer can become effective). Then it's just a value-prop of "do we think it's worth it to wait it out for this particular employee" because they're always learning and leveling up.
Other problems, like dishonesty, not doing enough work, not appearing to level up, honestly all come back to comp/benefits/company-culture. I genuinely believe that a good manager with sufficient resources can get good engineering work out of literally anyone, given sufficient time and (possibly quite high) resources.
And sometimes, the employees that require the highest investment in that regard can have a very high return when they finally do level up. In fact, I find that a really good predictor of success is simply ambition to level up. I care about that much more than I care about raw skill at the time of hiring.
Of course what you are saying is true but there is more nuance here. The fact is that regardless of architecture, requirments and test cases the engineer is going to make lots of small decisions, and if they are not motivated to make good decisions for the benefit of the org then there will be consequences that maybe could be mitigated but will still impose significant costs. So the fact remains that these engineers need to exit the org.
Every time I read a variation of the "for the benefit of the org" phrase I cannot help but laugh at the absurdity of it.
Do I own the org? If I produce 5x more, do I get rewarded 5x more? What about the other way around: will the org work "for my benefit" every step of the way?
Folks, most people work where they work because they have to. You work or you starve, that's the deal society gives us.
So many clueless managers buy into this crap and go on to become horrible managers "for the benefit of the org".
This phrase is completely nonsensical because it implies that the employee, that has no real stake in the company (no, stock options don't count), should be altruistic and work in the benefit of the organization above his own interests. I say above his own interests because if the interests of the organization and the individual's were aligned, this would be a non-issue.
The reality is that the absolute majority of organizations don't want to fix their incentives because it's cheaper and easier to label people "difficult employees" and fire them. After all, we're all replaceable.
Anecdotal but I've never come across someone that was actively trying to harm their employers. Even the ones labelled "difficult". It was always about bad incentives from the organization.
That's a big mischaracterization of what I wrote. No, it's not a binary choice between professional or not professional. This kind of simplification is exactly the type of harm the original article reinforces.
If you wanna tout around "professionalism", at least explain to all of us what that entails in your world view. Because, for me, someone that does what they're paid to do is professional with or without a blind sense of loyalty to "the organization".
This is also why I believe after many many failed iterations and variations of capitalism, we will arrive at worker-owned co-ops winning in the end. It is the only way to truly align interests while still working within this ridiculous capitalist framework.
The fun part is the union leader becomes the CEO, gets elected, etc.
> The list goes on, but the bottom line is that many folks will be happy to optimize for their personal "local minima" but literally harm the organization in the process.
Yes, because doing exactly what you're supposed to, exactly how its asked, and then clocking out "harms" the organization. No one has passion for your CRUD app for dogs. Everyone wants to make money, go home, and live their lives.
Maybe the managers should write better specs that capture the company vision instead of this dysfunctional bullshit we call agile. Agile creates the drive to the local minima. I don't care about anything happening outside my bubble and have been gainfully employed for decades now. In fact, everything you said can be solved by BETTER MANAGEMENT:
> Sloppy code that barely meets the requirements.
Not the developer's problem. Give me 2 sprint points and shitty specs you get what you wrote. I'm a squeaky wheel. In every company I've worked at I learn to shut up because asking for sprint points to double to in order to insure good, clean, testable code (not "perfect code") is looked at with ire because, allegedly, developers are just people who want "perfect everything" and without "proper management" they will end up rewriting the entire operating system every ticket. The result is garbage in garbage out. Give me a day to finish a ticket with tests and you're going to get a rock bottom solution designed to fit the exact use case, no more, no less. No matter how many "I told you so's" I give I've never been able to get a manager to understand why the alarms going off are related to their shitty decisions months prior.
> Zero coordination on a release that clearly left another team scrambling because it placed significant load on their service/ introduced a disruptive user story/ broke or delayed another team's clearly announced pending release
Sounds like the management should be coordinating releases between teams because they have a broader perspective on the ecosystem. You know, MANAGING the systems.
Your entire post reeks of the entitlement of an all-smiles CEO that uses the word "family" as a comma.
Yes these things happen, but in my experience it's about incentives set by the environment.
When short term gains outweigh long term gains, short sighted decisions will be favored.
When nobody really cares about quality, people ship sloppy code. See the broken window parable.
When rewards are given for shipping fast and not thinking about the whole picture, teams will ship without caring about other teams.
I acknowledge there are outliers that really do not give a f***, but those are rare. Personally I have yet to find a real "difficult engineer" in all my 15+ years in software. What I have found were dysfunctional organizations and managers that set the wrong incentives then fail to comprehend the ramifications.
> Ive found way more difficult managers than difficult employees in my career.
Yep. They set the tone. And if the manager's tone is not one of honesty, the ICs will intuitively not continue to be honest. Because they intuitively know that honesty will get penalized.
> but because most people just want to show up, do their time and get out to live their life with what little time they have left of their day.
I feel like this is overstated. Yes, ultimstely the job is just a job and most people have other things in their life. However its hard to devote 40-ish hours a week to some cause without starting to identify with the cause. In my experience most people do start to care about org goals, or they go crazy and get burned out spending so much time on goals they dont care about.
Generally people have a work ethic and want to do good work that gets recognized as such. So it's somewhere _between_ "just to get paid" and "align with company goals".
It absolutely sucks if you want to do good work and that doesn't align with company goals or doesn't get you paid (since most people need money). Those three things are not always reconcilable and I have seen how people can break if this creates an area of tension.
> It absolutely sucks if you want to do good work and that doesn't align with company goals.
It's particularly bad if you otherwise love your coworkers, your immediate manager, and what the company does enough to stick around indefinitely, but come find you're never actually allowed the opportunity to "do the right thing", because there's instead just always something else more pressing pushed on you. You'll never get the chance to fix the big problems that you see solutions to. You realize that for everything else you appreciate about your position, you're still just a cog in the machine. Then you feel depressed and slip into some negative developer stereotype.
> because they want to feel like they have the answers
A huge pet peeve of mine: I ask a really difficult question that might be impossible to answer, then someone interprets it as needing ANY answer (rather than a correct answer) and they just start talking. Or they answer the surface level question but don’t understand how much deeper it goes.
Then if you respond to them to clarify they didn’t answer your question they either try again or seem wounded/hurt/offended when what I want them to come with curiosity and ask enough questions to make sure they understand the full scope of the question.
In the book Multipliers one of the things they say is that managers should be responsible for asking the right questions (rather than thinking they need to have the answers).
> A huge pet peeve of mine: I ask a really difficult question that might be impossible to answer, then someone interprets it as needing ANY answer (rather than a correct answer) and they just start talking. Or they answer the surface level question but don’t understand how much deeper it goes.
It's funny how many HN comments fit this mold. Which actually makes this site very entertainig, because there's not that many other sites where you can hear utterly deranged opinions about things you know about :D
Indeed. In the thread, we see that when people don’t understand something, rather than recognize that, they wrap the territory beyond understanding with superficial word wrapping. I guess it’s an intellectual/social strategy to economize mental load and also project confidence, but at the cost of curiosity and awareness.
> Difficult engineers are difficult because they’re difficult
It’s a statement with no information. Just a declaration on an intellectual map that says I don’t go past here.
"I use the term "difficult" to differentiate between those employees where everything is going smoothly, and those where more effort is required."
... apparently "difficult" software engineers are those that might require the manager to do ANY WORK AT ALL.
Seriously, if this is anything to go by, managers of non-difficult software engineers could be replaced by a cardboard cut-out ... which would be a major cost saving.
The article matches my observations that I've seen across several teams and several companies over the past 40 years. I've seen these people everywhere.
The fact is these people exist - and they can derail a high-performing team. Some, such as the Lone Wolfe, are particularly toxic to a team. Most of the others the team is able to recognize and work around them. The Lone Wolfe? Management must deal with them. They're the most destructive individuals.
I've been such a 'toxic' person on some startup for couple of years.
Impotent management was unable to setup code style conventions and outsourced all decisions to the team in 'democratic' way. Weak inexperienced developers always voted against well known practices and started to invent something ridiculous all the time :D
Does it matter whether you are right? If people do something in a way you didn't prefer, and it goes well, can you admit that your preference didn't matter? If it goes poorly, can you admit that you may not know that it would have been better if your preference was honored?
Developers and management both need the opportunity to try new things and make mistakes.
Being the voice of wisdom doesn't necessarily mean being the force of wisdom.
As I said, I've been developing software for the past 40 years. In that time one thing I have discovered is code style conventions is 100% a waste of time. Actually, I take that back - they're a 110% waste of time. Why? Because code style conventions have nothing to do with the performance or maintainability of the code and wasting time on such trivialities is destroying team morale which is destructive to productivity.
I haven't done any code reviews for the past 15 years. Why? They're a complete waste of time. I follow the "show me, don't tell me" mantra. Show me evidence your code works. That evidence is in the form of repeatable tests. I'm going to review the quality of your tests - did you test the so-called "blue sky" case and a few of the most obvious error cases? Cool. People are stunned when I don't even look at their code. I don't need to.
Does this bite the team in the ass every now and then? Sure, but not as often as you think. When it does it's a teachable moment. I now have a younger engineer wanting to be mentored by the old gray-haired guy how they can improve. I always tell them there's no single best or right answer - engineering is all about trade-offs. I teach them how to recognize those trade-offs and how to evaluate them. As time goes on they come to me while they've evaluating the trade-offs and I can help them work through it. This is far better than any code review checking for style conventions. Besides which, architecture and design matter far more than any silly code style conventions.
Some people just have difficult personalities, period. They're difficult from the get-go, they were difficult before they entered to workforce. They're not a result of their work place, to put it that way.
It wouldn't be a HN thread without the top comment being something like a middlebrow dismissal (the comment you're replying to).
Of course there are cases where the company can influence a certain type of behavior, but I've seen several of these stereotypes in companies which definitely did not "cause" it. Pretty much everyone can be difficult now and then, but there are definitely quite a few chronic cases out there.
Personally I use a show-don't-tell approach, and what I saw in the article was a few words at the beginning telling how we should trust people, followed by a giant section of showing how we actually don't.
The author went from "trust them to do the right thing" to "Set clear deadlines and regularly check in on their progress. Make them accountable for those deadlines" real fast
The opposite is “set vague deadlines and don’t check in on their progress.”
You’ll be accountable for team deadlines regardless - would you rather be allowed to sail over a deadline you didn’t know existed and be reprimanded for it by higher ups, or have a clear picture of deadlines and someone checking up on progress?
I am always incredibly surprised when people are surprised when I miss deadlines.
I said I was going to do it for the following (rather good!) reasons.
It is around that time when I am usually informed that I have zero autonomy over such decisions.
Now I know.
If I am not allowed any autonomy then could you please be explicit and upfront with all the trade-offs I am allowed to make, all the risks I am allowed to accept and the technical debts I am allowed to accrue?
Oh, don't be a perfectionist!
I am not - I have no autonomy on such decisions. Here's a list of known defects - tell me which ones I am allowed to ignore.
Аpparently I am a difficult enginer. Meanwhile the leadership is outstanding.
I've had 1-1's with about 500 engineers between working with them or interviewing them. I honestly think you are being difficult under this described situation, yes. I mention the number only in case you'd trust that you are not alone in thinking this but:
A competent professional understands from context the amount of time available, the absolute requirements of the role (ie regulatory compliance, internal engineering practices, whatever), and their own sense of "would I put my name on this crap" and then says a number.
If you hire a plumber he doesn't ask you if you give him 2 days or 2 weeks or if he should use copper or plastic or if he should bring his good tools or his bad tools. He just gives you a reasonable estimate and does a reasonable job. If he is asked for better, he knows how to make it more robust by spending a little more time or using better materials, the same way you should know to make it scale up to more users or spend time refactoring into some better abstractions. But there is a bar that he won't go under and no amount of company policy or explicit bosses are gonna fix the fact that at the end of the day, it's a professional's job to predict how they are going to go about their work and how long they think it'll take.
A competent project manager in this undustry also understands that software engineering is not plumbing.
And the variance in effort due to lack of standardization, technical intricacy and hidden complexity is orders of magnitude greater than plumbing so our initial estimates always suck. Most competent proffessional in this insdustry know that nobody knows how to do accurate time estimates on delivering complex software projects, so why don't you know this and why do you want me to lie to you about the crudeness of my estimates?
Frankly, I've worked with hundreds of managers too and you sound difficult to work with. You seem to have unreasonable expectations that are impossible to manage with facts.
I'd say that my teams tend to meet the goals we set for ourselves (lol biased) without spending that long on estimation. We have an idea of our normal throughput and can use that to be somewhat accurate, and nobody gets shit if something ends up being harder than what we thought it was from our investigation, sometimes there are truly new things that are harder to predict. In those cases we take smaller chunks out of the big problem and focus on that first.
Anyway thanks for the advice on how it came across, I struggle with how to give this sort of view on things without coming across judgemental and I guess I failed here again, but I was honestly trying to say that I've seen your view shared before and I think the difference between you and other engineers that tend to be easier to work with isn't skills, it's just a slight difference in approach. But there's many different dystopian teams with unreasonable expectations for me to say that I'd think any different had I had the same teams and bosses that you had. Take care!
Eh, for the majority of cases, software engineering is more like plumbing than like R&D. There are exceptions, like building a new DB, or similar. But if the tools you need to solve the problem are postgres + Django + react, there shouldn't really be that much hidden complexity for you to uncover.
So the domain model has already been made explicit and is implemented for you? All the design choices have been removed from you? You don’t have to do any actual software engineering - just extending business logic? That’s nice.
Your trivialization of the complexity is laughable.
The tools are "standard". The data models aren’t.
It's like plumbing alright. With random, unknown substances in the pipes.
Plumbers don't get to decide how the pipes were laid out in the houses they come and work in, either - technically those are unknowns that could throw off a job. Doesn't mean it would be professional of them to insinuate that the variation in each individual building means they can't give a good faith estimate for a job.
> I am always incredibly surprised when people are surprised when I miss deadlines.
I relate with this. Any skilled engineer worth their salt know that there are going to be a lot of unknown unknowns. Slippage is 99% guaranteed.
What surprises me is that managers are surprised at slippages. Like, did they ever engineer anything in the past?
> If I am not allowed any autonomy then could you please be explicit and upfront with all the trade-offs I am allowed to make, all the risks I am allowed to accept and the technical debts I am allowed to accrue?
This question is the one that irks managers. Because in reality, they want to be "own" only the successful decisions, not the failures. And they dare not ever clarify anything because it may end up leading to a failure. BUT, they also want to penalize you for the failure.
Agree fully...I have found working in corporate America, that it is quite effective at stripping off branching talents or 'non-core' skills of a bright person and making them form a lane of specialization. Essentially stunting their natural curiosity and desire for more knowledge, malforming them into a one trick pony.
Woe is me, I’m a cog in the machine but I want to be the machine itself. I think the technology industry is detached from the rest of the world.
Programmers and mathematicians train to be “the utmost correct” and everyone thinks they figured it out. On this quest for hyper-optimization, hyper-correctness, and so on, EVERYONE has become ridiculous.
Rather I find that people develop workplace behaviors that are rational responses to what they can see from their vantage point, and most of the time they have the organization's interests at heart, as well as their own, just as managers do. For example, sometimes, engineers procrastinate on releases and deliverables because they intuit negative consequences that will impact them more than others, once the release happens.
When workers are entrenched in workplace behaviors that are not aligned with the needs of the org as a whole, I believe it is important to start from a position that they have a good reason for behaving as they do. Then we walk them on the path from how they behave now, to how we agree they need to perform, by establishing a current routine that over time, shifts into a routine that is mutually aligned. It's a two way street of learning, where also bottom-up issues are addressed along the way, and incorporated into how the team functions as a whole.
Low-competence managers like to oversimplify the work of getting stuff done, because they want to feel like they have the answers, but in a serious endeavor that has domain experts in the team, insight-discovery does not happen primarily top-down.