Yes but I feel like this thing has existed for decades. I mean, on the nineties people were tinkers because of necessity. To get any game running, you had to fiddle with driver and memory configuration. To get to internet, you had to ptpp stuff manually. To get the game connected to internet, you had to load the driver, connect to net, unload the driver to have enough memory, then load the game to highmem. It’s somewhat made-up example but I do remember lowmem being important even if you had “enough” total RAM. Similar with programming. You had to know a bit if everything.
But as soon as OSes took care of that, the decision makers had already made huge silos of Java Devs who had to know the enormous amount of boilerplate and standard libraries, DBAs who got into, and System Admins who knew about file permissions.
I remember one freelance job or another, late 2000s, where I was hired to “secure the server”. The Java Devs read on some forum that to debug their server, they had to configure their SSH daemon for X forwarding, si that they could install some GUI debugging thing, to hunt for some problem in the Java app. As Windows users, they had no idea what they were doing, the entire server was wide-open and nature took its course toward someone who had different ideas for the server resource allocation.
So it’s not a new thing with node/next devs, like the article says, it’s been here fit two decades. On first thought, I would say that containers help with that. They’re mostly getting standardised around a decent set of defaults, and managed k8s clusters took care of majority of the rest of the security problems. We also have decent tracing and monitoring, and as long as you’re not junior who’s expected to make these fun mistakes, you should be fine with doing just application development.
That said, the last couple of years I’ve been focused on front-end development, and I feel like i can run rings around the hotshots because of mylow-level Linux skills.
So, being an expert at one thing, or knowing a bit of everything. who knows what’s the best.
I’m one of those developers. That doesn’t mean that I’m not tinkering, or trying to learn. I am doing so. But I have yet to find another language that works well for me, even though I have tried a bunch, and I’d rather stick with something in which I can write good code quickly, than to go with something that’s trendy, but impedes my ability to program quickly. After all, there’s a lot more in programming than languages, and learning doesn’t have to stop with them.
If you’re tinkering and learning, you’re pretty far from being one of those developers. Having a favourite stack is fine. Being unwilling to consider anything outside of that is limiting. Even if you ultimately decide your favorite stack is better, it’s the willingness to learn enough to make that call that is the difference.
I like to tinker with abstract concepts, for doing that, the underlying system is more often a hindrance.
I don’t disagree with the general thrust of the article, as a full stack developer I have had many hours wasted because of insufficient systems knowledge and can also attribute any success I have to the ability to learn such systems. I just feel like there are plenty of exceptions where this does not apply. Sometimes I want to tinker with something abstract like a new general path-finding algorithm. Sometimes I just want to have a working application for desktop use that does what I want it to do. In such cases having an IDE that writes half the code for you, with a button that says ‘build’ and another that says ‘deploy’ is extremely valuable and having to learn additional systems knowledge is merely a hindrance. I am currently experimenting with Godot as an application development platform and I am loving it for exactly this reason. It is like a less stupid version of electron. It allows me to make desktop GUI applications that work on most devices and can be deployed as a web application without any knowledge of any of the underlying systems.
In the end there is more to learn in the human sphere than one person can ever learn in a lifetime, what you should focus on depends on your goals. If you wish to be a better developer who is adaptable and competent and able to solve problems that other developers get stuck on then the advice in this article is excellent.
That’s a good point. The author seems a bit biased toward tinkering with system-level *nix stuff, but the advice to favor tinkering over the ship-at-any-cost mentality/learning strategy I think works at any level of abstraction.
Author here, yes I’m biased. But that was also an example from a personal experience, it’s not always about *nix or system-level stuff, it’s more about uncovering certain levels of abstraction and tinker with them.
Yes of course, everyone is biased in one way or another. I didn’t mean that to be derisive. :)
I agree with the author that learning as much Linux/Unix administration as you can goes a long way. Even in serverless-land, if you understand OS and system concepts, you’ll know how to structure your “functions” properly and efficiently.
Just curious, what would be an example of an OS/systems concept that would help in the writing serverless apis?
AWS Lambda instances get re-used between invocations closely-spaced in time, so often your runtime will have some persistent junk lying around in its temporary storage. We recently encountered “disk full” errors as a resulting and are being more careful to clean up storage.
While learning more about “the underlying system” is all well and good, there are more directions to go than down. For people building runtimes or APIs, this could mean keeping a hand in application development to remember what makes for a good development environment. For people building applications, this could be learning about basic design principles to be a little more self-sufficient. Application developers who are not given explicit, pixel-by-pixel design direction often excuse themselves from the responsibility for poor design decisions with the phrase, “I’m not a designer.” Like it or not, as Michael Beirut says, we’re all designers.