vp8989

"And way too many operational issues."

I've seen this kind of thing mentioned many times, pretty baffling TBH based on Dynamo's pretty good reputation in industry. Are these mostly to the stateless components of the product, or do they see data loss?

Its shocking to me how people don't get bored of rehashing this same, tired opinion over and over and over again and discussing it with hundreds of comments. There is a blog post like this every other day on the front page of HN and it always generates the exact same discussion.

It's not just the developer experience, in fact that is probably lower on the priority than you would think. The entire business IME struggles to reason about a product, in the details, that is logically 1 product but physically N products by virtue of all the different target platforms and codebases required.

It depends what your career goals are. Repeated execution of non-trivial things in different contexts builds your engineering sense and intuition. Amazon has a quote, "there is no compression algorithm for experience".

People who fast track that step too much are not on a stable footing. You can probably sometimes get away with it, which is why we see the kind of "thought leadering" shared in the OP ... but I'll say that I'm "only" ~10 years in to my career and I've already seen quite a few instances of VP+ people who bet the farm on some nonsense and end up flaming out.

I like this framework. Is this only applicable for debugging projects that are already in motion, but going poorly?

I was trying to think if it could also be used to shape the discussion and documentation in the planning/design phase. But at that stage it seems like you'd first need to declare WHO is responsible for deciding what the appropriate WHY/WHAT are?

I have been doing this for about 3 or 4 years too. I wouldn't say it necessarily makes you "productive" unless you work in a very isolated fashion.

By whittling it down to the bare essentials you at least know if you are unproductive it's not because you are faffing around with the tracking of your own tasks.

Would this post be considered marketing? A teaser? Whatever it is, I strangely enjoyed it a lot. It's a perfect appetizer to get the juices flowing on thinking about the next generation of application software and how databases can enable that.

I think currently in the industry we are stuck in a hyper pragmatist, "value extraction" holding pattern and there is going to be a next generation of applications at some point that will be, at least partially, enabled by some of the advances discussed here.

In my mind at least, the actual "web3" or the next major generation of applications is not going to be this goofy decentralized blockchain gimmick factory.

It will consist of AR applications that you literally "wear" and let them enhance your reality in physical space, in real useful ways.

These applications will have a whole other level of latency and stability requirements because when they are quite literally in your face the user is going to have increased sensitivity to any latency or jitter.

Nice post, I think "software engineering" is slowly becoming yet another "bullshit job".

I "normalize" my previous titles to whatever pattern/scheme my current company uses. It more clearly demonstrates the career progression on your resume and you typically only get a reference check at your previous employer so putting an "inaccurate" title for jobs older than that is unlikely to matter. Obviously don't inflate the titles.

"I've got so many other things to handle and deal with that being technical except at a high level seems silly."

Like what?

You are (conveniently or not) incorrectly assuming that the unit price of provisioned vs on-demand capacity is the same. It's not.

The actual observed problem in the article is that the team's SDLC pipeline can't handle the current flow it's being subjected to. Work is getting "blocked" in code review.

Devising a coping mechanism for developers so that they can increase the inbound flow to an already overloaded system is not actually a solution.

The real solution to this rather common problem is to introduce a culture where "done" means "shipped" and not "I created a bunch of PRs for my team mates to read and while they all do that Im gonna create some more" and to use tech where you can to increase the flow the SDLC pipeline can handle.

This involves things like moving as much "code review" into the compiler/linter as you can, do a little more design/consensus building upfront, streamline all acceptance testing and deployment steps to their bare essentials etc...

https://trunkbaseddevelopment.com/

"Who here is writing software which runs on Linux, yet needs to be running Windows while they do it?"

Backend developers at .NET shops who were issued Windows laptops by their companies.

Are you actually likely to have a "high bill" on Lambda but also be "surprised" that all your requests are 30x slower?

Presumably anything that can generate a "high bill" also has some reasonable level of on-call, alerting, SLAs etc ... such that if your Lambda invocations were all taking 30x longer people would notice.

Being replaceable tends to make work less satisfying. All the places I've worked at that followed your advice had the most churn and the least productivity/ROI on engineering $ spent.

An "uchi-mata" or "ankle pick" or whatever ... to that person becomes it's own martial art or "game" as people normally think of it.

There is incredible breadth to discover once you go 1 level deep into something. Every technique worth specializing in will have a multitude of entries/setups, then you need to know how people defend/counter and how to counter that, there could be slight variants that work better against different body types etc ... really staggering amounts of breadth/depth involved in putting someone on their back.

There will also be some breadth provided by general meta concerns of each combat sport like grip/hand fighting, defense, strategy, conditioning etc ...

So even the people who are hyper-specialized still have to know loads of stuff.

Follow the volume. Work on things that have lots of users, lots of revenue, lots of transactions etc ... nothing exposes bad engineering more effectively than tens of thousands of requests a second or terabyte size transactional databases.

Ye to be clear, I meant even building on top of GKE/EKS it seems like a lot of work configuring things, testing etc ... at least from the outside looking in.

"Enter Kubernetes. Now you have a core DevOps/SRE team managing the “platform” (the Kubernetes cluster and various add-ons such as operators) which gives the application developers a high-level interface for operating their applications."

I've personally changed my opinion on this in the last ~2 years ... observing at work what it takes for people to stand up and manage a Kubernetes platform it really just feels like incredible waste that we have hundreds and thousands of SREs across our industry all building their own unique compute platforms when the public cloud vendors have already done that work.

The Serverless paradigm just seems fundamentally superior to me, but it also seems like it inherently requires vendors to be very opinionated in order to provide a good developer experience with it which AWS is not and aren't ... at least not yet anyway.

"Whenever I investigate examples, though, I find the devs have to go through a ton of effort to avoid memory allocations"

Yep, also the median dev in a GC'ed language is simply incapable of writing super efficient code in these languages because they rarely have to. You would have to bring in the best of the best people from those communities or put your existing devs through a pretty significant education process that is similar in difficulty to just learning/using Rust.

The resulting code will be very different to what typical code looks like in those languages, so the supposed homogeneity benefits of just writing fast C#/Java when it's needed are probably not quite true. You'd basically have to keep that project staffed up with these kinds of people and ensure they have very good Prod observability to ensure regressions don't appear.

It's become very trendy these days to be hyper-pragmatic and dismiss attempts to push forward new big ideas or programming languages as frivolous.

"Shut up and give me another 500 lines of PHP, we have (made up) deadlines to meet!"

Wouldn't you be using 2 threads for at least some of the duration of every instance of that? Seems like it would scale very poorly.

Elaborate on what? Rust or the pragmatism stuff?

"Turns out that the language is far less important than having really great libraries. I’ll re-evaluate rust when things like resilience4j and micrometer exist for it."

I agree. Ecosystem shapes how good a given language is right now but the language itself is what provides the long-term ceiling. One very real example is JavaScript. You can write all the JavaScript libraries you want and people certainly have ... but ultimately the language is what it is and many of its users still clamor for something better even after immense investment in the ecosystem.

Agreed. Some new languages actually have the inherent capacity to be much more boring than incumbents, once the requisite work has been done to flesh out their ecosystems and make them familiar to people.

I used to think this until I really took the time to dig into Rust. Rust has completely snapped me out of this depressing, "pragmatist" learned helplessness that people seem so keen to try to cram down everyone's throats these days.

Yeh I should have mentioned MySqlConnector as another example of a high quality .NET library, my apologies.

We ripped out the Oracle MySQL library at work and put MySqlConnector in. The high quality documentation made it really easy to understand and make adjustments for the differing behaviors between the 2 libraries. Any time I've poked into the code to try to understand some fine detail of it, I've always found it very easy to quickly understand what could be going on. It's great.

The Confluent.Kafka one, the AWS .NET SDK (though this is improving), the old MySQL one was really bad.

My impression from reading the code and GitHub issues is that they're not maintained by real ".NET people" who are plugged in to all the fine details and best practices of the framework and the runtime.

StackExchange.Redis is a good example of one that is independent of MS but still very high quality.

Making JIT 4% (or whatever) faster is cool but it would probably have higher ROI for the .NET ecosystem if Microsoft assigned some of these high caliber people to instead work on improving or simply rewriting some of the atrocious open source libraries that are available.

Would you rather have an A language/runtime with a D open source ecosystem or a B for both?

Agreed. It's not explicitly stated in the post but why would amount of experience (aka age) and Y-intercept even be mentioned at all if not to imply that more experienced people have a less steep slope.

I think this is a false axiom that young people have more potential. You actually have very low signal about people that age. They just went from a very structured context to a very unstructured context, so you may be assuming a lot from how they operated in the former context that may not be true now that they are in a different one.

This kind of ties in with another thread on here about OP being disillusioned with the skill level of their FAANG colleagues.