Hacker News Reader

Comment by vsareto | Hacker News Reader

I wouldn't be surprised if most people don't learn it in-depth because:

A) you can google or ChatGPT things more easily these days

B) there's a truck load of services and ways to connect and do things. It's hard to learn all of these or pick a best option for everyone

C) SSO + identity models + API permissions generally made everything more complex

D) Many things in Azure are changing often, so you don't want to get too invested in a particular "version"

So things got more in-depth while expanding your available options (which are usually just as complex)

View on HN

> you can google or ChatGPT things more easily these days

This should not be a valid excuse to not understand your job.

> there's a truck load of services and ways to connect and do things. It's hard to learn all of these or pick a best option for everyone

Agreed, and I think this is where people go wrong. Giving devs the ability/permission to pick whatever random tooling they want is not a good path for maintainability. "It's in AWS, so we can use it." I'd go so far as to argue that if you want to use Managed Service X, you need to first successfully launch it on an EC2 with no other help than the official docs; otherwise how can you possibly hope to understand it when it goes wrong?

> SSO + identity models + API permissions generally made everything more complex

Fully agree, IAM is a nightmare. But again, if it's your job, that's not really an excuse for anything other than higher pay.

I think people don’t learn it [all] in-depth because to do so is essentially impossible.

Back in the bank days all of understood Windows, multi-tier AD, DNS, DHCP, SMS* (now MECM via SCCM), that distributed file system whose name I forget, file & print, Exchange, and all the other things that had a plugin to mmc.exe — we could do ‘em all. Oh and a handful of networking because that was also much simpler. Oh and all of the client configuration.

You could give me a server and a day and I could stand you up a basic infrastructure. I could know it all.

(*Though the maniacal way that SMS 2.0 did its magic with text-based log files shuttled in from the endpoint always drove me bonkers.)

And, by the time you "know it all", the playing field has changed.

RESTful APIs? Nope, we are going full-gRPC.

No hand-rolled OAuth - we are using AuthSolution1. Forget that, AuthSolution1 has a security vulnerability, we are going with AuthSolution2. Wait, AuthSolution2 won't work with cloud providers database offering... let's try AuthSolution3.

Let's use IFTTT. No, how about Zapier. But, we need gRPC and now GraphQL.

The databases are over-provisioned, lets look at serverless as a critical path item. Executive VP #2 thinks we should use a NoSQL solution.

BTW: Cloud provider X is dropping support for database version 1.1, we need to migrate to 2.0... or skip ahead to the just-released 3.0.

And, then the CEO comes and asks: "Can you spend some time trying to get ChatGPT to build this whole thing for us?"

Every god dammed day of my life.

Opened up an AWS app earlier in the week, asked wtf is this and how does this even work. Logged out and said not my problem.

I feel like the complexity and the knowledge pulled back and hidden by the layers of abstraction still must reside in a mind to make things work. I am troubleshooting issues in code that I can’t write or fully read, I ask how it work, what it relies on, what it writes to, what it’s intended function. By the time we get through explaining the problem to me, we usually come up with a solution or understanding of why it doesn’t work and what needs to change.

Some really smart folks writing this stuff but cannot keep it all or understand how these systems connect and work together. 300 lines of code can hit 10-20 different technologies and it made perfect sense when you wrote it, but when it’s broken…

Reply on news.ycombinator.com