Compiler

A Chief Technology Officer needs to be an expert in technology. That much is clear. But what does a CTO actually do every day? What outcomes are they responsible for? And how can others help them achieve those goals? 

The CTO and the Vision is the first episode in Compiler’s series on tech careers. We call it Re:Role. We launch a fictional startup that needs to expand its team as it grows. But before we hire, we need to understand when it makes sense to add another role, what it is the people in those jobs need to accomplish—and how they fit into the company structure. 

The company, its business activities and its employees depicted in this podcast are fictional and are not intended to represent or depict any current or former business organization or any individuals living or dead. Any resemblance to any individual or organization is purely coincidental.

While working in a software stack, IT professionals may have to bridge gaps in practical knowledge, institutional knowledge, and communication. Teams may be located in different countries or backgrounds, and may even work in different areas of the stack.

 The practice of building software is deeply technical, but it’s also deeply human. In the final episode of Stack/Unstuck, we discuss how bridging gaps in communication and expertise helps teams come together from across a software stack to build something great. 

The Compiler team would like to thank everyone they spoke with in the making of Stack/Unstuck. Earlier in this series, we mentioned how building software was like building a house. One of our guests, Ryan Singer, made a great video where he discusses the similarities. Check out his explanation here. 

And to check out what David Van Duzer and his team are up to, you can visit the Open Up official webpage.

We reach our penultimate episode for Stack/Unstuck, and arrive on the topic of testing. Testing isn’t necessarily part of any technology stack, but it is a vital part of building software. Sometimes, it can feel like testing is an afterthought, or just a box for busy coders to tick once completed.

We hear from our guests about how testing doesn’t need to be saved for a curtain call. It can have a starring role when identifying problems within different components of a software stack. And as we include it more in discussions and planning, and as we start thinking about it earlier in development cycles, testing can further an application’s potential, and help teams build software better.

The operating system wars are over. We’re still left with Windows, Linux, and MacOS—along with Android and iOS. Many argue that there’s little left to accomplish with the bottom of the software stack. But work on the OS is far from over. 

The kernel and user space provide the literal foundation for the rest of the software stack. Drivers, networking, and countless other features are abstracted away as common resources so the other layers of the stack can focus on their own functions. So when the overlooked layer gets an upgrade, it can really make a difference.
 

Writing data is easy. You take in the information and put it away for future use. It’s remembering exactly what you wrote and where you put it that’s the challenge. Just like having to look for your keys as you try to rush out the door, getting that data quickly makes all the difference. And when your database is your bestie, it can serve that information faster than you could imagine. 

Getting a database into shape takes specialized skills. From planning and development to maintenance and rebuilding, it’s a layer of the stack that needs constant attention and evaluation. It can be a performance booster—or an efficiency bottleneck. What does it take to keep your database and the information it stores available to the stack?

Frameworks exist to make building apps easier, and there are a lot to choose from. We hear from one long-time Java developer about his passion project, an app designed to remind users of important deadlines and appointments. We explore his app’s framework—how he chose it, and how things changed along the way.

While they are there to help developers build applications very quickly, frameworks shouldn’t be seen as a salve or a substitute for basic knowledge. When things go awry, that’s when knowing the fundamentals can help, whether you are building applications on your own, or working on a larger team.

Front-end development can be complex—and that means a front-end developer’s skills are essential, albeit constantly shifting. But a humble web search can produce various memes and jokes about how the front end isn’t as much of an endeavor as other parts of an application can be. 

Expanding knowledge beyond one’s area of the software stack can strengthen the skills they have, but negative perceptions can become a barrier to building those necessary relationships. As communities and companies grow, though, attitudes can begin to change. How can front-end developers communicate their expertise to their peers, and learn new talents along the way?

The software stack is like an onion. Or a sheet cake. Or lasagna. Or is it? It’s often described as having layers that sit on top of each other. The reality is much more complicated—and learning about it can help any tech career. 

The Great Stack Debate is the first episode in Compiler’s series on the software stack. We call it Stack/Unstuck. We explore each layer of the stack, what it’s like to work on them, and how they come together into a whole application. 
 

Mistakes are part of growth. If we’re lucky, we’re in an environment where they’re not punished harshly. That lets us fix the problem, learn to do better, and move on—but also to tell the story once the sting has passed.

Last episode, we heard three stories of people blundering into trouble and coming out the other side a little bit wiser. This episode adds three more stories of mistakes being made—but the culprit isn’t always as clear.