Full stack engineer is a term I see used all the time, generally meaning you can work on the front end, APIs and databases. From w3cschools :
“A full stack web developer is a person who can develop both client and server software.
In addition to mastering HTML and CSS, he/she also knows how to:
Program a server (like using PHP, ASP, Python, or Node)
Program a database (like using SQL, SQLite, or MongoDB)”
As an engineer working in todays industry, an aptitude to understand general concepts and pick up new tech is what’s important. You’ll be working across various technologies, it’s always changing, always progressing — new tools and approaches emerge as cloud providers release new features, so you’re expected to be a full stack engineer when it comes to technology
You’ll be better at some than others, probably an expert in a few areas rather than all, but the ability to use a variety of different tools and languages and learn what you don’t know is part and parcel of being an engineer. Understanding concepts & knowing what’s important are the things that matter.
For me, full stack engineering is about a mindset that can span across a number of traditional roles. It’s not about a technology stack or a particular framework, it’s about some fundamental principles that will always apply
- You can understand requirements and question them. Why are we doing this? What’s the desired business outcome? Who’s the customer? Is there a better way to achieve what the customer wants?
- You work on story refinement— You don’t wait for things to be handed to you, you track down what you need and find the details that will help you build the software you need
- You help everyone on your team fully understand what’s needed to deliver a piece of functionality
- You’re happy to work on backlog refinement and know it makes everything much easier
- Can understand how to sequence stories so they are delivered in an order that gives the most value at the right times.
- You can prioritise and focus — you know what’s important and what can wait
- Therefore, your delivery causes the least amount of friction to your consumers and dependencies
- You know the behaviour of distributed, cloud based, synchronous and asynchronous systems and the variety of pitfalls waiting for you.
- You could draw out a system and explain the moving parts
- You know that less is more, simple is better
- You see single points of failure that might get you out of bed in the middle of the night
- You can write code in a number of languages
- You know that you and others will spend a lot more time reading code than writing it, so always try and make it as easy as possible for the next person to understand
- You know that tech debt will slow you down and frustrate, so tidy up as you go.
- You know that less code > more code
- You might not know a particular piece of technology, but you know you can upskill quickly and apply what you know about other tech
- You write documentation with all the information you wish you’d had on some project that had zero. Meaningful documentation explains why things are the way they are, and gives the next engineer to work on the solution useful context.
- You know that whatever you create now is to solve a particular business requirement and something better might come along. You’re not precious about what you create.
- You’re questioning the business requirements, what are we trying to achieve? Why do we need to do this?
- You’re thinking about how you can break the system. What can go wrong?
- You write tests as you write code — How can you test this as efficiently as possible?
- You think about how this will run on build servers and other engineers machines, so code is totally portable. Any machine OS should be able to run your tests.
- You’re thinking about the test pyramid and isolating dependencies
- You know that tests describe your system better than documentation can and the next engineer to use them will thank you for well written, accurate, reliable tests
- You understand and plan for how performance testing can be run, both at small scale(engineers machine) and very high scale (multi-vm perf test rig)
- You know when you’re improving or degrading your application and can prove that with time sequenced data
- You’re comfortable working with a number of different database technologies.
- You know that data is pretty much the goal of all computing systems
We build UIs to input data, we build APIs to capture data. We transform, store, encrypt and replicate data. We query and extract data. We build reports on the data we’ve captured, and make business decisions based on what we learned. Mess up your data model and you’ll be hacking around everywhere else!
Data is king — a system is empty without it.
- You think about how to automate everything from the very start. No manual changes, ever.
- How can you represent infrastructure as code, using continuous deployment provisioning
- You see the automation of everything as important as other deliverables
- You think about things with a secure mindset, how will an attacker exploit your solution? How can you be secure by design?
- You threat model and have an understanding of who your attackers are likely to be
- How will you know you’re being attacked? What will you be able to do if that happens?
- You know that to successfully run a system, you need to be able to see inside it and understand what’s happening.
- You build telemetry in logs and metrics, expose those as dashboards and automated alerts and hook those in to notification systems.
- You think about the operational levers you can enable in your application, allowing you to change a behaviour profile with no downtime
- You can feature switch in new functionality
- You don’t want a phone call at 3am, so think about self-healing features you can apply and automated/1st line support fixes
Site Reliability Engineer
- You can piece that all together and know you want to automate everything, have repeatable and predictable processes, can measure what you do and can prove that changes you make are adding value.
After all that, you know that sometimes when you’ve done your job well it might go completely unnoticed. You made massive change without downtime, you seamlessly migrated customers to new versions without impact — everyone who uses your product just carried on using it, blissfully unaware of the amount of things that just happened.
Unless of course that included a font or colour change, in which case everyone gets excited.
Engineering is the art of making complex change as simple as possible — of delivering the requirements with the least amount of code and infrastructure. It’s being able to replace the engine while the motor’s running, and making it as easy as possible for others to pick up where you left off, knowing why you made the decisions you did at that particular time. Then going to the pub.
I’m Dylan Morley, one of the Principal Software Engineers at ASOS. I primarily work on the back-end commerce APIs that enable our shopping experience — All views are my own.