Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Worst Programmer I Know (2023)

dannorth.net

Post reply on HN
Print view View original

281–290 of 385 posts

Re: The Worst Programmer I Know (2023)

#281

Post by ArthurStacks »

glouwbug wrote: post #272
ArthurStacks wrote: post #233

In my company I would have told him to start doing some work and getting stories delivered or he's gone. Yes, he's being useful in assisting others but I can easily find someone who can do that and their own work at the same time. He doesnt need to be sat there with others the whole time. What is likely going on there is Tim is playing his boss, playing up his pairing role and its benefits in order to sit being idle…

Might it be that he’s so good everyone comes to him first and not you?

I would not hire him in my business regardless of how 'good' he thinks he is. I'm interested in people who can get work done.

Re: The Worst Programmer I Know (2023)

#282

Post by lodovic »

psychoslave wrote: post #169
lisper wrote: post #162

Earlier quoted context omitted.

> who was writing the most code There's yer problem right there. Code quantity is not correlated with value. In fact, it can be negatively correlated with value if it's buggy and laden with technical debt. Measuring productivity by lines of code produced actively discourages writing clean, maintainable, bug-free code.

Turning a 100+ lines function of 5+ intertwined control flow mess into a single expression using a combination of method chaining of just a few lines is always a delighting experience to my mind.

Until a coworker needs to debug a specific edge case that was too specific for the single expression, and it all has to be rewritten back to long form. Dense code is not always better and sometimes makes a code base incomprehensable.

Re: The Worst Programmer I Know (2023)

#283

Post by siva7 »

stickfigure wrote: post #271
bitwize wrote: post #175

Earlier quoted context omitted.

Vibe coding is now a skill requirement for real, actual jobs but, thankfully I guess, no place I want to work (yet). The other day I saw a YC24 company in the "financial services industry" with a "vibe coder position". A prerequisite for the position was at least 50% of your current code being generated by AI; vibe-coding experience was "non-negotiable". Traditional programmers need not apply. And you'd better be rea…

This must be satire. It is a stretch even for Poe's Law. Someone is punking YC.

No it's not.

Re: The Worst Programmer I Know (2023)

#284

Post by siva7 »

eclipxe wrote: post #140
fsndz wrote: post #127

Earlier quoted context omitted.

it's definitely nice for prototypes, but nothing more complex.

I used to feel that way but my perspective over the last 6 months has changed greatly. You can absolutely build very complex things in this style

I wouldn't trust vibe coding to a junior. This would be a recipe for desaster. It's a skill best paired with a very senior dev who can correctly assess the output of the AI.

Re: The Worst Programmer I Know (2023)

#286

Post by atoav »

Every metric bas unintended side effects. Sure capitalists tend to think the greatest stuff happens from competition, but for real competition you need redundancy -and pay multiple people for writing functionally the same code.

Competition within teams selects for the people who invest most time into looking as if they produced worked punishes those who are good team players.

On top of that, how do you compare a guy who produces 100k lines of unmaintainable boilerplate code versus a guy who in the same timeframe hunts down a particularly nasty and hard to fix race condition and changed 1 line in the end? Any programmer knows the latter is much more exhausting and provides lasting value, while the former might actively hurt the project down the line.

If you manage software development either you trust your team or you have to understand the program yourself and micromanage them. Best would be to trust and understand the program and only inject yourself when it is really needed.

Re: The Worst Programmer I Know (2023)

#287

Post by hadlock »

slowtrek wrote: post #255
sour-taste wrote: post #237

Earlier quoted context omitted.

This is what Japan does. Employment is presumed to be for life. There are games companies play to get out very poor performers but most people get approximately lifetime employment.

How was that society taught this? Or how did they come to know this?

What are you asking

Re: The Worst Programmer I Know (2023)

#288

Post by rightbyte »

lodovic wrote: post #282
psychoslave wrote: post #169

Earlier quoted context omitted.

Turning a 100+ lines function of 5+ intertwined control flow mess into a single expression using a combination of method chaining of just a few lines is always a delighting experience to my mind.

Until a coworker needs to debug a specific edge case that was too specific for the single expression, and it all has to be rewritten back to long form. Dense code is not always better and sometimes makes a code base incomprehensable.

Single use long functions are great for debuggability and following the code path.

Injection or whatever fancy term used for passing function pointers around is ofent write only.

Re: The Worst Programmer I Know (2023)

#289

Post by NitpickLawyer »

Yoric wrote: post #153
eclipxe wrote: post #140

Earlier quoted context omitted.

I used to feel that way but my perspective over the last 6 months has changed greatly. You can absolutely build very complex things in this style

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 dump}, this is the 3rd party integration docs / example {code dump}, write interfaces for this". And it works most times. For things that are a bit more complicated, /architect first and then "now write it" w/ some things from the architect session in context also works.

YMMV but don't dismiss it out of habit. Things are moving very fast in this space, and I choose to focus on what works now, not on what doesn't. I'm well aware not everything works, but when it does it saves a lot of time.

Re: The Worst Programmer I Know (2023)

#290

Post by PeterStuer »

You get what you measure. If your metric is claimed completed story points, you'll get people good at claiming story points.

Every system can and will be gamed, either directly or indirectly through osmosis and attrition.

The only way to win is not to play. Put people in charge that know how the pie is made, then trust them to make the right calls.

This btw is one of the major reasons why non-technical founders/managers so often fail.

Post reply on HN