Exploring technology, leadership, and life's adventures
21 stories available
More Than a Poster on the Wall
As a leader who builds and nurtures engineering teams, my desk sees a constant flow of resumes. I see bootcamp grads with fiery ambition, senior engineers with impressive project lists, and everything in between. But a pattern has emerged, a subtle trap that many talented developers fall into without even realizing it. It’s the resume that boasts "ten years of experience" but lists five different companies, each with a tenure of about two years.
We talk a lot about Imposter Syndrome in the tech world. That nagging, fraudulent feeling that we’re just one tough question away from being exposed as a complete novice. It’s a real and debilitating struggle for many brilliant engineers. But what about its opposite? What about the engineer who feels perpetually overlooked, convinced their skills are top-tier, yet their influence and title don’t reflect it? This is the person simmering with frustration because they weren’t invited to the architecture meeting. They’re the one quietly (or not so quietly) believing they’re long overdue for that senior promotion, even if the evidence isn’t clear to others.
There’s a saying in research and writing that you don't so much *finish* as you find the right *stopping point*. That principle is a game-changer when you apply it to software engineering. Our craft has a never-ending supply of features, enhancements, and bug fixes that can consume your time without mercy. We've all stood at the base of a massive project, a monolithic feature request, and felt that sense of dread. The summit seems impossibly far, and the default path is to think in all-or-nothing terms. "This has to be complete before we can ship it."
There’s a conversation that happens in quiet corners of the office (or via Zoom or Slack if your office is like mine). It’s the one about promotions. It’s often tinged with a bit of anxiety, a dose of confusion, and the lingering question: “What do I actually have to do to get to the next level?” I’ve given every team that I lead the same piece of simple, yet almost paradoxical advice: **The best way to get the job is to do the job.** At first glance, it might sound like a catch-22. How can you do a job you don’t have? But this isn’t a riddle; it’s a roadmap. It’s a call to reframe how we see our roles, our responsibilities, and our growth.
You’re graduating at a strange and exhilarating time. The world is crackling with the energy of something new. Artificial intelligence is no longer a far-off science fiction concept; it’s here, and it’s changing everything, including the very idea of a career. You’re likely feeling a mix of excitement and a gnawing anxiety, asking a question that seems impossible to answer: “What should I study to be valuable in a world where machines can learn my job faster than I can?”
Advice for Graduates in the AI Generation
Have you ever felt that nagging suspicion that the intricate web of technology we’ve woven around ourselves is becoming something… other? That the very systems designed to empower us are, in fact, creating a subtle but relentless drain on our own capabilities? This isn't just a feeling; it's the tremor of an approaching earthquake I call the Incompetence Apocalypse.
In the world of software engineering, we obsess over the elegance of our code, the efficiency of our algorithms, and the robustness of our systems. We speak the language of logic, of bits and bytes, of precise instructions for a machine to execute. But the most critical instruction set we ever have to master isn't for a computer; it's for the people we work with.
An Engineer’s Guide to Workplace Communication
I’ve spent the vast majority of my tech career leading engineers who were smarter, more accomplished, and more technically impressive than I could ever hope to be. My teams have been filled with people holding PhDs from top-tier universities, architects who could visualize entire systems in their sleep, and developers who wrote code so elegant it felt like poetry. And for a long time, if I’m being truly open, that created a quiet struggle within me. I’d sit in architecture reviews or planning sessions, listening to them debate the merits of a particular algorithm or a complex database schema, and a nagging voice would whisper, *“What do you even bring to the table?”*
There’s a phrase that echoes in the halls of businesses across the world. It’s a quiet poison, a subtle rejection of teamwork that masquerades as professional boundary-setting. It’s the reflexive, almost knee-jerk response of, “That’s not my job.” We’ve all felt the sting of it. You’re up against a deadline, a critical task needs a fresh pair of eyes, or a small, unexpected problem pops up, threatening to derail a project. You turn to a colleague for a little help, only to be met with that verbal brick wall. It’s a statement that says, "Your problem is not my problem." In that moment, the team’s shared mission dissolves, replaced by a collection of siloed job descriptions.
Have you ever tried to work in a cluttered, disorganized workshop? In the beginning, you can still get things done. You know where you *think* you left that wrench, and you can shove a few things aside to make space on the workbench. But over time, the clutter builds. Simple tasks take longer. Finding the right tool becomes an archaeological dig. Eventually, you spend more time navigating the mess than you do building anything new.
Every engineer has been there. It’s late, fueled by caffeine and the sheer thrill of the chase. You’re facing a beast of a problem, a feature request that seems to cut against the grain of your entire application. So you dive in, becoming a trailblazer in the dense, uncharted jungle of the codebase.
As a manager, I've started noticing something remarkable. The tasks I can confidently hand to my junior engineers are growing more complex, more ambitious. Problems that once required a senior engineer's seasoned eye are now being dissected, explained, and often solved by those newest to the craft. The reason? They are wielding the powerful lever of AI.
Mentoring Engineers in the Age of AI
There’s a new term buzzing in the developer world, a siren song for the hurried and the hopeful: "vibe coding."
Don't Let AI Write Checks Your Skills Can't Cash
There's a haunting line from the series Severance that has been echoing in my mind: 'The work is mysterious and important.'
A couple of years ago, working as a software developer, I remember that familiar knot in my stomach tightening every time I read about the latest AI breakthrough. It felt like machines were sprinting ahead, getting smarter by the nanosecond. The question loomed: would they soon be crafting code with a speed and precision I couldn’t match? Would my skills, my career, become relics of a bygone era in five, maybe ten years? It was, frankly, a terrifying prospect.
Software Engineering Lessons From...Baseball?
One of my favorite new tools is Mage AI, an "open-source data pipeline tool for transforming and integrating data." What I appreciate the most is their first-class documentation. They make it easy to get up and running in no time with extensive help and support for multiple platforms and providers. However, the reason I’m sharing this write-up is that the current version of the Mage docs does not cover key aspects of what it took to implement my scenario.
I needed to implement a queueing solution for my enterprise notification services that live mostly in Google Cloud Platform. The requirements were relatively simple and GCP offers a couple services that fit some of three specific points in one way or another.
When building applications, managing sensitive information like API keys, database credentials, and other secrets is a critical security concern. Hardcoding these values or storing them in version control is a significant risk.
I’ve sat on both sides of that interview table, maybe a few too many times over two decades. I've navigated the labyrinth of *gotcha* questions that felt more like trivia night than a measure of skill. And yes, I’ll own it – I’ve made my missteps as an interviewer, even when I knew better. It’s time to change the game.