Ugh of course the worst programmer you know is actually the best one. While I agree with it, there is nothing new in this article and the obviousness of the bait and switch is depressing.
The worst programmer I know
471–480 of 668 posts
Re: The worst programmer I know
#472For Tim MacKinnon's sake I sure hope you got Tim's permission to post this, and that Tim is near retirement age and not needing to interview for any team in the future because unfortunately, searching for "Tim McKinnon programmer" tells me he is the worst programmer in existence. If I were hiring and found that as the first link on Google, and feeling particularly lazy that day, Tim's C.V. would be round filed. HR would reject him before I ever got to see his C.V. Poor Tim.
Re: The worst programmer I know
#473Earlier quoted context omitted.
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?
Some firms simply hire nothing but Seniors. You trained up a Junior-Mid-Senior? Cool, well offer him 20k more and call it a day.
> Some firms simply hire nothing but Seniors
The firms that claim to do that almost invariably do not hire people with 20 years of experience, they hire people with 2 years of experience 10 times over. Sometimes that's fine. Usually it's not.
Re: The worst programmer I know
#474Earlier quoted context omitted.
Depends on the company and management. Google codifies this role to some extent as Tech Lead, which is an engineer expected to act as a force multiplier and mentor more than an individual contributor. It doesn't always work as designed (ok, maybe rarely works as designed), and TLs can get too bogged down in cat herding, planning, and bike shedding to actually work as an engineer. But at least the spirit of the role i…
Tech Lead is a very difficult role. :/ If you are immature or competitive, you cease being a force multiplier to be a morale destroyer. If you are more of a domain expert than your Product Managers, you will spend your time fighting and refining tasks to build features the right way. If you don't have enough time to code, you'll go obsolete.
> If you are more of a domain expert than your Product Managers, you will spend your time fighting and refining tasks to build features the right way.
If you are more of a domain expert than the product managers, argue for the product managers to be fired - they serve no purpose.
Re: The worst programmer I know
#475Earlier quoted context omitted.
>I was actually much more impressed by the latter skill — among other reasons it’s simply rare Not exactly something to encourage, but it sounds like he has experience in competitive competitions, where generating code to a problem on the fly is necessary. It's not something you can't learn yourself, but rote memorization of common problems and solutions (to the point where you can mechanically type down some algorit…
Don't competitions usually have completely different kinds of problems than what you typically run into in production fires? When I think of competitive programming I think of algorithms and puzzles, not network errors and data corruption. In my experience production fires are rarely put out by rote algorithmic knowledge, the skill is more having a detailed knowledge of the inner workings of every layer of the system…
This is my understanding as well. Rare is the day I’ve solved a production firefight by editing some algorithm - it’s almost always arcane configuration, restarting services in the right order, some network thing flapping/dos-ing the rest of the system, some service aggressively restarting and dos-ing others, actual malevolent dos, noisy neighbors, resource starvation, etc.
Re: The worst programmer I know
#476Earlier quoted context omitted.
> ...or broke it down into smaller achievable tickets that continuously added to their points totals. These teams were filled with happy stress free developers. But that is part of the point of scrum. To break down stories into consistently stress-free achievable stories, rather than big risky ones filled with unknowns. I'm not saying this was a good workplace, it doesn't sound like it at all. But to me, it sounds li…
The point of scrum is to provide employment for consultants and non-engineers. I left engineering for an engineering job in finance. No scrums, no POs, just trader driven development and I haven’t looked back once. Glorious.
"The point of scrum is to provide employment for consultants and non-engineers"
I'm actually starting to believe this. I work for a very large company that switched to agile. We have agile / scrum coaches in pretty much every big meeting and I have yet to hear one say anything. I don't mean anything useful, I mean anything at all. They just sit there blinking. I have no idea what they do.
Re: The worst programmer I know
#477I worked at a company for a couple years where you had to produce 10 points a week or you got pipped. Didn't matter if you were a jr or sr. I worked on a few teams there and you could immediately tell how the teams measured points by the stress level of the developers. Teams that attempted to measure the points in good faith were stessed and most of them showed signs of burn out. They regularly worked 60 hours a week…
Seems like it would just incentivise every ticket being estimated as something like an 8. Even in an environment where story points essentially mean nothing it already ends up with some people just wanting to put high numbers on everything.
Thats exactly what happened. People that tried to do it right, got punished as they ended up working weekends all the time. People that did as you suggest and went high, were stress free.
Re: The worst programmer I know
#478Earlier quoted context omitted.
Some firms simply hire nothing but Seniors. You trained up a Junior-Mid-Senior? Cool, well offer him 20k more and call it a day.
> Some firms simply hire nothing but Seniors The firms that claim to do that almost invariably do not hire people with 20 years of experience, they hire people with 2 years of experience 10 times over. Sometimes that's fine. Usually it's not.
Agreed, I will almost always take someone with 5 years of experience at a couple of good shops rather than 20 years of experience broken up across 10 different ones.
Re: The worst programmer I know
#479Earlier quoted context omitted.
It depends on “when” along the timeline of the project. If we don’t know if anyone will want the product, the quality of the product is less valuable than validation of product market fit. Later, I care much more about avoiding accidental complexity and having a great technical foundation.
But you can’t have the technical foundation later because you’ve already built on something else.
Sure you can - you just have to be willing to throw what you have away. If the outcome of that is having to rewrite one of five experiments because it is a hit, that is a _great success_, not a failure.
Re: The worst programmer I know
#480Earlier quoted context omitted.
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.
That is a great example. By not taking account of risk on the front end by embracing change, the system gets progressively more expensive to maintain (extended support contracts) and the risk of eventual inevitable change grows higher. Further, the system becomes progressively less valuable compared with newer systems.
> becomes progressively less valuable compared with newer systems.
Indeed, business people do not typically model depreciation curves for software as they should. That doesn't mean that the plant control system becomes less valuable (the value is tied to the operation of the plant, probably for the lifetime of the plant), but in many other situations it does mean that.