Often times, development of a feature comes in multiple phases, across many contributors, touching many areas of your code base. Every one of these touch points increases the risk of new bugs or regressions.

So how do you deliver quickly while minimizing risk?

Feature flags! 🏳️

What are feature flags?

A feature flag is a software implementation that allows you to control the flow of your code (“feature”), by switching it on or off (“flag”).

Feature flags are added to the code and deployed once, then toggled without additional code changes or deployments. This allows your team to skip the deployment pipeline and quickly disable troublesome areas to reduce exposure and user disappointment.

More advanced feature flag implementations include the ability to segment users, allowing flags to be toggled for specific users or groups. For example: users who opt into beta features, customers at specific subscription tiers, geographical targeting, etc.

Feature flags are also referred to as feature toggles or feature switches. Different terms, same concept.

What feature flags are not.

Flags are not permanent.

It’s important to distinguish that feature flags are temporary, and are meant to be removed when you no longer need to toggle flows based on development and release cycles.

When your feature is 100% available to its target audience, you should remove the flag from your code.

Leaving flags in your code that are no longer needed contribute to bloat, confusion among your team, and even resentment and morale issues. Read more about Broken Windows in this previous issue:

Flags are not access control.

If your platform includes features that are only accessible at certain tiers, you should use proper authorization checks to protect the flow of that code.

You can use feature flags during development of said feature. The feature flag determines who is sent to the access control check.

Feature flags are not a direct replacement of access control. Flags should be the first gate that your code passes through. Here’s a pseudo-code example using the early return pattern:

if (featureIsEnabled('analytics') === false) {
    // Feature flag is disabled; no access, stop here.
    return;
}

if (user.can('analytics.view') === false) {
    // Feature is enabled, but current user does not have access.
    return;
}

// Feature is enabled AND user has access; continue happy path...

How do feature flags work?

Most feature flag implementations have two primary components:

1. Flag Definitions: a string ID, e.g. `analytics`, and a ruleset that determines the status or value of the flag

2. Rule Evaluator: the runtime system that retrieves a flag’s ruleset and evaluates it against the current context, returning the resolved value

A flag is given a definition to determine the flag’s status based on the conditions you define. Implementations vary, but they can all be thought of as conditionals. I’ll use a fake expression language to demonstrate here.

The most basic rule is a static ON or OFF, with no context necessary:

return false;

If you want a feature to be enabled for a subset of users, you might have a flag configured to be ON for users in a certain group or having a certain attribute, and OFF for everyone else:

return user.group IN ['beta'];

Complicated rules can involve a combination of AND and OR conditionals:

return user.group IN ['beta'] AND (customer.isEnterprise === false OR user.volume !== 'high');

When it’s time to check the actual value of a feature flag during code execution, the rule evaluator gets the flag’s definition and evaluates it using the current context.

In the above examples, the current context would include values for the variables `user` and `customer`.

Rules and context can be as simple or complicated as your application and business require.

Benefits of Feature Flags

• Deploy without causing effects – Isolate changes and explicitly control when effects take place.

• Increase business value by segmenting releases – Slowly roll out new, potentially-risky code (canary releases without the deployment complexity). Release a rough draft of a feature to beta users for testing and feedback. A/B test options to determine the best choice.

• Separate releasing from deployment – Release features to your users when it makes sense to your business rather than your deployment schedule. A step towards continuous delivery.

• Develop faster – By isolating code with feature flags, you can continue to develop around that code before it is fully complete. This enables smaller pull requests and faster code reviews, continuous delivery, and more.

• Test easily in multiple environments – No weird branching strategies to determine what environment gets what features.

• Test in production – Enable a feature in production for a single internal user to check a weird issue that can’t be replicated.

Trade-offs of Feature Flags

• Developer education – Devs may need to be taught feature flag concepts and how to implement them properly.

• It’s easy to forget old code – If you are replacing an existing feature with a new version, the old version’s code is no longer needed when the new one is 100% rolled out. Remember to delete the feature flag AND the old code!

• Testing multiple paths – If your organization values test coverage (and it should), test BOTH paths of a feature flag, on and off.

• Ongoing maintenance – It can be easy to forget what flags are completely rolled out and can be removed. Clean them up regularly and leave everything better than you found it.

• Toggling flags can confuse end users – Toggling flags quickly or multiple times may confuse users, as their experience changes randomly.

Implementation Best Practices

• Don’t build your own – Use an existing service or library.

• Cover both paths – Ensure your code has proper fallbacks for a feature flag being off, whether that’s reverting to the existing feature or displaying a message to the user.

• Cover broad areas – Feature flags should cover large chunks of code, like an entire feature or endpoint. Don’t be granular and cover a single function or component.

• Use consistent naming – Whatever standard you choose for feature flag naming, keep it constant.

• Make deleting flags easy – Separate the code for the old path and use early return patterns, so removing the flag means only deleting code:

public function analytics() {
    if (featureEnabled('newAnalytics') === false) {
        this.analyticsOld();
    }

    // New analytics implementation...
}

private function analyticsOld() {
    // Original analytics implementation...
}

When the feature flag is rolled out 100% and we’re ready to remove the code, we can delete the IF conditional and analyticsOld implementation, leaving the new implementation untouched.

How Seniors Approach Feature Flags

• They identify a need first – Seniors identify shortcomings in the projects, practices, and business, and find solutions proactively. Consider adding feature flags to your code base if you’re dealing with one of these problems:

  • Deployed code often has a negative side effect and needs to be rolled back or fixed immediately

  • Pull requests are large, hard to code review, and aren’t merged quickly enough

  • A feature is complete but can’t be deployed because another team (like Marketing) isn’t ready yet

  • You want to test a feature in an environment outside of local dev, but your git arrangement for that is complicated

  • The business isn’t sure if they should use option A or B

• They understand the trade-offs – Like any new addition to your codebase, feature flags come with a cost of proper implementation, maintenance, and possibly performance. Understand the pros and cons and make decisions and adjustments accordingly.

• They don’t build their own implementation – Unless absolutely necessary, save time and effort by using an existing solution.

• They standardize and document – Make sure everyone around you has the resources to learn and use flags also.

• They stay on top of maintenance – Don’t introduce something you aren’t willing to own and take care of.

• They make engineering faster and more reliable – Feature flags offer a lot of benefits for both developers and the business as a whole. Their wins are your wins!

👋🏼 Always a pleasure to have you here, Seniors! Talk again soon.

Aken 💙

Ugh, bug duty 🙄

The bane of many an engineer. Why would you want to fix pesky bugs, when you can be architecting and developing new features that will take your company to the next level?!

We want big wins for our resume, dammit!

I don’t blame you; those are definitely more exciting and potentially more valuable.

However…

Site reliability duties will make you better at those big feature wins.

Bug duty comes in many different flavors, from being the occasional point person for escalated support tickets (we called this “triage” at my last org) to full-time site reliability positions, and everything in between.

Many devs lament stepping into bug duty because they focus on the negative aspects. You have to fix others’ mistakes. It isn’t very glamorous work in comparison to feature development. It doesn’t seem to make a tangible impact. And so on.

You know the reasons. You’ve felt them.

Instead, let’s highlight and focus on the benefits of bug duty, and how it can help you grow into a Senior Engineer.

Every bug is a learning opportunity.

It is incredibly unlikely that you are such an experienced developer that you can easily resolve every bug that lands in your Jira board. (I bet there’s an AI for that somewhere…)

But that’s a privilege! An opportunity to learn, explore, tinker, and more.

You get to practice problem solving, which is the core skill an engineer should have and should be practiced as often as possible.

You get to see technology you haven’t used before, such as new parts of the code base, or software like a database or logging tool.

You get to practice optimizing your time by recognizing when you’re stuck or focusing on something less efficient.

You get to potentially work across teams, recruiting assistance from support, security, infrastructure, or whomever can help assist you in your bug squashing quest.

You get to practice reading, understanding, and modifying code written by others. With any luck, you can solve the problem and teach the solution to others so they can learn, too. Which is part of the “leave everything better than you found it” mentality.

Bugs reveal opportunities for extra improvements.

Speaking of “better than you found it”, bug fixing can identify and inspire a slate of improvement opportunities around your technology and processes unrelated to the bug itself.

Seeing a lot of bugs that follow the same theme? Teach your team how to avoid them. Or even better, automate protections against them where possible.

Automation in general goes a long way. Increase test coverage. Reduce build times. Automate deployments and rollbacks. Reduce code review time by automating certain checks and fixes that code reviewers shouldn’t have to focus on.

Are you having trouble identifying a bug due to lacking logs, metrics, or other exposure? Add them!

Suggesting, and more importantly implementing these improvements to your products and organization are a key way to increase your influence and seniority as an engineer.

Every bug increases your domain knowledge.

Seniors are domain experts. They have a depth of understanding in one or more areas of an application. They’re considered subject matter experts of the technology and the business problems the features solve.

When you fix a bug, you learn about that area of the business, thus increasing your domain knowledge.

The more you understand what problems the business is solving for your customers, the more your engineering efforts will match the business’ value, increasing your value.

Bug fixes are a great time to practice TDD.

Test-driven development can be tough to use for the majority of your everyday work. Fixing a bug is a perfect time to practice, because most of the infrastructure is in place. You already have working endpoints or services or whatever your entry point is. You have a well-defined outcome that currently isn’t happening. And you definitely don’t have an existing test in place, or it would be failing already.

Applying TDD when fixing bugs helps you practice TDD, it adds more test coverage, and it helps guarantee the problem is resolved as expected.

Every bug fix is a customer problem solved.

Engineers are often isolated from customers, and as such rarely see the direct impacts of their work. This has pros and cons. On the good side, you never have to deal with rude and irrational customers. On the bad side, you never hear about how your work is impacting in a positive way.

At the end of the day, there’s a real person on the other end of your bug fix, who is ecstatic that one of their pain points has been removed. And that’s a real win.

Even if the ticket was created internally, it’s likely a customer has experienced it without reporting. Like reviews on purchases, bug reports cover only a fraction of total occurrences.

Ask your customer-facing team to share the response when the customer is told their bug has been fixed. It should brighten your day!

And speaking of your customer-facing team, they love delivering good news. Bug fixes have an impact internally, too.

Bug fixes may seem like a mundane task lacking excitement and value. By focusing on the learning opportunities around your app, technologies, and business, you can see how much value they really hold.

That said, hopefully you don’t get stuck only fixing bugs for a long time. 😉

Happenings & Findings

Articles

Hatchet, a distributed, fault-tolerant task queue, wrote about implementing fair queueing strategies for Postgres-backed task queues.

Technologies

Canvas Confetti, a confetti effect JS library.

Pragmatic Drag & Drop, a low-level drag and drop JS library by Atlassian.

Fun

Up Next

🎓 An Introduction to Architecture Testing

Subscribe now

You’re the best!

Aken 💙

Do it more often!

Wow, that was an easy newsletter this week!

…Okay FINE, I suppose I can go into slightly more detail. 🙄

What is pair programming?

Pair programming is a collaborative coding technique where two software engineers work together at one workstation to develop software more effectively.

In modern remote environments, the shared workstation is replaced with screen sharing and real-time editor collaboration features, while the principles and techniques remain the same.

The most common method (one of many in use today), two engineers take on different roles: driver and navigator. The Driver writes the code, focusing on the immediate programming task. The Navigator looks at the big picture, thinks ahead, suggests improvements and alternative solutions, and reviews code as it’s written.

Importantly, the devs should regularly switch roles during a pair programming session. This encourages collaboration, mindset and perspective shifts, and learning.

Benefits

Technical Benefits

• “Two minds are better than one” – combined wisdom and skills results in better technical solutions

• Work gets done faster – two people are less likely to get blocked, and when it happens action is taken sooner and more effectively

• Code reviews happen in real time, allowing code to be approved and integrated more quickly (which is HUGE for team velocity – more on those metrics in a future edition)

Soft Skill Benefits

• Practicing collaboration results in greater empathy and bonding

• Improved communication and listening skills

Career Growth Benefits

• You learn more in a hands-on, practical way

• Your work and collaboration is made more visible, and more likely to be recognized

• You provide leadership and mentoring, even if you are the more junior engineer – everyone brings their unique perspective to the table, even if you only ask questions

All the stuff needed for Senior! ✨

Success Stories

Amit Masaun, VP of Engineering @ Deep 6 AI:

After decades of leading engineering teams, I've found no better approach than collaborative coding. Pair up ( or mob up ) and you'll write cleaner, more robust software while spreading that hard-won knowledge across the team. And when everyone's in the loop through that open dialogue, you move as one unified force towards your technical vision.

CJ Odina, Software Engineer and BASE subscriber:

I had the opportunity to engage in a series of pairing/mentoring sessions with a senior engineer at my job which, among other things, helped me better understand design and architecture patterns. As a result, I was able to build better, more resilient software as well as confidence in my skills.

And personally, my success stories are not one big moment but a lot of little ones like CJ’s. Pair programming was incredibly helpful when resolving a production outage, hunting an elusive bug, introducing new patterns or paradigms, or creating a consensus between two opposing ideas.

Any opportunity I can take to both solve a technical problem and grow my bonds with coworkers I will embrace and encourage.

Downsides & Gotchas

Pair programming has a ton of benefits when done well, but it is possible to pair in an ineffective way. If you’ve had a bad experience with pair programming, chances are you were burned by bad implementation.

First, it takes practice. You need a mindset of collaboration, focus, and knowing when to stop. Unequal or selfish participation, unbalanced roles, and a general unwillingness to collaborate are going to make pair sessions less valuable.

If there is a large skill gap between participants, a pairing session could be more training than collaborative problem solving. This can be slower than working individually. Incredibly valuable when onboarding and mentoring, less valuable when tackling a hard problem in a time crunch.

Similarly, pair programming is not always a time saver. If two devs are each assigned a task, pairing on both tasks fully may not deliver the tasks quicker. Focus your pair programming time on only the parts that are most effective – hard problems, questions, blockers, etc. Once you have a clear path, individual contribution is likely more effective.

How To Pair Effectively

• Use pair time for items of substance: problems, decisions, mentoring. Once there’s a clear plan and only implementation steps left, revert back to individual contributions.

• Switch roles regularly while pairing

• Keep an open mind, avoid micro-managing, and allow your teammate’s style to influence your own rather than be incompatible

• Talk often. Explain your thinking, ask questions.

• Practice! Sometimes you will pair better with one person than another. Don’t let any frustrating experiences stop you from finding efficiency and enjoyment elsewhere.

On Pair Programming on MartinFowler.com goes into greater detail on different methodologies, tools, implementations, and gotchas. I highly encourage further reading if you want to pair program more often.

Do you have any success or horror stories with pair programming? How has it helped you? Hit reply, I’d love to hear about it!

Up Next

🎓 Why Seniors embrace bug bashing and site reliability duties.

Subscribe now

Thank you as always!

Aken 💙

Share

If only it were that easy! Happy April Fool’s Day! 🫣

I’m sorry I can’t unlock the secrets of instantaneous promotions for you today. Hopefully I can make your Monday a little more tolerable with a bit of silliness and companionship.

There is no single secret or trick to performing well as a software engineer, just as there is never a single way to solve a problem using software and code.

Your path is unique. You are unique.

Curiosity, perseverance, and confidence will take you anywhere you want to go.

By being here and reading this newsletter, you are already taking the right steps by seeking knowledge and experience. Keep it up.

I know you didn’t fall for the clickbait title. You knew what you were getting into. Because you got this. 💪🏼

See you later, Senior!

Aken 💙

Thank you for being a part of this community! As always, if you’d like to request a topic or share any advice, hit reply. I’d love to hear from you.

Subscribe now

You’re starting a new job – congratulations! Every new gig is an exciting opportunity. You will be challenged in new ways, learn new things, meet new people, and maybe even hit that coveted Senior Engineer title!

The first few weeks and months are crucial for building relationships, understanding the intricacies of the business and its products and tech, and setting the tone of your time there.

Here’s how a senior engineer effectively onboards at a new job:

Focus on learning.

You were hired at this new job for your potential to add to the team, based on your existing skills and past experience. But your first few weeks at an organization are not for demonstrating what you bring to the table, but for learning what’s already there.

Every organization has its own business problems, technical nuances, team dynamics, goals, and more. Your onboarding time is best spent learning about all of these, and determining how you can best apply your existing skillset to them.

Be humble – don’t assume you know anything already. Ask all the questions, even if you think you know the answer. Absorb everything.

Build relationships early.

Your ability to influence and lead is closely tied to the relationships you build. The first few weeks is a great time to introduce yourself to your new team, learn how you will work together, and along the way identify key stakeholders and potential mentors.

Here is the strategy I recommend:

1. Meet one-on-one with every person on your immediate team. Get to know each other a bit, but focus on having them explain their current work to you.

2. Get into as much detail as time allows. Have them show you the product, the internals, any documentation, etc.

3. Ask any and all questions you have. Write them down as you have them, so you can follow up in case time runs out. “Why” questions are the most important – they’ll help provide critical business and team context.

4. Ask how you can help them be more successful. Not everyone will have a specific answer, but those who do are opportunities for increasing your influence.

5. At the end, ask them who else they’re working with on other teams. Repeat the same process with those people.

6. When you run into people who aren’t working on anything relevant to you, you can stop.

Using this strategy, you will:

• Make yourself known to as many team members as possible

• Gain valuable insight into the business

• Learn about the product in a way that’s relevant to your first few months of work

Set clear goals.

With help from your manager and immediate team, define clear and achievable goals for your first 90 days.

Ideally your goals will balance networking, learning, and tangible contributions (writing code).

Regularly check in with your manager on how these goals are progressing, and adjust as needed together.

Take ownership and demonstrate value.

While listening to your new coworkers and learning about the org and its tech, look for opportunities to contribute early on. The freedom you have during the onboarding period is a great time to add some wins to the team that they’ve been meaning to get to but haven’t had the capacity yet.

These wins could include:

• Improving documentation, especially anything that has gotten out-of-date since it was last updated

• Adding useful automation, such as tests or code quality checks

• Fixing an annoying but low priority piece of tech debt

• Making an application tweak to add consistency or improved UX

• Optimize a slow-loading process

Your onboarding time is a perfect opportunity to leave things better than you found them. More on that in this previous edition:

Stay open to feedback.

An extension of being humble while learning, stay open to constructive criticism. Actively seek it, encouraging your team to provide advice when they feel you need it.

Feedback isn’t only about ways you can improve; it’s also about understanding how your work aligns with your team and the business’ goals.

It also establishes a culture of openness and trust, which is critical to your long-term success.

Use your product like a customer.

Put yourself into the mindset of one of your business’ customers, and start using the products your company offers.

This provides so many benefits:

• Understand customers and their problems help contextualize future work

• Learn about the products and their benefits and utility; ask questions about features you don’t understand

• Identify any improvements that could be made

Which leads nicely into…

Understand the broader business context.

Senior engineers are expected to understand not just the technical, but also the business implications of their work.

Take time to learn about the company's products, market position, and strategic objectives. This broader perspective will enrich your contributions and enable you to drive more impactful innovations.

Own the process when there isn’t one.

Engineering teams understand that it takes time to onboard. You will almost never be expected to deliver production code within the first couple weeks, if not longer.

If your new organization does not have a formal onboarding process, or it is lacking some of the steps mentioned here that you find beneficial (or want to try), create a plan yourself and ask your manager for the time to execute it.

Taking initiative and ownership is a huge part of being a Senior. Set a good impression by demonstrating that in your first days on the job. Without overstepping what they have planned for you already. 😉

The beginning of your journey in a new organization is a unique opportunity to redefine your professional identity, expand your skill set, and contribute to something meaningful. By approaching this transition with intentionality, curiosity, and a commitment to excellence, you'll not only succeed in your new role but also set the stage for lasting growth and impact.

Up Next

🎓 Why you should be pair programming more often!

Subscribe now

Thank you for taking the time to read. It means a lot to me!

I’m coming up on an initial MVP release of my mobile app, Stay Woven. If you’d like to help me test it out, sign up at StayWoven.com.

Are you working on anything cool right now? Hit reply and tell me about it!

Aken 💙

I was having a conversation with one of my favorite managers in recent years, Brandon, at my last full-time job.

We were discussing how to deliver value both individually and as a team, and how to do it more quickly.

He shared a wonderful article that helped me redefine MVP – Minimum Viable Product – as a focus on the value instead of the product.

Instead of rewriting the same idea and analogy, please read Making sense of MVP by Henrik Kniberg. Keep reading here for a brief TL;DR and my thoughts on how a senior engineer applies this mindset.

TL;DR:

An MVP is not a chunk of “big bang” delivery, where you don’t deliver customers anything until it’s 100% complete.

If the intention is to deliver a car, an MVP is not releasing a wheel, then a frame, then a body… Engineering teams in agile environments tend to fall into this pattern as we plan for sprints.

An MVP is better thought of as a Minimum Valuable Product, or as Henrik puts it, the earliest testable product. (“Testable” means can be tested by users, not automated testing for code.)

The sooner you deliver any kind of value for your customer, the sooner you can get feedback on the direction you’re heading. Learn, iterate, repeat. If you get too far into a big bang delivery and you’re wrong about something, you lost a lot of time and effort.

How a Senior applies this mindset

Figure out your skateboard.

Identify an MVP that delivers value by breaking up your work into fully-functioning pieces. Do you need to build a feature that includes both front- and back-end layers? Don’t deliver one on its own – that’s the same as delivering the wheel of a car. Find a vertical slice that includes a minimum valuable and usable portion of all layers to deliver first.

Think in terms of MVPs when prioritizing and planning.

When working through your backlog, think about delivering MVPs of the features first to help determine what has the most impact (priority), limit scope creep, and provide timetables for planning.

MVPs help you learn.

In my last issue we discussed Making (Reasonably) Good Decisions Quickly, and one way to do that is to use prototyping to learn and validate an idea:

Use prototyping, testing, and automation. Building prototypes and conducting quick tests can provide immediate feedback and inform decisions, especially when choosing between different technical approaches or designs.

Foster a learning and iterative culture.

Encourage a mindset where failures are seen as opportunities to learn and pivot, rather than setbacks. Use MVPs and iteration to develop this resilience, especially when building new products.

MVPs enable communication.

Keep stakeholders informed with regular updates that focus on progress, challenges, and decisions. Guide junior team members through the MVP process, teaching them to balance speed, quality, and user focus in their work.

You become a Senior Engineer by focusing on the value you deliver your team, your organization, and your customers. Every MVP that delivers value, even a small amount, increases your impact and shortens your path to Senior. 💪🏼

Subscribe now

Vertical vs. Horizontal Scaling

Scaling refers to increasing the ability of a system or application to handle increasing amounts of data, traffic, or load, without compromising performance or security.

Scaling comes in many forms, from application code changes to significant infrastructure additions. Today we’re focusing on two types of server infrastructure scaling: vertical and horizontal.

Vertical Scaling (Scaling Up)

Vertical scaling involves increasing the power of a single server or resource. This could mean adding more CPUs, RAM, or storage to the existing hardware.

Pros

• Simplicity – It's often easier to scale a system vertically because it doesn’t require significant changes to the application’s code.

• Immediate performance boost – Adding more resources can provide a direct and immediate improvement to the application's performance.

Cons

• Physical limits – There's a ceiling to how much you can upgrade a single server, determined by the hardware's maximum capacity.

• Downtime – Upgrading hardware might require downtime, which can be a drawback for systems requiring high availability.

• Cost – Beyond certain limits, it becomes very expensive to increase server specifications.

Horizontal Scaling (Scaling Out/In)

Horizontal scaling means adding more servers to your pool of resources to distribute the load more evenly across them. Instead of having one super-powerful server, you have multiple servers sharing the workload.

Pros

• Flexibility – You can add or remove servers based on demand, making it ideal for handling variable workloads.

• No physical limit – Since you’re adding more machines, you’re not limited by the capacity of a single server.

• High availability – If one server fails, the system can reroute the load to other servers, ensuring that the application remains available.

Cons

• Complexity – It requires more sophisticated management, load balancing, and possibly changes to how the application handles state, sessions, or databases.

• Networking overhead – More servers mean more network traffic, which can introduce latency and complexity in communication.

Choosing Between The Two

A senior engineer thinks about scalability from the outset of their projects, considering both short-term and long-term needs.

Those needs include both the technical and business requirements, such as:

• Expected growth – How is your application expected to grow in scale?

• Architectural decisions – What is more important: availability or performance? Simplicity or flexibility?

• Maintenance and team capabilities – Who will maintain the scaled infrastructure, and what are their talents and capabilities? How will maintenance impact engineering capacity?

• Cost – What budget is available to the team and the organization?

For applications expected to grow significantly and unpredictably, horizontal scaling offers more flexibility and scalability. On the other hand, for applications with predictable growth, vertical scaling might be a simpler and cost-effective choice initially.

Imagine you’re running a social media application. In its infancy, vertical scaling might suffice to meet your needs. However, as your user base grows and traffic spikes occur unpredictably, horizontal scaling becomes essential. You'll need to design your application to efficiently distribute requests across servers, handle sessions consistently, and synchronize data across multiple nodes.

Until next time, ciao!

Aken 💙

Part of a senior engineer’s responsibility is creating clear direction for their projects and their team. Clear direction comes from decisions made in uncertain situations, where multiple options are viable.

By making well-informed decisions quickly, a senior unblocks themselves and their team and enables action, learning, and iteration.

Why make decisions quickly

The decisions we’re talking about today aren’t clear and obvious ones. They’re decisions made during uncertainty. Maybe you have multiple options that all seem viable. Maybe you aren’t sure if your problem will be solved by the chosen direction.

Decisions should be made quickly to get clarity faster.

The faster a decision is made, the faster action can be taken, and the sooner you will have the result or outcome of your decision.

Decide → Act → Learn → Repeat

How long exactly is “quickly”?

Every engineer’s favorite answer: it depends!

There is no specific time frame a decision must be made within. Thankfully, there are two heuristics you can use to help gauge how long to consider your options:

• How big an impact will this decision have on the organization? If the topic is mission critical and will support the foundations of the entire business for years to come, take your damn time! If there’s minimal impact and things can be easily changed, decide quickly and iterate from there.

• When will you know if the decision was good or bad? If the outcome of your decision can’t be known for a long time, spend more time up front. (And be careful that your scope isn’t too big.) If you’ll know in a reasonably short time, the initial decision can be made more quickly.

How to decide quickly

• Understand the problem. Make sure the problem and desired outcome from the decision is well-defined. Have an answer to the question “How will I know if my decision was correct?”

• Prioritize. Focusing on the most critical aspects of a decision can make the process faster.

• Reduce scope if needed. Does the decision seem massive, with a large potential impact? Reduce scope to be less impactful, and can be decided and iterated on more quickly.

• Research your options. Narrow your choices through research that supports better options and rules out others. Limit your time using the aforementioned impact and duration heuristics.

• Collaborate with your team. Utilize the knowledge and experience of your peers. Ask for their opinions, especially if your options are more subjective. Letting your team express their preferences will help you get buy in.

• Don’t wait for unanimity. It’s incredibly rare to have everyone fully agree on something. Don’t wait for it. Make a decision that is supported by a majority.

• Don’t stall with multiple choices. When you’ve done all this and there are still multiple options that seem like good choices, just pick one! Especially if the impact is low and you can iterate quickly. Getting to the act phase is more important than choosing the “best” option, because acting will help you learn what best actually is.

• Use prototyping, testing, and automation. Building prototypes and conducting quick tests can provide immediate feedback and inform decisions, especially when choosing between different technical approaches or designs.

How you can apply this today

When presented with a choice that you would usually ask a more senior team member for direction on, try deciding yourself first. Then talk to that team member, present the options, and what you think the best decision is and why.

If the team member disagrees, you can have a conversation about why. A great learning opportunity.

If the team member agrees, the conversation will be short, you have saved them time and mental capacity of having to make another decision, and you both get confidence in future decision making opportunities. Eventually you’ll be empowered to make decisions like that without consulting others.

👥 Using a third entity instead of using a join table

A join table is commonly used in relational databases to associate two records with each other in a many-to-many relationship.

Consider this example of a University with Student and Class entities. There are many Classes, each with many Students. A basic join table structure may look like this:

This works just fine if there is no additional data in the middle of this relationship. However, the University wants to know more than who is in the class. We need to track attendance, grades, etc. for each student.

We could add these attributes to our existing join table, but some frameworks and ORMs don’t play nicely with that. We’re also now seeing more of our domain coming into play. This isn’t just a relationship, this is first-class data.

Let’s reflect that by replacing the join table with a proper Enrollment entity:

By adding a third entity, we’ve:

• Better reflected the domain and business logic of the University (a student enrolls to a class)

• Alleviated any issues with frameworks or ORMs that don’t play nice with additional data in join tables

• Kept all the same relationships

Things & Happenings

Tech

• Bruno, a new API client alternative to Postman

• OpenMoji, open source emoji for everyone

Learning

• Eloquent JavaScript (4th Edition, 2024), a book about JavaScript, programming, and the wonders of the digital

Tools

• dbdiagram, used to make those table graphics 🙂

Other Reading

• Celebrating women in tech this International Women’s Day by Elastic

Coming Up

• What an MVP actually is

• Horizontal vs. Vertical scaling

I posted a poll on LinkedIn about future topics to cover. Head there to vote and influence the content of this newsletter!

Talk to you again soon.

Aken 💙

Slack is a wonderfully beneficial tool for productivity, team communication, and even automation. But it can be both incredibly distracting and a lot of noise! 💥

Senior engineers constantly iterate on and improve their workflows, how they spend their time, and how information flows to and from them. Here are ways you can Be A Senior and use Slack effectively to both improve communication and minimize distraction:

Improve Communication

• Default to using Channels. Channels allow more participants and make content more accessible both immediately and long-term. It keeps discussions relevant to a single topic in one place instead of spread out among DMs. And it doesn’t disrupt others from their focus, if they’ve followed my advice below about minimizing distractions. 😉

• Make more channels. Do you have 50 engineers all posting about their projects in the #engineering channel? I have a hug and a shoulder to cry on waiting for you if so. Create channels for teams, projects, and even one-off situations. 📚 How to organize your slack channels.

• Use private channels. Some conversations are naturally more sensitive, but are still relevant to work and not private matters. Private channels have all the same benefits while limiting access. This is especially useful when you need to add someone new, as they’ll have access to the channel’s history right away.

• Use threads. Threads allow multiple conversations to happen in parallel without overwhelming a channel, and are easier to reference later. Be careful letting a thread get too long or diverge from its origins; create another thread if that happens.

• Add useful integrations. Share build pipeline updates. Auto-link Jira tickets. Update your status automatically when meetings on your calendar begin. Be notified when you’re assigned to something. Trigger automations right from Slack. The options are endless.

• Share info through statuses and reactions. Who knew emoji could be so damn useful? Update your status when focusing or away from your desk. React with 👀 when looking into a question. Mark your own question with ✅ when answered. These small bits of communication are incredibly useful to others, and add up to a lot of time saved.

• Try not to post rapidly. This one is more important when direct messaging someone, but can apply to channels and threads, too. Don’t say “Hi” and then write a novel, or send 5-10 rapid lines of mind dump. Make your first post a full thought. Don’t take someone’s attention then make them wait.

• Write well with proper grammar and spelling. I’ll admit this one is a lot of personal opinion and standard. I have a hard time reading shortcut-style text with words replaced with letters and a lack of punctuation. I also won’t take you as seriously if you write like that, even if you’re a great developer. Kind of like dressing nicely for an interview, the way you write makes an impression.

Minimizing Distractions

• Use notifications for DMs, mentions, and keywords. Don’t use notifications for everything, ever.

• Turn off “Include a preview of the message in each notification”. This keeps you from reading whatever the message is about and switching contexts even further, and helps with privacy when sharing your screen or someone’s looking over your shoulder.

• Use Do Not Disturb mode often. Think of it like closing your door and putting your headphones on – this is your time, and people should leave you alone. Set your Slack status to “Focus Mode” or “Heads Down”, turn DND on, and focus.

• Adjust notifications at the channel level. Sometimes one specific channel is noisy, or you can’t convince someone to stop using @here every time they post (I hate them, too 🤬).

• Unsubscribe from threads. Sometimes you don’t need to keep up with a thread you participated in. Hover over the original post, click the three dots, and choose “Turn off notifications for replies”.

Don’t let these notifications take over your life like this guy:

Automated Dependency Updates

Technical debt comes in many forms. One form you’re probably familiar with is outdated third-party dependencies. They can be a huge chore to maintain and update, and rarely are you bestowed the time to do so.

How does a Senior approach convincing the company to give devs the time?

First, you have to communicate the issue in business value rather than technical.

Don’t ❌

You: “We need time to update these packages.”
Them: “Why? Are they broken?”
You: “No…”
Them: “Okay then we don’t need to. This feature takes priority.”

Do ✅

You: “We have packages our software depends on that are out of date. These old versions have security vulnerabilities and bugs that have since been patched. If we avoid updating now, our app is open to security risks, and updating later will be a larger undertaking that could risk more bugs or even downtime.”

Them: “Yikes! Let’s do that now. How long will it take?”

By expressing the value in terms of business, you’re more likely to get buy-in from the decision makers. But that last question is still a tough one – how long will it take? This won’t be the only time you do dependency maintenance, either. Will it take that long every time? You need a plan.

Automation to the rescue! 🛟

Automated dependency updating software tracks your project’s dependencies, identifies when new versions have been released, and creates pull requests with the updated versions automatically.

This flow has big wins for you and the business:

• Engineers don’t have to spend time on the tedious parts, allowing them to focus on more impactful work

• Each dependency update is small, taking minimal time and effort

• Dependencies don’t go stale, preventing security risks

• Can be implemented relatively quickly

However, there are still some considerations and potential trade-offs:

• In order to reduce engineer work as much as possible, you should have a mature delivery pipeline with a large amount of test coverage. Otherwise it will still be a manual testing effort.

• If you aren’t doing continuous delivery, you risk rolling back a release full of features due to a bug not found in an automated update

• Having a lot of projects (e.g. a large microservice ecosystem) could result in a lot of automated PR noise

• Automating some dependency management makes it easier to forget about the non-automated stuff

At the very least, being notified when a dependency update is available and reducing the amount of work needed to test and merge it is a win for your team.

Here are some solutions to consider:

• Mend Renovate

• GitHub’s Dependabot

• Depfu

• Snyk

Coming Up

🤔 How to quickly make (reasonably) good decisions

👥 Creating a third entity instead of using a join table

That’s all for today! Not enough Happenings happened or Findings found. See what I did there? (⌒▽⌒)

Have you been enjoying the two-subject format lately? Hit reply and shoot me your thoughts and advice.

Aken 💙

Working on the projects handed to you from managers, leads, or other leaders on your team is normal and valuable. The problem is, it’s valuable more to the company than it is to you.

Most work handed to you will be within your assumed current skillset. As a junior engineer, you’ll be given more basic tasks. As a mid-level, you’ll be given features that are more complex, limited in scope.

In order to make the biggest leaps in knowledge and experience, you need to work on things that are beyond your current skillset. As you demonstrate growth, you’ll naturally be given more responsibility and opportunity to influence your team and organization.

Here are 6 actionable ways to position yourself in more aspirational projects and situations:

1. Give an impression of trust and added value. You may have all the skills and qualifications to receive more complex projects, but you won’t get them if the team doesn’t trust you. Improve your standing by participating in meetings, turning your camera on, helping your teammates, and overall demonstrating you are a valuable part of the team. It doesn’t mean overtime or extra work, it means not hiding or giving your team reasons to question your abilities.
   

2. Ask or volunteer for the work. Let your manager or lead know you’re interested in pursuing more difficult and complex work to gain experience. Sometimes all it takes to get more difficult tasks is to make others aware that you want them. If one is open for the taking already, volunteer to own it.
   

3. Surround yourself with people already there. Direct ownership of a more complex task isn’t the only way to gain experience. Ask your more senior team members if you can watch them work via shadowing or pair programming. Have them think out loud so you can hear their mindset and processes. Ask questions any time you don’t understand something – these exercises are about learning, not pride.
   

4. Accept opportunities that feel beyond your skillset. Don’t let fear, uncertainty, or doubt keep you from excelling. Stagnation is an enemy in your journey to Senior, and avoiding learning opportunities will delay your progress. You won’t regret pushing outside of your comfort zone.
   

5. Own an ugly problem. People – yourself included – naturally want to do more interesting and impactful things. But tech products are riddled with unsexy issues in the backlog. By taking initiative, owning, and fixing unsexy problems, you’ll pick up more experience and position yourself as someone that can be trusted. Remember that the key to trust is to deliver whatever you own, ugly or otherwise.
   

6. Ask for help, and admit defeat if necessary. Part of taking on more complex projects is the risk of failure. Something, at some point in your career, will be too much for you to complete on your own. Don’t get down about it! First, ask for help when you get stuck. (You should do that at every phase of your career, but it’s especially important when pushing your boundaries.) If all else fails, let the project be taken over by someone more qualified. Your team will help you recognize when this is needed. At which point you can reflect on what you learned, where you got stuck so you can focus on getting back to that point, and maybe continue to pair with whomever takes it over.

Working on projects you aspire to is very much within your grasp. Be confident in your ability to learn, vocal in you desire, proactive in your ownership, and humble in your success or failure. 🍾

Design Pattern of the Day: Adapter

Have you ever tried to charge your phone in a foreign country and found your plug didn’t fit in the outlet?

Have you reached for a dongle so you could plug your USB-A device into a USB-C port on your shiny new laptop?

The Adapter Pattern in object-oriented programming (OOP) serves the exact same purpose in your code, acting as a link or bridge between two incompatible interfaces.

One use case is adding a third-party library to your application. Its interface may not be directly compatible with your domain code. Perhaps your data is already in XML format, but the library prefers JSON. Instead of modifying the library or creating your own custom integration, you can add an Adapter layer in between that performs the necessary data conversion.

Benefits of the Adapter pattern:

🟢 Quicker development – only create the layer in between two existing interfaces
🟢 Clean code – single responsibility lets classes focus on only one area
🟢 Flexibility – adapters can be swapped as long as interfaces stay the same
🟢 Testability – the adapter layer can be tested and swapped independently

Potential downsides:

🔴 More code – sometimes it’s easier to just change your existing interfaces
🔴 Slow – implementations may have performance impacts

Further Learning

Adapter Pattern @ Refactoring.guru

PentaLog discusses more potential downside nuances, which are good to consider (as always with software, It Depends!)

LinkedIn Advice: How do you use the adapter pattern to integrate legacy or incompatible systems?

Happenings & Findings

Articles

• Postman’s 2023 State of the API report is full of interesting data

• Shekhar wrote an analysis of GitLab’s Postgres schema design (2022)

Technologies

• Netflix released SafeTest, a novel approach to front-end testing

• Knock provides notifications as a service, great for mobile apps and more

Jobs

Find your next opportunity through Cupalo, an ethical, above-the-table staffing partner who treats you like a real person. (Not sponsored! Lauren is a wonderful founder friend from an entrepreneur group. She’ll take great care of you!)

How’s BASE doing?

• Newsletter subscribers: 47 (+176%)

• Newsletter open rate: 46.27% (+3.3%)

• LinkedIn followers: 63 (+425%)

• Twitter followers: 4 (+33%)

While the numbers aren’t specifically impressive, the growth is! 📈

I posted on my personal LinkedIn about BASE and asked for shares and referrals, and it was by far my most widely-seen post on the platform. Thank you to those who shared and interacted, and welcome new subscribers!

What I’m Working On

I’m currently building Stay Woven, a personal relationship manager mobile app.

I’ve never built a mobile app, so it’s an exciting new tech adventure! The stack I’m using is React Native with a Firebase backend.

I’m working on multiple products in 2024 on my journey to becoming a successful entrepreneur and business owner. Follow along!

Coming Up

In the next edition, I’ll cover:

• How to use Slack effectively for more productivity and fewer distractions

• How to automate dependency updates to reduce tech debt

Subscribe now

Thank you for reading!

Come chat with me on LinkedIn, Twitter, or hit reply and let me know how I can help with your engineering career.

Aken 💙

Today for you I have:

• A Story of Failure

• BASE Tech: Full Text Search Engines

• Links & Happenings

A Story of Failure

An upper mid-level engineer on our team deployed consecutive releases to production that caused bugs or failures.

You can probably relate to how they felt. Terrible at their job. A disappointment.

This dev was certain they were going to be fired.

But we had a positive culture in our engineering team. We used our regression protocols to revert the deployments. We let them immediately fix the issues and deploy the corrected features to production. We analyzed how the bugs eluded our review and testing processes so we could better protect against future occurrences.

All without blame.

Because it happens to us all. Releasing a bug to production is a right of passage. (Hopefully one that doesn’t have too big an impact on the business!)

This dev knew they made a mistake, was empowered to fix it, and learned from the process. They improved their experience and skills, and gained trust in the organization that didn’t punish them.

Senior engineers acknowledge the fallibility of humans, introduce and encourage a culture of support, ensure technology is in place to help protect against mistakes, and encourage autonomy.

And we learn from our mistakes. 🙂

Do you have a similar story about yourself or a colleague? Leave a comment or hit reply and tell me about it!

BASE Tech: Full Text Search Engines

💡 Each BASE Tech briefly covers a technology, its purpose, and how a Senior engineer might approach using it.

You want to add search to your app, and all your data is currently stored in a DB such as MySQL. The first solution you might turn to is LIKE ‘%query%’ SQL queries. No new software and it “gets the job done”, right?

Searching is complex, and not just in implementation. A great search experience includes many features and nuances that are not provided by LIKE SQL queries:

• Language and Text Analysis – Fuzzy matching common typos, stemming (reducing words to their base or root form), lemmatization (considering the context to convert a word to its meaningful base form), and handling synonyms. Such features improve the search's ability to match on the intended meaning rather than just the exact text.

• Relevance Ranking – Rank results based on their relevance to the search query. The most relevant results are returned first, improving the user experience. Many engines also provide highlighted relevant terms you can use in your UI.

• Advanced Search Features – Boolean operators, phrase matching, proximity searches, wildcards, and more. These features allow users to perform more complex and precise searches.

• Performance – Full-text search engines are optimized for searching text data efficiently. They use specialized indexing strategies that allow for much faster search operations, especially across large datasets. LIKE queries, especially those with leading wildcards, can be very slow because they often require scanning entire tables or columns to find matches.

• Customization – Tailored indexing, field-level configuration, custom ranking algorithms, and more.

A full-text search engine empowers you to provide the search experience your users expect (Google and major tech has spoiled them all). How does a Senior make that happen?

Gather requirements, choose an engine, and create an implementation plan that includes development, pre- and post-launch phases:

• Gather Requirements – Understand your users’ needs of what they are searching and why. Use this to define the scope of searchable content – the fields, data, and types to be searched. Don’t forget requirements like security and compliance.

• Choose an Engine – Find one that has the features you need based on your requirements, while balancing performance, scalability, cost, and ease of integration.

• Model and Index Your Data – Design a schema that represents your searchable content. Develop the process for indexing your content, ideally an automated one to ease deployment and ensure consistency.

• Build the Thing! – Integrate search into your backend, creating service/repository/data layers and abstractions, calling APIs, and anything needed for indexing and querying data. Implement mechanisms to keep the search index up to date with data changes.

• UI/UX – Design and implement the search interface. Add delighting features like autocomplete, faceted search, filters, and sorting where applicable.

• Test and Optimize – Stress test the search implementation under various loads. Adjust ranking algorithms and relevance settings to improve the quality of results based on user feedback and analytics (have a plan for this, it isn’t an afterthought!)

• Monitor and Maintain – Track usage, performance, and health of your search infrastructure. Understand what maintenance you’ll need over time, such as software updates and scaling as your data volume grows.

You’ve now planned for and implemented a powerful and useful full-text search feature just like a Senior engineer would! 👏🏼

Here are some engines I recommend looking into for your search needs:

• Elasticsearch

• Typesense

• Meilisearch

• Apache Solr

• Algolia

There are more open source and paid hosted solutions out there, if none of these suit your needs. I’ve used Solr (and Sphinx, which doesn’t seem as modern or maintained as others) in past projects. More recently I implemented Meilisearch for SpendBetter.com, then switched to Algolia when I needed multiple geo coordinates per record.

Have you implemented full-text search? Use a different engine than one mentioned here? Let me know how your experiences went!

Links & Happenings

I recently upgraded my laptop, and with a fresh start have been trying new software: Warp, a modern, Rust-based terminal, and GitKraken, a git GUI. Yeah, I’m a GUI guy, let’s fight about it!

My friend Andy is experimenting with Airplane, a developer platform for internal tools. It has a self-hosted option which is unique for the space.

I’m creating a silly API project this month and Zuplo is on my radar as an API Gateway layer. They also have a silly-but-useful tool: RateMyOpenAPI. Shout out to Adrian @ Zuplo for sharing!

Last night I tried the Sleep Cycle app for the first time in an effort to improve my morning routine. It worked pretty well as an alarm and captures some interesting data (and sound clips of my wife snoring 😴). I’ll be curious to see if results stay consistent. Shout out to Zach Highley’s How To Become a Morning Person YouTube video for the recommendation.

Happy Wednesday! Come chat with me on LinkedIn, Twitter, or hit reply and let me know how I can help with your engineering career.

Aken 💙

I left that conversation happy with sharing things that I felt were useful.

The dev left the conversation feeling like I was once again micromanaging and nitpicking their work.

My good intentions didn’t matter, and it hurt. 🙁 All I wanted to do was share tips that I personally found useful. But the way I communicated made the dev feel like they sucked at their job.

You can avoid the same mistake by tailoring your communication to your stakeholders through:

1. Identifying who they are

2. Understanding their needs

3. Classifying them based on power and interest

What is a stakeholder?

A stakeholder is someone with an interest in, or is affected by the project you’re working on. They’re usually internal – people at your org that you work with regularly. They can also include people external to your company: customers and clients, third-party vendors, suppliers, regulatory bodies, etc.

On engineering teams, you’ll often intuitively know who your stakeholders over the course of discussing a project:

• Your boss

• Your team lead

• The other devs on your team

• The Product team

• Related teams like Design, Infrastructure, Security, etc.

Good teams have documentation in place that identifies key people and their roles in a project (when the scope is big enough). These are immensely useful for both identifying stakeholders, and knowing who to turn to if you have questions or concerns.

Identifying a Stakeholder’s Needs

(I swear if I write “stackholders” one more time…)

Each stakeholder in a project has their own goals, needs, and desired outcomes for a project.

The CEO might not care about the project itself, but rather than health and growth of the company as a whole.

Your boss has significant interest in your project, in terms of both personal and team success.

Another dev on your team is mostly interested in their part of the project.

Understanding the needs and goals of a stakeholder can help you classify and tailor communication:

The CEO needs to know how the project will help with company health and growth, not what you’re doing today.

Your boss needs more regular involvement about the project’s status and your ongoing tasks.

Your coworker needs to know if they’re doing a good job achieving their development tasks.

When I gave advice to my coworker, I focused on what I wanted and not what they needed, which was to know if their work was effectively progressing our team’s goals. My small tips came across as focusing on little things that didn’t matter, regardless of their validity.

Once identified, you can classify your stakeholders to tailor communication.

Classifying Stakeholders

Using a combination of their needs and their position in your company’s project and/or org chart, stakeholders can be classified using two key characteristics: their power to influence your project, and their interest in your project’s results.

Those with significant power over a project will need to be kept satisfied.

Those with significant interest in a project will need to be kept informed.

Those with significant power and interest are effectively partners in the project. They should be kept fully engaged along the way to ensure their satisfaction and information level is high.

Those with low power and interest are minimal priority, and can be given similar efforts when it comes to communication.

Here are some examples of engineering stakeholders, their needs and classifications, and how to tailor communication for them:

• The CEO: needs company-wide stability and growth. High power, low interest. They’ll want to know how the project helps achieve stability or growth. Depending on your organization’s size and structure, this will likely be handled by someone else.

• The CTO: needs to reduce technical cost and complexity (also read: needs to help achieve stability and growth through technology). High power, low interest. Treated like the CEO, might not be on your radar at all.

• Your boss, an engineering manager: needs effective output from their team(s). Medium-to-high power and interest. Treat them like a partner and remain engaged with them. Good ones will make it very obvious what their goals are with the projects, so you won’t need to ask or, worse, guess.

• Your team’s lead, a senior+ level engineer: similar to the manager but on a more implementation level, needs effective output from the team and make the manager happy. Low-ish power, high interest. Utilize your project management tools like Jira to keep your work visible and up-to-date. Tell them about blockers early. Make it so they never have to come ask you what the current status is.

• The Product owner who created the feature spec: needs to achieve their own team goals, such as increasing revenue or improving customer satisfaction. Low power, high interest. Keep them informed, especially of any changes to the feature or its timeline.

At the very least, imagine yourself in the role of the stakeholder. What actions would others do that would make you happy, make your job easier? Do those things, communicate those things, and you will be a valued asset to your team.

Is there a role not mentioned here you’d like help tailoring your communication to? Do you have a similar failure in attempting to communicate as mine? I’d love to hear your questions, anecdotes, or how your engineering career is going lately!

I apologize for missing a week of Become a Senior Engineer. I caught the flu from my daughter after it wreaked havoc on her for almost a week, my basement backed up with water after our sump pump went out, and we said goodbye to one of our pet cats.

May you and your pets remain healthy and happy! 💙

Preparing For Possible Layoffs

Losing your job sucks. Our society revolves so much around money. As soon as our income is no longer a secure thing, we freak out.

While software engineering can be a lucrative and stable career, individual jobs aren’t. Here are some ways you can make the possibility of a layoff less scary:

1. Save up an emergency fund: Build an emergency fund savings account with enough to cover your expenses for 3-6 months. You’ll have peace of mind for regular unexpected costs (like your car exploding) along with an unexpected job loss.

2. Document your successes: Ensure your resume is current and showcases your latest projects, skills, and accomplishments. Keep your online professional profiles, like LinkedIn, updated. Maintain a portfolio of your work, especially any public contributions to open-source projects or personal projects that demonstrate your skills.

3. Keep learning and practicing: The tech field is constantly evolving. Stay updated with the latest technologies, programming languages, and industry trends. Online courses, certifications, and workshops can be beneficial.

4. Get a side piece: Engaging in side projects or freelancing can not only hone your skills but also create additional income streams and open up new career opportunities.

5. Be emotionally ready for reality: Layoffs can be stressful. It's important to maintain a healthy work-life balance and have a support system in place. This can include family, friends, or even professional counseling. True for regular job stress and burn out, too. Talk to someone when you’re not doing great.

6. Peep the market: Keep an eye on the job market and the health of companies in your industry. This awareness can provide early signs of market downturns or opportunities in emerging areas.

7. Brush up on your leet code: Regularly practicing for interviews can keep you sharp and ready to present your best self when opportunities arise.

Further Reading

Gregor helps you document your successes:

Engineering Leadership

Keep a brag list of the wins you achieved, thank me later

Intro It’s really important to work and focus on things that are impactful and try to provide as much value as possible to the organization, but it’s also very important to note down what you achieved and have it ready whenever someone asks you for your achievements…

Read more

2 years ago · 68 likes · 19 comments · Gregor Ojstersek

John’s newsletter is full of engaging challenges to help you learn and practice:

Coding Challenges

A weekly Coding Challenge to help software engineers level up.

By John Crickett

The OWASP Top 10

As a senior member of engineering teams at two organizations, I often interviewed developer candidates for mid- and senior-level positions. One question I liked to include was: “What security risks should engineers be aware of when developing SaaS applications?”

Very few candidates could list more than 3 or 4 security concerns, and almost no one mentioned OWASP or other security standards they could reference.

Application security is a critical and often required facet of modern software development. Knowledge of security risks should be included in your broad knowledge, alongside things like programming languages, databases, etc.

The Open Worldwide Application Security Project (OWASP) is a nonprofit foundation that works to improve the security of software. Launched in December 2001, its programming includes open source projects, 250+ local chapters worldwide, industry-leading educational and training conferences, and more.

The OWASP Top 10 is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications. It was started in 2003 to help organizations and developers with a starting point for secure development. Over the years it's grown into a standard used as a baseline for compliance, education, and vendor tools.

Why should you care about the Top 10?

Security is not optional. Creating secure code is inherently part of the value we provide businesses as software engineers. This is especially true (and required by law) for software surrounding payments, medical records, and other highly-regulated sensitive data.

Security is important for the business. Sometimes it’s difficult for developers to understand what is important to their employer and the business as a whole. Avoiding costly security breeches, lawsuits, or other ramifications of insecure applications is one thing any good business will prioritize.

Considering security helps you think about more than the happy path. By imagining how your software will be used in ways other than its normal intended functionality, you can ensure a better experience overall. The UI, code quality, tests, and more all will increase in quality.

It makes you look better in interviews. When I interviewed candidates, I expected engineers to have enough knowledge about security to understand how it impacts their role. By mentioning the OWASP Top 10, you demonstrate awareness and an authoritative resource you can rely on without needing to be a subject matter expert.

It’s knowledge and experience! “Never stop learning” is a common theme here at Become a Senior Engineer. You never know when you’ll be in a situation where the Top 10 could save you, your team, or your business the headaches of dealing with a security exploitation.

Knowing what it is and why it should be in your toolbox, head over to the Top 10 to see what the risks are, examples of each, ad how to mitigate them in your apps.

Is it a console, terminal, or…?

No real nuggets of senior wisdom to go along with this, just something fun to nerd out on:

What is the exact difference between a 'terminal', a 'shell', a 'tty' and a 'console'?

Things & Happenings

• ✨ CharmUI, beautiful production-ready components built with React and Tailwind CSS – by my friend Tim Wilson

• Work Chronicles, a web comic

• Pathless Path by Paul Millerd is now free to download

• ASDF, a runtime version manager

• Tally, a really nice looking free form builder

• Teal, an AI resume builder and job app tracker

• go/links, an internal URL shortener to easily find important info

Starting a newsletter is a journey, especially if you’ve never done it before like me. Every issue is a learning opportunity for the process, the business, who you are as a writer, and all that jazz.

I wanted this newsletter to be a revenue generator for me, as I am currently a solo entrepreneur trying to be self-sustaining. The chances of that becoming a reality in a short enough amount of time is low. So, I’m pivoting a bit.

Starting now, 98% of BASE content will be free. The paid tier is still available (now reduced to $5/mo) in a “support the creator” capacity, but will not include much in the way of exclusive content for now.

The newsletter will be reduced to one scheduled release a week, with occasional supplements. It’ll be a little more casual, yet always emphasizing how to use the knowledge shared as a senior would.

If you ever enjoy a piece of content, the format of the newsletter, or have any advice to share, just hit reply and send me an email. I’d love to hear from you.

But wait, there’s more! (insert cheesy infomercial music)

Replacing the reduced newsletter content will be a new blog on the .com, where more formal or long-form content will be added, especially anything code-heavy. While there is no promised release schedule there, all relevant content will be highlighted through the newsletter.

I’m working with some other engineers, managers, and creators on content for the blog. Stay tuned for that.

Here’s a preview of this week’s newsletter, releasing tomorrow (Wednesday Jan. 24):

• Preparing for a possible layoff

• A senior’s security resource: the OWASP Top 10

• Is it a console, or a terminal, or…?

Subscribe now

If you’d like to follow my solo entrepreneur journey, connect with me on LinkedIn.

Thanks for coming along on this ride with me!

Aken 💙

This week has been a very productive one for me, but not when it comes to being prepared for the scheduled newsletters. So I apologize for this one being a little half-assed. 🙂

Having multiple blizzards this week here in Wisconsin hasn’t helped!

Here are some random tidbits for your Friday. I’ll see you next week with the regular actionable issues. 💙 ❄️

Friday is the perfect day for reflection.

Do you reflect on your job and career often?

Fridays are a perfect time to do so. Here are ways to reflect on your week as an engineer:

• How did you feel this week? Did you enjoy work? Find ways to do more of that work you enjoyed. Did you have a crappy week? How come? Recognize your emotions and how they impact your job, whether they’re caused by your job or not.

• What did you learn this week? Take time to actually think about it. Probably more than you realized once you quantify it.

• Check in with your people. Did a teammate have a good or bad week? Reflect on it with them. You will improve your influence on the team by sharing your attention and showing you care about them.

• Write down your successes. Big ones are great for your résumé. Small ones are great for you – every success is a bit of experience and growth.

• Write down your failures. Ask how you got to that failure point and what you learned to make sure it won’t happen again. Share your failures with your team or network

Sharing your failures is part of leaving everything better than you found it:

Happenings & Findings

Articles

Mihhail Lapushkin reflects on and shares tips from building the Paper text editor for macOS & iOS.

PostgreSQL data types – what are they, and when to use each.

Technologies

shadcn/ui – Beautifully designed components that you can copy and paste into your apps. Accessible. Customizable. Open Source.

Phoenix Framework – A web development framework for the Elixir programming language that gives you peace of mind from development to production.

Jobs

Flycore, building the next generation of software in aviation, is hiring a founding engineer.

Flood is hiring a remote Web3 full stack engineer.

How is BASE doing?

• Newsletter free tier: 17 subscribers

• Newsletter paid tier: 0

• LinkedIn followers: 12

• Twitter followers: 3

Honestly not bad for a publication less than a month old, by a new author with almost zero existing following. I hope to improve those numbers through the end of January. I’d love to see 50 subscribers by then.

LinkedIn will continue to get attention as a driver to the newsletter. Twitter is not a priority, but will still get regular content.

I’d love it if you shared BASE with your colleagues to help me achieve these goals. It’s free, only takes a minute, and it helps me tremendously. And you can get a free upgrade to a paid subscription!

Share Become a Senior Engineer

Community

Subscriber Joel Clermont shares his favorite code editor feature:

The GitHub PR feature in PHPStorm is great. Getting syntax highlighting in the PR is so nice!

Hope you have an awesome weekend, and your 2024 is off to a happy and productive start. 💙

There are many factors that can contribute to software rot. The most important one seems to be the psychology, or culture, at work on a project. Even if you are a team of one, your project’s psychology can be a very delicate thing. Despite the best-laid plans in the best people, a project can still experience ruin and decay during its lifetime. Yet there are other projects that, despite enormous difficulties and constant setbacks, successfully fight nature’s tendency toward disorder and manage to come out pretty well.

What makes the difference?

In inner cities, some buildings are beautiful and clean, while others are rotting hulks. Why? Researchers in the field of crime and urban decay discovered a fascinating trigger mechanism, one that very quickly turns a clean, intact, inhabited building into a smashed and abandoned derelict.

A broken window.

One broken window left unrepaired for any substantial length of time, instills in the inhabitants of the building a sense of abandonment. A sense that the powers that be don't care about the building. So another window gets broken. People start littering. Graffiti appears. Serious structural damage begins. In a relatively short span of time, the building becomes damaged beyond the owner’s desire to fix it, and the sense of abandonment becomes reality.

Senior engineers regularly identify, fix, and prevent broken windows in their projects and teams by leaving everything better than they found it. Here’s how:

📑 Improve Documentation

An important trait of senior engineers is their ability to increase the success of those around them, not just themselves. Interacting individually with another person isn’t the only way to do that. By iteratively improving your project’s documentation, you enable others to easily access information necessary for doing their job successfully.

Add New Documentation

Are you adding a new feature or learning a process that hasn’t been documented yet? Add it for yourself and the next person.

Update Existing Documentation

Is a document you’re referencing wrong or out of date? Maybe a dependency has changed, or a related feature has been removed.

A great time to add or update docs is when you’re new to an organization, team, or project. As you onboard, you’re bound to find something not quite accurate.

Turn Questions Into Documentation

If you have a question that you have to go directly to another person to answer, or if someone comes to you with a question, consider documenting the answer. Not everything needs to be written down somewhere, but be aware of what information you or others are lacking and how it can be made accessible.

💡Expose Hard-to-find Resources

Similar to documentation, sometimes resources and dependencies for your projects are not effectively shared or easily referenced. If you need to go hunting for something you need to do your job, make it so the next person can find it easily on their own.

Share Files & Credentials

Sometimes project files that aren’t committed are passed around directly between engineers. Try to remove these manual processes and ensure everything is shared with those in need.

• Commit non-sensitive files to appropriate repositories

• Created shared file drives for non-code resources

• Utilize password managers to share credentials

And remember, you can implement these things! Bring the solution to your boss and work together to determine how much of their help you’ll need. Your initiative will be recognized.

Improve Logging & Metrics

Are you having trouble debugging, looking for performance insights, or generally investigating your application? Add appropriate logging and metrics.

Is there a lot of noise in the logs or metrics for things that really aren’t valuable? First, check with your team to confirm they aren’t valuable. You may not know the full context. If the team agrees, remove the noise.

👩🏽‍💻 Clean Up Code As You Go

This is a huge one. Listen up:

The reality is, software development is a means to achieving business value. Business value means customer value. And customers don’t see improvements to technical debt.

(I can feel you starting to argue with me. Of course there’s nuance in every situation, including yours. Forget your argument for a second and listen.)

There will always be something wrong in the code that you would like to fix. Always. And you’ll wish for a sprint or a month to tackle that debt. It will never happen. Instead, clean up code as you go. In small iterations, when you’re already working in that part of the code.

Making iterative improvements to your code as you work around it will significantly reduce the amount of technical debt in your code, without ever needing specific time dedicated to it.

Make it a part of your deliverables. Include a buffer of improvement time in your estimates. Check the code when doing your feature planning to see if you’re going to be touching anything ugly, so you can fix it along the way. You’ll never get a dedicated sprint, but you will get an equal amount of time and then some if you spread it out into each feature and deliverable you work on.

Improvement Opportunities To Look Out For

• No tests. Add tests to important parts of your application that aren’t covered. Especially if the code is confusing or complicated – tests help document expectations.

• Repeated code. Keep things DRY (don’t repeat yourself).

• Hard dependencies. Is changing an implementation or adding test data difficult? Use good abstractions and dependency management.

• Difficult APIs. If a dependency is difficult to work with, create layers that can help “translate” the difficult part, separating the calling code from the difficult logic.

All of these will be explained in more detail in future issues of Become a Senior Engineer. Subscribe today, and hit reply to tell me which topic you’d most like to learn about:

Subscribe now

⚙️ Implement Processes & Standards

The blending of many engineers and their own styles and opinions often leads to a more complicated code base. If everyone is implementing things in their own way, it becomes more difficult to comprehend and modify. It can also be accidentally insulting (“Why did you change my code? There was nothing wrong with it!”).

Senior engineers recognize the importance of having defined processes and standards that everyone can adhere to. It improves quality and understanding, while eliminating decision making and opinion clashes.

As you run into situations where a difference of opinion or a lack of standard creates multiple possible implementations or confusion, find a single solution the team can follow.

I know – this is harder than it sounds. Those differences in opinion will lead to some arguments. Thankfully, there’s a two step path to success:

1. Listen to everyone. After introducing your standard, listen to everyone’s responses. Create a shared document and show that you noted their thoughts. People want to be heard and considered – demonstrate that you have done so.

2. Decide, then iterate. Don’t wait for a solution that everyone unanimously agrees on – it’ll never happen. Pick one that the majority approves of, implement it, and iterate from there based on what the team learns and experiences.

🚫 Teach Your Failures

This one is less tangible than changing documentation or code. The principle is the same, though: leaving your team better than you found it.

Senior engineers still have failures. Sometimes they’re even bigger due to the larger scopes of their projects.

What differentiates senior engineers is:

• They are not afraid of failure – they ensure risks are minimal, and have plans if things go wrong

• They embrace failing as much as success, in that both are incredible teaching and experience moments

• They take their failure and share it with the world

By teaching your failures to your team / organization / blog / newsletter / social media, you add to the collective knowledge of your audience. You position others to eliminate a point of failure before it occurs.

You know not to eat a poisonous fruit or play in poison ivy,because someone before you unfortunately learned the hard way. While less life-threatening, the same is true for your failures on the job.

Audience Questions

✨ 🆓 Answer any of these questions for a chance to win a free book!

What is your favorite piece of documentation?

What recent action did you take to leave your project better than you found it?

What failure did you experience lately that could be a teaching moment? No failure is too small!

Hit reply to answer any and all of these, and I’ll highlight your answers in a future issue!

Happy Thursday, engineers!

I’m the author of Become a Senior Engineer, a new educational and community endeavor. I’ve been been in professional software development for 20 years as a full-stack engineer.

Here’s my story of getting started in software development and where it has taken me along the way!

The Early Days

Like many people, I was likely predisposed to some sort of computer-based career due to my father. An electrical designer by day, we would spend evenings in his office playing with an old Apple IIe. It had a black-and-green screen that I’m reminded of every time I see The Matrix. I loved finding the large 5.5” floppy disks that had my favorite games to play. As I got older, Dad would show me some of the silly cartoons and newsletters he’d make on his Apple Macintosh (that he still has today).

When I was around 9 or 10 years old (1995-ish) we got a regular PC tower and the internet. 🤯 I thought websites were the coolest thing on the planet, and I wanted to learn how to make them.

The next few years or so was a trial-and-error journey of self teaching. Checking the source code of web pages, copying and pasting, changing things and seeing what happened. Netscape Navigator and Geocities dominated my desktop.

(I have a hand-drawn wireframe of a Geocities website somewhere that I desperately wanted to show in this article – couldn’t find it 😡. Literally drawings of gifs with their filenames listed underneath! The internet was so cute back then.)

Eventually I had a pretty good handle on HTML and CSS, and started introducing dynamic elements with JavaScript and PHP. Macromedia Dreamweaver was my editor of choice, allowing me to be hands-on with the code when I knew what I was doing, and using the WYSIWYG editor and built-in scripts when I didn’t.

First Paid Gigs & University

After graduating high school (secondary school), I began freelancing as a PSD slicer. I would receive website designs as Photoshop files and turned them into static HTML and CSS. Freelancing taught me a lot about client communication, pricing and invoicing, and other fun intro to business lessons. Though I was still very much an 18-year-old not really thinking about careers. Web development was always just fun.

I began going to a local state university right after high school. I made it three semesters. School was never my favorite thing to do. University felt like more high school, except I was not forced to go and it cost money. I knew the university wasn’t for me when I had to take an “Intro to Computers” class as part of the computer science program.

I ended up taking a few basic jobs for a university-aged guy – retail, pizza delivery, that sort of thing. Meanwhile, I continued to freelance occasionally while learning and exploring more complex dynamic code solutions, particularly on the back-end which I am most drawn to.

This is the stage in my career I regret the most – not thinking of development as a permanent job. I very likely could’ve found a job as a junior engineer, or focused on freelancing full-time. I had a great time at this age with many friends and hobbies and shenanigans, but I could’ve incorporated my career also and progressed a lot quicker.

E-Commerce

In 2006 at 21 I moved to the East Bay area of California to join a friend’s online retail business. He had outgrown his solo home-based setup and rented a warehouse next to a small airport. Since we were friends for a while and often exchanged help and ideas for his business, he asked me to come be Employee #1.

Along with all the usual e-commerce tasks of logistics, customer support, purchasing, etc., he and I rebuilt the store platform from an off-the-shelf solution to a homegrown one. (Do NOT build your own e-commerce software platform unless you absolutely have to.)

Unfortunately I ended up pretty homesick, and moved back home near the end of the year. After a little more freelancing and another service industry job, I landed another online retail job, this time 100% focused on development. From then on, software engineering was my full-time career, that I’ve been doing ever since.

My next e-commerce gig was one of the more interesting ones, at least for the type of work. It seemed like every few months the owner would pivot to some new idea, and we’d have to build some custom functionality for it. Logistics integrations. Custom candle configurator. Pricing calculators. And for a while I was the only dev there doing everything.

Startup Life

In 2013 I joined a local e-commerce agency startup. Literally overnight – I emailed about the job opening on a Wednesday afternoon, interviewed that evening, accepted their offer in a follow-up email, and started the very next day. What a turnaround!

I was employee #5, and we all worked out of the founder’s condo. The East Side of Milwaukee isn’t Silicon Valley, but it was still startup magic. There is nothing like a small group of people all invested in growing a business, working next to each other without formality or bureaucracy. Shit gets done, and it’s some of the most fun I’ve had in this industry.

While most of our customers were e-commerce focused, I worked on custom applications or individual components. Two of my largest accomplishments were SaaS apps for employee recognition and a learning management system.

The startup eventually got a real office and grew to nearly 40 employees, which included a satellite office in Europe. A little more formality and bureaucracy, but still a wonderful job. I doubled my salary, and even received a minor partnership stake.

I left when the custom application side of the agency was removed to focus on e-commerce. I took with me a lot of experience in both engineering and business growth, and long-term relationships with colleagues I still enjoy spending time with 10 years later.

Solo Founder Failure

When I left the startup my family was living with my in-laws. With a fresh start, a savings runway, and the cheapest cost of living I’d probably ever have, I decided to give my own startup a shot.

In 2018 I started developing Nicheket, the “niche marketplace”. I’m a toy collector, and I wanted to create a marketplace that would compete with eBay but be focused on specific niches. Interested only in diecast cars? Visit that section and you can search, buy, and sell within it. Buy from multiple sellers in the same transaction with one payment. All the bells and whistles.

I spent about 10 months building the first production release. I registered the business, got a bank account, all the usual new business actions.

Except I never built a customer following. No customers knew about Nicheket. No marketing was done. Nicheket made about $20 in revenue.

After about 6 months of expecting customers to appear out of thin air (pro tip: it never happens), I admitted to myself I didn’t have enough runway left to stay full-time on it. After considering starting another type of business with my wife, I began searching for another full-time dev job.

Six Figure SaaS

After one bad employer that only lasted a month, I found a stable SaaS in the data collection ecosystem. They had a recent investment and were growing their engineering department by 2-3x.

After all of my experience at this point, I really wanted to break the six-figure barrier: $100,000+ USD in compensation. It’s one of those milestones that really helps you feel like you made it. At least to this millennial who had 15 years of experience already – those of you new to the field in the last 3-5 years might have this salary even at a junior or mid position.

Because of a bit of self-doubt and imposter syndrome, I didn’t feel like I was worth asking for much more. So, I asked for $105-110k as an initial range.

They hired me at $110k. I made it! 🎊

Later on, I learned from the hiring manager that one of the lead engineers messaged him in the middle of one interview saying “Can we just hire Aken right now?” So much for that self-doubt, eh?

Over the next four years I was a part of many major projects and features, CI/CD improvements, hiring processes, mid-level mentoring, healthy debates about code organization, and all the fun and nuance that comes with it. I was part of an engineering team who helped deliver the shift in our product to a more valuable B2B offering, that resulted in regularly increasing revenues.

Along the way, I also received a substantial pay increase as part of a market adjustment. Kudos to the organization for recognizing some of our turnover and hiring challenges were due to lower rates, and they made the adjustment for both existing and new engineers.

Fired Into Today

In September 2023, I was fired from that SaaS position.

It’s important to tell you that for many reasons. I want to be honest, relatable, vulnerable. I want to show that failure doesn’t define you, and you will always be better for it.

I was a great employee in many ways, and difficult in others. Those difficulties were a combination of traits that were incompatible with the company and the team (sometimes things aren’t a good fit, not really anyone’s fault), and skills which I need to improve on. Skills I intend to practice along with you, because you should never stop learning and seeking to improve yourself.

After taking time to process, grieve, and adjust, I found myself back in the same spot as 2018. A fresh start, a savings runway, and a new found desire to never be in a position to be fired again.

That brings us to today! I’m once again a solo entrepreneur, attempting to create one or more successful products that can sustain a full-time income as a founder and business owner.

Become a Senior Engineer is one of those products, and this newsletter is only the beginning. Please consider becoming a subscriber. Paid subscribers receive exclusive actionable content, and as part of the founding audience you can receive 50% forever. Check with your employer to see if you can expense educational content at no cost to you!

Subscribe now

And please share this newsletter with anyone you believe it would be valuable to. Sharing is free, takes only a minute or two, and it’s incredibly helpful for me. I’d be honored.

Share Become a Senior Engineer

Thank You! 😊

I appreciate you taking the time to learn a bit about my professional background. I’m looking forward to more opportunities to share stories and anecdotes, and to hear yours!

Hit reply and tell me your favorite part of becoming a software engineer, or one of your best career wins.

For more of me personally, you can find me on X at @AkenRoberts and on the web at AkenRoberts.com

#KeepSpritzing 💙

Aken

As a software engineer, you’re already reading various docs. Programming languages, frameworks, pipelines, SaaS tools, and more are all referenced on a regular basis.

When’s the last time you read all of the docs offered by a particular language or tool?

I know, I know – your language’s standard library docs are far too vast and dull to read. Let me explain how senior engineers consume documentation:

Start by, well, actually reading the docs!

I hope you’re already reading documentation. 🔎

Manuals and docs are there to help you use the software and tools to their fullest. If you are only skimming through documentation and jumping right into the code, well, I don’t ever want to assemble an IKEA bookcase with you!

Don’t make assumptions.

Don’t read the source code first (as fun as that is).

Don’t rely on third-party information that might be out of date.

Seniors ensure the information they’re consuming is relevant, accurate, and useful.

Okay, so I don’t mean all of the docs… 🫣

Reading literally every word of documentation for a language, framework, or tool is usually not the best way to spend your time.

Here’s how seniors make the most out of documentation:

Guides vs. Reference

Documentation usually consists of two types of content: guides and reference material.

Guides such as “Getting Started” are meant to tell more of a story; to walk (guide) you through the steps of understanding the software, a particular feature, concept, etc. They help you get from nothing to a finished goal (shout out to our favorite “Hello, World!”)

Reference material usually documents specific parts of the software. API endpoints, standard library functions, client libraries, that sort of thing. Reference material is read more like a dictionary.

Seniors know whether guides or reference material contains the information most likely to help with their needs.

Must Read Sections

Whether checking out a brand new piece of tech or returning to an old favorite, here are some must-read sections of documentation:

• Release Notes / Change Logs – Check out what’s new, especially if you’re using the product already. 💡 Seniors think: When was this last updated? What release cadence is used? Is there anything new that would be useful for us?

• Installation & Upgrade Guides – Some tools have strict installation requirements or complex steps. A tool you already use might have a new, more convenient way to install it. 💡 Seniors think: Can I install this in our existing stack easily? How difficult will it be to maintain?

• Best Practices – The authors and community that know the software best have already solved a lot of problems for you. Follow their lead. 💡 Seniors think: Is there anything we’re already doing that we can improve? What should we watch out for as we get started?

• Fundamentals / Architecture Concepts – Understand the core principles that the software employs, and the fundamentals that drive its development moving forward. 💡 Seniors think: Does this align with what our team is used to? What’s critical for us to know?

When Looking For A Specific Thing

Have a problem to solve. Docs are great at helping you solve problems, but they aren’t going to come up with the problems for you. If you aren’t sure what you’re trying to accomplish, the docs might be harder to read. They don’t usually have a plot, after all. Seniors come to the docs with a clear problem to solve.

Utilize search. Both internal and external (e.g. Google), search for the specific topic or issue you’re having. Google pro tip: include the documentation’s URL to search within the docs when they don’t provide an internal search:

how to refund a customer site:https://stripe.com/docs

Check for community comments. If the docs support it, see if the community has made any comments about the reference material you’re using. Communities are great at pointing out common gotchas or better options. If the docs don’t have community options, a quick Google should help.

Look around a bit! If you’re in a reference section that’s pretty dry, maybe looking at a function in the standard library of a language, take some time to wander around a bit! See what related methods do. You never know what bits of information might stick in the back of your brain and become useful later in your career.

I Still Don’t Get It

Still feeling hesitant about why you need to read so many parts of the docs?

Reading = Learning. Never turn down a chance to learn.

Learning = Experience. Okay, I’m stretching a little on this one, but hear me out. Part of being a senior means having experience. But not all experience needs to be raw, hands-on work. Knowing about a tool and what situations it fits well into can be equally valuable when a future scenario calls for it.

They know better! Even as a senior with 20 years of experience, I’ve been surprised when the Best Practices section has a tip for a situation I tried to solve myself only looking up reference material.

It’s practice. You’ll read documentation for the rest of your engineering career. Get good at it.

It’s part of your job. Of course writing code is the fun part of your job, but that doesn’t mean you can ignore the boring parts. Still better than meetings!

It can make you more useful to your team. The better you understand, the more you can be a reference to your teammates. Even if that means sharing a link to a piece of documentation, you have information that can level up those around you. That’s what being a senior is about.

Write Documentation When You Can

Senior engineers look for opportunities to document and teach others. It is a exercise in communicating with those without the knowledge you possess, which translates well into teaching engineers more junior than you. It also makes you appreciate good documentation and the effort that goes into it.

Modern code editors and integrated development environments (IDEs) come with a fabulous suite of tools to aid in writing and ensuring the quality of your code. Here are 15+ that will superpower your development today:

Syntax Highlighting

A staple of all good editors, syntax highlighting helps you quickly read and understand code. You’re probably using this already. If you’ve never switched beyond your IDE’s default color scheme, there are many great ones out there! I use a customized version of the default Oceanic Material theme on my JetBrains IDEs.

Code Analysis & Inspections

One of the most powerful features of IDEs is built-in code analysis and inspection. Automatically check your code for quality and adherence to standards, including but not limited to:

• Static analysis – usage errors, type safety, unreachable code

• Unused or deprecated code warnings

• Style guide adherence

• Typos

Keyboard Shortcuts

Fully customizable keyboard shortcuts let you perform most tasks without needing to move your hands away from the keyboard, including most features mentioned here!

There are even plugins for IDEs that will teach you the keyboard shortcut for a function you perform manually.

Refactoring

Refactoring means restructuring code without changing its original functionality. Moving or renaming parts of your code are common practice, but can be tedious if the code is already implemented. IDEs can refactor your source code and usages simultaneously.

Code & File Templates

Use a specific code template every time you create files of a particular type, such as class or test. Include headers, comments, copyright information, or necessary boilerplate.

Create brief triggers that expand into more complex code blocks that are commonly used. ifelse + tab automatically becomes a full conditional block.

Code Completion + AI

Who doesn’t like writing code faster? Code completion tools can help automatically fill in method calls, parameters, structures, and way more. Framework- and tool-specific plugins add autocomplete for your favorite stack.

Many IDEs now come with AI-powered tools to write entire code blocks based on prompts. GitHub Copilot is a notable example, with many others including plugins powered by ChatGPT. There’s even an AI-first editor!

Multiple Cursors + Text Utilities

Use multiple cursors to write or modify multiple sections or lines of text simultaneously.

Automatically adjust and format text such as reordering, case formatting (e.g. make all TitleCase), reversing,

Program & Test Execution

When configured, you can run and view the output of code and tests directly from your IDE.

Debugging

print debugging only gets you so far. Enable a debugging session in your IDE to pause at specific breakpoints, inspect the state of your application at any given point, step through function and method calls, and more.

Profiling

A wonderful companion to debugging, profiling helps you understand the performance of your code. Find where your code is slowing down, how an unexpected loop is occurring, and why all that memory is being used.

Pair Programming

Modern IDEs offer real-time code collaboration tools, allowing multiple developers to watch, follow, and code alongside each other. Combined with a video call or voice chat, remote pair programming is just as effective as sitting next to each other at the same computer.

Checkout JetBrains’ Code With Me and Visual Studio’s Live Share for two popular solutions, or search for what your IDE of choice offers!

Database & SQL

Connect to your database software and view table structure, list and query data, run explain queries, perform imports and exports, and more.

HTTP Client

While not as full-featured as a dedicated client like Postman, your IDE can probably make basic HTTP calls and make use of .http files. Make one-off calls during development to figure out a third-party endpoint. Use them for automated testing or CI/CD pipelines. Skip the cURL syntax and stay in your IDE.

Version Control, Diffs

Do you prefer GUIs instead of the command line, or simply like interacting with as few tools as possible? IDEs offer first-class support for Git, version control, and common workflows such as Git Flow.

Highlight differences between version control history, open files, or even a file and your clipboard using your IDE’s built in diff tools.

Are you using GitHub? Many IDEs integrate with GitHub offerings such as pull requests, issues, and releases. Create PRs, do code reviews, and mark off completed issues right from your editor.

Integration & Automation

Docker, CI/CD platforms, package managers, command line terminals, build tools… You name it, your IDE likely integrates with it. When it doesn’t, there’s usually a scripting option that allows you to hook into the workflow exactly when you need.

Graphical User Interface

Many developers enjoy working with a clean UI that provides all the information needed during development at a glance or easily accessible in one place. Color schemes and customization options help make the editor feel like home. Other modes like distraction-free and presentation offer optimal screens for specific tasks.

Remote Code

Harness the power of the cloud by editing and debugging remotely-hosted code as if it lived on your local machine, without sacrificing any IDE features.

Programming Language Support

Some IDEs are built to have first-class support for a specific programming language. They come set up with most tooling and integrations popular for that language. If you’re new to a language, getting an IDE meant specifically for it could give you a head start in writing efficiently.

Plugins & Extensions

Extend the default capabilities of your IDE in many, many ways using their plugin or extension ecosystems. Add autocomplete and tooling for all the languages and frameworks in your stack. Integrate with third-party platforms and applications. Simplify your workflow by allowing as much functionality as possible in one GUI.

Audience Questions

✨ 🆓 Answer any of these questions for a chance to win a free book!

What is your favorite IDE or editor?

What feature does your IDE have that you appreciate the most?

What feature do you wish your IDE had? (Have you checked? Now’s a great time!)

Did I miss a capability that should be listed here?

Hit reply to answer any and all of these, and I’ll highlight your answers in a future issue!

This is a conversation space in the Substack app set up exclusively for my subscribers — kind of like a group chat or live hangout. I’ll post short prompts, thoughts, and updates that come our way, and you can jump into the discussion.

To join our chat, you’ll need to download the Substack app, now available for both iOS and Android. Chats are sent via the app, not email, so turn on push notifications so you don’t miss conversation as it happens.

How to get started

1. Download the app by clicking this link or the button below. Substack Chat is now available on both iOS and Android.

Get app

2. Open the app and tap the Chat icon. It looks like two bubbles in the bottom bar, and you’ll see a row for my chat inside.

3. That’s it! Jump into my thread to say hi, and if you have any issues, check out Substack’s FAQ.

Join chat

Meetings quietly cost more time than scheduled. Engineers often need to context switch before and after meetings. You may be in the middle of developing an algorithm or hunting an elusive bug. Stopping that work prematurely for an unrelated meeting loses your momentum. After the meeting you need to figure out where you left off and what to do next. Or maybe you have another meeting on a separate topic right afterwards that you have to context switch into.

Engineers are paid to write and maintain code. That is your core value-add to an organization. Taking time away from that core mission should be done carefully and with intention.

Maximize the effectiveness of your time by attending meetings that are valuable to you and your team. In those meetings you should accomplish at least one of three worthwhile actions:

Subscribe now

🎓 Learning Something

Will the meeting contain a knowledge share of some kind? Improving your skills and capacities as an engineer is always valuable. That’s why you’re reading this newsletter, after all!

One caveat to learning is you don’t always need to learn directly from the source. Keep reading to learn how to decline a meeting you would still like to learn from.

🧑🏽‍🏫 Teaching Something

On the other end of learning is teaching. Do you have knowledge to share about a current project, a change at the organization, or a presentation on a new technique or piece of software? Senior engineers actively help by spreading knowledge and leveling up those around them.

🫵🏼 Making a Decision

Is there an outstanding question needing answering, or a direction to be set? Make sure you’re available to remove any confusion and blockers for your team.

Assessing A Meeting Request

Now that you know what activities make your presence in a meeting valuable, how do you know which meetings to attend?

• Ensure the meeting has an agenda. What is the intention of the meeting? What is the desired outcome?

• Clarify your role. When you aren’t sure how you fit into the agenda, ask the organizer or another colleague how you can contribute.

• Check your calendar and workload. What else are you doing that day? Is the meeting at a weird time? Do you have a difficult task and want to minimize distractions and context switching? Meetings can work around your schedule.

If you aren’t learning, teaching, or making a decision, your time is better spent on other tasks. Decline the meeting.

How To Decline a Meeting

You’re going to love this:

Just decline it, with a short message why.

That’s it! People vastly overthink the repercussions of not attending a meeting at work, and feel obligated to attend everything they’re invited to.

The only rule: have a good reason why. “Meetings suck!” isn’t going to win you any influence at an organization (even though a lot of times it’s true). Your reason should explain why your time is better spent elsewhere.

Examples

I am a bit behind on my current feature development, and would like to maintain focus on that so I can meet our sprint goals.

The meeting might be valuable, but sacrificing your current goals for the meeting isn’t worth the trade off. You can always ask for an update after the meeting with any learnings or decisions.

Amit and Jarrod are already attending, they’re more than capable of getting you up to speed without me.

Do you really need everyone invited to accomplish a goal? Share the responsibilities of your team. You aren’t required to learn or decide everything. Teammates can fill you in or own that part of your team’s knowledge.

Bonus tip: As a senior, you can protect the time of your teammates by “falling on the grenade” and handling meetings on their behalf.

I’m not sure where I fit into this meeting. Please add to the itinerary and invite me again if appropriate.

This may be a clarifying question via company chat or email first before an outright decline, but the goal is the same: if you aren’t sure what value you have by attending a meeting, don’t go.

My Tuesday is really busy and I have an important task to do that day. Can we shift this meeting to Wednesday?

Most things are flexible, just ask.

What if I have to be there?

What if you want to decline a meeting but someone has specifically requested your attendance? Clarify the value. The person asking for your attention needs something, you should understand what that is. Outright declining leaves them feeling unimportant and makes you look unhelpful or unreliable, and they still have a problem to solve.

What if the meeting request comes from a person of authority, like your boss, and you feel obligated to attend? Like other scenarios, start by clarifying the value. Is it your CTO giving an engineering-wide update about something? Missing it might not be a huge deal – you can be caught up after. Is it a one-on-one meeting about your performance? Very valuable, must attend.

What are your reasons for wanting to decline? Are you swamped with work and worried about missing a deadline? Let them know.

Any time you attend a meeting you feel obligated to and it doesn’t end up being valuable to you, share that feedback. If you’re not sure the meeting was valuable, talk to a more experienced teammate that was there with you. Ask them what value they found, what takeaways they believe were valuable to you, and help you contextualize the experience for next time.

Meetings still suck. What else can I do?

Most likely, your growth into a senior engineer will be accompanied by more meetings. What else can you do to optimize meetings and your productivity?

In future issues of Become a Senior Engineer, we’ll discuss topics such as:

• Making meetings as effective as possible for all attendees

• How to listen and observe in meetings

• How to keep meetings on track

• How to avoid having meetings in the first place through asynchronous conversations

Subscribe now

What did you think of this content? Do you have any questions or items I can clarify? Did you try any advice here and have success or difficulty? I’d love to hear about your experiences! Reply to this email and share your story. 📢