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 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.
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.
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 complex software projects, so why don't you know this, why are you comparing this industry to plumbing and why haven't you adjusted your expectations to match the context?
Frankly, I've worked with hundreds of managers too and you sound difficult to work with. You have unreasonable expectations that are impossible to manage with facts.
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.
Software industry estimates are way off the mark compared to plumbing industry estimates.
People who don’t like this fact refuse to understand why software isn’t like plumbing.
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!
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.
Managers are the biggest cop out there are.
Difficult managers need to be terminated as well.
Amazing how a few bad senior managers can allow for so much bad behavior.
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.
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.
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'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.
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.
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.
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 a lot more rare than we think. 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.
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...
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.
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.
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.
You're talking about a platonic ideal that rarely ever occurs in real life, except for very simple systems.
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.
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.
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.
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.
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.
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.
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).
That's pretty much the gist of this shortie: https://littlegreenviper.com/miscellany/problems-and-solutio...
> 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.
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
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.