The Full Stack

The Stack

The stack is bigger than you think it is. All of that is the “technical” stack, but then there’s people. There’s all the engineers, there’s the infrastructure team, there’s management, there’s product, there’s the business.

All of these people form the “social” layer of the stack. But let’s not forget the other people in the stack. The customers.

As engineers we thrive on abstraction, we use each of these layers to hide complexity. We thrive in the abstraction, but ignoring the details is at our peril. Take the customers for example. Zoom In. Some have accessibility needs, some are regular customers, some are new customers. They all have subtly different needs and the needs of the software we are building can (and perhaps should) be different for each.

Knowing that the technical layer isn’t the only one that you have at your disposal is powerful. Sometimes the best solution is simply talking to someone. That might be the customer, it might be another team member. It might not need any code written at all, or it might turn a crazy complex solution into a simple one.

What other layers are there?

The most obvious other one is the business layer. This informs the majority of the reasons that we are creating a solution. Yet, this is just another set of details on another tier that we have to use to help. Does the business want to interact with the customer here? Are we charging enough? Is doing this going to affect our cost in a way that we didn’t for-see originally? Understanding more of this, zooming out, and thinking about the business needs creates better solutions across the stack.

There’s also the product layer. Is what we are building the right thing to be building? Can we work with the design and product teams to adjust this, hone the product to be better. To help the customers achieve something better? Often these in-flight adjustments that we make in the development process make a good feature a great feature.

So they are the obvious layers. But the more you zoom in (or out) the more you see. It’s turtles all the way down.

I currently work at Up, which is an Australian bank. So our “regional” layer is Australia, but we also have customers traveling overseas. They have different needs, and our solutions should be tailored to them.

What else does this regionality mean? Well, there’s a number of inferred layers that it it provides. We have the regular ones that most businesses encounter, taxes, privacy laws & consumer protection laws. But being a bank, we also have a regulatory layer. This is covered off by APRA and ASIC and the banking legislation that is in place. In other industries or jurisdictions there are be different regulators and regulations.

Surely these layers are immutable, not possible parts of the solution? “Leave that to the lawyers” It’s easy to think that, but all of these pieces of regulation are interpreted. Perhaps re-reading and re-interpreting it can gain valuable insight. They are also constantly changing and being part of the change or understanding it might lead to a different set of outcomes.

A great example of this was a number of Up’s leadership team addressing a Senate Committee hearing on screen-scraping. Did this create a change then? No, but hopefully we dragged the entire industry in a direction that was better for our customers and better for everyone.

So what should I do with this knowledge

One of the great things about thinking about layers and stacks like this is that it lets you explicitly think about moving between them. The common one that we think about in normal software delivery is solving things on the front-end OR on the back-end. They have different trade-offs, maybe one is easier to ship, maybe it’s easier to test, or simply it might be your expertise.That’s

The same applies to other layers of the stack. Can we modify the design to make this problem go away? Can we understand the business requirements better to know if this is the right call? Think clearly about the layers, what you know about them and if there’s parts of the puzzle that can be filled in by other layers.

That’s what it takes to be a real full-stack developer.

---

Photo by Alexander Grey on Unsplash