Why Full Stack really just means Software Developer

I started working construction under the Denver summer Sun. My job involved walking between stacks of precast concrete soundwalls for hours, tracking their location by memory. Once a panel was placed on a stack by a loader, I would mark an id on the side using a wax pen. One day while think there had to be an easier way to track these giant slabs of concrete, I realized I could turn this problem into a program. I could make a map of the yard, and use DOM Scripting to model the process of storing the panels of concrete. It would be an overhead view. And it would work! Somehow I knew it would work.

Up to that point, I hadn’t build anything useful in JavaScript. But there was one thing I knew. I had realized that code worth more than basic doodles requires you manage the state of the application. It was like a I had found a ghost in the machine. And unless I could retain the state, I would kill the ghost. And that was proving difficult. Most of my free time those days I spent working on my first big application. It was an all in one solution for restaurants that was nothing but spahetti, minus delicious meatballs. More like chopped up spaghetti for a 5 year old. I could not stop killing the ghost. But it made me realize why JS on the front end needs JS on the backend. And that led me to realize what full stack development really is.

Here is what I learned, a list of technologies that went into developing the Yard application. I want to discuss those things. But I will also discuss what I learned about software development, and why I know for a fact now that being full stack is not special.

  • jQuery — jQuery is actually the start of the story, and yes, this is 2021. I used jQuery in 2020. Why? Because it is an interesting technology that is a part of the web’s history. And I was tired of seeing jQuery in Stack Overflow as the solution to problems and not being able to understand those solutions. So I thought maybe I should use jQuery in my app. Especially since the app had a large drag ‘n drop component to the functionality I was envisioning.
  • Express — I worked on the UI using HTML, CSS and jQuery until I found the ghost in the code. And I realized how to manage state. I realized I needed to periodically save the state of the application. And that I could do that by using a database. Boom! My head exploded. And that database could be in the cloud. Boom! My second head exploded. So I started learning Express and Node.js while building the app. I didn’t know HTTP or REST and I didn’t know that “mobile” and AJAX were about to give me the biggest bear hug ever. I didn’t really understand what servers did on the backend. All I knew was that I could only get to the database by going through Node/Express. That was the rule. And I knew that I needed to teleport the ghost to the database, then call the ghost back to the UI when I needed it there.
  • JSON —One day it dawned on me as I wrote the id on a ton of concrete hanging in chains from a loader… it dawned on me I understood the secret of being a programmer. I finally understood what it was that we do. We look at a problem, and we find a way to model the problem. To do that, we pick a technology that can successfully capture the details of the data that are important. Then we use that to model the data from the problem. I realized for my problem, of how to make an application that could store the panels, that I could pass that data to a database. But how? And then like a voice in a soft dream my mind whispered “JSON”. And for the record, JSON is perfect. The way it works with JavaScript is like blood in the veins.
  • MongoDB — So now I found the heart of the hive, the honey in the bowl. The data! There was a stockyard filled with data that I could model with JSON, load into a database, call that data from a server, send it over the Internet, download it into a handheld device which presents a UI that has it’s elements positioned based on the values stored in JSON! Whew! And no one around me cared.

Nobody told me to write this app. Nobody said, “Hey Will, you’re a programmer, right? Well I want an app that can track the location of panels in the yard in a handheld device. You know JavaScript right?” None of that happened. I just started writing it. I didn’t even tell my boss that I was writing the app. I thought to myself, “Why bother? I know I’m going to write this app. Mainly because I think it is a cool idea, and I know that it will work, even if I don’t know how to build it.” I think that moment is when I became full stack.

I would wake up at 5:30 in Denver. And be at work by 7am, outside in the winter. Frozen hands handling metal rebar and tools. Then that sweet sweet Sun would rise and turn my fingers into pins. But that pain was better than the cold, and I could look at the stock yard and see all that data. Lunch would come then working under that Denver sun in July, shovel after shovel of concrete being dragged by yours truly out the shoot of a truck, covered in dust, oil and sweat, thinking ‘bout that sweet sweet code, all that data I was learning how to model, like God turning dust into man.

And when the dark black death cold of space crept into the night and my breath was like a white mask I would go inside and write code still covered in concrete and eating like an ape. Then sleep till 5:30.

And I did that for nine months. And in that nine months I learned what software is. Software is a solution to a problem. The problem is modeled by the developer a number of ways. One of those ways is capturing the data to analyze it and reuse it. The problem also becomes a series of functions that mimic the processes that the problem is made of. These functions use the modeled data to reproduce the world of the problem with abstractions. These abstractions of the real world data and processes form software.

So a full stack developer is a software developer, because a software developer is a professional who knows the tools of his craft, and can use them reasonably well to create a desired outcome.

What makes a software developer (AKA, a full stack developer) different from a front-end or back-end guy is the ability to show the user the entire abstraction as a UI they can use to solve the problem. Creating a UI that the user of the software recognizes as a model of his data AND a solution to his problem. That is the final piece of the puzzle. Seeing the whole solution at once.

So the software developer is a man between two worlds, fighting with two chains trying to bring the two halves of the world together. He sees the UI and the data model in his mind at the same time. And he thinks to himself, “Hmm… this thing is going to work. I don’t know how, but it is going to work.” He sets out to learn how to fill the gap between the screen and the data.

And so back to the beginning we go… and why full stack development is actually just being a software developer.

I’m sure you’ve heard the term “non-trivial”. And for years I wondered what that meant. What is a “non-trivial” program? And when will I know when I wrote one? I could never find a good answer on the Internet. So here is one… a good answer to that question… what is a “non-trivial” program?

A “non-trivial” program is a program that is born of the desire to solve a problem that may not even be seen as a problem. Or rather, the writer of the non-trivial program is often times revealing a problem and the solution to the problem at the same time. And that solution (and here is the key part, my little woodland friends) requires state management that extends from a datastore to the UI, with multiple technologies in between. You know what a “non-trivial” program sounds like? Software. It’s beyond the boundaries of an algorithm, or a tutorial. It’s a problem that you noticed in the real world that you put in a UI. And it was born of data that needed to be organized. The UI reflects that organization, it is the model of the process, it is the tool used to communicate effectively with the user. If you have written a “non-trivial” program, you will know exactly what I mean. Otherwise you are still learning how to be a “full stack” developer. I’m kidding… I am not that cynical. But I do think there is a technical aspect to this art that has to be understood. You have to know the difference… software developers use a “full stack” from the database to the UI to create solutions. They always have.