The Worst Programmer I Know (2023)
301–310 of 385 posts
Re: The Worst Programmer I Know (2023)
#302The 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…
Re: The Worst Programmer I Know (2023)
#303Earlier quoted context omitted.
That's actually not a contradiction. As far as I can tell, you can build very complex prototypes. But unless these prototypes can be both trusted and maintained, that's all they are.
> As far as I can tell, you can build very complex prototypes. I think GP was saying you can do more than prototypes. I agree, but it's not (yet) universal on where you can apply it. The best case for my projects has been in trivial but tedious "3rd party integrations". Say you have a mature product but client x wants integration with product z. We are now at a point where we can say "this is our internal model {json…
Re: The Worst Programmer I Know (2023)
#304Earlier quoted context omitted.
I’m getting a similar sense from many of the AI “success” stories we’ve been hearing. There’s amazement about how many lines of code the AI produces in a short amount of time. But not so much about maintaining and debugging all those lines of code once they’re created.
But the code runs great, over a hundred transactions per minute ! All on just a $750 a day AWS instance! Saved so much money on those expensive developers! /s Math left as an exercise for the reader.
That being said, I've found AI to be quite powerful given that I already know what infra I'm planning to use and restricting it to use only those tools and services.
Re: The Worst Programmer I Know (2023)
#305Re: The Worst Programmer I Know (2023)
#306Earlier quoted context omitted.
Kind of meaningless statement though. Even if they do, which Im not sure is true in general case because you have to be good yourself to know who’s really good, they are not telling you anyway.
In every organization I've worked in, everyone knew who the productive and non-productive people were. Just like in school. Everyone knew who the good teachers were, and who the good students were. I don't fathom how you can work with other people and not be aware of it.
Re: The Worst Programmer I Know (2023)
#307Used 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…
> the problem is trivially fixed by management by attaching tim’s name to any tickets he may have helped out on. I don't think this comes even close to solving the problem. This in fact makes the problem worse, because a) you admit the metric is shit and does not reflect work, b) you opt to keep the bullshit metric but instead try to manipulate it to bump the score under some scenario. That's not desirable outcome by…
if you can't throw out the game you may as well adjust the rules.
Re: The Worst Programmer I Know (2023)
#308Earlier quoted context omitted.
> As far as I can tell, you can build very complex prototypes. I think GP was saying you can do more than prototypes. I agree, but it's not (yet) universal on where you can apply it. The best case for my projects has been in trivial but tedious "3rd party integrations". Say you have a mature product but client x wants integration with product z. We are now at a point where we can say "this is our internal model {json…
We're talking about vibe coding, not just AI-assisted coding. Do you put this in production without review?
edit:
So I did a quick google, apparently it's this:
> Vibe coding is an AI-dependent programming technique where a person describes a problem in a few sentences as a prompt to a large language model (LLM) tuned for coding. The LLM generates software, shifting the programmer’s role from manual coding to guiding, testing, and refining the AI-generated source code.[1][2][3] Vibe coding is claimed by its advocates to allow even amateur programmers to produce software without the extensive training and skills previously required for software engineering.[4] The term was introduced by Andrej Karpathy in February 2025[5][2][4][1] and listed in the Merriam-Webster Dictionary the following month as a "slang & trending" noun.[6] (from wiki)
So ... now I'm confused again. I don't see the no testing / reviewing part in here. Is vibe coding the new AGI, where everyone has a different definition?
Re: The Worst Programmer I Know (2023)
#309Used 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…
That's how you get individuals who insist that you attach their name to your ticket (or better yet, do it themselves) after they helpfully inform you about an automated test failure in your commit. "Relentlessly mentoring team members on culture of quality" et cetera.
Re: The Worst Programmer I Know (2023)
#310Earlier quoted context omitted.
I'm actually shocked that Tim, himself, knowing the metric exists and was going to be used in firing decisions, did not attach himself to all these tickets in the first place. Talk about a lack of self-preservation. Everywhere I've seen that measures performance by some metric, everyone instinctively tries to pump that metric all by themselves. No other motivation required.
Sounds like Tim's in a position where he knows he's appreciated by his team and enjoys his work, and is more than skilled enough to jump ship the second upper management decides to upend that. He has no reason to play the silly metrics games