This is a post that I've been meaning to write for quite some time now.

The question of "Should I become a Front-End or Back-End developer" pops up quite regularly, so I thought I'd pose the question here too. No, not for me, the author, but for you, the reader who may be new to programming and wondering which of these directions you should head in.

This question is usually phrased in such a way that the options are either-or, but never both. But more importantly, the question is usually phrased in such a way to imply that these are literally the only two avenues to pursue as an aspiring developer.

I want to offer you an exploratory thought experiment into the vast array of other possibilities that you could potentially explore if you want to get into software development. Front-end and back-end web development is only an extremely small fraction of what is out there!

Why might you consider other areas of development? Web dev is where all the hype and buzz is, surely that's the best possible path, right? Well, that honestly depends. Lesser talked about positions usually means there is less competition for those jobs, and with less people applying, they often offer higher payouts as an incentive to try to get the best possible candidates for these less popular jobs.

But, you may ask, "what ARE these other possibilities as a developer?"

Let's start by expanding on the idea of a web developer. The core back-end languages and toolkits used today revolve around PHP, Node.js, Python, Ruby, .Net, and other similar languages.

Now think of each of the libraries for these languages.

Do you include a module to access a database? Ask yourself, "who writes that library?"

How about something that parses JSON? Or generates JSON for data? Same for XML? What about the library that reads the metadata from a JPEG image file? Or how about the library that fetches HTTP(s) content from another system?

Each of these libraries are pieces of code that someone, or a group of people, wrote, manage, and maintain. These types of libraries are often open-source, and available to accept contributions too!

But how did they come into being? Usually someone is working on a particular project, saw a need, wrote some re-usable code, and decided to package it up as a library.

One such example is when doing web development in PHP, I was frequently writing complex SQL queries to interact with my databases. Over time, I realized most of the code was repetitive, so I eventually bundled it up as a separate library and published it publicly.

Sometimes it may be something that seems simple and trivial, but it can save a significant amount of someone else's time to research. Another library I published is a single file, a single function. It translates shipping/tracking numbers into a URL for each shipper's tracking web site. Pass in a USPS tracking number to the function, and it spits out the URL for tracking that particular USPS package. Not terribly complex, but it means the research of several different tracking number formats can be crowd sourced! As users of the library handle other shippers, they provide those shipper's tracking number formats as either issue tracker items or pull requests, and everybody benefits. :)

Now let's take things into a slightly more complex direction. Computer languages don't inherently exist on their own, and they get updated over time. How exactly is this?

The ability for a computer to read and understand code such as PHP or JavaScript inside of Node.js are themselves programs written in other languages. These are also areas of active development. Some of them have high profile companies backing them, such as .Net from Microsoft, Go from Google, Swift from Apple, or Hack from Facebook. Each of these languages has an entire team of people who work on them full time at their respective companies!

Let's take a step back for a second, and look at the wide picture instead.

Are you a Mac user? Or Windows? What about Linux? Or possibly even FreeBSD? Each of these are also programs that have people actively maintaining them!!! Well, kinda...

Yes, each has a mountain of people that work on them. However, they're each not an individual program. They're collections of programs all bundled together, often maintained by entirely separate teams.

For instance, the Windows Start button is an entirely different codebase managed by entirely different people than Notepad!

But this doesn't stop at just user-facing desktop applications.

An entire computer is layers on top of layers of different types of programs all interacting with one another.

Your keyboard for instance is most likely USB (even possibly true if you're on a laptop, with an internal USB connection). There is firmware on modern keyboards that accept the key presses, and then sends the signal over USB back to the USB root device.

Think to yourself: "who writes the keyboard firmware?"

But then the USB root communicates back to the rest of the system, sometimes over PCI-Express.

Think to yourself: "who writes the USB interface code?"

And then there is a keyboard driver in the operating system to receive and interpret those commands.

Think to yourself: "who writes the keyboard drivers?"

From there, the driver sends a signal to the operating system kernel to handle and route.

Think to yourself: "who writes the keyboard kernel subsystem?"

At that point, the keyboard subsystem routes the message to the active, in-focus application though the kernel's ABI (application binary interface)

Think to yourself: "who writes the ABI?"

Now let's say our application just so happens to be a web browser. This web browser is displaying a form on the screen with several elements that are interactable.

Think to yourself: "who writes the browser code to handle the keyboard event, sending it to the right focused item on the web page?"

And all of this is for a single key press, every key press, every time you type.

Web browsers can do quite a bit more than just accept keypresses though. They send and receive data over networks using a variety of protocols, encrypt your data for privacy and protection, decode and display a variety of photo, audio and video formats, and countless more features.

This may seems like a single monumental task, but that's not entirely the case. Instead, like mentioned previously, this is all handled via a collection of smaller, simpler libraries. Most of these libraries are maintained entirely independently of the browser itself.

Curious what these libraries may be? In Chromium based browsers (Google Chrome, Microsoft Edge, Opera, etc), Go to "Settings" > "About" and click on "open source software". Microsoft Edge that I'm typing this on currently has 371 libraries listed.

Do you use the command line interface in your operating system?

Every single CLI command is a program or a script that somebody at some point wrote.

Who wrote all of those commands? Who manages and maintains them? And who will write the next iteration of them? That could possibly be you!

But what happens when we step away from the desktop computer, what else is out there?

Think to yourself...

Who writes the user interface for my smart TV?

Who writes apps for cell phones?

But wait, who writes the OS itself for the cell phones!?

How about those IoT devices, who writes the program for those smart outlets, smart switches and other IoT devices?

And how about those drones everyone loves to fly, who writes the software for those?

This being the Christmas holiday season, who writes the microcontroller code that allows Christmas lights to blink?

Who programs the digital interface on your microwave or stovetop?

Who programs the traffic lights when you're driving down the road?

What about digital signs on billboards and in windows of businesses?

RGB LEDs are all the crazy right now! But who writes the code for those to change color and blink?

... lastly, obligatory ... who programs the VCR?

But this is still nowhere near an exhaustive list of areas a programmer can explore! This can also become quite overwhelming very quickly, being flooded with endless possibilities.

The vast majority of these, however, can be broken down into a simpler context: problems and solutions.

In the end, all we're doing as developer is using structured commands to have electronic machines solve problems for us.

So next time you think to yourself "should I be a front-end or back-end web developer", change that up to "which problem am I trying to solve, and which set of tools would best solve it?"

It may be that extending an existing library might solve the problem at hand. It may be that a new command line tool could solve it too. Or maybe it does require a nice web based graphical interface. It all comes down to what tools are available, and which ones are the best at the time to get the job done.