devoid of context - rss feed

Let the right one in

Tue, 20 May 2025 00:00:00 GMT

As mentioned in my recent post on not being invisible, it's important to be intentional about the projects you choose to work on. It's a deceptively simple idea that can have an outsized impact on your career, and putting it into practice often feels like navigating a maze. It's less about picking "hard" or "easy" tasks and more about understanding what will actually make a difference, and that's where it gets tricky: defining what "make a difference" even means.

In corpo-speak, prioritisation should start with alignment. It's about understanding what the organisation values most and where it's heading. When you focus your energy on work that aligns with those goals, you're making yourself part of the solution. Nobody gets promoted for solving problems nobody asked about.

Does your team have an overarching objective for the quarter? Maybe it's delivering a big-ticket feature, reducing technical debt (doubtful), or improving the reliability of the system. Whatever it is, that's the X on the map leading you to treasure. The closer your work ties in the better. Visibility becomes almost effortless when everything you do has a direct impact on what leadership is already keeping an eye on.

It doesn't always need to be glamorous, either. Sometimes, the unsexy problem like deploying new content or reducing abuse is far more critical than the flashy feature everyone's talking about. If you can fix it, you become the person who made everyone else's job easier, and that kind of impact doesn't go unnoticed.

Choosing impactful work isn't just about the work itself either. It's about how obvious the impact of that work is to others. Developers love to pine about coding as an art form, which is noble and all, but careers don't operate in a vacuum. If people don't understand the significance of what you're doing, it's easy for your contributions to fade into the background, no matter how valuable you believe they are. The work that gets recognised isn't the most technically hard or proficient, it's the work that leads to a clear outcome that people can see.

Hint: Work that most developers believe is "hard" and "important" is often work that isn't easy to see the impact of. If you want to be seen, work on projects that are easy to understand and have a clear outcome.

It doesn't just have to be flashy feature work either. Working on projects with broad visibility (things that touch either customer experience or the workflow of the team) can be a strategic choice. Take, for example a pain point that's been plaguing users for months, or an issue in deployment that is caused by the application code. By solving those problems, you're making an impact that stakeholders can feel, not just hear about in a sprint review. Those are the projects that emerge in retros and stick in people's minds during performance reviews.

Hint: The best people to talk to about these kind of problems are customer support and dev ops. They are the ones on the front lines dealing with the actual pain.

It can be tempting to sprint for every shiny project because it has the potential to stand out. Your tech lead pitches a flashy new microservice architecture? Sounds cool, lets spike our next feature on it. Another team is implementing cutting edge performance rendering improvements? Lets get that into our code before it's out of alpha! Wrong. These might sound flashy, but you have to return to the fundamental: what is the impact of this work, and does it align with the business goals of the company? If you can't answer both of those questions then this project is a distraction.

Caveat: If you do take on a project that's outside the main priority, have a solid reason for doing so, measurable outcomes, and make sure your chain of command is on board.

This has all been framed in terms of promotions, but what if you're not looking for a promotion? What if you just want to do good work for good work's sake? That's very noble, but ignoring the politics of your workplace will not only impact your ability to get promoted, but if layoffs come around it also gives them an easy target to cut. If you're not visible, you're not a team player, and if you're not a team player, you're not a priority. It's a harsh, but it's the world we live in.

You don't need to always be angling for credit either. No-one likes that person. But being the one who your leaders see as someone who can "get stuff done" is a valuable trait. Inversely, don't let promotion or layoff anxiety push you into an unsustainable mindset. The fastest way to burnout is saying yes to every project in a desperate bid for attention. Instead, aim for focused impact. You don't need to rack up a long list of contributions that barely scratch the surface of what matters. A handful of well-chosen, high-impact projects will serve you better than a dozen trivial ones.

Choosing the right projects is less about being lucky enough to stumble upon the perfect one and more about staying intentional. And trust me, when you're intentional about your work, the impact follows.

Size doesn't matter

Fri, 16 May 2025 00:00:00 GMT

When I started out as a software engineer, I heard a lot of sweeping ideas about how the size of an organisation would dictate the work experience. Big companies meant rigid structures, endless meetings, and hierarchies you couldn't hope to untangle. Small companies meant agility, creative freedom, and direct access to decision-makers. Medium companies were supposed to be a mix of both, but whether it was a good mix or a bad one depended on who you worked for.

The truth is, the size of an organisation doesn't matter nearly as much as people like to think it does. Whether you're at a ten person startup or a multinational with thousands of employees, certain things seem to remain constant. Work can be hectic, personalities clash, and yes, bureaucracy will find a way to wrap itself around even the scrappiest group of folks. Why? Because organisations are made of people, and people are, well, people.

Sure, the problems may scale, and the culture can shift depending on the size, but ultimately, everywhere you go, most people are just doing their best with the resources and constraints placed in front of them. And here's the kicker: thriving (professionally and personally) isn't really about organisational size at all. It's about the people you work most closely with.

In every organisation I've joined, the biggest predictor of my day-to-day satisfaction came down to my immediate circle: the coworkers I bounced ideas off, the manager who guided my growth, and the leadership I directly interacted with. When those relationships were healthy, productive, and built on mutual respect, I thrived.

Think about the undercurrent of office politics. Many people assume that politics get worse in larger companies because there are more stakeholders, more agendas, more potential conflict, right? But even in smaller organisations, I've seen similar dynamics play out, just on a different scale. Clashing egos, differences in working styles, and misguided communication aren't limited by size. They surface anywhere because people, by nature, aren't perfect communicators, and we all have our own biases and insecurities. The "we're a family" trope is a lot more common in smaller companies, and in my experience (and that of others based on the memes) it leads to a pretty toxic environment a lot of the time.

Now, what does this all mean? It's freeing in a way. Chasing the "perfect-sized company" is pointless because there isn't one. What actually matters, and what you can influence, is the quality of your interactions with your peers. Get along well with your coworkers, and suddenly those tough deadlines or endless Zoom meetings aren't so bad. Build a strong rapport with your manager, and they're more likely to advocate for your promotion or help you find opportunities to grow. And let's not forget your skip level, and so on up the chain. These people might not figure into your "day one priorities" when you're getting settled in a new role, but they're the ones who shape how decisions are made, including ones about your own career trajectory.

To be clear, I'm not suggesting that you start networking purely for the sake of climbing the ladder. Genuine relationships aren't transactional. But the better you understand what drives the people you work with, the easier it becomes to align your goals with theirs, and that goes a long way in making your working life smoother no matter where you are.

While the size of the organisation you work for can certainly shape your experience, it's not the only determinant of your happiness, growth, or success. Big or small, companies are just groups of people figuring things out as they go. If you can nail the human side of things, like building strong, authentic relationships with your team and those who have the ability to shape your career? You'll be in a much better position to thrive. Because if you're not happy at work it doesn't matter if there are 5 people, or 50k people. You'll be miserable either way.

Don't be invisible

Thu, 15 May 2025 00:00:00 GMT

You know the funny thing about being a software engineer? A lot of us got into this career because we liked the idea of talking to computers more than people. Machines are predictable, rational, and (mostly) fair judges of effort. If something isn't working, the feedback loop is immediate. It's not subjective. No politics. No office drama.

And yet, as cozy as that sounds, it's unrealistic. It turns out the human side (the one we might have been trying to avoid) is just as essential. If you want to thrive in your career, you can't afford to be invisible.

Let's get one thing straight: invisibility isn't about your physical presence at HQ or how much you talk during meetings. It's about whether people know who you are, what you do, and why it matters. Because if they don't, your hard work might as well not exist. So, if the idea of "self-promotion" feels awkward or unnecessary, let's reframe that. Being visible isn't about boasting. It's about ensuring your contributions aren't lost in the noise.

Let's start with glue work. You know, the unsung heroics: code reviews, writing documentation, testing, refactoring, fixing those data migrations no one else wants to touch, performance and accessibility enhancements, etc. These are the things that keep the system together, even if they're not the splashy features that make it onto a quarterly presentation slide. But here's the rub: glue work is invisible to most people unless you're intentional about making it visible. When everything's running smoothly, people overlook the maintenance it took to get there. If it breaks someone might remember, but by then it's damage control.

If you're quietly refactoring that state manager or writing documentation for onboarding new folks to a project, don't just silently commit your changes and move on to the next task. Share the backstory with your team or manager. Say, "Hey, that performance slowdown we kept running into was because of XYZ in StateManager? I refactored it and added tests to prevent regressions. We've gained ABC on our scorecards and should make it easier to expand without issues going forward." There's no chest-pounding here, just giving people the context they need to appreciate the value of the work.

Still, I get it. If you're introverted or working remotely, this can feel like climbing uphill in the rain. It's easier to sit back and assume the work will speak for itself, but in reality it rarely does. In the chaos of deadlines, meetings, and Slack notifications, people don't always notice what isn't explicitly put in front of them. Visibility takes effort, but it doesn't mean you have to fundamentally change who you are.

Here are a few achievable ways to get started:

Document and share your work: Going beyond code comments, write up short summaries of what you've tackled each sprint. Post in a team channel, write a post (at GitHub we use discussions), or highlight it in a retro.
Be active on pull requests: Leave thoughtful comments and reviews (and not just nitpicks about formatting). Engaging in code reviews isn't just about strengthening the code base, it's also an avenue to demonstrate your thought process and let people see the quality of your engineering mind.
Speak up during meetings: Even remotely, you have opportunities to chime in. If you've worked on something relevant or have insights to add, don't hesitate to share. Even if it's just a brief, "I wanted to highlight X. we've seen improvement in performance since implementing XYZ." You don't need to dominate the conversation, just be present in it.

Now, beyond making glue work visible, let's talk about prioritization. If you want to be visible, work that aligns with the organisation's priorities is your ally. If you're tinkering on side quests nobody has asked for, guess what? No one's paying attention. What's worse, when deadlines crush the team or major blockers flare up, that invisibility isn't going to work in your favor. Focus on initiatives that matter to the broader goals of the team or the company because visibility isn't just about broadcasting what you're doing it's about working on things others care about.

This doesn't mean you should drop everything to chase every flashy thing that crosses your desk. That's a recipe for burnout. But when you have the choice lean toward projects that have a clear impact, lift the team, or make the product demonstrably better. Fix the bug that has bugged QA for the last quarter. Build the feature your customers have been begging for. Do something where the "why" is interesting to your stakeholders. This is especially true if you're angling for a promotion.

I know there's a tendency to roll your eyes at phrases like "stakeholders" or "showing impact" and the like. It sounds corporate. But look, the reality is, software development isn't about writing code. It's delivering a product that meets the needs of users. If you want to be recognized for your work, you need to show how it contributes to that goal. And that means being visible about what you're doing and why it matters.

It also means choosing the right projects to work on, but that's a blog post for another day.

So the next time you think, "They should know what I'm doing," remember that they probably don't. And that's not a failure on their part it's an opportunity on yours.

What are you testing?

Fri, 25 Apr 2025 00:00:00 GMT

Writing tests can feel like eating your vegetables. You know it's good for you. You know future-you will thank you. But sometimes you just don't want to do it. Or, worse, you do it begrudgingly, rushing gh the task to check it off your list without really stopping to think. We've all been there: you write a quick test that lightly prods at the outer shell of your code, pat yourself on the back for covering your bases, and move on. But then a bug slips through, and you're left wondering, "Didn't I test for this?"

Here's the thing about testing: it's not just an exercise in covering lines of code or getting your "percent coverage" into the green. Effective tests are about understanding why you're testing something and making sure that what you're testing actually matters. If you're not asking yourself, "What exactly am I testing here?" before you start, then you're probably not writing the tests your code really needs. Let's walk through why this matters and how to ask the right questions.

First, let's talk about purpose. What are you trying to achieve with your code? This might seem obvious, but it's the foundational question you need to answer before typing out test assertions. Tests should validate that your code is doing what it's supposed to do, not just that it works in the most obvious way, but that it holds up under real-world use cases. And while it's tempting to fall back on default mental heuristics like "test the happy path," that's only part of the picture. Sure, test that your perfect scenario works. But what if things aren't perfect? What if the inputs are weird, unpredictable, or downright wrong? Do you want your code to gracefully fail, throw a descriptive error, or plow ahead obliviously? More importantly, how will you know that's what it's doing? Your tests are where you define and enforce these expectations.

But the real kicker? You also need to think about what you don't need to test. Not all code is created equal when it comes to failure risk. Some parts of your codebase are inherently more prone to breakage, whether due to complexity, external dependencies, or just the fact that they're actively evolving. Others are so static or trivial that spending time on them isn't worth your energy. Unless, of course, your organisation requires 100% test coverage in a fit of code-aesthetic purity (in which case, my sympathies). Focusing your testing efforts where they will have the highest impact is a time-management superpower. If you wield it correctly, you'll avoid writing mountains of unnecessary tests that no one will ever look at again.

Let's dig into UI testing specifically, because this is a trap I've seen more teams fall into than I can count. UI tests are important, don't get me wrong, but they are also a giant time suck if you let them veer off into the weeds. What's the number one thing people love to test in UI code? You guessed it: how things look. Did the layout render correctly? Is the button blue? Does the page have the expected text? These are easy things to write tests for, and easy traps to fall into because they feel like progress.

But here's the truth: most users will never care if a button changes from blue to green. What users do care about is whether clicking that button does the thing it's supposed to do. Your job as a developer isn't to protect the aesthetics of the UI, it's to protect the behavior of the app. UI tests shouldn't be about pixels. They should be about outcomes.

This means approaching UI tests from a state-and-action perspective. Ask yourself: when I interact with the UI, does the underlying state of the application change the way it's supposed to? If clicking a button fires off a network request and updates a list you don't need a test to check the the exact layout, what you care about is whether interacting with the UI successfully triggers the state change, processes the response, and updates the list correctly. Anything beyond that is window dressing.

Which brings me to edge cases. If happy-path testing is like brushing your teeth, edge-case testing is like flossing: so easy to skip, so essential for preventing disaster. Your edge cases are where bugs breed. When inputs are malformed, states are messy, or events cascade unexpectedly, does your code still hold up? You have to embrace the chaos. Test for the things you think could never happen: extra-long names that break layouts, unsupported file formats, someone mashing buttons like they're playing a video game on turbo mode. These are the scenarios that will bite you in the ass.

Finally, think about the lifespan of your tests. No one likes maintenance-mode testing, but the truth is, your tests should grow and adapt just like your code does. Push yourself to ask: what's likely to change in the future? If a function has volatile business logic, get a test in there. If a critical workflow is prone to iterative updates, lock down its behavior in your suite. Remember, tests are a tool for safekeeping the intentions behind your code as it evolves. They are not sacred documents. Keep them relevant, prune the useless ones, and evolve them alongside your application.

At the end of the day, testing is a skill, and like all skills, it gets sharper with practice. But it starts with awareness: ask yourself what you're testing, why you're testing it, and what matters most in the moment. The more intentional you are, the more value you'll get. Not just from your test suite, but from the confidence you carry into every pull request. Because knowing that your code is doing exactly what it's supposed to (and nothing it's not) is a feeling that trumps any arbitrary coverage metric every single time.

Reduce, Reuse, Refactor

Sat, 18 Jan 2025 00:00:00 GMT

Like most software engineers, I've spent most of my career reading other people's code. Between pull requests, tracking down bugs, building out new features, and just plain old research to learn a code base, there is a lot of time an engineer will sink into trying to understand what other people are thinking.

Hell, if you’re around long enough you’ve probably come across indecipherable code that a previous version of yourself wrote, and if you’re lucky you’ll have proof of your growth when you cringe at some of it.

All of this is to say that I’ve come up with a few questions I ask myself when I approach adding new and fixing old code. Things I find helps avoid the classic pitfalls of refactoring “bad” code and making it “clean”.

Is it messy, or is it complex?

Messy and complex are often conflated. It’s the primary impetus behind a lot of unnecessary rewrites — especially when written in a language or framework that you’re unfamiliar with. Particularly when said framework/language is not currently “cool”. No one likes having to learn new things to build a feature that they already know how to build. Besides, that old code is messy as heck! Lots of it is completely unnecessary. You could make this much cleaner and more efficient.

Sound familiar? Tell me, how much did your stomach drop when you happily deployed your new clean code and now support is inundated with bug reports? What do you mean people on old iPhones can’t load the page anymore? Huh, the layout is broken in Firefox? Why has our accessibility score dropped below an acceptable rating? You'll discover that most of that "messy" code was written to solve those same bug reports over the last few years. The code wasn't messy. It was battle-hardened.

Take those few extra cycles to understand the purpose of something. If you don't know why it's there, sure it could be left over from something long removed, but it also could be something you don't yet know you don't know. Getting better at recognising this comes down to experience, but at least being aware of it means you'll be less likely to remove something in future that you don't understand.

Do I actually have to rewrite this?

The second best thing a good software engineer does is write code. The best is to delete it. Every line of code added to a codebase contributes to headaches. That code must be tested, understood by others, maintained, and considered for future changes. It is also a potential area for bugs, regressions, security issues, etc. You should always attempt to reduce the amount of code you write in any way possible, and the best way to accomplish this is through code reuse.

It's easy to fall into the trap of writing new and clever code, but reusing existing code is always better. This is true both in terms of time spent and code quality. As mentioned above code isn't messy by default, but because it's been used and abused over time. You can write some new code that is clean and elegant but it won't cover all the edge cases and bugs that the messy code has already solved.

What's the simplest way I can write this code for future use?

If you absolutely must write new code make sure you're writing as little as possible and that it's as simple as you can make it. This doesn't mean being clever -- it means being clear. You always want to write code that is easy to read, understand, and maintain. Chances are you work in a team and might not always be there to show someone how the code works. You have to make it accessible to others, especially those without as much experience as yourself.

Is there something close to this functionality that I can modify to cover both use cases?

Recycling code is when you take existing code and modify it to include your use case without breaking the original purpose. This can be as simple as just a helper file within your codebase or something completely independent like a library (useful when separate services do similar things but comes with issues around maintenance and ownership). Which way you take this is up to your team or organisation to decide.

Regardless of how you intend to refactor a code base, I hope that you always go in with a few of these things in mind. Remember that no one wants to write bad or messy code. Everyone wants to do their best work but a lot of the time the reality of priorities and deadlines can mean decisions were made at that time that were considered good enough. Generally, the end user doesn't care about the difference between messy and clean code as long as the functionality is the same. Remember to practice patience and thoughtfulness, and to remain humble, because the next time you're cursing someone's bad code you might see your name in the git blame column.