The Purpose of Principal Engineering

In the world of tech hiring, there’s always a struggle to balance experience with cost, technical chops with the ability to lead. When the stakes are high, and you need more than just code but also architectural vision, that’s where the Principal Engineer comes into play.

But what does a Principal Engineer (or “Staff Engineer”, etc) really bring to the table? And why would a CIO or CTO be willing to invest in this role?

Here’s the deal: a Principal Engineer is more than just a senior developer cranking out code. They’re strategic thinkers, problem solvers, and critical linchpins who hold the project’s technical map in their hands. Here’s a breakdown of the unique value they bring, along with what your leadership should expect when hiring for this pivotal role.

In this post I aim to break down and detail some of the deliverables that a principal engineer is on the hook for. But emphasis is on *some* of the deliverables. The role has specifics per company and org that they’re working with.

Technical Vision and Strategy That Scales

In a fast-paced engineering environment, you need a technical roadmap that not only meets today’s needs but anticipates tomorrow’s challenges. A Principal Engineer builds out this technical vision, aligning it with business goals and real-world needs. They’re not just thinking about if something works—they’re focused on how it’ll work at scale and why those architectural choices make sense for the future.

Deliverable: Expect a Principal Engineer to lay down an architecture that scales, not just through lines of code but through the decisions they make about tech stacks, data models, and more. This isn’t a job for someone who just learned Kubernetes last week; it’s for someone who can see around corners and build with flexibility.

Continue reading “The Purpose of Principal Engineering” →

A few words on getting into Computer Science in 2024 and on?

The journey into advanced software development can feel like plunging into a tumultuous ocean. At first, there’s the excitement of learning—those ‘aha’ moments when distributed systems suddenly make sense, or when the intricacies of concurrency click into place. But once you pass that initial rush, the reality sets in. It becomes clear that mastering these topics isn’t just about understanding technical nuances; it’s also about navigating a web of complexities that intertwine across systems, tools, and people.

This journey brings its fair share of frustration and existential concern. As you go deeper, you start grappling with problems that feel abstract and distant, yet profoundly impactful: distributed state consistency, data synchronization, avoiding deadlocks. You realize that these issues aren’t just technical puzzles; they represent the invisible backbone of everything you’re building. And it’s overwhelming to think how fragile these systems are, how they’re held together by code you and your team write, and how any tiny oversight can cause cascading failures.

Yet, perhaps the most exhausting part isn’t just the code; it’s the human element. Once you develop the social skills to communicate these technical complexities to people at different levels, you realize the challenge isn’t just the knowledge—it’s helping others grasp it without drowning them in details. It’s like being fluent in a language others only have a basic vocabulary for. You spend time rephrasing, simplifying, and drawing analogies, only to have people nod, agree, and repeat the same mistakes next week. They’re not at fault; these are tough concepts. But it can be isolating, being the one person who sees the problem three steps ahead while everyone else is still figuring out step one.

Continue reading “A few words on getting into Computer Science in 2024 and on?” →

Maximizing Impact: Travel as a Developer Advocate

I almost titled this post “Wasting Company Time & Burning Yourself Out” considering some of the interactions and involvement I’ve seen in the DevRel Community of late. But I’ll get to that drama and angry frustrations later in the post, but immediately let’s get down to brass tacks.

As I dive into the nuances of traveling as a Developer Advocate, it’s crucial to clarify that this post isn’t just about logistics or coping mechanisms, but about the larger strategic picture beyond just the tactical underpinnings of day to day travel, airports, train stations, and the like. Instead, I aim to delve into what underpins the demand for travel as a developer advocate. Travel is far more than just getting from point A to point B to partake in an action. It’s about positioning myself—and by extension, the organizations and efforts I represent—to make meaningful connections, drive impact in decisions, and stay ahead in a rapidly evolving industry.

Strategic Travel: Guiding the Future of Major Projects

When it comes to strategic trips, the stakes are high. These aren’t just any industry conferences or casual meetups; they’re focused events where the future of a project might hang in the balance. Take, for example, a situation where a software fork of a major open-source project is on the horizon. The decision to fork isn’t taken lightly—it’s a move that could redefine the project’s trajectory, influence developer adoption, and ultimately shape the software landscape for years to come. Being on the ground and having built connections with the people involved face to face is irreplaceable. Having just had few meetings or video conf calls doesn’t cut it, one can’t replace the built trust of time spent face to face builds. This is where traveling to where people are, as an advocate, become priceless.

In these scenarios, my travel is centered around influencing and guiding these pivotal moments. I’m there to represent the interests of my company, to ensure that our vision and goals align with where the project is heading. This might involve meeting with the core contributors, understanding their motivations, and providing insights that can help steer the project in a direction that benefits both the community and the enterprise. It’s about being at the table when decisions are made, rather than reacting to them after the fact.

Continue reading “Maximizing Impact: Travel as a Developer Advocate” →

The Missing Pieces: What Online Tutorials and Docs Always Seem to Forget

Yo, fellow coders and tech enthusiasts! Adron here, and today we’re diving into a topic that’s been grinding my gears for ages – the stuff that’s always missing from online tutorials and docs. Buckle up, ’cause we’re about to get grumpy!

0. The Invisible Prerequisites

Before we even get to the main course, let’s talk about the appetizer that so many tutorials forget to serve – the damn prerequisites! I can’t tell you how many times I’ve started a tutorial only to find out halfway through that I needed some obscure tool or specific version of something that wasn’t mentioned upfront.

Here’s the deal, tutorial writers: lay out ALL the prerequisites clearly at the beginning. And I mean ALL of them. Don’t assume I have jq installed for your GraphQL tutorial. Don’t assume I’m running the latest version of Python (and for the love of code, specify WHICH Python – 2.x or 3.x?).

And here’s a novel idea: how about actually telling me where to find and install these prerequisites? Give me links, give me version numbers, give me command line instructions. Assume I’m starting from scratch on a fresh machine. Because guess what? Sometimes I am!

Even though this isn’t a tutorial, but just because I mentioned them here, check out jq here and Python here.

Continue reading “The Missing Pieces: What Online Tutorials and Docs Always Seem to Forget” →

Elaborating on Multilevel Engineering Teams

Just wrote up the previous post and wanted to elaborate further on the different levels, examples for leadership to follow, and related ideas from my own learning. Thus, the point of this post, enjoy.

Junior Engineers

Example: Onboarding and Mentorship Programs for Junior Engineers

In one of my past roles, I spearheaded the onboarding process for junior engineers by introducing a structured mentorship program. Each new junior hire was paired with a senior engineer or a mid-level engineer who served as their mentor for the first three months. During this period, the junior engineers were assigned shadowing tasks during dev cycles. This included sitting in on design meetings, assisting in code reviews, and collaborating on smaller feature developments.

The shadowing model had a two-fold benefit: it accelerated the learning curve for the juniors, giving them real-world exposure to engineering best practices and the development process, while also offering senior engineers the opportunity to practice leadership skills by teaching and guiding these new team members.

In this mentorship framework, juniors were tasked with bug fixes or smaller features. For instance, a junior engineer might be responsible for writing the unit tests for a feature developed by their mentor. By working on tangible parts of the codebase and receiving feedback directly from senior engineers, junior engineers quickly gained confidence in their abilities, which also led to early wins for the team.

Why It Works:
This approach enhances team cohesion and knowledge-sharing while ensuring junior engineers are not thrown into the deep end without support. It also fosters growth in senior engineers by reinforcing the mentor’s knowledge and leadership through teaching.

Continue reading “Elaborating on Multilevel Engineering Teams” →