Full stack
WHAT 'FULL STACK' MEANS TO ME
Chris Coyier has an article called The Widening Responsibility of Front-End Developers and what I find most interesting about the article is how it skates over one of the most critical issue in web development since the release of Backbone.js: the emergence of data-driven websites. In the same way that a travel magazine, a cooking magazine, and a copy of the an annual farm report are different, so there are lots of different kinds of web development: the first is light and fluffy and needs no data; the second has some important data needs, especially if you allow for things like ingredient substitution, modifying serving counts, and nutritional information; the last is incredibly data-driven, being almost nothing but tables and charts.
I share the strong interest in UX. Developing for people with different needs, different cognitive and physical skills, and on different devices, is a fantastic challenge. But most of my work has always been incredibly data-heavy. My time at Isilon and Splunk were quite naturally data-heavy, but so were Spiral Genetics and CK-12, and even Indieflix was organized around a core about movies, student filmmakers, and film festivals.
So I bristle a little bit when Coyier writes:
The big picture is that as long as the job is building websites, front-enders are focused on the browser. Quite literally:
- front-end = browsers
- back-end = servers
This isn't how I see it at all.
I see it more like this:
- The Website = HTML/CSS/JS & the data, acquired by REST or GraphQL
- The Business = Why we're building the website.
This is why, when I talk about full stack, I talk about the back-end in the most boring technologies possible. I just Python & Django, or Go & Swagger, or Node & Express, because those are boring, easily bootstrapped tools that do one thing well: they provide an interface between The Business and The User.
Which is what I do.
I put useful, elegant front-ends in front of businesses. At Isilon, the "business" was configuration and monitoring of the first major cloud storage hardware platform; the website suite used a boring back-end, Python & Django, to communicate with that platform and present details to the user, and took user input and marshaled it into commands to that platform.
Indieflix: I put a website in front of a non-profit's business process that helps student filmmakers get the work out into the world. Spiral Genetics: I put a website in front of the first parallelizing gene sequencing engine in the world. CK-12: I put a website in front of a non-profit's classroom management algorithms. Splunk: I put a lot of websites in front of specific Splunk search & visualization requests for a variety of companies and products, including T-Mobile, Microsoft Exchange, and VMWare. Big Fish: I lead a team putting a face in front of our decision-making processes for publishing games.
The Spiral Genetics example is especially trenchant. The engine they'd written was capable of multiple sequencing steps, but the command line tool could only initiate one command at a time. By wrapping that in a Python tool that could take multiple commands, we turned the command line tool into a library that took a genetic sequencer DSL written by our brilliant subject matter expert. I made that request, and it opened up a whole new world, because now the website could run asynchronously, and the user could receive notifications when jobs were done via SMS or Websockets, and the usability of our web interface skyrocketed.
If you're a "front end guy" and your team doesn't control the REST API, and doesn't understand how the business process is being translated into the data you're expected to manage, you don't know how to do your job! Your blindly following a recipe, and you're expected to get it right. Maybe you will; lots of people follow recipes to the exact letter and get what they want. But if you don't have a comprehensive understanding of how the front-end and back-end interact you can't identify when the API is insufficient and request changes, as I did at Spiral Genetics.
I see React and Redux and so forth as a natural upward evolution of web
development. Some of it, yeah, feels a little bit like The Return of
Visual Basic, complete with the no-code tool things that are now
popular. Those of us who are good at programming know that sometimes
you go around Django's ORM and write SQL; sometimes you go around
Python's facade and write to the metaprogramming layer, and sometimes
you go deeper and write a C-shim to pull in performance; sometimes you
give React the finger and write that you want to use
document.getElementById()
anyway. These are last resorts, but knowing
them and having the experience to know when to use them, can make a big
impact on your abilities, and your career.
Which is why I continue to be "full stack." It's not enough to care about the browser layer. You have to care about the data. You should know enough to talk about how the data is acquired, organized, massaged, parsed, and presented, both from the business to the browser, and from the browser to the business. Let other people write and work on the business logic, sure; but understand it well enough to present it, because that's what we web developers do: we present a business's interests to people interested in the business.