Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The cloudy layers of modern-day programming

vickiboykis.com

Post reply on HN
Print view View original

41–50 of 177 posts

Re: The cloudy layers of modern-day programming

#41

Post by CuriousCosmic »

thr0wawayf00 wrote: post #33
jjav wrote: post #28

Good article, great points. The Knuth quote on lack of creativity is right on the money. It's why I've been drifting away from hands-on programming even though I'd rather not. I still love programming as much as I ever did as a teenager. Late at night when everyone is asleep and I can work on my own code, it's as much joy as it ever was. What's different is that at $DAYJOB back in the 90s and 00s it used to be just a…

> 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 electronic systems spanning continents into a largely trivial task for most projects.

Re: The cloudy layers of modern-day programming

#42

Post by thr0wawayf00 »

pcthrowaway wrote: post #37
thr0wawayf00 wrote: post #33

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.

OK, what if we say plumbing then? Same idea, and the pay is within an order of magnitude at the median.

Personally, I think it's pretty hard to make that kind of comparison accurately without having professional experience in both fields. One could also argue that it's as intellectually stimulating as being doctor, but how do we actually know that?

I've cleaned toilets professionally, and I'll say once and for all: writing software, no matter how monotonous or boring, is nothing like cleaning toilets. And I'd be willing to bet that someone trying to make such comparisons has ever had to do that kind of work.

Re: The cloudy layers of modern-day programming

#43

Post by nijave »

midiguy wrote: post #5

Would you rather do some library gluing, or reinvent a thousand wheels with every project? The latter is neat the first few times. Whatever your preference, your value as an engineer is much higher if you can glue. Imagine if a carpentry workshop gives a carpenter a fully-fledged set of industrial power tools, but the carpenter insists she can recreate all the other tools with just her whittling knife because it's in…

Ideally a healthy blend of both. Wheels where it relates to your companies core competences or there's a gap in the market. Glue for everything else (you don't need to invent an infrastructure provisioning solution unless you're and infrastructure provisioning companies--there's plenty of mature solutions). Other places like application libraries--it might make sense.

Re: The cloudy layers of modern-day programming

#44

Post by CuriousCosmic »

CyberDildonics wrote: post #39
xxpor wrote: post #17

Do architects reinvent the I-beam every time they design a new building? No, of course not. The reason society works is because you can reuse abstractions that other people have already invented . It allows you to scale. Without economies of scale, you end up with Baumol's cost disease, which is extremely obvious in the US in industries like child and elderly care. We don't want most software devs to be doing anythin…

I beams aren't abstractions, they are a well designed standard that can consistently meet certain expectations.

I beams are both an individual abstraction and part of the greater abstraction.

Your catalog of beams, bolts, brackets, weld patterns, rebar, piles, and concrete pour standards are all abstractions over extremely difficult subfields of materials engineering and structural engineering.

They exist so that your engineer can focus on building the structure using parts and resources with known, standardised behavior under the conditions the building will be put in.

Of course you'll see engineers break away from these abstractions when they need to for a given structure but those abstractions do exist and are commonly used so that a given structural engineer doesn't also need a PhD in materials engineering and countless other specialized fields.

Re: The cloudy layers of modern-day programming

#45

Post by Dave_Rosenthal »

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 crux of the issue. You can face the same issue (you're plumbing things, not a designing a system) whether you are working with low level or high level components.

Heck, you could be working on a hardware circuit, but if the only thing you had to do was make sure the right wires, resistors, capacitors, etc. were in place between the chips you're still just doing plumbing work.

To me, one of the most satisfying things about programming is when you can build something great by starting with a concept for your lower-level primitives, your tools, and then work up through the higher levels of design, ultimately having the pieces you designed fit together to form something useful to the world.

This building-things-to-build-things idea is even satisfying in other areas. Just gluing a bunch of wood together to make a piece of furniture is fine, but building your own jigs and tools to be able to do the kind of cuts that enable the end design you envision is way more satisfying, and opens up the design space considerably.

If I had to lament anything (and perhaps this is what's most in alignment with the post) it's that most of the high-level primitives you touch these days tend to be sprawling, buggy, not focused, and just generally not of high quality or performance. It's possible for high-level primitives to avoid these pitfalls (e.g. Sqlite, the canonical example) but it does tend to be the exception.

I think there is still plenty of interesting and satisfying software engineering work to be done when starting with high-level libraries and tools. You just need to think about how to use their properties and guarantees (along with maybe some stuff you build yourself!) to enable the design of something more than just the (naively-plumbed) sum of the parts.

Re: The cloudy layers of modern-day programming

#46

Post by agumonkey »

gryf wrote: post #13
jakeinspace wrote: post #7

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…

This. I already started using ChatGPT to solve problems because I can’t be arsed to read through ten vendors worth of documentation. It wrote me a fairly complete and accurate chunk of code the other day to solve a problem.

I have to admit that having it giving short summaries of framework docs and models felt like drugs in my veins.

Re: The cloudy layers of modern-day programming

#47

Post by agumonkey »

mattgreenrocks wrote: post #31

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…

It's not far from the top-down vs bottom-up too. Having a wide enough infra helps adapting at the upper layer faster and cleaner.

Re: The cloudy layers of modern-day programming

#48

Post by agumonkey »

somrand0 wrote: post #4

oh yea. using a software framework like django for "rapid application development" gives me a feeling closer to writing configuration files rather than actually "programming" (where "programming" is writing hardcore algorithms). but don't get me wrong, I liked doing that, I got paid to do it. But let's call it for what it is: that python code (django app) was really django framework config. this is a simlar phenomeno…

it's config until you need an option not in the 'language' and then you have to get real dirty

Re: The cloudy layers of modern-day programming

#49

Post by tester756 »

CyberDildonics wrote: post #36
tester756 wrote: post #18

If you feel like "modern programming is boring configuration mess" then ask yourself - what have you done in order to have interesting job, projects, challenges, etc? I mean, if you decided at some point that $big_salary for throwing JSONs via REST from CRUD app is what you want to do until you pay your loans (e.g decade), then it's fine, but don't be shocked that you aren't doing bleeding edge R&D at some fancy plac…

If you feel like "modern programming is boring configuration mess" then ask yourself - what have you done in order to have interesting job, projects, challenges, etc? These two things don't connect to each other at all

How so?

Re: The cloudy layers of modern-day programming

#50

Post by einpoklum »

somrand0 wrote: post #19
einpoklum wrote: post #11

Earlier quoted context omitted.

> they need to be written once Well, if you were writing abstract pseudo-code, then maybe. In practice, the same algorithms are often reimplemented multiple times. > and then everybody can use them ah, if only that were true... implementations are often not that flexible, nor are programmers that keen on utilizing existing implementations. > this is a giant problem Problem? To the extent it's true - it's a boon, not…

well sure, I completely agree that it's indeed a boon. a HUGE boon. the problem I describe is not a technical one, but a social one. and it's only a problem due to the current way society works. It's only a problem for some people (e.g me); them who are well satisfied by this "status quo" don't see any issue beyond lacking enforcement of IP 'rights' and the need for better DRM, and copy protections, and other things…

> I'm saying that this boon brought about by digital technology is only benefiting a select few.

If you mean how most people in the world are under stricter social control with the advent of technology than they were in primitive tribal society (or maybe even middle-age agrarian society), then maybe.

But if you mean the benefit from being able to make these copies - then definitely disagree: People get to have tons of free (libre & gratis) software, and lots of free (gratis) cultural products like images, audio, video and text. Are you bemoaning what we do with this glut, and perhaps the problem of over-abundance, shallowness of cultural taste etc.? Otherwise I'm still missing your point.

About piracy: I'm using the right definition, it's the copyright crooks who are using the wrong one :-P

Post reply on HN