So - you’re not planning to become a developer but you’re in a development-adjacent career and think you might want to learn to code. Great! Coding is fun! But a bootcamp or even just a couple classes can be a significant investment. Naturally, you want to know what you’re going to get out it. Every class is different - but there are some areas where hands-on experience can help non-developers better understand the developer psyche.
What I’m going to give you here is a shadow curriculum. You would probably learn most of these things directly or indirectly in a bootcamp anyway, but having a framework to hang your knowledge on will make learning easier and more efficient. By the way, if these areas sounds mostly contextual, that’s on purpose. You want to understand development as deeply as possible in the shortest amount of time, so think about weaving more of a hammock than a quilt. By tracing a few lines across the space, you can quickly build a supportive understanding.
Prerequisite #1: It’s not magic, you can do it!
Don’t get me wrong - when you first start programming there are going to be a LOT of things that are confusing. You will often (constantly?) feel like you only understand a fraction of why things are working (or not working) the way they are. But you will also feel tiny fleeting rushes of control. Every time you make a computer do something, you reinforce that this is just a skill like any other. It requires equipment, knowledge, practice. But as soon as you make a computer do something, you’ve proven the power is in your hands. Relish it and take confidence from it. Goodness knows the rest of us do!
Prerequisite #2: Everything is built on top of something else
Have you made a peanut butter sandwich? It’s so easy - just smear some peanut butter and some jelly on some bread and slap it together. But… where did the bread come from? You could have made that yourself, just get the flour, the yeast, combine it, let it rise… but wait, where did the flour come from? You could have made THAT yourself. Planted the wheat, killed the weeds, etc etc. But thanks to the industrial food system of our agrarian society you didn’t have to do all that stuff and making a PB&J is a viable lunch option.
Coding is the same. When you look alllll the way inside, it really is just ones and zeroes. But a lot of people have spent a lot of years grinding the flour and baking the bread so you don’t have to think about it. And that’s one of the best parts of coding! You’re always leaning on decades of work from a lot of smart people.
In practice, this also means we can’t really “code” in isolation. The code is intrinsically connected to the tools, the languages, the browsers. Those things are literally the bread and (peanut) butter of development. If you want to learn to code, you have to learn about these things too. Putting all those contextual pieces in place is what the bulk of this post will focus on.
Prerequisite #3: Not everything is important
What kind of bread is best for a PB&J? Was it pre-sliced or do you need to cut it yourself? If you have too much, should you store it on the counter or in the freezer? What about a take-and-bake loaf? There are reasons you might choose one over another, but at some level it really doesn’t matter, a sandwich is a sandwich. It’s the same with code, but as a newcomer those distinctions can be difficult or even impossible to spot. Just be aware they exist, and if you find yourself struggling ask someone if it’s because you’re trying to use the wrong end of the knife (no problem, just flip it around!) or trying to grow your own wheat (give up).
Development Shadow Curriculum
Alright enough with the prereqs, let’s start digging into the top-level tools and ingredients of development. These are the big-picture contextual building blocks that come together to create the modern developer experience.
The basic building blocks of the web:
Many of these are the mainstays of bootcamps and code classes. You can take classes in most of these things individually, and for good reason. They’re relatively simple and visual, so they’re pretty approachable topics but still let you get a lot done.
HTML is the code that contains all the content and structure of a web page. It differentiates between headers, paragraphs, and images.
CSS is the code that contains all the stylistic instructions for a web page. It can make a paragraph green or yellow, move an image to the side or the center, and round the corners on a button.
Javascript is an actual programming language that runs inside your browser. You can use it to add some interactivity to your web page.
HTTP is the way we move data around, which is why you type “http://” in your browser when you want to get some data.
Browsers bundle up all this web stuff into a single cohesive package. They make the HTML and CSS work together, they run your javascript, and they have special built-in tools for developers to help you build your web pages more easily and debug any problems you’re having.
When people talk about “front-end” programming, this is the stuff they’re talking about. Don’t get me wrong though, front-end programming is an approachable entry point but it’s a DEEP rabbit hole. Professional front-end development is just as rigorous as back-end development. The javascript aspect in particular expands to include many concepts from this next section.
The basic building blocks of a web application:
Usually when we talk about web apps we’re talking about being able to go to some URL, log in, and do something useful. Many “simple” sites would still be considered a web app - uploading a photo to flickr, buying something on amazon, saving a recipe on pinterest - these seemingly simple actions require some code on a server to do some work. Here are some of the basic components involved in building a web app.
The programming language is the first decision you have to make when writing an application on the web. All the code you write is going to be in this language. Common languages for web apps include ruby, python, php, perl, and java - but there are dozens more.
The framework is the second decision. If you were going to put out a fire, the framework is the fire truck. You still have to do a lot of work yourself, but the siren, hose, and ladder make a REALLY big difference. There’s nothing magic about the framework, it’s just code. But it’s code someone else wrote specifically to try to make your life easier. How nice!
The application code is the code you write yourself, the guts of your application that accomplishes your business goals.
Databases are a place to keep things. When someone creates an account on your site, you’d put their username in your database so you can look them up next time they visit. Your framework probably has some code to help you work with a database pretty easily. Common databases for web apps include MySQL or PostgreSQL. You can think of them as basically a complicated spreadsheet, because the data is stored in a table format.
A library is code someone else wrote that you want to use too. Different programming languages have different names for these, but they’re all the same idea: a reusable component that you can use instead of doing all that work yourself. Libraries tend to be relatively small and specific - for example, you might use a library to create PDFs. If you’ve people talking about open-source software, this type of code sharing is what they were referring to.
APIs are another way to piggyback on work other people have done. When you use a library, that code is essentially copied into your codebase. That isn’t always a useful or desirable way for someone to share the work they’ve done. With an API, you’re using code that’s running on someone else’s server instead of your own. For example, google has an API to get the latitude and longitude for a street address. Whatever code they use to figure that out, they don’t let you run it on your own server. You have to send them the address, they figure it out, and send you back the coordinates.
Servers are just computers running your code that are available on the internet. (And “the cloud” is basically just servers you rent).
Clients are the devices that are asking your server for information. In general this is just someone’s browser. The reason we say “client” instead of “browser” is because if your server is hosting an API, your clients might include other people’s servers as well/instead of web browsers. Or, maybe your servers are handling traffic from a native mobile app. The mobile apps are considered clients of your server as well.
That’s quite a few things, but not unmanageable. It does take a while to wrap your mind around these, and some of them blur together, so it is pretty helpful to have an instructor walking you through it. If you’re trying to learn to code on your own, definitely find someone you can at least ask questions of. If you don’t know any web developers, meetups are a great place to start.
The basic building blocks of actually writing code:
Previous sections were mostly about the environment or ecosystem that you’re working inside of. This section is about how you actually do that work.
Editors are any program we use to write code. They don’t have to be fancy - you probaby have an editor on your computer already, like Notepad or TextEdit. You can use just about any text editor to write code. However, there are many programming-specific editors that will make your life a lot easier. Sublime is a really popular one, it will highlight different aspects of your code in different colors so it’s easy to read. Depending on what kind of programming you’re doing, there might be an IDE available like RubyMine or Eclipse. IDE stands for Integrated Development Environment, it’s a high-powered program to assist in actually writing your code and with many of the ancillary activities that you need to do as well.
The command line is a way to interact with your computer using text instead of using the mouse. It lets you get directly into the guts of your computer and do some pretty powerful stuff. Some types of development rely much more heavily on the command line than others. For web development, you’ll use it mostly for installing stuff and starting up your apps. While it isn’t necessary to become a command line expert, it’s one of the most transferrable skill sets because it’s at a “lower” level than ruby/python/javascript/etc. Not every developer uses ruby but every programmer uses a computer.
Debugging is the fundamental iterative workflow of development. You have a goal in mind, you write a tiny piece of code to take a tiny step toward that goal, you run it, and - inevitably, it doesn’t work. So you dig around, make some guesses, try some other options, until finally it works! And the cycle begins again. And again. And again. And again. And again. And again. And again. And again. And again. And again. And again. And again. And again. This is not a joke - you’re going to be doing some serious debugging.
Google is honestly the primary reason I have a career. You’re going to be googling syntax, error messages, code snippets, questions, expletives… the list goes on. Google sits alongside debugging at the heart of the developer workflow. Don’t think for a second that “real programmers” don’t google; professional developers spend at least as much time on google as they do typing code.
Actual coding concepts turn out to be important too. This is where you’ll learn about variables, data structures (lists and hashes), and control flow (ie code that makes decisions). For you as a non-aspiring-developer, these are important because if you don’t understand them you won’t be able to make much progress in your learning. But I’ve buried this item so deep in this post to emphasize that development is not just about the code.
A version control system like git is a way to collaborate with other developers. It’s like the “track changes” feature in Word or “suggestions” in Google Docs: it lets everyone see what’s been happening. There’s a heavy emphasis on git in many bootcamps because it’s central to a professional workflow where you’re part of a team. The details of git can get pretty arcane, I wouldn’t worry too much about this one. Get a good cheat sheet and leave it at that.
I know I haven’t exhaustively laid out every single piece of a professional development workflow. For example I’ve omitted environments, release, and automated testing. Hit me up on twitter or email if you have any burning questions about something I didn’t cover.
The basic building block of writing good code:
There’s only one, but it’s one of those “minute to learn, lifetime to master” kinds of things.
This might not be super strongly represented in your introductory coding classes. Intro classes are mostly about the mechanics of getting something working, rather than the deep philosophical questions behind various tradeoffs of doing things one way versus another. But, I’d be remiss to leave this out because it’s critical to the developer experience.
There’s an old dev saying: “There are only two hard things: naming and cache invalidation.” Cache invalidation is pretty technical, and it makes intuitive sense that there are some hard problems in programming. But naming? What is so difficult about naming that it’s one of only two items in a saying?
First let’s define exactly what names we’re talking about. Without knowing what code looks like, it might be difficult to imagine, but bear with me… It takes a lot of code to make the sites and apps you’re familiar with. I’m guessing thousands of developers have written millions of lines of code to create Amazon.com. How do they keep all that code straight? How do they work together? What keeps it from becoming a giant mess? Naming.
When we write code, we have two audiences. One is the computer - if the computer doesn’t understand what we wrote the program won’t run. But the second audience is other developers (or our future selves). Let’s take a really small example:
dog = Dog.new(name: "Aston", breed: "French Bulldog")
.
.
.
. # a lot of other code
.
.
.
dog.name
What do you think dog.name will do? Even if we can’t see where the dog was created, it’s clear that dog.name represents the name of a dog. Now look at this equivalent code:
x = Dog.new(name: "Aston", breed: "French Bulldog")
.
.
.
. # a lot of other code
.
.
.
x.name
Huh? What the heck is x? It could be anything, and x.name isn’t much better. It could be the name of a book, a movie, or a person. In this small example, it’s easy to look up a couple lines and see that x is a dog. But in a complex system with millions of lines, the definitions and usage of a concept easily become distantly separated. The only thing that keeps everyone productive (and sane) is clear, consistent, descriptive names.
Sounds easy enough, maybe even obvious, right? Wrong. Code includes contextual meanings, colloquialisms, and all the variety and flexibility of plain english. Ideas that are commonplace on one team might be totally foreign to another team, and the words or phrases that some people understand almost implicitly mean very little to others.
To add to this complexity, there’s also a structural component at play here. We decided to make something called a “dog” but why not “pet” or “mammal?” What if we make both “dog” AND “pet?” We naturally start to create hierarchies of meaning and relationships between different entities, just like in the natural world. And just as writers and poets have spent lifetimes describing the world, so too do programmers.
Because at its heart, programming is about creating a specific representation of a particular slice of the world that happens to be important for a business, so that we can manipulate those ideas digitally and in turn manipulate the real world. Names are the way we do it.
A final word of encouragement
Reading code is way easier than writing code, so if you get your head around some of these big ideas you will definitely be in a much better position to have confident discussions with developers at a relatively granular level.
I do hope you spend a little time playing around with programming. Let me know if you need any help!