[deleted]
The Worst Programmer I Know (2023)
111–120 of 385 posts
Re: The Worst Programmer I Know (2023)
#112Used to be bitten by stuff like this until I figured out something Tim and this author apparently didn’t - the problem is trivially fixed by management by attaching tim’s name to any tickets he may have helped out on. he can ask his teammates to do this and they gladly will, or, nice teammates will usually throw a “figured this out with the help of @Tim” in the ticket. goes a long way to keep “tim” on your team again…
In football you track not only the goal scorers but also the assist (the person who passed the ball to he goal scorer). That still does not cover all contributions, but maybe that's a way to create more transparency for Tims case ?
Re: The Worst Programmer I Know (2023)
#113Damn. Now that I read this I realize why my current team feels like nothing gets done and the reason is the team has no Tim.
That’s not a good excuse
Re: The Worst Programmer I Know (2023)
#114The idea of measuring individual developer productivity is kind of absurd to me. I'm not saying that what we do is magic, there are just so many variables. Measuring story points or lines of code is kind of the opposite of productivity. This encourages developers to do as much meaningless work as possible. I'd want a developer to make a task simpler or use an existing tool which means less time writing code. The valu…
the worst programmer nowadays is the vibe coder. vibe coding is so overrated imo
https://www.lycee.ai/blog/why-vibe-coding-is-overrated
Re: The Worst Programmer I Know (2023)
#115Maybe.
There’s also folks that pair because they’re a crutch for one or two other engineers. The other engineers never improve or are let go, but softly slow down the team.
There’s also the folks that pair because their code doesn’t make sense on its own. Or they have some config files they’ve refused to check into the repo, etc.
Pairing makes them feel valuable.
Re: The Worst Programmer I Know (2023)
#116The idea of measuring individual developer productivity is kind of absurd to me. I'm not saying that what we do is magic, there are just so many variables. Measuring story points or lines of code is kind of the opposite of productivity. This encourages developers to do as much meaningless work as possible. I'd want a developer to make a task simpler or use an existing tool which means less time writing code. The valu…
the worst programmer nowadays is the vibe coder. vibe coding is so overrated imo https://www.lycee.ai/blog/why-vibe-coding-is-overrated
I've been writing code professionally for a decade but I've never written so much code in my free time because I can just vibe code it all. I wouldn't do it at work and I probably wouldn't trust a juniors vibes as much as my own but no tools have made me feel quite so powerful.
Re: The Worst Programmer I Know (2023)
#117Earlier quoted context omitted.
Not to be a total fucking asshole... but: > Someone needs to manage product delivery: You mean the 2-week delivery cycle into an automated CI/CD? Good lord I hope they don't have a useless scrum master too. > Someone needs to manage the backlog: I'm curious what input the manager has into this besides reading through a list of engineer curated items. > Someone needs to manage the training of everyone: Tim seems to be…
Do you have experience being a tech lead and/or a manager? Tech leads and people managers are two explicitly different roles in many organizations, for good reasons, including, but not limited to them being both full time jobs. It certainly depends on the company and the size of the team and other things, but many many tech leads are not at all comfortable hiring & firing, nor with interviewing and prioritizing work…
Man that is a whole lot of fluff to differentiate between being able to hire and fire. I wonder what Tim would do.
Re: The Worst Programmer I Know (2023)
#118Glad to hear that Tim stayed and author managed to steer the entire process towards the right direction. Which requires a listening manager. I experienced the "bad ending" of this productivity metric trickle down: OKR. This startup wanted not just team-based 3-month review Objective Key Result but also individual one, and on top of it, tied stock option to OKR. It was a robotics startup so very cross-domain teams (So…
I think just because this startup botched OKRs they still make a lot of sense.
Intel and Google apparently relied on them heavily in their formative years. But:
- they should be cascading (so conflicting OKRs between departments should not happen)
- you should never, ever tie them to individual performance results/compensation/rewards
Re: The Worst Programmer I Know (2023)
#119Earlier quoted context omitted.
> they were assigned because it would have been malpractice otherwise. I don't know understand this means. > This was very much a team built out of the resources available, rather than intentionally selecting only new grads. Yet your other comment says, "this particular company paid way below market rate with the promise of interesting work. It without a doubt incentivizes hiring new grads where you roll the dice and…
> I don't know understand this means. It means, this team was very much a team built out of the resources available, because the existing experts in the company who could have been mentoring new grads were already working full time doing something with a direct contractual obligation to the company. I would have been negligent to pull them from an existing inprogress contract to mentor newbies, and the contracts had…
>> But the team was 5 to zero.
> The team you called pathological? Yeah, it was bad. Missing deadlines is bad. I don't understand where you're confused.
>> [just like 1 to 1 is bad...] Why?
> I already answered. Because of politics a project
I was confused because I thought you were trying to make general points, but apparently you're mired in the minute details of one company and its extremely specific projects and politics.
I'm getting the impression that there were so many idiosyncratic constraints on the project that it simply couldn't have gone any other way, and thus there's no real way to critically evaluate whether things would have gone better with a different arrangement. Be that as it may, I'm not sure what kind of general conclusion we're supposed to draw from such a constrained example? Going back to the linked article, the case of Tim didn't appear to be so constrained:
1) They were thinking of getting rid of Tim, which presumably wouldn't have killed the project entirely.
2) They expected Tim to make more individual contributions, which presumably wouldn't have killed the project entirely either.
3) The team already had a mix of junior and senior engineers, not simply Tim and a bunch of new grads.
Re: The Worst Programmer I Know (2023)
#120I think a lot of this idiotic thinking about measuring productivity through "stories" is to pin on the "Agile" industry overselling their low value "methodologies" to the MBA-type managers, which are now unfortunately just about everywhere. Hence you have some clueless person deciding who has to go, based on how many tickets get moved on the board. As Joel Spolsky once said, no software company can succeed unless a programmer is at the helm.