All I had to do was read the title of this article and the first sentence to understand that this is an example of what's wrong with the software development industry. I would rather work with people that act like good people and are human, than to work for the idiots measuring your every breath looking for a reason to fire you.
The worst programmer I know
271–280 of 668 posts
Re: The worst programmer I know
#272Earlier quoted context omitted.
The saddest thing is that some bosses want throwaway code. I had a short stint once in a company where the owner wanted the web service rewritten from scratch every 6 months so they could use the newest web framework and follow the current fashion. He would hire a 5000 LoC per week hero on the spot.
> where the owner wanted the web service rewritten from scratch every 6 months so they could use the newest web framework and follow the current fashion This sounds like an improvement over the opposite, a code base that is rarely touched and uses eol frameworks. Software is a living thing and if you don’t act as a ruthless gardener you wind up a museum curator with 1990s DEC hardware running in the 2010’s. The right…
Hey, if the 1990s DEC hardware still works, and it'd be more expensive to change it...
There are PDP-11s running nuclear plants today with support contracts to keep them running until 2050.
PDP-11s.
Re: The worst programmer I know
#273The horrifying part of this is
> Instead we would measure stories delivered, or it may have been story points (it turns out it doesn’t matter), because these represented business value. We were using something like Jira, and people would put their name against stories, which made it super easy to generate these productivity metrics.
I have never worked anywhere where middle management measured individual engineers via issue-tracker metrics. That seems almost implausibility dysfunctional. It’s not just measuring a hilariously wrong thing at the wrong level of granularity, it’s also disempowering the line manager from evaluating their own people. Is this a real thing companies do?
Re: The worst programmer I know
#274Earlier quoted context omitted.
This sounds like possible malicious compliance. Regardless, it’s an important life skill to learn that it’s generally not enough to ask people to do what you want, you need them to actually “buy in” to what you want, and then they’ll actually care enough to at least try make it happen. This applies to managers and their employees, or also when trying to get on the ground employees to adopt a product initially sold to…
"Buy in" is what you use for people acting in good faith. But managers aren't acting in good faith. They just want it done so that they look good to their own bosses. They don't actually care about the product/service. Their ask to "go faster" is a bad faith argument where there is no real need to go faster except for the manager to look good. I don't feel the need to get "buy in" for bad faith managers.
> but managers aren’t acting in good faith
An overly broad statement which, my experience, is not true. Managers come in many shapes.
Although, I suppose ironically, if you act in bad faith as a response to this perception, then I think that perception will quickly become true.
Re: The worst programmer I know
#275Earlier quoted context omitted.
In my experience, the best raises are from getting a new job. What were raises like for your engineers that stuck around for 10-20 years?
Not very good. These were highly skilled engineers that could easily have commanded better salaries, elsewhere. That meant they stayed for other reasons. I wonder what those reasons could be?
This is brilliant. I'm a mid-level engineer with decent C/C++/Rust background. Have yet to find a team like this. I'm inspired by your story to keep searching!
Re: The worst programmer I know
#276A very relatable story. Of course, we all feel sorry for those other Tims out there who were not lucky enough to have such a good manager. Partly, because we see the Tim in ourselves.
I think this is what we can do to help: Remember sometimes we are also those co-workers who took help from Tim around us and conveniently forgot to Thank their contribution in success of our project. A simple thank you note in the right meeting, slack channel or in the project delivery mail goes a long way. Measuring the indirect impact of an employee is hard, even if you were the manager at any level. Taking help is not a sign of weakness or acknowledging the contribution of a co-worker doesn't make your effort any smaller.
Re: The worst programmer I know
#277The horrifying part of this is > Instead we would measure stories delivered, or it may have been story points (it turns out it doesn’t matter), because these represented business value. We were using something like Jira, and people would put their name against stories, which made it super easy to generate these productivity metrics. I have never worked anywhere where middle management measured individual engineers vi…
Fortune100 eng here, yes it is a thing.
Re: The worst programmer I know
#278Now when you Google “Tim Mackinnon programmer”, the 5th or 6th result for me is a link titled “The Worst Programmer” and the little descriptive blurb below that says “His name is Tim Mackinnon…”. I know the author was click baiting and flipping the story on its head, but I would be a bit annoyed if Googling my name + programmer surfaced something like that.
Tim thinks it's awesome: https://twitter.com/iterex/status/1697927494479777844
Re: The worst programmer I know
#279Earlier quoted context omitted.
My problem in my last role when I read large Pull Requests is that they tended to be way more complicated than they should have been but because they worked and I couldn't single out a small number of specific problems, I had no choice but to approve. Still, I knew it would slow us down in the medium and long term but this bloat is completely invisible to management. It has become taboo to say things like "This code…
"You don't need to add an external dependency for that" "You're violating separation of concerns" I've found that kind of feedback to be useful actually. And when giving similar feedback it is received better with a small change in wording to make it more about the code and not the person. Even if that is the intention the wording does matter. For example: "An external dependency isn't needed here, try implementing w…
The imperative can rankle too. I like passive voice or "let's" statements.
Re: The worst programmer I know
#280It’s like Draymond Green. Individually his statistics suck. He’s jokingly called Mr Triple Single (a triple double is a major achievement, a triple single not so much). But he’s such a fantastic defensive coordinator and playmaker that his impact metrics on the team are massive. Like practically comparable to Steph, his more lauded teammate, in some stretches. A common refrain in basketball is that people forget it’s…
Came here to say something similar.
In this case, Tim from the blog post is a football defender or a linebacker if you're an American. Measuring them based on the amount of goals they scored or a touchdowns they caught is stupid. Instead they're stopping costly errors and providing the foundation that allows others to go on and score. You're probably not going to win very much if you field 11 strikers or 11 wide receivers.