DEV Community

Discussion on: Evergreen skills to use throughout your career?

Collapse
 
mgaruccio profile image
mgaruccio

Interestingly both of those technology items look to be ripe for change. relational databases are beginning to lose share to NoSQL databases like Mongo, and SDN is causing some massive upheaval in the networking world, at least inside the datacenter.

Thread Thread
 
ericschillerdev profile image
Unfrozen Caveman Dev

For the networking piece, I don't entirely disagree, and should have clarified that even with SDN (software defined networking for those reading that don't know the acronym -- also look at "infrastructure as a service") and all things cloud, the really basic stuff hasn't changed in that you still have ports, HTTP/HTTPS, etc. Now, some of those things are way easier and faster to work with, and there's more opportunity to move quickly knowing the what and not the how (I know that you can spin up instances on AWS, but not how Amazon is actually running their datacenter), but for a dev to talk to a devops or full hardware person in their terms is a legit skill. Even with stuff like containers and serverless, knowing the basics can still save a ton of time.

As for databases, I'd say that swings back and forth. Relational isn't going to ever completely go away, because it's the best solution to a specific block of problems. The implementations are improving in response to popularity of other options, and ORMs help developers dramatically in not having to deal directly with a database, but knowing the basics of how they work can make a huge difference in otherwise simple code. If anything, you've reminded me that I should have expanded my statement to include data storage in general and which does what/how to interact. Sometimes a graph database like Neo4j is a way better choice than something like Mongo. Regardless, any variation I've seen still has some concepts of set mathematics to deal with your data.

Also, some of my statements come from the fact that I work with a lot of legacy modernization, where sometimes you're moving from a 10 years ago framework to a 4 years ago framework because you can't convince the customer to get into the 2018 framework just yet (or they started 2-4 years ago and can't upgrade again for a while). That, and even newer things in smaller orgs often involve convincing a CIO/CTO who stopped being technical a few years ago that the "proven" method they're used to is outdated -- or worse, they're on board but years of various security policies keep things locked in.

So yeah, agree with you on some level on both counts, but also would note that the shelf life on technology is way longer than tech people often give it credit for being. A year ago I was working on a project moving an organization off their mainframe to a 2014ish era web app (because that's when the project started). My last job involved working with a vendor that sold us something written in Delphi, and it was created way later than the 90s. Disruption is happening, but outside of certain sectors, it takes a very long time to spread, so knowing the slowly changing basics is still helpful.