A Full Stack Mindset

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 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

  • 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 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 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 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 know when you’re improving or degrading your application and can prove that with time sequenced data

Data Engineer

  • 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 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 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

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

Principal Software Engineer, ASOS.com