Live data from Hacker News

The cloudy layers of modern-day programming

vickiboykis.com

101–110 of 177 posts

Re: The cloudy layers of modern-day programming

#101
post #22

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.

You still get to do something as close to the metal as writing raw CSS? I'm reliably told that's cavalier and you should be writing something that compiles to CSS.

Re: The cloudy layers of modern-day programming

#102
post #40

One 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

That's not my experience with sre and DevOps, often it's just consuming tool written by others. It's basically being a sysadmin with a git repo

Re: The cloudy layers of modern-day programming

#103

Earlier quoted context omitted.

How do they not connect? How do they connect?

Yup - how do they not connect in your opinion?

It's not a yes or no question, I'm asking you to explain how these two separate things have anything to do with each other. The burden of proof is on you, you're the one who said it and you're asking me to prove a negative.

Re: The cloudy layers of modern-day programming

#104
post #91

Earlier 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.

As someone who's been fortunate enough to work on and lead these kinds of projects (and watch coworkers work on them) I've come to a near opposite conclusion which is that sprints reveal how bad the ROI on this work tends to be.

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

#105
Though I too get a little frustrated with the lack of doing deep programming sometimes, I'm extremely grateful that I don't have to manage a machine with a database. You know what sounds really boring, at least to me? Making sure the machine has power. And cooling, and proper backups, etc.

I 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

#106
post #90
post #85

Earlier 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.

I wouldn’t call GPS the cloud

Re: The cloudy layers of modern-day programming

#108
I get the complaint kind of. But this articles example doesn't really feel right to me. I'd like to see the author pull off this project on his own 10 years ago. Not sure it's even possible. He'd be spending years writing some of this from scratch. Instead he finished it, figured it out with time left to write a blog post about it.

Re: The cloudy layers of modern-day programming

#109

Like 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…

I came to this same conclusion last week when I started writing my own webgpu renderer. I went into it with no knowledge of graphics and without using libraries. Having to create my own generic abstractions for pipelines, passes and buffers has been a massive creative and educational experience. I haven't felt this satisfaction from programming in years from my day job.

Re: The cloudy layers of modern-day programming

#110

Earlier 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…

> web services are largely just a rigamarole of reciting the right incantation and duct taping bits together

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".

Post reply on HN