Live data from Hacker News

The worst programmer I know

dannorth.net

261–270 of 668 posts

Re: The worst programmer I know

#261
post #25

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…

Harry Nyquist isn't exactly an unknown engineer who doesn't have his own achievements, though - not sure why people are saying he would be fired in a modern company!

Re: The worst programmer I know

#262

It 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…

> There is a very good chance that the same feature set could have been implemented with just 10K lines of code, less buggy and in half the time

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

#263
post #62

Now 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.

Get your resume. HR looks up your name. Throws out the resume. It could be fun if you can get an interview. It might hurt you though.

Re: The worst programmer I know

#264

Earlier 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.…

You are both right and need to take a break :)

Re: The worst programmer I know

#265

Personally 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…

A senior engineer can work through a hard problem assigned to a junior engineer, resulting in a well-implemented hard feature and a less junior engineer. Just because a junior engineer is working on it doesn’t mean by default it’s an easy problem—how are you going to grow your engineers otherwise?

Re: The worst programmer I know

#266

Tim’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…

I have struggled to find work my entire life, but people like this get jobs. I hate life

Re: The worst programmer I know

#267

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.

Do people honestly think this kind of thing replicates with formally scheduled Zoom 1:1s? I don’t.

I don't know about you, but I don't tend to have breakfast and lunch over Zoom.

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…

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?

Re: The worst programmer I know

#269

When 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…

Have you ever seen an organization filled with service-oriented employees and no doers? Zero-interest rate policy has lead to having more Senior Director of Jira Board Management and Lists of Tasks type roles and not enough people that can do the work. I'm not opposed to the idea that others can be a catalyst for the productivity of others, but you need the others for anything to get done, otherwise it's necrosis.

Re: The worst programmer I know

#270
post #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…

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?

Post reply on HN