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 feel attacked. I still dislike most team meetings, agile ceremonies, etc. Slack and emails give me anxiety. A 30 min meeting will disrupt me for 90 minutes. But, yea, the code was never the bottleneck. Except maybe when I worked at a startup. All of the above are true. Personally I find it hilarious that the same people at my company who can't be bothered to write down detailed requirements and are constantly fight…
Um… how do you get those requirements if slack / email give you anxiety ? And meetings are disruptive ? I am genuinely curious. I understand where you are coming from, you want to maintain flow state. How does one effectively load the funnel to support flow state ? Jira tickets? Requirements documents in some kind of ALM tool?
Hmm... everyone is different and I'm not sure I'm the best representative of the "flow state" crowd. For one, I'm a DS not an SWE. Also I tend to do more research-y projects, projects where the requirements are vague at the start of the process and a big part of my job is requirements gathering. Projects that aren't super time sensitive TBH. Jira rarely works well. So the projects that have worked best for me involve lots of brainstorming meetings at the start, then documentation (literally Word docs), then development work, then restart the cycle. The worst projects involve stakeholders who want to make science decisions in real time. If that makes sense? None of this may apply in your world.
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…
Sounds like JIRA is a very important tool.
Nothing special about Jira, specifically. The clear record/state is what's important.
I feel attacked. I still dislike most team meetings, agile ceremonies, etc. Slack and emails give me anxiety. A 30 min meeting will disrupt me for 90 minutes. But, yea, the code was never the bottleneck. Except maybe when I worked at a startup. All of the above are true. Personally I find it hilarious that the same people at my company who can't be bothered to write down detailed requirements and are constantly fight…
Isn't solving problems, instead of blindly implementing a high-level description of the solution, your job as a developer?
I don't understand this reply. Yes, I solve problems all the time. And that usually requires thinking deeply about the problem. And that deep thought is difficult when I'm getting constantly pinged about other stuff.
You don't wait. You run multiple independent incremental feature in parallel, while also running a code review, which will create the next set of tasks while you or the llm think up the feature to add after.
Context switching back and forth between a dozen different things is sort of the opposite of flow state, IMO.
It's not "flow state" but working on three features in parallel requires focus that's equally as fragile, at least if you want to follow the output of the LLMs and steer it if it makes mistakes.
> Obviously usage of something goes up when it gets cheaper. Sure. But is it not also obvious that when usage of a resource becomes more efficient, the price of that ”usage” becomes cheaper? So usage goes up obviously because efficiency increases. It is called a paradox because some people naively think that increasing efficiency is a good way to decrease consumption. Almost everything that is called a ”paradox” is t…
It’s surprising (not using the term paradox) in situations where demand was seen as inelastic. An example of probably inelastic demand is the cost of diamonds which has fallen as synthetic diamonds enter the market. But people typically don’t buy more engagement rings than before. With code it could be different. People might think that the amount of code that needs to be written is fixed, so the ability for a person…
> Only people who never worked in a software company could believe that.
Unfortunately these are many of the same people who make company-wide hiring decisions. They’re getting their sentiment from some guy 15 years younger who also never wrote any code, who heard a sound bite on a business podcast 6 months ago.
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…
Yes! So much of professional software development is about assisting the nominal job of management—planning and budgeting—rather than users or even business fundamentals. Why am I awake at 1:00am, ruining my brain and body, trying to get this feature finished before the end of the week instead of three days later? Ah yes, so that we meet our quarterly OKR, and the next quarter's plan that the EM and PM negotiated wit…
> Why am I awake at 1:00am, ruining my brain and body
Stop. They don't deserve it. If you have to sacrifice yourself, do it for someone who deserves it.
Value your body, value your life. Your bosses see you as a piece of meat.
yes, most places I have worked were hobbled by the organizations being completely idiotic. which is why engineers want to be left alone to code, historically. Better to be left alone than dealing with insane bureaucracy. But even better than that is working with good bureaucracy. Just, once you know it's insane, there's not really anything that you can personally do about it, so you check out and try to hold onto a s…
> there's not really anything that you can personally do about it Small companies/startups don't have insane bureaucracy, and they're hiring.
They also expect you to do 4 roles in one while low-balling you because you are not in the USA.
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…
I don't think that this is very hypocritical on the part of the developer holding such views. Typing code has never been the bottleneck, building the mental model has. You need the mental model so you know how the domain and the actual model will interact, which is needed for pre-empting what tests you need, what QA you need to do, etc etc. and the limitations of the system. You can demo this out with a specification…
I was an LLM naysayer for a long time. During that time I would have agreed with you. Recent experiences have changed my mind. The accuracy I get from models does not suffer from the problems you describe, and many of the issues you're describing are also true, in different ways, of human beings. There's never any guarantee that any of the text you or I produce will be accurate, or that our summary of it will be accurate, but if you ask us to generate text, we will. It recalls that funny meme: "Your job application says you're fast at math. What's 513 * 487?" "39,414." "That's not even close." "But it is fast."
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.
And sometimes an LLM can find those 10 lines in 10 minutes. Or it can find a 100 and you cut them down to 10 in two hours total. Yes I've seen this in practice. The amount of code an LLM can tirelessly ingest is super human.
Twenty minutes ago Claude digested about a dozen pipeline definitions, a sequence of build files and targets, read the scripts they use, found the variable that I could reuse for my purposes, and made the appropriate change in the right (looking) place, so that I'd be able to achieve my goals.
I could not have done this nearly as quickly. On the other hand, I gave it clear, precise instructions.