Programmers: Look Deeper And Learn More

programmers

This is not a rant.

If you read yesterday's post, you might presume that I'm going on a daily rant. But today I'm not ranting. I'm just making a simple observation – and hope it will help you out, if you're a programmer.

A quick look back

When I started to write code for the web, there was a clear distinction between people who had to know servers and networks and people who had to know web programming languages. This was back in the mid nineties and the first group of folks were called network engineers. The second group were called software engineers.

A trend worth noting

In the last 19 years, something really remarkable has happened. Maybe you've noticed it. The web, web applications, and software are everywhere. This means servers are everywhere. Your code is everywhere.

And it all has to stay online all the time.

High performing software doesn't code itself. And it's not natural. You have to think about it as you code it. And that means you have to understand what you're doing. And that means….wait for it….

You have to understand servers and networks.

You see, in the old days, you could focus on your code and let others worry about scaling it. But today, you can't hide in your cubicle, working on your own code, in your own virtual environment, and just hope it will all work.

Hope is not a strategy.

So when you write code, when you call an API, when you write SQL queries or anything like that, it's important that you understand the architecture of the platform you're coding on.

Here's what I told a friend this evening,

“Programmers used to just have to know languages and tools. Today they have to understand architectures and networks. If they want their applications (and code) to scale, they have to know the full architecture stack that's delivering their app.”

So as you go about writing code, look deeper. Learn more.

The question isn't if you know Ruby, Python, PHP, or C#. The question isn't if you understand MS SQL, MySQL, MongoDB or PostgresSQL.

The question is how well you understand the specifics of the architectures you're using, on the server infrastructure you're using, so that you can minimize risk, maximize uptime, and deliver on your business promises.

So look deeper and learn more.

This post may contain affiliate links. If you click on them and make a purchase, I'll get a commission, at no cost to you.