The post and most of the comments feel kind of naive. Yes, these things are frustrating, but it’s your job. That’s what you’re paid to do. Nobody cares if you ship a hack if it “works”. Every single legacy project I’ve seen that earns actual money is full of hacks like that - it’s just the way it is, and a senior engineer should know how to work with that, how to communicate what really needs to be done and why it’s important. That involves dealing with management that doesn’t speak your language - learn how to do that too.
Ways to annoy your senior engineer
71–80 of 91 posts
Re: Ways to annoy your senior engineer
#72Earlier quoted context omitted.
> The best way to handle situations like this is to leave, quickly! If you find these situations frustrating, I agree. There is little hope of changing how software development is done in these companies. > Companies that operate like this don't last long, because someone else will come and out compete them. I take it that you haven't worked in many corporate environments. This is how software development is done in…
> I take it that you haven't worked in many corporate environments. I'm mid-career and I have worked in all different sized companies. That's why I explained how to avoid these situations. You don't have to put up with being a pawn, nor should you encourage others to put up with working conditions like this. Edit: I was in situations like the article describes twice. The first time was when I tried to start a company…
I'm only disagreeing with your assertion that companies that work like this don't last long. They do, and if they get disrupted by competition, this way of working is not the biggest reason for it.
Re: Ways to annoy your senior engineer
#73> [Senior engineers] keep things running, ensure projects get delivered, and prevent your codebase from turning into spaghetti. The good ones? They’re rare and highly sought after. I didn’t see much of the ”highly sought after” bit in the recent years. On the contrary, the job market looks employer-friendly and the strategies for recruiting senior engineers seem increasingly backwards. Or is it expected that good sen…
We make great layoff candidates because most of our code is something other people can take over maintaining. They keep the jackass who makes things nobody else understands.
In the jackass. Until now I thought I’m surrounded by people who cannot understand reasonably complex code. Currently I hope that both can be true at the same time. I’ll enjoy my job safety, although now more humbly.
Re: Ways to annoy your senior engineer
#74First reaction: Has this person been my coworker? I feel like someone’s been taking notes on places I’ve worked. Second: But OK, those ones about shifting priorities? That’s startup life. Sometimes you throw something out the door because a customer wants to pay you $12M if you can salve over that one pain point. You know darn well that hack’s going to be there until The Rewrite (which, if you’re lucky, will never co…
If you're following the bullshit that is SAFe/"Agile" at a startup, you're going to fail. Capital-A Agile is project management for dummies that won't learn about things like GANTT charts, what "slack" means in links between dependent tasks, what a "critical path" is or how to analyze it, let alone things like S-curves and earned value.
Kids these days barely know how to make a proper waterfall model before they start writing. It’s disgraceful.
Re: Ways to annoy your senior engineer
#75First reaction: Has this person been my coworker? I feel like someone’s been taking notes on places I’ve worked. Second: But OK, those ones about shifting priorities? That’s startup life. Sometimes you throw something out the door because a customer wants to pay you $12M if you can salve over that one pain point. You know darn well that hack’s going to be there until The Rewrite (which, if you’re lucky, will never co…
I have worked at places that prioritized the wrong customer and ended up with a product that was tuned to work only for the ones who won’t pay more than what we originally offered the product for. Even inflation adjusted I’m sure it was less than $12M. You have to watch what your costs per year end up being for that check you got three years ago. The VCs will notice when they look at your books.
That’s all true, but it works both ways. I’ve also been at a place that stuck to its plans rather than incorporating customer feedback and requests. You haven’t heard of it, and that’s why.
I guess my main point is that you have to always be making the right thing. Sometimes that changes, and you have to be ready to pivot quickly.
Re: Ways to annoy your senior engineer
#76Earlier quoted context omitted.
We make great layoff candidates because most of our code is something other people can take over maintaining. They keep the jackass who makes things nobody else understands.
In the jackass. Until now I thought I’m surrounded by people who cannot understand reasonably complex code. Currently I hope that both can be true at the same time. I’ll enjoy my job safety, although now more humbly.
I told the last one that his confessed difficulties with documenting his code probably come not from a failure of literary skill but a failure to write code that can be explained.
Re: Ways to annoy your senior engineer
#77I find these complaints to be symptoms of taking yourself too seriously, which is not only a poor way to act at a company but also a poor way to live your life. Yes you’re an engineer and your time is valuable but you don’t have to act like it! Even if getting distracted causes you to lose some threads, you can’t ignore that you’re helping other people in the meantime. If you’re emotionally upset when you’re helping…
I don't think you read the article, or understand engineering if you discard the author's opinions with "taking yourself too seriously". For example, reread the following paragraph: > Few things are more disruptive to engineering than constant priority shifts. They make it impossible for engineers to plan or finish meaningful work. Again, reread it and try to understand why the author stated that, instead of accusing…
Definitely I did read the article but I’ll address your point about priority shifts.
I think handling priority shifts is a part of the job. If you can’t get people to talk to each other about priorities and help illuminate that they have to compromise on what is important in order to get the best outcome, then you’re failing as an engineer.
However I do work at a company where I have an active hand in planning the roadmap as a senior engineer. I often tell the senior leadership what my thoughts are about priorities and I feel empowered to say “no,” or “let’s do that later” to asks. I understand this isn’t how everywhere works. Maybe the author and I have very different work experiences.
To me, if someone says “we are shifting priorities.” I think of it as a chance to improve what work we are doing. I feel that the author would see it as an opportunity to waste their time more.
I don’t believe that engineers are pawns in a political game. I think it’s a strange thing to suspect and I have some doubts about your mental well being. Looking through your other comments, it seems to be a common trend of yours to speak of people as pawns. Perhaps you feel like you are a pawn at work? Or maybe you see the world as a political game where you are a pawn?
I don’t think that’s a wise perspective - even in chess a single pawn often can win the game. Even with even pawns, the better coordinated pawns can win. Just some food for thought.
Re: Ways to annoy your senior engineer
#78Earlier quoted context omitted.
I don't think you read the article, or understand engineering if you discard the author's opinions with "taking yourself too seriously". For example, reread the following paragraph: > Few things are more disruptive to engineering than constant priority shifts. They make it impossible for engineers to plan or finish meaningful work. Again, reread it and try to understand why the author stated that, instead of accusing…
Definitely I did read the article but I’ll address your point about priority shifts. I think handling priority shifts is a part of the job. If you can’t get people to talk to each other about priorities and help illuminate that they have to compromise on what is important in order to get the best outcome, then you’re failing as an engineer. However I do work at a company where I have an active hand in planning the ro…
The problem is continually shifting priorities, not the setting priorities like you described. (IE, the priority shifts described in the article imply that engineers should not have been involved in the projects yet.)
I only use the term "pawn" in this thread to set context: In a workplace where leadership exhibits the behavior described in the article, they have lower respect for their engineers than the workplaces I've been in.
Re: Ways to annoy your senior engineer
#79Earlier quoted context omitted.
In the jackass. Until now I thought I’m surrounded by people who cannot understand reasonably complex code. Currently I hope that both can be true at the same time. I’ll enjoy my job safety, although now more humbly.
I told the last one that his confessed difficulties with documenting his code probably come not from a failure of literary skill but a failure to write code that can be explained.
That sounds like a useful distinction, I like it - thanks for sharing. I hope they draw the right conclusions, i.e. start writing code that can be explained instead of documenting current code with "# Too complex, cannot be explained"[1].
Re: Ways to annoy your senior engineer
#80Earlier quoted context omitted.
I told the last one that his confessed difficulties with documenting his code probably come not from a failure of literary skill but a failure to write code that can be explained.
That sounds like a useful distinction, I like it - thanks for sharing. I hope they draw the right conclusions, i.e. start writing code that can be explained instead of documenting current code with "# Too complex, cannot be explained"[1]. [1]: https://stackoverflow.com/a/185106
I think the ultimate observation is that when you write a piece of code incrementally, you are memorizing your own code with small alterations that fit into working memory. And if you write the code for yourself instead of other people, you write it in exactly the shape that fits most compactly into your own brain instead of anyone else’s. When you write for others it gets a bit bigger (which is probably why people balk).
But the bigger issue is that nobody else has memorized your code. So they have to fit the entire codebase as it currently exists into working memory. And since that is impossible it can take them months or even years to get as proficient as you are. Because they have to memorize it piecemeal to understand it, and unlearn false assumptions they couldn’t disprove until later. And meanwhile you keep adding new changes to the code. That’s a you problem, not a stupid coworkers problem.
If you’re very friendly you can bring a handful of coworkers along so you have the bus numbers, but any new hire still has the cognitive load problem.
The way out of this is to eschew “power” (Principle of Least Power), condense the core of the problem to its essential complexity, and write discoverable code - code that leaves breadcrumbs that invite a curious user to peek into functions where the real work is done. Which for instance polymorphic recursion absolutely does not do.