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

The bottleneck was never the code

thetypicalset.com

Post reply on HN
Print view View original

111–120 of 446 posts

Re: The bottleneck was never the code

#111

Post by adrian_b »

ftmootnomoat wrote: post #26
nayroclade wrote: post #15

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…

This is a false dichotomy. Software development has always been about keeping people in agreement, from the customer to the coder, and all the people in between (the fewer the better). Meetings that increases sync between customer and coder are few and precious. In large organisations ceremonial meetings proliferate for the wrong reasons. People like to insert themselves in the process between customer and coder to a…

Well said.

This matches perfectly my experience in working in many companies, where in most of them meetings were useless, but in a few places meetings were very useful, depending on how the companies were organized and how the attendance to meetings was selected.

I have seen projects that had to be abandoned without bringing any money, despite being executed perfectly according to the specifications. The reason was that the specifications were wrong because the customers have not thought about describing some requirements and the developers could not ask about those, because of lack of direct communication, while the middle men had no idea about both things, about what the customers might require and about what the developers might need to know.

Re: The bottleneck was never the code

#112

Post by tempaccount5050 »

aleph_minus_one wrote: post #105
tempaccount5050 wrote: post #99

Earlier quoted context omitted.

It's 100% denial/ego. I've been a contractor longer than I'd like and it's the exact same response I see when I join a new team. The team complains they have too much work and can't get anything done, so their manager pulls me in. Suddenly, they don't want to give anything up. I'm actually in the middle of this right now. The team "is swamped" yet somehow, they are able to argue that almost everything I can handle is…

> A - they are replaceable and their work isn't that unique and B - they are the bottleneck, not the process or workload. The problem rather is: often good programmers have quite good ideas how these problems could be solved, but for "organizational politics" reasons they are not allowed to apply these solutions. Thus: Concerning (B): Because they are not allowed to apply their improvement ideas, they are the bottlen…

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.

Re: The bottleneck was never the code

#113

Post by IshKebab »

TheLudd wrote: post #107
paldepind2 wrote: post #100

From the article: > Jevons Paradox: when something gets cheaper, you tend to use more of it, not less. That's a butchering of Jevons paradox. What's stated is not a paradox, but a very natural effect. Obviously usage of something goes up when it gets cheaper. What Jevons paradox actually describes is the situation where usage of a resource becomes more efficient (which means less of it is needed for a given task), bu…

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.

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

Re: The bottleneck was never the code

#114

Post by tikhonj »

nayroclade wrote: post #15

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…

Ceremonies and tickets aren't especially effective for actual collaboration. They're primarily tools for making work legible and controllable to management.

There is a reason (well, many reasons) that, if I'm working on a creative project with somebody outside a company, we would never think of reaching for Scrum ceremonies or Jira.

It is more than perfectly consistent to complain about that while valuing collaboration.

Re: The bottleneck was never the code

#115

Post by hirako2000 »

nayroclade wrote: post #15

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 bitching was about meetings and ceremonies that took away the little time left to spend time asking more features to be implemented, or revisited before it could get completed.

No developer was ever unhappy to communicate. But when pointless communication occupies too many long hours, interrupting useful the progress of understanding what could and should be done (by coding, yes, experimenting, getting a grasp of the beast), then yes they became unsympathetic.

Re: The bottleneck was never the code

#116

Post by mayhemducks »

rudyp_dev wrote: post #19
jorisw wrote: post #10

Earlier quoted context omitted.

> difference between code used to implement a product and when code _is_ the product Care to elaborate? I don't understand the difference unless you mean code that _is_ the product, being OSS code or code for license.

I think what I'm trying to get at is that there's a lot of code out there that really just needs to work. It doesn't need to scale to millions of users, it doesn't need to be abstract-able and useful to use cases we don't even know about yet, just needs to get an idea off the ground. That code is not the product. In such a case writing the code very much is a bottleneck. If you're writing OSS code or software project…

In my mind this is what prototyping is for. Just get it working quickly and see if the concept has legs. But be prepared to completely re-write it because the "just make it work" mindset will make it more difficult to change and improve upon in the future.

But when you factor in today's favorite business model of "make it shitty", perhaps this matters very little.

Re: The bottleneck was never the code

#117

Post by goda90 »

nayroclade wrote: post #15

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 posit that getting into a coding flow state isn't just about producing code. It morphs and develops the problem space in the engineer's head. It helps them realize where the spec is lacking. It familiarizes them with the capabilities of the codebase so they can speak confidently about what future changes will entail.

Re: The bottleneck was never the code

#118

Post by vishnugupta »

nayroclade wrote: post #15

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 got nothing to add to the discussion but want to take a moment to appreciate your ability to construct long sentences. It flows beautifully.

Re: The bottleneck was never the code

#119

Post by stronglikedan »

xquce wrote: post #101
ftmootnomoat wrote: post #26

Earlier quoted context omitted.

This is a false dichotomy. Software development has always been about keeping people in agreement, from the customer to the coder, and all the people in between (the fewer the better). Meetings that increases sync between customer and coder are few and precious. In large organisations ceremonial meetings proliferate for the wrong reasons. People like to insert themselves in the process between customer and coder to a…

Not a false dichotomy. I agree with OP and I can say for certain that if you are one of the few developers that is "fond of meetings with customers" you are not the the type of person OP is talking about, and you are more rare than you think. I am a former Dev turned PO/PM and now CEO, I can tell you many a developers are not fond of those meetings you are fond of and people like myself don't insert our selves where…

> you are more rare than you think.

Truth. I'm that person and didn't appreciate how rare I was until I became an EM and learned that most of my team would actively avoid conversations with the customer. Even though I have no way to quantify it, I'm sure it's benefitted my career.

Re: The bottleneck was never the code

#120

Post by TheLudd »

IshKebab wrote: post #113
TheLudd wrote: post #107

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.

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

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.
Post reply on HN