Comment by sgarland
14 days ago
It’s because by and large, web devs do not know computing fundamentals, because they’ve had no reason to learn them.
If your language handles memory management for you, why would you learn about it?
If poor performance in your app can be dealt with by spinning up more copies of it, why would you spend time profiling your code?
And, explicitly to your point, if networking can be hand-waved away by tools like ngrok, why would you need to know how it works?
And so on. People who grew up on computers in the 90s, 80s, etc. largely do know these things, because they had to. Understanding those fundamentals, as in any industry, pays dividends.
It’s incredibly frustrating to me that at almost all companies I’ve worked for, when I suggest we self-host something instead of forking over millions to AWS, it’s an instant no. The most honest answer I’ve had so far was “that skill set is difficult to hire for.” It is, I agree – and how do you think we got to this point? By perpetuating the status quo, and enriching the hyperscalers, who seem to have no problem hiring for that skill set.
> when I suggest we self-host something instead of forking over millions to AWS, it’s an instant no.
This is something that bothers me a lot, and I've given up. It's to a point where we're paying thousands of dollars sometimes a year for 200 lines of code.
It also kinda makes it harder to sometimes just practice engineering skills.
For example, I wrote a just in time access request solution at work. However, okta also has one of these. Funny thing is, the one I wrote is a proof of concept - so it's a little rough around the edges but nothing spectacularly wrong.
I then used the okta solution for this and my god, what an absolute mess of software they have.
1. They don't have the ability to have the requester specify a duration of access they want. It all has to be hardcoded.
2. Imagine you request access to group A for 3 hours. 2.5 hours later, you're thinking "Hmm, I think I'm going to need more access. So you make another access request for 3 hours. After half an hour that first access expires, and just removes your access. Even if you still have 2.5 hours left from your second access.
3. Without even trying, I got the backend for setting up the access requests into an inconsistent state. Okta's UI is insisting I can't delete a group because it's used by an access request form. However, when I was making that access request form the save button partially failed, so now there's this dangling foreign key somewhere in their database. Inconsistencies like that in software that's supposed to be the source of truth of access is just absolutely unacceptable.
4. Okta "removes" access by removing you from the group that you had requested. However, if there's any issues with Okta's provisioning code, from Okta's perspective you don't have access but the third party service might still think you do. They don't _remove_ the access from the third party first before removing it from their own source of truth.
What's depressing is that in my proof of concept, before even trying Okta's product I thought about and planned around all of these problems.
---
Anyway rant over, but at least in hiring I am very adamant about the candidate knowing how to get a basic website up and running and understanding NAT/Port Forwarding/HTTP(S) Proxies. Why? Well, when our customers run into issues with our software our engineers need to have the fundamentals to help troubleshoot.
I mean ngrok doesn't handle all your networking pains. It is kind of a quick tool to get a public URL to localhost. But yes, it is painful to find good candidates with some computer networks / OS knowledge. We run a similar service https://pinggy.io