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

161–170 of 177 posts

Re: The cloudy layers of modern-day programming

#161

Post by TeMPOraL »

pclmulqdq wrote: post #86
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 am thinking very hard about the CAP theorem right now while working on a billing system for a cloud API right now and it is an absolute joy. No, it won't deploy in version 1, 2, or 3, but it might in version 4, and if it does, it will be glorious. You can find cool technical problems anywhere as long as you are willing to take the path less traveled.

> You can find cool technical problems anywhere as long as you are willing to take the path less traveled.

After doing that a few times, I'm no longer sure if the reward of tackling cool problems to create more robust, better, faster components is worth the stress of missing deadlines.

Looking back on what value of better work materializes and what is, per YAGNI, usually wasted, I just had a thought: perhaps the right way is to take the easy/dumb way and focus all available time/effort to optimize it for performance - instead of abstraction and extensibility. Because in my experience, nobody ever extends the code the way you envisioned - if they do it at all, they do it by first refactoring it to suit their own idea. And, nobody ever goes back to fix performance. Therefore, making things abstract and extensible is mostly a wasted work - but making things fast pays back for as long as the code is in use.

Re: The cloudy layers of modern-day programming

#162

Post by jesse__ »

spoils19 wrote: post #136
jesse__ wrote: post #120

Earlier quoted context omitted.

Going one step further, challenge yourself to _not_ use stdlib, just raw language constructs. Need a hashtable? Write one. You won't come out with a celebrity HN presence, but you may gain enlightened samurai monk status.

Going one step further, challenge yourself not to use raw language constructs, but dive deep into assembly. Need a conditional? Time to jump around. I wrote a web server that scales to over 1 million requests per second, and I found out it's much more maintainable, scalable and environmentally friendly for our company.

Touche

Re: The cloudy layers of modern-day programming

#163

Post by mattgreenrocks »

nijave wrote: post #40
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…

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

#2 is distinct from pure DevOps/SRE. Those roles have co-opted the infrastructure meaning to be more along the lines of "making sure things don't catch fire at 3am." Which is valuable, but, even farther removed from programming.

Still, they value the same things that the "pure infrastructure" people I were referring to do simply because they end up being on the hook for how it behaves.

Re: The cloudy layers of modern-day programming

#164

Post by aprdm »

myth_drannon wrote: post #156
aprdm wrote: post #140

Earlier quoted context omitted.

Try to find work in visual effects, lots of interesting work and they’re on prems. Anyone with software background can get in !

Right, but the hours are long and the pay is low. VFX is even worse than games from career perspective

That's not true in programming. I was 9-5 on 7 years there over multiple studios. My last studio (one of the most known ones) actually had 4d weeks.

It is definitely true for VFX Artists. And you will definitely get a pay cut compared to tech (50%-ish TC)

Re: The cloudy layers of modern-day programming

#165

Post by TeMPOraL »

pif wrote: post #155
havercosine wrote: post #124

I agree that most of the routine software work feels like, umm, filling forms? The way I've made peace with it is to accept that the work that pays the bills is going to be boring. After considering ourselves to be special as software developers for many years, maybe we accept that it is not so special after all, like flipping burgers. Two ways to out from the existential dread: one startup on a problem statement tha…

> like flipping burgers. Programming an information system is like flipping burgers; developing industrial software is not.

I worked on what you could classify as industrial software. I was still flipping burgers. With a rusty spatula. The cloud people at least get slightly nicer spatulas.

Re: The cloudy layers of modern-day programming

#166

Post by uoaei »

Hermitian909 wrote: post #104
uoaei wrote: post #91

Earlier quoted context omitted.

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

Fiction and non-fiction writers have been struggling with these issues long before software was a concept. Their solution: "writing is re-writing".

I didn't mean to imply a dichotomy. I don't think an intense planning phase up front solves the problem. But feature-sprints tend to crowd out refactor-sprints because of the demands from above for new features. Downtime working on backend stuff is not perceived by the customer as anything benefiting them. But here, the backend is a codebase no one enjoys working with and the customer is the C-suite expecting X features this month because X or X-1 features were pushed last month.

Re: The cloudy layers of modern-day programming

#167

Post by tester756 »

overbytecode wrote: post #151
tester756 wrote: post #78

Earlier quoted context omitted.

So the only way is to complain whole life?

Lets not reduce this article to "complaining", it didn't just say "modern software development sucks" and be done with it. The author gave an overview on what she thinks is wrong about the field, with a fairly detailed example and references. Even if you disagree with her take, these kinds of articles force us to reflect on the state of the industry. There is nothing wrong with that. Should we be mindlessly churning…

tbf I've been mostly focused on HN's comment section's opinion

Re: The cloudy layers of modern-day programming

#168

Post by tester756 »

CyberDildonics wrote: post #103
tester756 wrote: post #71

Earlier quoted context omitted.

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.

wut? what "proof" are you talking about, there's nothing to prove.

The connection is simple: If you don't like something, you're free to change it (in this case)

If you feel like your job is easy and you feel bored, then you're free to quit and apply to place which will challenge you.

If you expect that some magic will happen and one day you will come to your job and you'll be tasked with coding spaceship, then you're optimistic as hell.

So, the question stands - what did you do in order to improve your situation? if nothing, then do not expect magic to happen because that's unlikely.

Re: The cloudy layers of modern-day programming

#169

Post by Hermitian909 »

artificialLimbs wrote: post #159
Hermitian909 wrote: post #104

Earlier quoted context omitted.

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

So what is the way (are optimal ways) from the beginning?

Ultimately, "It depends" and no answer will satisfy all cases.

My general advice is that software engineering has a lot of well worn patterns for problems, stick to those as much as possible. Their great advantage is that any experienced software engineer will recognize them and onboard quickly, allowing you to focus on those parts of the problem specific to your project/company.

In most cases, whatever common pattern you shoehorn your problem into will suffice for the purposes of the business. It will be ugly, and have warts, but will be generally maintainable and not often touched. Again, if this turns out to be wrong after it's been battle tested and shown value, you can begin to migrate away to something new.

There are exceptions to the above, and many companies don't actually go through the motions of following well-worn patterns even when they think they do e.g. many companies with public APIs make a common set of mistakes we've known how to solve for over a decade and have known they're easy to solve if you deal with them up front.

Re: The cloudy layers of modern-day programming

#170

Post by pclmulqdq »

TeMPOraL wrote: post #161
pclmulqdq wrote: post #86

Earlier quoted context omitted.

I am thinking very hard about the CAP theorem right now while working on a billing system for a cloud API right now and it is an absolute joy. No, it won't deploy in version 1, 2, or 3, but it might in version 4, and if it does, it will be glorious. You can find cool technical problems anywhere as long as you are willing to take the path less traveled.

> You can find cool technical problems anywhere as long as you are willing to take the path less traveled. After doing that a few times, I'm no longer sure if the reward of tackling cool problems to create more robust, better, faster components is worth the stress of missing deadlines. Looking back on what value of better work materializes and what is, per YAGNI, usually wasted, I just had a thought: perhaps the righ…

I am doing this for a particular purpose, though, that no billing system I have seen has. I hate metered API billing, and I don't want to use it. In particular, I don't want a customer running up a $10,000 bill and calling me for a refund. It probably will cost me O($1,000) to give them a refund, between the processing fees and the lost compute, and I will be out that money. Most companies that would ask for a refund also won't pay the bill when it arrives (which is, I think, why AWS is so liberal with refunds).

Instead, I want to do credit-based billing: you buy credits, and when you get to 0 credits, you are cut off (with an auto-refill option for the "metered billing experience," but with strict spending limits). This is, in my opinion, a much better UX than metered billing. From a distributed systems perspective, it's isometric to "metered billing with a hard spending cap" which may be the ultimate version.

The problem with credit-based billing (and why nobody does it) is that if you have a service in multiple datacenters, you have to consistently update a database to make sure that you don't drop below 0 credits, and that is very slow. However, by fiddling with the CAP theorem the way CockroachDB/Spanner do, I think we can do credit-based billing and make it feel like the AP system that metered billing is, and behave like a CP system only when we absolutely need to.

Also, this is basically all enabled by the fact that AWS has a precise time service.

In theory, version 1 of the API will be only in one region, version 2 will have active/passive redundancy, and around version 3 or 4 I want to switch to active/active in several DCs to give low latency and high reliability.

Post reply on HN