What scares me about ChatGPT is less so that I’ll lose my job (though it’s possible), but more so that I’ll be using language models to work at higher and higher levels of abstraction doing mainly configuration tweaking. Some of the particular pain points expressed in the article should be removed with AI in the loop development, but it’s another step away from “real programming”, which is what attracted most of us t…
Its already like this. My first job in the 90s I wrote our own linked list classes, a logging framework and a persistence layer. Now it feels like I write css and yaml all day.
The cloudy layers of modern-day programming
101–110 of 177 posts
Re: The cloudy layers of modern-day programming
#102One thing I had to learn to value my sanity here was to simply not argue about certain topics, such as software architecture. It was like there was this wall of people who emerge from the shadows anytime I argue for better architecture, because it wasn’t directly responsible for Important Enterprise Business Features. Now I realize there’s probably more than one flavor of engineer: 1. software eng: ships features, pr…
I think in any moderately large business you'll have both. 1. Is usually implementing business logic for the product 2. Is generally working on things #1 uses to work productively I'm not sure about the composition on HN, but I see a lot of #2 in "DevOps"/SRE roles. Usually these roles are skipped for small startups but at some point they get big enough they need dedicated people to take them on
Re: The cloudy layers of modern-day programming
#103Earlier quoted context omitted.
How do they not connect? How do they connect?
Yup - how do they not connect in your opinion?
Re: The cloudy layers of modern-day programming
#104Earlier quoted context omitted.
I'm not gonna flame you, but I will note that, as someone who gets paid to use my judgement to decide on the optimal trade-off between quality, time spent on the project, and its future maintainability... I feel like all three will suffer quite a bit with this self imposed "handicap".
This is the main crux of the issue IMO: feature output velocity. With the enforcement of sprint-scale development scope, you really don't have time to iterate on a wide-reaching and supportive base layer of software infrastructure so you reach for tools that will get you what you need within the timeframe demanded by whoever hired you.
The way many of these projects go is someone very smart works with subject matter experts to map out the problem space. The smart person (or people) then go and begin building this set of primitives and integrating the product, adjusting as they go along accruing some warts.
After 6-12 months we have this beautiful tool that improves developer velocity, new features are easy to code; then disaster strikes. It turns out the map of the problem space was wrong! A bunch of things the team believed to be invariants aren't! Suddenly business needs are forcing developers to tear down walls in their beautiful abstraction castle until all that's left is a tangled maze no other developer has a hope of understanding.
Now the project is a millstone around the dev team's neck rather than velocity boost they'd hoped for.
The way these projects more often succeed is some senior engineer pastes together an abstraction layer sends it out into the world. It gets heavily abused for years until finally the team says "We know this sucks, and there's a lot of business value if we make it nice, let's invest a bunch of time in retrofitting this" and fight like hell to make the business case. IMO this tends to lead to better projects and value (though unfortunately many companies make the fight harder than it should be)
Re: The cloudy layers of modern-day programming
#105I am so, so grateful that someone else does all of that stuff, and I can pay cheap cheap rates for some space on that machine, and a few CPU cycles on another one, etc.
Re: The cloudy layers of modern-day programming
#106Earlier quoted context omitted.
Or, just don't work in webapps. Get into embedded programming. Or join a games studio. I have a friend who is writing code to run on a sort of exoskeleton meant to benefit disabled people and help them walk. He has never in his life "deployed to the cloud" and wouldn't have the foggiest idea of how to do it.
It’s only a matter of time before someone realizes how helpful a GPS transmitter would be in an exoskeleton for disabled people. Now you have a cloud component.
Re: The cloudy layers of modern-day programming
#107Re: The cloudy layers of modern-day programming
#108Re: The cloudy layers of modern-day programming
#109Like many other commenters (of a certain age?), I too have this unsatisfied feeling about a particular kind of modern software development. The kind where you never really dig down and design anything, you just plumb a bunch of stuff together with best practices you find on stack overflow. Many commenters are attributing this problem to the modern high-level tools we now have access to. But I don't think this is the…
Re: The cloudy layers of modern-day programming
#110Earlier quoted context omitted.
> Nowadays when it's just gluing frameworks together and configuring AWS services... it doesn't really feel any different intellectually than cleaning toilets. Comparing your six figure white collar job to basic janitorial work is pretty damn cringe and pretty objectively untrue.
You're right. Cleaning toilets is at least a laborious task. Your standard CRUD applications and web services are largely just a rigamarole of reciting the right incantation and duct taping bits together. It's immensely non-stimulating work when done properly. This isn't an insult by any means. It's a testament to the triumphs of decades of engineering efforts to turn the process of orchestrating extremely complex el…
Not only this, but there'll always be an a**ole to say that we're doing that wrong, and add a few more steps in between just to make the process "better".