The FullStack.coach would not be the FullStack.coach without its own definition of a FullStack Dev… Or Full Stack Developer… ehm... ok ok, Full-Stack Engineer… 🙈
But apart from this, if you are interested in becoming a Full Stack Engineer, it can be helpful to define a roadmap for you. This guide is here to help you get started with that:
- We will first clear some doubts and speak about the software industry's take on this terminology
- Then we will look at fundamental full stack skills with suggestions on how to learn them
- Lastly, we'll learn how to fly...
The Common Definition
How can you agree on a common definition of something if you can't even agree on how it is written? (we will explore more spellings as this article takes on speed)
You can’t. This is why every person and organization will define it as they see fit.
Bootcamps will narrow down the definition so you don’t freak out; similar to course platforms, that will tell you the X amount of cool tech you need to learn (which you will also coincidentally find on their platform 😉 There is nothing wrong with that by the way, sometimes it's better to just get started with what's there instead of diving deep into terminology as you are doing right at this moment)
True engineers will tell you that there is no such thing as a fullstack engineer.
Programming beginners will tell you that Fulled Stacked is cool and sometimes that they want to "become a Full Stack".
Pragmatics will tell you that there is no such thing but will like the convenience of the terminology.
L. Ron Hubbard will tell you that there indeed exist Flying Egg Laying Wool Milk Pigs...
OK, one thing is clear: full stack won’t ever make it into the Oxford dictionary. But whom to believe and how to embrace this fuller stack developer?
I’m a mix between a pragmatic and L. Ron Hubbard, so here goes a bipolar view.
#1 The Real Part - The Terminology
As mentioned, Bootcamp advertisers, course makers, mentors, and coaches will sometimes say something like: Frontend Technology X + Backend Technology Y + a bit more stuff they are teaching = Fulled Stack
Other well educated engineers and craftspeople will keep things simple by despising the full stack terminology per se.
That’s not necessary, though. This top-notch article on the topic explains in detail how this is still a useful designation for a well-versed engineer who knows how to tie together the front and the back of an application and how to top it with additional skills like infrastructure, cloudiness, UI/UX, web design as well as business requirements like project management, marketing concepts, design basics, etc.
Yeah, it's a lot, but a bit more about it in the next part.
While I jumped through different stages of my career, I always felt uncomfortable having done so many different stuffz and thus calling myself a Fool Stack Engineer. At all of my companies, I had varying responsibilities which couldn’t be described more concisely.
But to be complete: I will tell strangers that I’m a software engineer and I will put “software engineer” in more personal online profiles and “Full Stack Engineer” in profiles that describe my career in more detail.
I will almost always tell HR, employers, and CEOs that I'm a "fullstack" because they can categorize it.
And mostly I will be more specific with fellow developers telling them that I’m doing Ruby/React at the moment.
I hope you agree now, that Full Stack Developer is just a convenient term for people who have strongly variable responsibilities as a developer. But at the same time, there is never one answer to everything.
#2 The Surreal Part - The Requirements
This question is all over the place:
"Me want become a fuller stacked, what do I need to learn?"
Let me suggest you a metaphor:
Germans are infamous for describing things "well" with long expressive nouns (and possibly other word classes) squashed together into 1 word. "Full Stack Engineer" translated to German is "Eierlegendewollmilchsau" and then translated back to English again it means almost literally: "Egg-Laying Wool Milk Pig"
I first read this term in a mail when I applied for my first student developer job at an outgrown start-up kind of company. To describe the job position, the kind lady wrote that they don’t look for the Eierlegendewollmilchsau...
—> Sidenote — very ironically, the CEO had a funny day interviewing me: I guess because I didn’t have experience in development whatsoever he bombarded me with riddles like how to express the number 32 solely with one hand or how a refrigerator works. And lots of other stuff from physics, maths and science. So he definitely DID LOOK for the FLYING Egg Laying Wool Milk Pig! This was my craziest interview ever and being the first one in the software industry I thought, “damn what have I gotten myself into??” Thank god they didn't hire me to use me as a fuhl stäck engineer.
So, the real question becomes...
What is an Egg-Laying Wool Milk Pig?
Here is a digest of key skills sourced from articles, quoras, some good YouTube videos, and of course my personal observations as a Wool Milk Pig. You can use it as a guide for your own definition of Full Stack.
Please be careful with the "How to learn suggestions". Some of them are just accompanying methods that helped me when I needed them. The first and most important action you should be taking is building full stack web app products from the beginning and then use additional materials that power up your process.
Egg-Laying
Oftentimes you’ll just shoot out some small eggs here and there. Change the character max. amount of Twitter to 223 again, add a new thumbs down 👎 button to Facebook… optimize here, refactor the old stuff there… front- and backend banalities like this…
To do that you’ll need to have some understanding of how backend, frontend, and the database work together. Sometimes you’ll need a grasp of the configurations of the applications to understand how to manage performance.
Then, from time to time, you’ll build some foundational nests where you’ll put the eggs. For example, building a whole new "amazon Prime Later" section, a convenient API microservice for the FBI to track who is at home right now, a "little" CRM application for your CMO, or a quick prototype to test an idea of the CEO…
How will you do all this? By having a Minimum Viable Fullstack Engineer "profile":
- Uses version control
- Knows HTML
- Knows CSS
- Has a strong grasp of programming fundamentals
- Is comfortable with JavaScript frontend development (other languages are a plus, JS is non-negotiable)
- Understands distributed systems
- Knows at least one primary backend language
- Is skilled with at least one datastore/database
As you take on more responsibility as a developer, you’ll also be asked to make a decision to choose the right stack for the bigger “eggs“ and "nests".
Because technology, job positions, and employment status are changing so fast it’s virtually impossible that you’ll stay inside the tech stack that you initially learned. Learning one new language and one new approach/framework per year could become a reality for you.
Thus, figuring things out on multiple levels of abstraction and complexity as well as adapting to new requirements will be a key part of your developer life.
How to learn to lay eggs?
The best way to learn the different fundamental fullstack parts and how they work together is to build products.
If you’d like to build something useful, you can put in some thought into preparation.
If you just want to get started now, take a tech stack of your choice and look for a good complete walkthrough that covers most points mentioned here.
Produce the Wool
No matter if it’s just the eggs or the whole nest. It’s better to give them an additional layer of wooly protection.
Full stack devs are expected to have an understanding of testing. Even better if you can sprinkle in some understanding of TDD.
But it doesn’t have to end here. Security, authentication, authorization, caches, cookies, and other deliciousness will definitely be on your list too, sooner or sooner.
Hot to learn to produce wool?
You'll need to dig deep into the testing vocabulary and its concepts. For starters, let this be your main focus:
unit testing & integration testing
To understand unit testing and TDD, this is the best resource for all levels of developers: Test-Driven Development: By Example by Kent Beck. If you are at the very beginning, you'll at least understand the half of the book.
In his Ruby on Rails Tutorial book, Michael Hartl also test drives some integration tests for the web application which is awesome learning!
To get a feeling of authentication/authorization I’d suggest that you build the complete thing in 3 ways a few times:
- completely from scratch (e.g. Michael Hartl's Ruby on Rails Tutorial book)
- semi scratch by using 3rd party libraries (e.g. the walkthrough project at serverless-stack.com)
- mostly automated by using authentication providers (build something like a firebase project)
Get the milk out there!
You can imagine the milk to be the delicious end result of your breeding. You've built the product, and now it's time for other engineers to look at or work with it. Better have a glass of milk for them!
To make this possible, you not just have written the code and the tests for it, but you also took the time to...
- take a deep breath
- comment on the weird parts
- or even better: refactor ambiguities and let the code speak for itself.
Of course, you have tracked all your code in GitHub and committed often so that you and other developers can see what you've tried to do when you added that one nasty bug.
Documentation is great if you have a final target audience to potentially read it. Then it's just like writing to a friend and explaining to them things that are kept in the dark by the code.
In the end, writing good descriptive tests and committing often will already give you a great documentation foundation.
How to learn to get out the milk?
In order to refactor and write better code, you'll need an understanding of:
- Clean Code (read the book with the same title by Robert C. Martin)
- Refactoring (read the book with the same title by Martin Fowler and use it as a reference)
- much more...
(These are very fundamental books. While you should probably read them at some point anyway, there might be books, videos, and courses better suited to help you with your current challenges. Let me know if you need some tips!)
If you haven't heard about committing often in git, you should definitely Google it now.
You can also check out README.md documentation templates on GitHub and have one handy when you start your next thing.
Be a pig!
Pigs get some food and then they find some mud to lay in (sorry, for my limited understanding of pigs). Similarly, prioritization should always be on the top of a software engineer's list. This point is especially important in the full stack field.
I found myself taking on way too many responsibilities, especially when I worked in bigger companies, just because there is so much cool stuff to be a part of. However, the more responsibilities you take on, the less you can focus on The One Thing that will create the most impact for your company and your business.
Pigs are also known to be some of the smartest animals on the planet! And let's be honest there is nothing more important to become and stay a full stack engineer than continuous learning and practice.
Pigs can take ownership and create a great impact! How do I know that? I've read Animal Farm. Having an impact is what top-notch engineers say that they do to be where they are (just in case you want to get there).
How to become a pig?
One great widely recommended book on prioritization is The One Thing by Gary Keller, check it out!
You might also become a tad smarter if you read this article to the end and create your own roadmap to become a full stack engineer.
Leadership skills and creating impact can be learned by reading Animal Farm, obviously. Another way to get there is by talking to people and researching in order to deeply explore:
- your domain/industry
- the business situation and its needs
- as well as the customer must-haves and might-wants.
Ultimately, there is no way you can learn to be a pig unless you practice being a pig.
The FLYING Egg Laying Wool Milk Pig
Now that you have the basics, it's time to make you a truly magical being. It's time to learn to fly. You have generalized so much, that there couldn't be anything wrong with a little specialization. Depending on the industry where you'd like to be in, there could be different core skills that you will find worth exploring and learning.
This earlier mentioned article will give you the details if you'd like to understand why the different fields could be important for a full stack dev:
- Design basics
- Core CSS features
- Marketing fundamentals
- Software Architecture
- DevOps
- Databases and general data work
- Networks
- Understand Browsers
- Understand Computer Systems (Hardware)
- Project management
Yeah, I hope you've brought a lot of time with you.
The Roadmap
Hmmm, that's a lot for a single sane person. So yes, the magical Flying Egg Laying Wool Milk Pig might not exist, you've got me! But, it's still a viable terminology to describe what you are doing and remove duplication (which is a truly dev thing to do):
Saying
“I'm a Full Stack Developer”
is more SOLID than saying
“I'm a Software Engineer, working sometimes in the Frontend and Backend, occasionally helping the marketing team to optimally implement their growth hacking ideas..” 😴
It also gives you somewhat of a focus if you are thinking about your roadmap on how to become a full stack engineer:
You'd want to build products from start to finish and understand your domain as much as possible.
Thus, a simple abstraction of your roadmap will go something like this:
- Choose a tech stack
- Build your web app
- Learn
- Repeat
Just fill in the details, and fire up!
Being a fullstack developer gives you freedom to choose whatever kind of a Flying Egg Laying Wool Milk Pig you’d like to be. Happy flight!
Oh damn, writing all this reminds me that I have to go experimenting with new React features, reading through "Inside the Machine", and building that other Ruby on Rails app that I dreamt of this night…
