How to Become a Developer Part 3: What type?

Part 3 in "How to Become a Developer." We've covered a lot of ground so far. We're almost to the point where I start telling you, "Go read this. Go do this."

Part 1 was focused on why you would want to become a developer, and Part 2 covered the character traits you need to succeed as a developer.

What could possibly be left, you ask? Well, before you become a developer you need to figure out what kind of developer you want to be, and that's what this post will cover. I promise the next post will be actionable steps to send you down your journey, but first let's start with the end in mind and figure out where we want to end up.

Here's what we'll cover in this post:

1. What kind of software should you build?
2. What kind of development should you learn?

What kind of software should you build?

To help illustrate this, let's analogize becoming a developer with becoming a musician.

If you wanted to become a musician, you'd have to decide a couple of things. What kind of music do you want to play? Pure jazz—or a little bit of everything? What instrument(s) do you want to play? Most people already have these answers in mind. They imagine playing drums in a jazz trio or an electric guitar in a rock band.

Like music has genres and instruments, software development has application types and programming languages.

Jazz, pop, and classical

There are a few basic types of applications. This list is definitely not inclusive, but it's a list of the most common ones. These are also my own definitions used for the purpose of the discussion to follow.

Websites

Websites are one of the simplest application types. They're really not even applications—they're more like a collection of documents put online.

For our working definition, a website is a site online that is not interactive. There's no user accounts, no logic, no data inputted or outputted—it's just a collection of pages strung together by links. Maybe there's an occasional form or something, but there's really not much to interact with. You're just reading content online.

There are fewer and fewer pure websites out there today—most people want to interact online and not just read a virtual document—but there a few still out there (one of my personal favorites is the Space Jam website that Warner Bros. has decided to leave up in its original glory).

Webapps

Webapps differ from websites in that webapps are interactive. You can create a user account. You can upload pictures or write posts. You can upvote, like, comment, or hide posts. You have followers, networks, etc.—there's logic to what you see: you only see your friends' posts.

Based on those definitions, Facebook and Twitter would be considered web apps. We colloquially call those sites "websites", and that is correct. It is a site on the web. But a webapp is a more specific classification of a website. It's an "app." It's kind of like in math class when they said "all squares are rectangles, but not all rectangles are squares." All webapps are websites, but not all websites are webapps.

In the end there aren't wars that need to be fought over these definitions. They're only stated just to aid discussion to come.

Apps

We all know what apps are. Apps cover about anything that is interactive that isn't also a webpage. Apps live on your phone, your TV, your refridgerator (just why?), and many other places. Apps generally behave differently from webapps. They usually don't feel like just using a browser that happened to be located on your fridge. They feel different. Native. Smoother. More intentional in their purpose. Apps usually exist for more than just to be a button on your home screen linked to a webpage. They usually have a special context. If it's an app on your phone, it's not just a remake of a website—it's the website content enhanced by things like your camera, your voice, or your location.

Apps seem to be the way of the future and the present. Small, isolated contexts for a specific purpose.

Internet of Things

I'll mention this category briefly, and that is Internet of Things. Here's Wikipedia's definition:

"The Internet of things (IoT) is the inter-networking of physical devices, vehicles (also referred to as "connected devices" and "smart devices"), buildings, and other items—embedded with electronics, software, sensors, actuators, and network connectivity that enable these objects to collect and exchange data."

Basically, a lot of devices have internet connectivity now, and they do some "thing" on the Internet. These are things like smart dishwashers that can get hacked. (Not everything needs software and internet connectivity guys.)

Some of these IoT devices have their own companion apps, and some have touch interfaces that let you interact with them. You could call any or all of these things "apps." I just wanted to make a special distinction to cover the more hardware-y "thing + sensor" category—stuff that's not just various sizes of screens (phone, tablet, TV, etc.).

You want to be in webapp-land

As a new developer, you want to learn how to make webapps. The reason is simple: webapps will open the door to anything else you want to do. Want to make a webapp? Great. Website? Still great—websites are just simplifed webapps. Mobile app? A mobile app needs a webapp to power it (as we'll talk below). Even if you want to get into playing with hardware and internet-of-things-esque things, those devices are powered by webapps, and the skills you learn will directly transfer to it.

As a side note, you probably don't want to be just a website developer. The time for making pure websites is probably quickly coming to a close. Things like Squarespace and Medium are essentially webapps that make websites. The time of just making pure websites is going away quickly, and may already be gone.

Ok. So we know we want to make webapps (also interchangably just called "apps"), but how do you do that? One last thing to cover before we get into the how-tos: what kind of development should you learn?

What kind of development should you learn?

By what "kind" I don't mean should you learn python vs ruby—hang tight that's coming soon—I mean that there are different types of development, and we'll go through them now.

Expert or generalist?

Back to the music analogy: would you rather be an expert violinist, or the person who can play a little bit of drums, a couple riffs on the guitar, and some keys? I'll answer that for you—you want to be the person that can just jam out on whatever is in their hands. This is an analogy and you can do whatever you want in your real life, but when you're first learning to develop you want to be a generalist.

Why a generalist? Well, a few reasons. For one, it takes a while to become an expert in something, and when you're just starting out the first goal is to learn enough to get some experience somewhere. There's so much you don't know that no matter what you end up doing you will learn and grow from it. Secondly, when you're first starting out, you really don't know what the options are and how you will like them. Being a generalist first let's you get your feet wet in a lot of different areas. Thirdly, any person I know or know of that is respected for expertise in one thing has general skill in all other areas. In fact, the general knowledge of other areas helps—and I might even say is required — for truly understanding one specific area. In college, music majors take a class that has them try very briefly (maybe a week or two) all of the other different types of instruments. Learning something in a related area deepens your understanding of another by seeing the relationships and connections between them.

You'll just have to trust me on this, but you want to be a generalist when you start out. A general app developer.

"The Stack"

Developers have a term for everything that is involved in making an app—from the actual code we write all the way to what server we use and how it's hosted. This is called "the stack." As a developer, you can choose to work at any slice or slices of the stack. For right now, we'll just look at two pieces: the "frontend" and "backend."

Frontend

The "frontend" consists of everything you see in the browser or on your phone. I'll quote from my "I have a great idea for an app" post:

Most apps today are really just a pretty presentation layer—they’re not doing a lot of processing or computing. The app requests data (like all of your Facebook posts) and presents it to you in a nice feed, and sends data back to the server (like when you post a picture of your coffee).

The frontend handles requesting data, presenting data, interacting with users, and sending the user's data and actions back to the server. Frontend developers are concerned with how the app looks, feels, and interacts.

Backend

The "backend" is everything you don't see in the app: servers, network requests, and databases. The backend is responsible for storing and retrieving data, authenticating users, and communicating with other apps and servers. It's the substance that powers the frontend.

"Full-stack"

This term is kind of sneered at amongst the developer community, but to become a good generalist you're going to need to become a "full-stack" developer. You can always specialize later on, but at the start you're going to want to know how to make an entire app soup-to-nuts.

Let's get to coding

With all of that out of the way, we can now begin the process of learning to code! Now we know exactly what we're setting out to do: to become full-time employed as a full-stack web developer.

In the next post we'll get down to brass tacks about how to learn development—complete with tutorials and all.

Thanks for reading!

John