Earlier quoted context omitted.
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 collaborati…
I require Jira for all my work to protect myself from three things, definitely not productivity: 1. µManagement asking "What have you even been doing?" Now they have a dashboard, and I have a nice record. 2. Protect me from people who wouldn't tell me problems existed, but would tell their managers they were blocked by those problems. Now, the understanding is that if the Jira doesn't exist, then the problem doesn't…
The bottleneck was never the code
361–370 of 446 posts
Re: The bottleneck was never the code
#362Earlier quoted context omitted.
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 h…
If anything, genAI for coding is making engineers seek more engagement, that can't be a bad thing given the fracture between the business and product development.
Re: The bottleneck was never the code
#363As software engineer, we should collectively realize that this is all cope. Every article or comment about how AI will never be smart enough, etc, etc will only be true until its not. One of our main valuable skill sets is now partially automated. Some of us are completely obsolete and its coming for the specialists and more experienced ones within a decade tops. You're not going to convince anyone that "um actually…
Yeah, you're definitely right about the shifting goalposts ("it's a stochastic parrot" -> "it hallucinates all the time, it can't even get APIs right" -> "it can generate functions but can't reason about the codebase" -> "the bottleneck was never shipping code") At the same time, humans can move up the abstraction ladder faster than the LLMs can. At least, some humans. Agents can produce lots of code. They can also d…
This was kind of the point, its only true for now. I agree with you that this kind of stuff will take longer. I don't think there's probably good training data for it right now. Handling abstractions and course correcting is probably the job now, and it also happens to be exactly the data that we will be typing in our prompts. They'll train on it or something like it.
Re: The bottleneck was never the code
#364Earlier quoted context omitted.
You are not wrong about anything you’re saying but like I said this misses the forest for the trees. I’m talking about like the next ~2 years. There is a common idea that we don’t understand this technology or what will happen performance wise. We know a lot more about what’s going to happen than people think. It’s because none of this is new. We’ve known about neural nets since the 40s, we know how RL works on a fun…
> look at say Claude sonnet 3.x. It’s an entire world away in like a year In the area I work I find them to be of very little value both then and now... I see no real difference. They help in marginal tasks. Eg. they catch typos, or they help new programmers to faster explore the existing codebase. So far, I haven't used a single line of code generated by AI, even though I've seen thousands. Some of them worked to dr…
> I see no reason to believe it's going to get better. Waving hands more forcefully isn't helping, there's no argument behind the promise of "it will get better".
That’s a real bummer to read that from someone who sounds like a professional, and not only a professional but someone thoughtful and smart. 30 years of brilliant work in RL, Bayesian stats, machine learning, measurement, and then trillions of dollars of funding and some of the best talent in the world, and your assertion is “I tried it on my codebase and I didn’t like it and that trumps literally entire fields of mathematics and statistics”. I mean, have you heard of Chinchilla scaling laws? Do you know how RL works? are you aware of benchmarks, their strengths and weaknesses? Are you following adoption numbers, accomplishments like new proofs of unsolved erdos problems?
> But, more importantly, the AI is applied on a level where really important things don't happen. It's automating boilerplate work.
Your experiences are your experiences, I don’t know what work you do or how it gets done, what languages you’re working with etc. but literally we’re at the point where the vast majority of code at major tech companies is fully AI written (not assisted).
> It's not the kind of decision it's called to make and nobody sensible would trust it to make such a decision because there isn't a clear right or wrong answer
What are you claiming is not fundamentally possible for an AI to do that a human can do here? People make judgement calls on ambiguous problems, taking into account vast amounts of context about the business, dev time, reliability, maintenance, etc; why do you think AI can’t do that?
Re: The bottleneck was never the code
#365Earlier 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…
Re: The bottleneck was never the code
#366Re: The bottleneck was never the code
#367Now if your design / requirements are wrong who cares? Tomorrow you will have a brand new stack.
Re: The bottleneck was never the code
#368Earlier quoted context omitted.
til https://en.wiktionary.org/wiki/Goomba_fallacy
The collective smarts on the Internet can't come up with a better name that might help our brains tag the concept? Although at least it has some cross-cultural references. Why is naming so hard.
Re: The bottleneck was never the code
#369Earlier quoted context omitted.
til https://en.wiktionary.org/wiki/Goomba_fallacy
The collective smarts on the Internet can't come up with a better name that might help our brains tag the concept? Although at least it has some cross-cultural references. Why is naming so hard.
Re: The bottleneck was never the code
#370Earlier quoted context omitted.
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…
Needing focus to think is not the same as needing focus to write code.. It can take a whole day to find 10 good lines to write.
So we've come full circle to code writing speed being a factor again? :)
In all seriousness, this just feels like a never-ending list of attempts to try to resist any notion that LLMs might accelerate software development, however small the increment. The original article was arguing that organizational and collaboration was the bottleneck and that taking a whole day to think about the code was not.