Reminds me of an anecdote about Bell Labs. Someone calculated who the most productive employees were (based on things like patents received), and found that many of them would eat lunch with the same person. That person wasn't individually very productive, but he would always ask thoughtful, compelling questions that in turn made his coworkers measurably more productive.
It might be from the great book The Idea Factory by Jon Gertner (p 135). 'In the midst of Shannon’s career, some lawyers in the patent department at Bell Labs decided to study whether there was an organizing principle that could explain why certain individuals at the Labs were more productive than others. They discerned only one common thread: Workers with the most patents often shared lunch or breakfast with a Bell…
The worst programmer I know
261–270 of 668 posts
Re: The worst programmer I know
#262It sucks being that person today because everything is about optics and that person will get purged. I know from experience. Team players, mentors, software architects; they tend to be tossed aside to make room for coders who can churn out large amounts of code, even as the company's capacity to deliver and maintain features declines over time due to tech debt. Managers always love a developer who can consistently wr…
A significant part of my personal code review process, is going back through my code, and factoring out complexity. It takes time and humility, but is very much, in my opinion, worth it.
Documenting my code is a trick that helps. When I am writing why I did something, I sometimes reflect, and say to myself "Didn't I just do this a few lines back?"
My code tends to be complex, by necessity, but it should be no more complex than absolutely needed.
A big, big tool for that, is OOP inheritance, which is considered "bad coder" smell, these days.
Re: The worst programmer I know
#263Now 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.
Annoyed? I’d love it: it would be an incredible door opener anywhere you went.
Re: The worst programmer I know
#264Earlier quoted context omitted.
Why do you say red flag? It is an exaggeration, of course, nothing is purely 1 hour. Rather it is 1 hour work in flow state, which is about 2 pomodoros, which is about 6 bulletpoints, which is about 1/4 of a day’s programming effort. Just about right for a 1 point card by a senior who only sit down to code when they kinda exactly know what to write
Talking about flow state and estimates? The red flag just gets bigger. You are asking me to show you that Santa is not real. A "very senior dev" will not be handing out "1 hour" estimates to a product team. An hour of what? Billable hours? Wall-clock time? It's just not the right framing. You will notice a good senior dev will be incredibly cautious about any commitment and not hand out "ego estimates" like one hour.…
Re: The worst programmer I know
#265Personally I want the seniors on my team actually delivering on the really hard stuff. Helping juniors do their job is great and all, but you still need experienced people to work on the hard and complex stuff that juniors can't because they don't have the knowledge/experience/people-skills. No amount of pair programming can replace that. You don't want to be in a situation where you have really really well implement…
Re: The worst programmer I know
#266Tim’s productivity score was zero I also have a Tim in my team but he is a net negative. Most of the time he would try to pair up. He just make noises that implies he is following your work. But you can see that is not the case when he tries to make a comment or a suggestion, he is clueless. Trying explaining things to him is a waste of time. Rarely he decides to work on a task himself. No matter how trivial the task…
Re: The worst programmer I know
#267Reminds me of an anecdote about Bell Labs. Someone calculated who the most productive employees were (based on things like patents received), and found that many of them would eat lunch with the same person. That person wasn't individually very productive, but he would always ask thoughtful, compelling questions that in turn made his coworkers measurably more productive.
Do people honestly think this kind of thing replicates with formally scheduled Zoom 1:1s? I don’t.
While I did go out to lunch with coworkers more often while working in the office it was almost exclusively with direct teammates, and other groups I occasionally saw where also on the same team.
Now that I'm fully remote, I will typically do a few "hacking sessions" over Zoom every week. Its much easier and more comfortable than standing over their shoulder in tiny cubes we used to have.
That said, especially now that i am fully remote, I've been trying and mostly failing to get developers especially across teams to talk and collaborate more. But its not too suprising: I was recently in a call and I was introduced to another developer who I replied, "Yeah, I know you. I was in the cube next to you for 2 years and on your team for 6 months."
Remote creates some new challenges, but its a culture thing, not a technology thing.
Re: The worst programmer I know
#268> Tim wasn’t delivering software; Tim was delivering a team that was delivering software. The entire team became more effective, more productive, more aligned, more idiomatic, more fun, because Tim was in the team. This was the money quote. Teams do big stuff. Good teams do good big stuff (very good). Bad teams do bad big stuff (very, very bad). It seems that the hyper-competitive nature of today's workplace means th…
Re: The worst programmer I know
#269When I've been asked to coach someone on "technical leadership" I always ask them to be on the lookout for "facilitator" employees, those whose help makes another employee more productive or effective. I am convinced there are "service oriented" personalities where people get more job satisfaction out of helping someone else do a great job than getting all of the credit for doing something amazing. As the author poin…
Re: The worst programmer I know
#270> Tim wasn’t delivering software; Tim was delivering a team that was delivering software. The entire team became more effective, more productive, more aligned, more idiomatic, more fun, because Tim was in the team. This was the money quote. Teams do big stuff. Good teams do good big stuff (very good). Bad teams do bad big stuff (very, very bad). It seems that the hyper-competitive nature of today's workplace means th…
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?
That meant they stayed for other reasons.
I wonder what those reasons could be?