The worst programmer I know • Hacker News Board

Re: The worst programmer I know

#181

Post by hardwaregeek » Sat, Sep 02, 2023, 5:24 PM UTC

KSS42 wrote: post #145

hardwaregeek wrote: post #86

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

That impact should show up in the plus/minus score? https://www.espn.com/nba/statistics/rpm For 2022/23 Green ranks 38. His defensive impact is very high but it is offset by his negative offensive impact.

Yeah that's what I meant by impact metrics. In the 2015-2017 playoff runs Green's impact is almost on-par with Curry. But for most people who watch basketball, they just look at the box score and don't look at advanced stats.

Re: The worst programmer I know

#182

Post by mattlondon » Sat, Sep 02, 2023, 5:25 PM UTC

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 implemented low-value features, but the high-impact and high-priority hard stuff was not done because some of your most experienced folks were helping the less-experienxed people write effective unit tests or whatever.

Re: The worst programmer I know

#183

Post by jareklupinski » Sat, Sep 02, 2023, 5:25 PM UTC

nine_zeros wrote: post #105

andai wrote: post #92

Earlier quoted context omitted.

Tangential but I was doing a web app for a client and gave a time estimate, which accounted for doing things properly (i.e. learning a frontend framework first). He asked "can you do it faster" and I agreed, thinking I'll make a throwaway version first and fix it later. Needless to say the project was a disaster, rapidly became unmaintainable. That's how I learned my job isn't to do what the client asks, it's to make…

> That's how I learned my job isn't to do what the client asks, it's to make sure their project succeeds even if it means making them (temporarily) unhappy. And I learned that doing it my way will get me fired because the manager has asked to do faster. The way I have learned to get around this is by making the manager publicly document the request to go faster. If they don't document, I don't see or act on it. Once…

that's great for covering your a, but the project will still fail and no one will get value / praise for all that time spent

if time is the only actual concern for the project's success, a good approach is to explicitly re-scope the feature list and start asking managers things like:

"do we really need feature X to release? can feature Y wait until after beta? did the request for feature Z come from a user or a stakeholder?"

document all that too of course ;) but then at least there is a chance for safety _and_ success

Re: The worst programmer I know

#184

Post by whstl » Sat, Sep 02, 2023, 5:25 PM UTC

throwaway92837 wrote: post #80

JKCalhoun wrote: post #43

Earlier quoted context omitted.

Having been in the industry since the around 1990, I can tell you that in the first half of my career we had no code reviews, no scrum, no story points, no unit tests. How on earth, you might wonder, did we ship software that worked? I then saw all these things come down the pike one after another during the last half of my career. Clearly to me every one of these benefit management who found themselves apparently un…

I would be interested to know your career history in more depth. To my understanding even IBM in the 70s had stupid ways of measuring productivity (KLOCs?).

I'm pretty sure there were companies doing stupid things in the old days but in my experience, back then managers were supposed to know what developers were doing, and if they were delivering value or not.

They did all that by walking around, chatting with everyone, helping devs, assigning tasks depending on the expertise level, sometimes doing boring work (like manual testing) to help devs, etc.

Of course, if a manager that has to handle Jira and Scrum meetings all day, then it gets difficult to do that.

Re: The worst programmer I know

#185

Post by raincom » Sat, Sep 02, 2023, 5:26 PM UTC

Philip-J-Fry wrote: post #124

I wish I could pair program more. I have so much knowledge to give other members of my team. Domain knowledge, programming knowledge, common pitfalls, etc. You get a code review pass at the time of writing the code, and it means you have more opportunity to change things for the better. Once it's written there's not much appetite for drastically changing working code during code review unless there's a really good re…

In almost all companies, even seeking help is frowned upon. One ex-Microsoft manager, now a senior Manager at Atlassian, called that 'hand holding'. Some actively don't want to help out others, due to PIP/bonus culture. At Amazon, some team members explicitly give bad advice when asked for help. That's why we have this culture of "lone rockstars", who spend a lot of time to learn without being mentored.

Re: The worst programmer I know

#186

Post by [deleted] » Sat, Sep 02, 2023, 5:28 PM UTC

corethree wrote: post #50

bee_rider wrote: post #15

Earlier quoted context omitted.

I believe that’s the conventional approach in Python, though? It is a duck-typing language, try-except is a legitimate way of seen if an operator works on an object, and objects should do sensible things with operators. The funny example is that the hasattr built-in just tries to getattr, and then catches the exception to tell if it has the attribute.

Conventions are changing. Modern python is shifting to type checking with external type checkers.

[deleted]

Re: The worst programmer I know

#187

Post by reneherse » Sat, Sep 02, 2023, 5:30 PM UTC

jongjong wrote: post #119

padjo wrote: post #107

Earlier quoted context omitted.

I’m 10 years older, my experience has been that getting to ask stupid questions is one of the joys of age/seniority/security. Very often everyone else in the room has the same stupid question but you get to look like a stone cold genius because you were willing to risk looking silly.

I guess maybe in 10 years I'll be working with 30 year olds who understand and value of that approach as I do today. My current reality is that I'm a 33 year old working with 20 year olds who think they're geniuses who are going to take over the world in 5 years; from that viewpoint, I'm essentially a failed engineer because I didn't build a Facebook, Uber or AirBnB even though I had 10 years to do it.

I'm curious what type of company has these team demographics. Startup, agency, SMB, bigcorp, academia, or?

Re: The worst programmer I know

#188

Post by jader201 » Sat, Sep 02, 2023, 5:30 PM UTC

The moral of this article seems to just point out what we all already know, and what has already been discussed on HN countless times: don't measure performance solely by things that should never be measured in a vacuum (like story points, lines of code, etc.).

Not sure why this is the #1 article on HN right now, other than maybe the (what I would consider) click-baity headline. But I wish there was an acceptable way for HN to use more fitting titles for articles (especially since most articles always use a click-baity headline). E.g. would it be at the top if the title was "Don't measure performance by story points"?

I guess some interesting anecdotes have resulted in the post, but the message of the article itself doesn't seem to share anything particularly new or enlightening.

Re: The worst programmer I know

#189

Post by Longlius » Sat, Sep 02, 2023, 5:31 PM UTC

closewith wrote: post #22

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…

In a remote world, can that person exist?

Yeah the main thing I've found helps is if there's a regular Teams/Zoom meeting where everyone just pops in for like 30 min to ask questions. Then you can use that as the springpad to launch into one-on-one sessions.

You do need to cultivate a culture in the team of people being willing to lower their guard and ask questions though. And I think the key to this is just staying humble so people feel comfortable approaching you.

Re: The worst programmer I know

#190

Post by Arainach » Sat, Sep 02, 2023, 5:31 PM UTC

TheRealPomax wrote: post #157

AStellersSeaCow wrote: post #95

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

It also doesn't get people promoted to that position just because that's what they're doing. Because politics.

My experience at Google has been that TLs were generally strong engineers who were doing that kind of mentorship and product leadership, so to the degree that it's a "promotion" (same money, more responsibility isn't a promo in my book) it does seem to go to those who are doing it.

Now TLM (Tech Lead + Manager), however......there's a role that's set up for failure. Be a manager but be judged entirely on your technical contributions.