It’s more that tired experience has taught that of the various disciplines, web devs are the most likely to have a shaky-at-best understanding of fundamentals, and thus do silly things like assume network calls will never fail, or store everything in JSON blobs and then wonder why their queries are slow.
I’ve also worked with some awesome web devs, to be fair.
It's wild to me that a lot of people consider that SWE need to be knowledgeable in business requirements and interact with clients all day.
Just try to imagine construction workers doing the same thing when building a skyscraper. Instead of laying bricks, mortar and beams, now every worker loses 1-2 hours each day asking each stakeholder separately what they want, if they like how it's going so far etc. And then make changes to the layout when the clients ask! What kind of monstruous building will emerge at the end?
Edit: if you downvote, at least provide a counter argument. Or is etiquette dead?
Construction worker is a spectacularly bad analogy for software engineer.
The architect and structural engineers design the building well in advance. Construction workers are mainly arranging materials according to a prewritten design.
Software engineers are not given specs that are equivalent to blueprints. They are given requirements or user stories. Then they have to flesh out the final real specification in place.
And then from the specification, decide how to implement it, which is not decided at all ahead of time.
Also, what software engineers are building is almost always somewhat novel, at least dramatically more novel than a typical building. It very often involves some type of research task, even if that is just sifting through components and configuring them.
There is much more room in software engineering for 1) miscommunication or poor communication of users needs, 2) substantive tradeoffs discovered based on technical details or 3) subtle contradictions in requirements from different stakeholders discovered during implementations, 4) better understanding of requirements by users discovered during prototyping, etc.
They should have a general idea of what they are building and why, in exactly the same way as a construction worker.
That doesn't mean they spend all day asking stakeholders what they want. It means that when there is a choice and the stakeholder has to make a decision, the developer should be able to understand some of what the stakeholder is looking for so that they can recommend a direction.
Sure, a carpenter is just putting up a wall, but if they're experienced and they see that there's going to be a joist that is going to block some feature, they should be able to point that out to the architect or builder or client.
Absolutely agree, but in practice this means devs are expected to sit in meetings with clients multiple times a week just to make sure everyone is on the same page. This also means that either all the devs on the team are required to be present, wasting time, OR that devs meet with stakeholders individually and knowledge ends up decentralized.
And secondly, I think that devs are expected to know WHY "all frobs are percurators" instead of just knowing that they are. Besides keeping up to date with all the tech stack, you are now expected to keep up with all the business details of your client (client which might change in a year or two).
The other argument about this is whether or not an SWE is a fungible resource.
When you're doing a construction schedule, you might have a pool of carpenters, pool of electricians etc. They can be assigned to the different jobs as a fungible resource, a different carpenter can take over a task just like one power drill can take over another.
We all know that no matter how much ceremony and process, SWEs are not equal, so you can't just move them around randomly.
If upvoting doesn’t require justification neither should downvoting.
But let me try to express why people disagree.
Change is software compared to physical systems is comparatively incredibly cheap. Unlike in building something known, design at the start of a software project is unlikely to be the one the client actually wanted nor would be the one that is one going to be build. Or at least it shouldn’t be.
The “brick-laying” part of software isn’t the hard part. Depending on want to analogise as “brick-laying” in software, that part could automated. Push to main and the deployment pipeline runs tests, makes sure things are working and voila! You have a new “house”. If its ugly or falls apart in software, easy , just revert to the previous version and its like nothing happened. Client wants a try different layout, it can be done affordably.
Most of the time in software engineering you don’t know exactly how to do something, there is always a degree of discovery, experimentation and learning involved. Heck the client probably isn’t expressing what they want clearly enough, and probably will at some point change their mind. Thus interacting with clients and customers is valuable.
> If upvoting doesn’t require justification neither should downvoting.
I disagree, since downvoting is not equal to upvoting. First off, not everyone has the ability downvote (at least on hackernews). Second, upvoting usually means you agree with something, while not agreeing should be reserved to the action of NOT upvoting. This is how most social media works. Downvoting should be reserved for something that should not belong on the thread.
Regarding the topic of the discussion, I agree that "builders" should be proactive and knowledgeable about the system that they are building, but the "chief architect"/project manager should be the intermediary between them and the clients, if for nothing other than being a single source of truth.
- Providing boilerplate/template code for common use cases
- Explaining what code is doing and how it works
- Refactoring/updating code when given specific requirements
- Providing alternative ways of doing things that you might not have thought of yourself
YMMV; every project is different so you might not have occasion to use all of these at the same time.
I appreciate your reply. A lot of people just say how wonderful and revolutionary LLMs are, but when asked for more concrete stuff they give vague answers or even worse, berate you for being skeptical/accuse you of being a luddite.
Your list gives me a starting point and I'm sure it can even be expanded. I do use LLMs the way you suggested and find them pretty useful most of the time - in chat mode. However, when using them in "agent mode" I find them far less useful.
"Agent mode" is vastly different in many ways. I suggest you read up on how people write things like CLAUDE.md files. But as I said earlier, every project is different, and one what one person was successful with won't necessarily make you successful, so you may find it more helpful to get somebody to coach you through prompting agents for your particular projects.
At some point no-one is going to have to argue about this. I'm guessing a bit here, but my guess is that within 5 years, in 90%+ jobs, if you're not using an AI assistant to code, you're going to be losing out on jobs. At that point, the argument over whether they're crap or not is done.
I say this as someone who has been extremely sceptical over their ability to code in deep, complicated scenarios, but lately, claude opus is surprising me. And it will just get better.
> At that point, the argument over whether they're crap or not is done.
Not really, it just transforms into a question of how many of those jobs are meaningful anyway, or more precisely, how much output from them is meaningful.
I don't agree. I've recently started using claude more than dabbling and I'm getting good use out of it.
Not every task will be suitable at the moment, but many are. Give claude lots of direction (I've been creating instructions.txt files) and iterate on those. Ask claude to generate a plan and write it out to a file. Read the file, correct what needs correcting, then get it to implement. It works pretty well, you'll probably be surprised. I'm still doing a lot of thought work, but claude is writing a lot of the actual code.
I still fail to see the regulation inflation. It is not like there was an absence of regulation before the EU. But now once you comply with EU regulation, you have access to a significantly larger market than before, where you had to comply with national regulations.
So yeah, depending on what market your institution is from, you might see an increase in regulation. But changes are, once you expand beyond national borders, you have less regulation to deal with as compared to before the EU.
AI, RGPD/DSA/etc, yearly money laundering regs are a good example. They come on top of local regulations, they don't replace them. Each country still has its own special laws.
The original EEC was to help maintain peace through economic interdependency. Now the EU is very different with ultimate goal of full integration, i.e. a federal state. The single market is a step, the single currency is another step, EU Parliament, tax rules, now possibly defence matters, etc. Step by step but always in the same direction.
The EU started with the coal and steel initiative, which created a common market for those commodities. It was indeed "peace through trade", but mainly trade.
And the goalpost has since moved very far, I don't see really how preventing countries from sending back illegal immigrants or making same-sex marriage has anything to do with European peace.
The point made is still valid since the EEC was created in 1957 and, before it, the Coal and Steel Community in 1951. Of course it is also unclear what they had in mind with that phrasing, and perhaps it even varied depending on whom you asked: The UK government under Thatcher signed it but I think we can all agree that she wasn't aiming for a federal EU (her famous "No, no, no" speech in 1990 makes it beyond doubt). I think the people at large did not want nation states to disappear within a federal EU, either (and probably still don't).
It's still simpler to deal with EU regulations instead of dealing with the national regulations of each member country. The weaknesses of the EU are where the member countries are not aligned yet.
The problem is that it also prevents countries from reducing the regulations in order to foster local innovation, avoid disadvantageous rules (there are more lobbyists than bureaucrats in Brussels, for a reason) or adapt to a new reality (AI being a good case). Moreover, each country still have their own specific laws, the EU regs come on top, and don't decrease the amount of laws. And the EU votes a lot of laws, since its the main power it has, on average 7 per day.
Individual countries are free to scrap their own regulations that are redundant or counterproductive due to EU regulations. There are still a lot of domains that are not or under-regulated by the EU. Since that doesn't seem to happen, something on the national level is not working, and the utility of national legislation over EU legislation starts to seem doubtful.
hackernews: where a large portion of programmers are considered inferior because of the domain they work in (the domain where hackernews also lives)
reply