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

151–160 of 446 posts

Re: The bottleneck was never the code

#151

Post by kadhirvelm »

Totally agree, we wrote our own piece similar to this: https://productnow.ai/blogs/teams-that-coordinate

I really think as code becomes cheap, misalignment between people, teams, and organizations is going to hurt a lot more, especially when everyone is trying to move at break neck speeds.

I also think a big piece of this is human attention and inertia. Aka, why bother doing the hard work to coordinate with others when you can just ship whatever you’re thinking. I think whichever organizations can figure out the human and cultural aspects to this will do phenomenally

Re: The bottleneck was never the code

#152

Post by ChrisMarshallNY »

> Software is what’s left over after a group of humans finishes negotiating with each other about what the system should do.

Love that.

I agree, in particular, about the context. That’s where long-retention, experienced, teams pay off.

I managed one of those for decades. When they finally rolled up our department, the engineer with the least seniority, had ten years.

When a team is together for that long, the communication overhead drops to an almost negligible level.

That’s what I find most upsetting about the current culture of mayfly-lifespan employment tenures.

Nowadays, I work mostly alone. I’m highly productive, but my scope is really limited.

I miss being on a good team.

Re: The bottleneck was never the code

#153

Post by albedoa »

abduhl wrote: post #34
forgotaccount3 wrote: post #23

Earlier quoted context omitted.

> nakedly hypocritical How is it hypocritical? If in the old world, the very important process that used up a lot of time and benefited greatly from no distractions was the actual writing of code then interruptions for various ceremonies with limited value other than generating progress reports for some higher ups would feel like a waste of time. That same person in the 'new' world where writing code is very fast but…

Well it is hypocritical. Hypocrisy is an action or statement that is contrary to a stated value or principle. Just because your values or principles changed doesn’t make you a suddenly no longer a hypocrite, it just admits that your former opinions are no longer tenable. I’ve noticed this push to try to clothe hypocrisy in made up virtues like intellectual curiosity and mental plasticity a lot lately. All I can think…

> Just because your values or principles changed doesn’t make you a suddenly no longer a hypocrite

Uh yes it does?? What are you talking about.

https://www.google.com/search?q=hypocrisy

Re: The bottleneck was never the code

#154

Post by MyHonestOpinon »

zabzonk wrote: post #45

> Real programmers don’t document their programs. Probably true, but I, for one, have always liked documenting how the code I've written should be used, whether programmers calling APIs I've created, or end-users actually making use of a program's executable. I find writing the docs just as interesting and creative as writing code.

> Real programmers don’t document their programs.

This is kind of a straw man. I suspect people say that tongue in cheek.

Good programmers try to make their code clear and easy to understand. They add comments to clarify, specially their whys.

The problem I have with documentation is that you end up with mountains of documents over time about a lot of things that are no longer true and many times contradictory. The only solution I have seen is making sure that documents have owners that update them periodically.

Re: The bottleneck was never the code

#155

Post by i_love_retros »

tlkan wrote: post #60

One of the bottlenecks has always been the code. That code has been stolen and is being laundered while companies rely on mediocre engineers who have never written anything of value to promote the burglary tools and call the process "writing software". It is the same as putting an Einstein paper on a photocopier and call the process "writing a paper". I agree with the point of the article though: code generation does…

I think the solution is to fix society so that we value quality over quantity, self betterment over getting rich, and making society better for every one rather than worshipping billionaires.

Re: The bottleneck was never the code

#156

Post by jayd16 »

tempaccount5050 wrote: post #99
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…

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…

Well who are you? Why should they trust you to actually complete a task and not dump unfinished work on them when your contract is up?

The manager didn't do the work to figure out what a contractor should do before hiring one. Why would they expect that org to plan the exit if they didn't plan the entrance?

Behavior shouldn't be surprising, no?

Re: The bottleneck was never the code

#157

Post by bcooke »

hirako2000 wrote: post #115
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…

> No developer was ever unhappy to communicate

I've worked with engineers all over the spectrum in terms of their styles, beliefs, and preferences... and some of them are frankly not very interested in getting out of their comfort zone (like heads down, writing code and being alone), and optimizing for the group rather than themselves.

So yes, they are in fact unhappy to communicate (in a general sense), because of how tedious and uncomfortable communication often is.

I'm not saying it's irrational or immoral, or not driven by the types of past poor experiences you mention, but in my experience it's often pretty obviously suboptimal and highly frustrating to work with.

Re: The bottleneck was never the code

#158

Post by syntax-sailor »

An awful lot of problems can in fact be solved by 'more code' in fact. People seem to straw man this in terms of product feature surface.

A lot of places skip creation and maintenance of decent observability - that's code.

We can now easily use advanced, code heavy testing techniques like property testing - code.

We can create environmental simulations to speed up and improve integration testing - code.

We can lift up internal abstraction levels, replace boiler plate with frameworks, DSLs - code.

Re: The bottleneck was never the code

#159

Post by skydhash »

neogodless wrote: post #130
nilirl wrote: post #11

Bottleneck for what? More features? I don't think amount of software is what determines whether a company does well. I don't think capturing quantity of context is that important either. Now, quality of context. How well do the humans reason? Then, attitude. How well do the humans respond to bad situations? Then, resource management. How well does the company treat people and money? Finally, luck. How much of the unc…

For business, software applications are tools that facilitate "the thing" that generates money. (We in the software world think that _thing_ is software and software _features_, but outside that world, there's usually a different _thing_.) The bottleneck for making software applications better at being used by (non-software) businesses is making sure the software does all the software things that actually benefit the…

> But yes, the speed can really help. You can prototype and trial and improve the feedback loop.

Based on what I’ve seen, prototyping has been always easy. You don’t even have to build software for the first iteration. For UI stuff you can use a wire-framing tool.

What has happened is that we abandoned the faster iteration methods (design think tank, quick demo and UX research,…) and we have full in on building the first idea that came in and fostering it on the users. That process is very slow and more often goes wrong.

Re: The bottleneck was never the code

#160

Post by ryandrake »

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…

> I simply have never seen a Dev Team work as the way HN tries to make the role sound "Dev/Eng and the customer is the only thing needed". Would love for this to be the case!

I think a lot of HN truly believes that Software Developer is the only important role at their company. Software goes straight from the developer's brain, through his fingertips into the computer, and then on to the online store (run by nobody) for customers to buy. Engineering managers, program managers, product managers, marketers, MBAs, tech writers, QA, lawyers, process people, various admins and liaisons... they all exist to play pointless political games, have distracting meetings, and obstruct the One True Role. Design docs, planning, schedules, e-mails, JIRA, reviews, syncs, exec updates... all are useless parts of a scheme to torture the developer. It should just be "developers developing, and then money comes in from somewhere." This is an exaggeration, but you see these themes all over the comment section.

Post reply on HN