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

91–100 of 177 posts

Re: The cloudy layers of modern-day programming

#91

Post by uoaei »

kspacewalk2 wrote: post #87
aliqot wrote: post #83

Earlier quoted context omitted.

Challenge yourself to use stdlib only for a while, or the future. It sounds unrealistic and I'm going to get flamed, but hear me out. It works. Most of my development these days is in reasonably complete languages like go, rust, zig, and various scripting languages, so your mileage may vary if you're writing in something like rune, hare or carbon that is still taking shape. If you think I'm crazy but have a lingering…

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.

Re: The cloudy layers of modern-day programming

#92

Post by phil917 »

This has been something that's been bothering me more and more over the years. I often feel like I'm just standing on the shoulders of giants that came before me. Occasionally, I do still get that feeling of satisfaction when I've built something that's *mostly" mine.

But a lot of times, I'm just connecting black boxes and slapping a coat of paint on top (aka our branding). And it leaves me with this sort of guilty feeling that I'm not actually doing anything valuable.

Ultimately I still do it because the money is great and overall it's a very privileged position to have in today's world.

But I think this is where having a hobby project comes into play. I can do things "my way" and not worry about needing to use the most efficient or industry standard components.

Re: The cloudy layers of modern-day programming

#93

Post by Aeolun »

tester756 wrote: post #78
dinosaurdynasty wrote: post #77

Earlier quoted context omitted.

Capability trap. Not everyone is capable of effectively working 2 jobs at once, and generally speaking no matter how big that $big_salary is you aren't going to have more money or time. Also there are lots of way for a company to say they are doing interesting/meaningful things or whatever and effectively not be. And no matter how great the work you may be doing, you don't want to be doing it if it doesn't pay enough…

So the only way is to complain whole life?

I mean, if you can’t, or don’t want to change your situation, it’s an effective outlet. There’s also more than enough people feeling the same to commiserate, so you’ll never be alone.

Re: The cloudy layers of modern-day programming

#94

Post by [deleted] »

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…

[deleted]

Re: The cloudy layers of modern-day programming

#95

Post by Aeolun »

deathanatos wrote: post #10
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…

I'd rather re-invent some wheels. The problem with VendorOps as I see it is that quite often the vendored "solutions" aren't solutions: they do not meet the requirements! Yet … they sort of get like 20% of the way there, so they get adopted nonetheless, and the devs toil away on trying to get glue code to push it the remaining 80% of the way. But if we had a system that we owned , then it could be adjusted to fit the…

We got random failures on our API gateway to lambda connections, and the answer we got back from the support agent was something like “automatically retrying on failure is industry best practice”.

I just wanted to shout at them to fix their damn system, but of course we ended up implementing retries instead…

Re: The cloudy layers of modern-day programming

#96

Post by scarecrw »

I work in CS education, and I've often wondered what this means for how we're preparing students. I don't teach frameworks or cloud services (and would be woefully under-qualified to do so), I teach the topics that have long been thought of as "foundational" for moving forward in computer science. The logic I've always clung to is that if students have a strong understanding of how to build things from scratch, they can apply that as they move towards more modern development tools. More and more I'm questioning the accuracy of that belief.

Perhaps we simply need to more clearly separate the goals of studying computer science from studying programming/development. For the time being, however, I'm left feeling like I may be doing students a disservice avoiding the reality of what "modern-day programming" has evolved into.

Re: The cloudy layers of modern-day programming

#97

Post by Aeolun »

Am I the only one that was wondering about OP’s table of data manipulation technologies?

I’d be inclined to process everything locally right up until the 1TB mark, and that’s only because my computer doesn’t have enough disk space.

Re: The cloudy layers of modern-day programming

#98

Post by mudrockbestgirl »

I agree with the sentiment in the article, but I also believe this kind of development is inevitable. How else are you going to to create increasingly complex high-level software if not by gluing together pieces that have already been written? Are you going to create your data layer from scratch every time?

I just don't see how you can arrive at today's productivity without running into this issue. Sure, it's not fun. Just like the author, it makes me miserable too. I have much more fun writing a parser or database from scratch as a side project. But it looks like you have to pick one: Do you want to be productive and get stuff done in time, or do you want to have fun and make art?

It's not a problem. It's an inevitable tradeoff.

Re: The cloudy layers of modern-day programming

#99

Post by scaredginger »

lordgrenville wrote: post #32

As some other commenters have said, this is really a self-inflicted problem. The author has chosen to do an EDA task which is very manageable on a laptop via a convoluted stack of cloud services - possibly just to illustrate a point. But even if this all worked smoothly, the fact that it is far removed from "software engineering" has more to do with the fact that it's a data analysis project. If it were about about w…

It's also well-known that pandas is memory-inefficient and Dask would probably do the memory estimation they described for them (after the author dismissed it). They're really just showing they don't really understand these tools that well

https://wesmckinney.com/blog/apache-arrow-pandas-internals/

Re: The cloudy layers of modern-day programming

#100

Post by tayo42 »

aliqot wrote: post #83
Dave_Rosenthal wrote: post #45

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…

Challenge yourself to use stdlib only for a while, or the future. It sounds unrealistic and I'm going to get flamed, but hear me out. It works. Most of my development these days is in reasonably complete languages like go, rust, zig, and various scripting languages, so your mileage may vary if you're writing in something like rune, hare or carbon that is still taking shape. If you think I'm crazy but have a lingering…

I don't think I you can compare the internet of the 90s to today's internet. The expectations and scale are no where similar.
Post reply on HN