A Full Stack Mindset

6 min readMar 19, 2021

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 browser (like using JavaScript, jQuery, Angular, or Vue)
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

Business Analyst

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

Project Manager

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

Architect

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

Software Engineer

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.

Quality Engineer

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

Performance Engineer

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

Data Engineer

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.

DevOps

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

SecOps

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?

Ops

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.

About me

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.