Live data from Hacker News

The bottleneck was never the code

thetypicalset.com

381–390 of 446 posts

Re: The bottleneck was never the code

#381

Earlier quoted context omitted.

And I totally respect that, I get it, I really do. But it's really obvious when people are being territorial and any contractor will tell you this happens every time. I suspect that a lot of the times, I'm hired to "teach them a lesson" in that "Hey, velocity sucks and I'm hearing a lot of whining, so if you don't like doing it, this guy will" and people snap into shape.

Unless the team are seriously bad developers, many times, it’s the manager fault. As a hired consultant, you often benefit many freedom that team is lacking. As someone that has been hired as a consultant, one of those are meetings and not having to worry about office politics.

I love how everyone is blaming management and if they only listened to the programmer(s) everything would be fixed.

I’ve been on all sides of this coin, and there is plenty of blame, misunderstanding, and bad ideas to go around.

Re: The bottleneck was never the code

#382

It's hilarious to me to see the same kind of engineer, who throughout my career have constantly bitched and moaned about team meetings, agile ceremonies, issue trackers, backlogs, slack, emails, design reviews, and anything else that disrupted the hours of coding "flow state" they claimed as their most essential and sacred activity to be protected at all costs, suddenly, and with no hint of shame, start preaching abo…

I think you're assuming the venn diagram is a circle here, I don't think that's a healthy perspective to have (in any context).

Re: The bottleneck was never the code

#383
post #181

It's hilarious to me to see the same kind of engineer, who throughout my career have constantly bitched and moaned about team meetings, agile ceremonies, issue trackers, backlogs, slack, emails, design reviews, and anything else that disrupted the hours of coding "flow state" they claimed as their most essential and sacred activity to be protected at all costs, suddenly, and with no hint of shame, start preaching abo…

The activity that needed and still needs to be protected is problem solving: - Understanding the problem at hand - Putting all the pieces together so that they solve the right problem the right way - Making sure that the solution facilitate future extension and doesn't lead to a ball of mud two months from now... Unless stakeholders want it to be quick and dirty, then making sure they understand the costs/risks - Pla…

> Understanding the problem at hand

I think one of the things that AI is uncovering is how bad many programmers were/are at this. Sure , they may understand by ref vs. by val, but they can’t or won’t take the time to really understand what needs to be built.

I’ve said for a long time that coding is the easy part, it’s understanding what needs to be built that’s hard. AI has now come along and born that out.

Re: The bottleneck was never the code

#384

Earlier quoted context omitted.

Right. That is not a paradox as stated. The paradox would be: * a TV used to be really expensive. So a home just had one * over time TVs become half the price. * now a home has 3 TVs, i.e paying 150% of what they initially payed.

It is a paradox. The paradox is that increasing the efficiency of resource usage can lead to more resource usage. If you think that isn't a paradox because you can fairly easily explain why that is the case, you need to go and check what "paradox" means.

You said:

> No, we pay less for it. But there's much higher demand so overall use goes up.

This is economics 101, not a paradox.

To clarify how I read you: "If the price goes down, more people will want to buy, hence more units are sold"

The paradox is that _one_ person, or entity, pays more as the price goes down.

Re: The bottleneck was never the code

#385

Earlier quoted context omitted.

Should the paradox not be that we PAY more for it? Or, if some process is made more effective, i.e. takes shorter time, we spend more time in that process.

Unit cost is down but aggregate cost is up.

Which aggregate?

The aggregate for one person or for the world as a whole?

Re: The bottleneck was never the code

#386
post #28

Earlier quoted context omitted.

Are you referring to the author specifically? Or a specific hypocritical person you know? If you're making a general statement about groups of online people you might be falling for the group attribution error[1], where the characteristics of an individual are assumed to be reflective of the whole group. In any case, two things can be simultaneously true: 1. Writing code is not the bottleneck, as in we can develop fe…

I think it's obvious that they're not referring to the author or a specific person at all. They're talking about how the zeitgeist has changed. Look at Hacker News archives 3 or more years ago and it would be really hard to find anyone arguing that coding speed is not a bottleneck or that engineers need to spend more time in collaboration. You would find a lot of arguments that leaving engineers alone to code is the…

Speeding it up provides benefit if speed was the bottleneck to begin with. As the author notes or hints at, faster code output leads to more features being delivered, more room for experimentation, etc. But that's not necessarily productivity, if the features offer no value, if the experiments end up on a shelf, if the maintenance burden and context becomes bigger than the organization can handle (even LLM-assisted).

I've done a lot of "rebuild" / "second system" projects and the recurring theme is that the new version does less than the original. I don't think that's entirely down to the reality of second systems, I think that's in part because software grows over time but developers / managers rarely remove functionality. A full rebuild allows product owners (usually different from the ones of the original software) to consider whether something is actually needed.

Re: The bottleneck was never the code

#387
post #129

Earlier quoted context omitted.

No because the goomba is the average of two real opinions, and the strawman is a distortion/reduction of any opinion such that its easy to argue against.

More like a superposition of two opinions.

Schrodinger's Goomba?

Re: The bottleneck was never the code

#388

It's hilarious to me to see the same kind of engineer, who throughout my career have constantly bitched and moaned about team meetings, agile ceremonies, issue trackers, backlogs, slack, emails, design reviews, and anything else that disrupted the hours of coding "flow state" they claimed as their most essential and sacred activity to be protected at all costs, suddenly, and with no hint of shame, start preaching abo…

I've had seniors tell me my entire career that writing code was the easiest part of their jobs.

I’m one of those, and it’s true.

One of the reasons I liked coding is because it’s easy on a relative basis. Dealing with people, ambiguous requirements, edge cases, business realities, are all the parts that are hard.

American football player Ray Lewis said one time he was paid to go to practice, but he played the games for free. I feel the same way about coding - I was (and still am) paid to deal with everything else.

Re: The bottleneck was never the code

#389

Earlier quoted context omitted.

Because a claim was made about a group of people.

Exactly. Does it matter if one member of that class does not follow the trend?

No, but no-one said that. It's far more likely that this "group" of people doesn't even exist, and it's yet another case of treating "strangers on the internet" or "other people" as one person and being upset when that "person" is being inconsistent.

Re: The bottleneck was never the code

#390

It's hilarious to me to see the same kind of engineer, who throughout my career have constantly bitched and moaned about team meetings, agile ceremonies, issue trackers, backlogs, slack, emails, design reviews, and anything else that disrupted the hours of coding "flow state" they claimed as their most essential and sacred activity to be protected at all costs, suddenly, and with no hint of shame, start preaching abo…

That was me. I complained a lot about meetings, design docs, etc. I did not understand that the process of discovery is messy and what looks inefficient is not really. I expected sharper meetings, shorter docs etc. In retrospect I see my naivety but it took me too long to change my attitude.
Post reply on HN