Yeah I mean obviously the technical points here are correct (and I wish my colleagues would write more robust code with less Bash and regex all over the place), but I don’t know why he thinks you need an asshole manager to deliver that message.
Over-engineered. Too many moving parts. Refactor.”
That was it. No “nice work.” No “good attempt”. Just a hard stop.
Uhm yeah, would writing “good attempt” have hurt? Obviously not. He could easily have been nice and still deliver the technical information.
Good attempt, but I think this is too over-engineered with too many moving parts. For instance x y z would be simpler to maintain, and a b c isn’t robust to 1 2 3 for example.
It doesn’t take much. Don’t be a dick.
The feedback in the article was obviously far from perfect, but from the sound of it, “good attempt” could be an actively harmful thing to say. Lots of effort had gone into making the wrong thing and making it fragile, which isn’t good at all, it’s bad. If you’d asked an employee to make a waterproof diving watch, and they came back with a mechanical clock made from sugar, even though it’s impressive that they managed to make a clock from sugar, it’s completely inappropriate as it’d stop working the instant it got wet. You wouldn’t want to encourage that kind of thing happening again by calling it good, and it’s incompatible enough with the brief that acknowledging it as an attempt to fit the brief is giving too much credit - someone who can do that kind of sugar work must know it’s sensitive to moisture.
The manager can apologise for not checking in sooner before so much time had been spent on something unsuitable and for failing to communicate the priorities properly, and acknowledge the effort and potential merit in another situation without implying it was good to sink time into something unfit for purpose without double checking something complicated was genuinely necessary.
Saying “good attempt” is just a nice platitude. It doesn’t actually mean that what you’ve done is good, especially if you follow it up with (effectively) “but you’ve got to do it all again”. I think most people understand that.
It’s not guaranteed that it’s interpreted as a platitude by the person it’s directed at, and when the mismatch between the task and the work done is big enough to make it obviously a platitude, it’s just patronising, and risks being more insulting than not saying it at all.
Sounds more like a tech lead than a manager.
Unrelated, but substack links seem to contain a lot of slop nowadays. Bear blog for the win.
Everything the author describes can still be accomplished by being diplomatic and understanding without being confrontational and direct. Plus, you build a better, more resilient team that way.
I’m not really sure the author learnt what he thought he learnt.
I think his conclusion was the same as yours. He learned the engineering lesson and added the human skills.
What’s the alternative to being direct? Being indirect? Dropping hints? Spreading a rumor?
Being direct is good. But ‘too complex, refactor’ as an explanation is just one word longer than ‘fuck off’. You need to explain in detail why the solution is bad and which parts should be changed, in this case it just shows that the reviewer did not actually read the code.
The problem there is not the directness, but the terseness. This is something I had to learn myself, and fortunately was able to get feedback from colleagues who appreciated my directness and wanted more elaboration.
Yes, being indirect. Instead of saying: ‘you did a bad job’, say ‘here are things you can improve for next time’.
On is confrontational and problematic, the other diplomatic and constructive.
You don’t seem to understand what “direct” means.
“You did a bad job” is a subjective value statement that communicates nothing of value. It’s direct, but also useless. The problem is not in the directness.
Providing immediate examples of improvements is also direct; the difference is that it’s constructive, and helps guide the junior engineer.
One is direct, and the other is not. And you’re right, one is not constructive, and the other is, that’s not coincidence.
What ‘immediate’ even means in this context I don’t know.
I just didn’t want to have to say “direct” again.
Did anyone run this through a few AI content scanners? This article was boring and pointless. I thought this was the programing feed and not butt sucking.
Not everything that’s poorly written is ai, you should give humans more credit
There are maybe three sentences worth of content.
Wrapped.
In stutters.
That make.
It.
Super hard.
To read.
It drives me nuts on LinkedIn; it’s sad to see it’s made the jump to “longform” on substack.
I stopped coding for myself and started coding for the next person who’d touch my codebase.
Yeah. The worst code is the code only one person can work with. Sucks if that person is no longer working at the company.
What’s with the image thumbnail that doesn’t appear in the article? It also looks like AI slop.
The content is good, but c’mon.
This AI gen illustrations are painful.
Over-engineered. Too many moving parts. Refactor
Why would a manager give his opinion on code?
Maybe the person is more of a tech lead?
A lot of companies make their most senior devs engineering managers, and expect them to stay technical. I assume this was the case here.
I had one of these when I was loaned out to another department. He made me realize that my manager is terrible and I need a new job.
We have an engineering manager that’s about the same, the only issue is that they let PR through because features are wanted and there’s no time to get things right.
I think, I may be pleased to have to redo everything several times to make it better and simpler, but what we get is that everything is bad but we’ll still merge 😞
I now feel at several times I fucked up quite a lot by making something that works but not something simpler.
