Live data from Hacker News

The cloudy layers of modern-day programming

vickiboykis.com

61–70 of 177 posts

Re: The cloudy layers of modern-day programming

#61
post #20
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…

Wheels aren't licensed rather than owned and charged per revolution... yet.

Shit they stumbled onto my YC pitch deck

Re: The cloudy layers of modern-day programming

#62
Not every pilot gets to be a fighter pilot. We have more software jobs than ever but a lot of them are about gluing things together. I think this is more about perceptions and expectations than actual approaches or state of the industry.

Not that there isn’t a need for optimization and replacing glued pieces with bespoke pieces. But just don’t do it prematurely because it’s more exciting. It’s regularly not advantageous.

Re: The cloudy layers of modern-day programming

#63

Earlier quoted context omitted.

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…

An abstraction is something that lets you hide complexity. An I-beam is exactly what you see, there nothing hidden.

Re: The cloudy layers of modern-day programming

#64
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…

I find it strange to see this sentiment... how far down the stack do you go before it stops being "configuration" to you?

Let's imagine building a video chat:

Are you going to build an OS from scratch? Network protocols? Encryption? The rendering engine for it? Compression algos?

Just how much of this do you consider "not configuration"? I think this all sounds very much like "old man yells at cloud" pining for a past that never actually existed.

Re: The cloudy layers of modern-day programming

#65

Earlier quoted context omitted.

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.

Very true. So few people talk about this topic is saddens me. I have had success switching mindsets when I get stuck on one.

It's a strong skill to know how to balance this.

Re: The cloudy layers of modern-day programming

#66
post #57

Earlier quoted context omitted.

Every project I worked on was JS/Node hell. Then I decided to switch to Elixir/Erlang and now I’m much happier. Of course, there are uninteresting or badly engineered projects but overall it’s much better.

There's a true joy in working with some languages. It's like using a great pen or driving a well-made car. You get focus and flow.

F#. Wield the power of .NET with functional programming and beautiful syntax.

Re: The cloudy layers of modern-day programming

#67
post #38
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…

I think you nailed it with configuration vs programming. modern software development is configuration. notice that "development" is not programming either. so this trend has been going for long time

[deleted]

Re: The cloudy layers of modern-day programming

#68
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.

> Comparing your six figure white collar job to basic janitorial work is pretty damn cringe and pretty objectively untrue.

I grew up doing hard farm/ranch labor outside in 95-105 degree TX heat and humidity. I agree with the ancestor comment that manual labor is a hell of a lot more satisfying and stimulating than gluing together AWS services with IAM/RAM snippets from stack overflow and updating some design doc about it. If it payed adequately I might do manual labor in the day and solve actually challenging and fulfilling technical problems at night. Programmers don't get to program much anymore :(

Re: The cloudy layers of modern-day programming

#69
I don't think the industry was supposed to create this magic environment where everybody gets to be a hacker and have good, artistic fun programming. Unfortunately it seems like integrating with as many ready-made solutions as possible is a pragmatic business decision. It doesn't come free, obviously, since we give up a lot of control to vendors and sometimes judging about system performance is hard because of how many things outside of our control are there, and programmers don't get enjoy themselves at all, but such are the economics of this market.

I hate it. But I also don't know if we can do anything about it. Like, for example the company I work at heavily uses AWS Lambda to build mobile app backends and, as a backend developer there, I feel very uneasy about how little I understand and control the system running our critical business logic. But it works well enough and the money savings are amazing when compared to using dedicated hardware, so I can't really make a good point why we shouldn't be doing it.

Sometimes I wonder if other professions get to have fun. Maybe I should explore design to scratch that artistic itch somehow.

Re: The cloudy layers of modern-day programming

#70
post #30

Although I sympathise with the sentiment, that's just half of the story. Today, I can deploy a high available cluster in minutes using any cloud technology + kubernetes and my favourite web framework. True, I need to learn half dozen of frameworks, and _it feels_ like I'm not working in the core problem, but had I tried to implement an equivalent system without those tools would have taken me months, and I would end…

> Today, I can deploy a high available cluster in minutes using any cloud technology + kubernetes and my favourite web framework. I think the point is (at least for me it is), when you do that, have you done anything new that few or nobody else has done before? No, it's just a well worn path which thousands of organizations have done already.

[deleted]
Post reply on HN