The worst programmer I know • Hacker News Board

Re: The worst programmer I know

#301

Post by whstl » Sat, Sep 02, 2023, 7:42 PM UTC

AStellersSeaCow wrote: post #95

jongjong wrote: post #18

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…

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.

Re: The worst programmer I know

#302

Post by hibikir » Sat, Sep 02, 2023, 7:43 PM UTC

This is also why the most hilarious anti-feature of Jira, supposedly a tool to manage agile teams, is how every ticket has one person assigned to it. If you do sufficient pairing, the person assigned to a ticket is completely useless. Also why performance measurement from the outside of a team is always going to be dubious.

Every team knows their best performers, and their lowest performers. The number of points aren't going to line up with performance most of the time, precisely because time helping others is never going to show up. And if suddenly getting help lowers your review, you are going to ask for less help, not more: Trading accuracy in external performance tracking for lowered team performance sounds really dubious.

Re: The worst programmer I know

#303

Post by vikramkr » Sat, Sep 02, 2023, 7:49 PM UTC

orpheansodality wrote: post #192

vikramkr wrote: post #102

So basically he just had the wrong title? Sounds like a great engineering manager or lead (in a company where that involves less code writing) or something. But his title is an IC role. But if he's spending all day pairing and not writing code then yeah - that manager seems to be correct, that's not his job? Why isn't he taking on any stories?

pairing is taking stories, it’s two people working on one task together.

So then he hasn't been taking zero, "literally zero" stories like the article says.

Re: The worst programmer I know

#304

Post by Stratoscope » Sat, Sep 02, 2023, 7:51 PM UTC

Some 20 years ago, I worked at a moderately large software company that sold a desktop application for Mac and Windows. The team had mostly Mac experience and they were just getting their feet wet with Windows. So naturally the Windows version had some problems.

At the time, I was known as a "Windows expert", so they hired me to help improve that version and help the team get more familiar with Windows programming.

I would often spend the first part of the day on what I called "house calls": visiting other developers' offices to either pair program or troubleshoot bugs or just talk about Windows API best practices and the like. (Yes, we all had private offices!)

After a while, one of my colleagues asked a question that stuck in my mind: "How can you afford to be so generous with your time?"

Sure enough, a few months later I got a review with a mediocre rating and a comment: "Your productivity hasn't been quite we hoped, especially considering that the rest of the team has gotten more productive lately."

Which was exactly what I thought they had hired me for!

Re: The worst programmer I know

#305

Post by tchaffee » Sat, Sep 02, 2023, 7:51 PM UTC

twic wrote: post #290

tchaffee wrote: post #263

Earlier quoted context omitted.

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.

This is just not something that actually happens.

Can you reassure me then with the data that backs up your claim? Because in my very long career I've seen a lot of people use heuristics when deciding who to follow up with.

"According to a 2018 CareerBuilder survey, 70% of employers check out applicants’ profiles as part of their screening process, and 54% have rejected applicants because of what they found."

Re: The worst programmer I know

#306

Post by mlhpdx » Sat, Sep 02, 2023, 7:52 PM UTC

Wonderful. In rowing there is a practice called “seat racing” where different combinations of people are rotated in and out of the eight positions to determine the combination that is the fastest. Individual strength is an indicator but it’s the team speed that determines who is in the boat for races. The inevitable result is that the fastest combination rarely includes the eight strongest rowers. There is very often one or two “magical” people who don’t look better “on paper” but make almost any boat faster when added to the mix. They have subtle ways of improving the set, rhythm and power of others. Not all coaches take this happily and resist it, with the obvious result of fewer wins.

This is very, very analogous to software teams. It’s the mix and results that matter most.

Re: The worst programmer I know

#307

Post by prerok » Sat, Sep 02, 2023, 7:52 PM UTC

The only 10x coder I knew was the one that managed to deliver stuff (almost) on time but also took the time to explain things to other (junior, me at the time) programmers. Such Tims are sadly rare and I think I should start working towards becoming like one.

Re: The worst programmer I know

#308

Post by liquidpele » Sat, Sep 02, 2023, 7:55 PM UTC

avanai wrote: post #38

Erikun wrote: post #25

Earlier quoted context omitted.

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 most impressive thing about this story is that they figured out the answer . They did the research, and nailed down that it was Nyquist who was was the productivity booster. It’s the exact opposite of the OP’s story, where management tried to fire the Nyquist-equivalent.

All they figured out was that the smart people hung out together.

Re: The worst programmer I know

#309

Post by adolph » Sat, Sep 02, 2023, 7:55 PM UTC

hnfong wrote: post #199

adolph wrote: post #166

Earlier quoted context omitted.

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

If you choose the right frameworks which have sufficient momentum to last you say 10 years, you don't have to put yourself in the dilemma. And yes, 10 years is quite possible these days. Besides the infamous Javascript framework churn, things are moving quite a bit slower in recent years.

“If you choose the right frameworks” is a big if. Even within a framework, there is versioning and dependency management to account for. Consider the log4j vulnerability. The cost and risk of patching something untouched for 10 years is higher than something touched more recently.

In part, this is due to the risks inherent to change have been spread out over 10 years instead of backloaded to the end.

Practicing mitigating risks by proactively taking them has value of its own. The parable of ergodic cakes shows this.[0] What % of cakes will fail if 10 people each bake one, versus one person baking 10 over time?

https://luca-dellanna.com/what-is-ergodicity/

Re: The worst programmer I know

#310

Post by sjtgraham » Sat, Sep 02, 2023, 7:57 PM UTC

This is not an argument on the merits of story points or metrics but Tim could have just put his name on the stories alongside the folks he helped. Problem solved.