It always takes longer than you expect, even when you take into account Hofstadter's law.

One mistake that smart junior engineers tend to make is under-estimating the amount of time that a project will take. It's not that more experienced engineers are sandbagging their estimates, but after gaining experience and seeing how hard-to-predict pitfalls can lay ruin to the best of plans, they learn to bake in an educated amount of buffer. This skill comes from better understanding of both the problem domain and the human elements of the project.

When estimating it can be easy to just consider the technical challenges, but often organizational elements of the project can cause serious delays. When estimating, make sure you account for delays in gaining access to systems, getting responses from other involved parties, or other inflight projects that might compete for resources or delay launches for the sake of stability.

Stakeholders would rather have a reliable delivery date than hear an overly ambitious estimate that needs to be extended later in the project. Trust that things will probably take longer than you initially think.

"Dude, sucking at something is the first step to being sorta good at something" - Jake the Dog

A huge part of being a software engineer is trying and learning new things. Inevitably, you will be bad at many of these things the first time you try them. Maybe you botch a presentation to senior leadership, maybe the first time you lead a project everything goes sideways, maybe you just don't get how a new tool works.

This is how it's supposed to be! If you're not failing, you're probably not growing. Try to fail quickly, learn from your failures, and then try again. If you never do work or try technology outside your comfort zone you'll never grow, which is very problematic in an industry that changes constantly.

So go ahead, be bad at it at first.

But how do you know what "perfect" is? If your feature isn't released yet, you don't really know how users are going to use it. You'll never know less about what your project needs than right now, so how can you know everything you need to do to make it perfect.

Get it done. Then improve it. And improve it again. Ship something small first. See how it holds up to real-world use. See what makes it hard to work on. See what tools/tests/metrics you wish you had.

Before you can optimize you have to know what matters and it's hard to know what matters until your code touches the real world.

Code is just a pretty good tool for many of the problems you're likely to work on. Unfortunately code is where bugs live.

Every line of code you write is a place where something could go wrong. It's a little bit more complexity in your applications that people will need to understand. It's weight that might need to be moved around in a future refactor or feature addition.

Writing code is fun and it can be tempting to build for the sake of building, but always consider the tradeoffs that come from growing your codebase. Especially with AI tools that make it even easier to produce more code faster, you need to be mindful of the risk that comes from bringing more code into your organization.

Writing code is obviously going to be a big part of your job. Just be smart about it!

Your project shipped late. Or it was really buggy when it did get shipped. Or maybe it just didn't work out and got scrapped entirely.

That sucks. But don't waste the failure.

Do something with that failure. Failure is a valuable piece of information. It can be used to figure out what assumptions were bad so that you can update your judgement for next time. It can be used to show you where weaknesses are in you and your organization.

It can be tempting to focus entirely on external or systemic reasons for your failure, but try to focus on the things that you have control over. Can you improve some of your own skills? Can you better manage expectations? Can you push to change processes on your team?

Avoid overfitting your learnings, but take some time to really understand why things went wrong. Maybe this is part of a formal team postmortem or just an exercise you do yourself, but don't waste a good failure.

Ease of understanding is part of the functionality of a solution. Code is not static. Codebases will be read and modified by many people over their lifetimes and the harder it is to understand the code, the harder it is to work with it.

It is much more impressive to see a solution to a complex problem that is easy to understand. This is the true mark of a senior engineer. A clear solution doesn't just solve the immediate problem, but builds a robust, easy to work with system.

Being "too clever" can include being unnecessarily dense in your code. Brevity may be the soul of wit, but that doesn't mean everything that can be a one-liner, should be. Code is cheap. Take a few extra lines and make it as easy as possible to understand what is happening.

While a clever solution might come off as an impressive trick a clear solution will always be more valuable.

Motivation alone isn't enough to get through non-trivial things. You need to set good habits. Habits externalize your accountability for things that are important to you.

Rather than hoping that you'll be motivated every day to work on learning that new language, just know that at 9:30, every day you put half an hour of work into it. Then there's no decision to be made or motivation to muster up. Put it on your calendar, if you must!

You're not always going to be motivated and that's ok, but you can set good habits to keep you going when motivation wavers.

Maybe?

Remember, careers have speed AND direction.

Going quickly toward something you don't want doesn't help you and can often be demoralizing. Think hard about what you want and seek out opportunities that will help you understand and grow in those areas.

What if you don't know exactly what you want yet? Well, then take random opportunities! Hop on whatever projects come up and learn something. But don't just learn new skills, learn if you like the work or not.

Obviously you won't be able to pick and choose every project you work on. Some work is just part of the job, but when you do have agency over your work, know how to use it.

Figure out your ambitions and you'll be able to tell the difference between opportunities and obligations.

Maybe. But doing the work without building relationships can put you at a serious disadvantage.

Don't use the stereotype of the socially awkward programmer to justify working in isolation. Don't fall into the outdated trope of the surly engineer who works "brilliantly" as a lone wolf. In order to know the right things to be working on, you need to keep your head up. In order to get people to recognize and advocate for you, it's important to get to know and care about other people. Listen to them, understand their work and challenges. Be helpful when you can. Be supportive when you can.

Building relationships is not political posturing. It's not an unsavory way to get special treatment. It's a fundamental part of human collaboration.

Do not underestimate the power of caring about others in a way that makes them care about you.

You start writing your internal blog post about how you "shipped X using Y technology", but why should people care that your project shipped? Why was it a good use of your time to solve that problem?

When talking about your accomplishments (to your manager, in a public post, in a self evaluation, etc.) focus less on what you shipped and more on why you shipped what you did. Did your work unlock new business? Did it save money by making things more efficient? Did it help the organization avoid legal issues by complying to regulations? Did it fix a bug that 100s of customers complained about?

If you can, support your why with graphs, data, and testimonials. The evidence makes your story stronger.

Remember, as an engineer it's not what you do, but what your work does.

• scope (how many things need to be done)
• timeline (when you can complete everything by)
• effort (how much work you and others can put in)

If a new feature is added to a project (the scope is increased) then the project either ships later or more work is done in the same amount of time meaning more hours or more people (and more people might not even help). Often times deadlines are hard to move and a so more features often means more demands on each engineer.

Sometimes this is necessary. An important project might require a temporary big push from everyone, that's just part of the job. But it shouldn't be the first tool teams reach for. Instead, when new requests comes in, look to adjusting scope first.

Reaching for increased effort or pushed timeline is often a crutch to avoid the important work of prioritization. There will often be lots of good ideas or features that you or others would like to see shipped but unless you're prioritizing well you can end up putting in a lot of effort without getting much more impact. This is because prioritization forces you to think about why you're doing work and how much impact it will have.

Having this common measure of impact helps facilitate conversations between product and engineering teams. Engineers can estimate the amount of time a new feature might take and have a conversation about whether or not the impact is worth it, rather than just adding more hours to their workday just because more work could be done.

Being productive isn't about doing more work. It's about doing the right work. Prioritizing ruthlessly is a way to protect your valuable time while making sure that you are as impactful as possible.

You need to be on the lookout for good new problems to solve. It's good for your career to drive this type of work and ultimately this is how you'll both increase impact and increase your own satisfaction.

But what makes a good problem?

Richard Hamming wrote a great bit on choosing good problems in science and picking a good software problem is similar. You want something important and approachable.

Knowing what problems are important is a skill in itself. You have to understand what your organization values and you need to be familiar enough with the systems to know where the shortcomings or opportunities are. It's your job to connect these values with gaps.

Figuring out if the problem is approachable is also a function of familiarity with the system and confidence in impact. Most software problems are not unsolved scientific problems, but having an understanding of effort vs impact will help justify your problem as worth tackling.

Look for things that nobody else is really paying attention to. These areas will come up as you gain deep experience from working on specific parts of your system or from taking the time to gather new data that others haven't been looking at or even just talking to people outside your domain to understand their pain points. Use this to get a sense of effort vs impact so you can justify your work. Just keep an eye out and you'll run into all sorts of good problems.

But critical feedback can be harder, particularly from a manager or someone with authority. When you receive critical feedback separate out the feedback you agree with and the feedback you don't agree with.

Now you have two actionable buckets of information to work from.

The feedback you agree with can provide clarity on areas to work on. Work with others (perhaps the person giving you the feedback) on the best ways to improve in these areas.

For feedback you don't agree with you have three options: change your mind, change the other person's mind, and do nothing.

You might talk with your manager or other team members about the feedback and discover there is some validity to the critique and now you have more feedback that you agree with. See earlier paragraph.

Maybe the feedback you received was based on incomplete information, your manager needed to better understand your impact or contributions. It's possible that with discussion and data you can bring people around to seeing things your way. But be prepared to present a strong argument, not just an emotional one.

The last option is to do nothing and ignore the feedback. This is rarely the best option, but it is an option. You should understand well the consequences of this. Will it affect your overall performance review/compensation? Will it require you to change teams or even jobs?

Getting performance feedback can be tough, but figuring out how to make it actionable can be the best way to handle it.

Communication is obviously a fundamental skill and that is never more apparent as when you are changing expectations. Often changing expectations means telling people that a feature will be shipped later than previously agreed upon or some desired functionality just won't be possible. Nobody wants to tell someone bad news and it can be hard to do.

But it's worse to put it off.

When you're changing expectations it is incredibly important to let people know as soon as possible and with full clarity. As soon as you see risks coming up, inform the people that will be affected by it. Nobody wants to be blindsided at the 11th hour when you tell them that the previously agreed upon ship date won't be hit.

And be clear about what you're saying. Avoid ambiguity and anticipate questions. Don't say things like "I'm worried about our delivery date". Instead say things like "Given our improved understanding of the complexity of this work, we should push the ship date back by two weeks". This is clear, gives context, and gives a description of the new expectations.

Don't avoid or delay important communications. Even if it's not what people want to hear, they'll appreciate hearing it sooner rather than later.

"Happiness" as a career goal doesn't necessarily mean that everything you do at work will be something you love. There will, of course, be unpleasant things (does anybody actually like being on call?). But the things that are unpleasant should be reasonable trade offs for opportunities that you value.

Sometimes things will be hard, but hard work that leaves you proud and satisfied is a good path to happiness.

Happiness as a career goal can also mean saying "no" to good opportunities. If something might be good for your job but bad for other parts of your life, considering overall happiness can help you figure out if the tradeoffs are worth it.

Career happiness isn't as simple as avoiding trouble or pursuing advancement, but at a fundamental level it is the goal.

Hopefully you've learned something.

Pay attention to how it feels to get closer to your goals. You now know more about yourself and more about what the realities of your goals. Use this information to make course corrections. Maybe you've been working to move from an IC to management role but it turns out you miss coding more than you thought you did or as part of some performance work you develop a deep interest in database optimization. Take these learnings into account and consider tradeoffs and new interests.

Don't just work hard on something because it was your dream 5 years ago. This is a recipe for a miserable career. As you learn, you grow. Expect to be a different person with different goals as you grow. Revisit your goals and be honest with yourself as you go.

Slow down a bit.

Take a minute to think about the best way to work towards your goals. Make sure that your approach is incremental, actionable, and accountable.

Incremental steps are small. You can take them right away and see if they're working (and if they're leading you in a direction you want to be going.)

Creating actionable steps often involves clarifying vague intentions. Instead of saying you want to "look for leadership opportunities", make it a goal to ask your manager about leading the next major project. It should be easy to figure out if you've done the work or not.

From here, make sure you can hold yourself accountable. This is sometimes as simple as just sharing your plans with someone else like a mentor or manager. Setting self-imposed deadlines can also keep you accountable to these plans.

By taking a little time to think about how you will approach your goals you'll end up much more likely to work on them in a productive way.

Know what you want.

And why.

In order to set goals and hope to be happy with accomplishing those goals you need to know yourself and what really motivates you. Start thinking about what you want to do. Maybe that's become a manager or start your own startup or be the most technical person in the room.

But take some time to think about why you want those things. And be honest with yourself. Does running a company really seem like something you want to do or does it just sound prestigious? Do you want that FANG job because you'd enjoy it or does it just seem like it would pay well? (By the way, it's ok for "make lots of money" to be your goal. But just be honest with yourself about it.)

If you want to set goals that will be worth working hard at, the first step is really understanding what you want. And why.

It's your job to figure out where you want to go.

It's your mentors job to help you get there.

Here's a rough framework for thinking about that:

Step 0: Know what your goals are and why.

Step 1: Figure out how to work toward those goals. (Your mentor can help with this.)

Step 2: Do the work!

Step 3: Revisit your goals to make sure you still care about them.

I'll do a few follow up posts to dig into some of these steps more, but the important thing is to think about both the "why" and the "how" around your goals when working with a mentor.

For any reasonably complex system it can be very hard to understand everything so it's good to know who in your organization can be a resource for the areas you don't know well. You can save yourself hours or days by knowing who can give you a quick overview of a new-to-you system or provide answers about an unfamiliar codebase.

How do you find these domain experts? In larger organizations, there might be some formality to these designations. Documentation might list system owners for each system. Teams might have discrete areas of ownership that make finding a point of contact pretty straight forward.

In other situations you may need to rely on more implicit indicators of expertise. Look for people who are active answering questions about certain topics in Slack. Check the commit history for code related to these systems. See who's given a "lunch and learn" talk about this area of the product.

What if there's nobody to ask? This can happen, especially in smaller organizations and it is often an opportunity to invest some of your time in learning about this domain and establishing yourself as the person to ask.

This inclination and ability to seek help is what gives collaborative engineers the advantage over "brilliant lone-wolf" people, so make sure you know who to ask. And ask them.

Being visible is the very similar to selling yourself but in a more implicit way. If selling yourself is about explaining to others how valuable your work is, being visible is about helping others form their own ideas about how valuable you are.

So how do you increase your visibility? Get out there! Answer questions in Slack rooms. Review PRs. Give presentations about your work. Be generous with your time in ways that help others. Creating your own content or speaking at meetups and conferences can increase your visibility outside of your organization, too.

As a maker it can be hard to balance getting things done with being available for others, so it can be helpful to schedule your "visible" time. Put events on your calendar to remind you to review PRs or check on support issues.

Make sure you're visible in impactful ways, not just performative posting and you'll see your reputation and career grow.

Wrong.

Boring is awesome.

Boring means it works as expected. Boring means a lot of the obvious problems have been solved already. Boring means people have already written a wealth of blogs and libraries around this technology so all that's left for you to do is build what you wanted to build in the first place. And odds are, by the time a technology is boring lots of other people will have used it to, so it'll be that much easier to get other people up to speed on your project. Boring technologies let you focus on what's interesting about what you're building.

There are, of course, reasons to try new and uncommon technologies. There are datastores that might be really well suited for your usage patterns. You might have deep expertise in a certain uncommon language or framework. But use your weirdness budget wisely. And default to boring.

A manager's motivations are likely a mix of two things; expectations passed down to them from higher up and their own values.

By understanding what's being asked of them (which is likely related to what the company values) you can understand where they're getting pressure and how that will get passed along to you. By understanding this you can prioritize and communicate your work so that it is easier for them show progress in ways that resonate up. Reducing pressure on your manager often makes your own life more pleasant.

Of course, managers have their own values as well. It's important to understand how they judge work and what puts them at ease. Are they excited about getting into technical details? Do they like to see detailed data to support results? Figuring out their personal value system can help you work and communicate in a way that causes less friction.

When someone is asking things of you, make sure you understand what is being asked of them and what they care about so you can work with them, rather than against them.

When talking through plans for a project, take some time to be pessimistic. Think about what can go wrong. Are there unknowns in the implementation that could prove to be big time sinks or high risk? Are there dependencies on other teams that could fall through? Is it likely that someone will make major changes in shape or scope while the project is in progress?

Imagine something went wrong with the project and try to predict what caused it (this is sometimes called a "premortem"). It's better to bring these up early than to pretend that everything will probably be ok. The "productive" part of being productively pessimistic is then taking some time to work out ways to handle these potential problems.

Don't just be needlessly negative about things, but don't let yourself be blindsided by problems you could get ahead of with a little pessimism.

Peacetime is when there are no eminent existential threats to the business. You'll often see more freedom to explore new things, invest in longterm bets, and have more leeway to indulge in pet projects. During times of peace and prosperity it's often beneficial to be a little less focused and try a few higher risk ideas that may or may not pay off. You'll see more investment in growth and general happiness.

A wartime company is under threat. Maybe there's a major competitor breathing down your neck. Maybe a shift in market conditions means that you could get left behind if you don't push hard. Wartime is all about focus, execution, and winning in order to survive. If run well, a wartime company will be VERY clear about its priorities, but this can also mean that projects may change quickly in order to best focus on those priorities. There is also a lot less room for anything that doesn't relate to near term wins. Things like open source contributions or quality of life improvements may be deprioritized. Even some company culture things may take a backseat to wartime focus. A common phrase that we heard during wartime at a company I used to work at was "Nobody worries about office snacks during wartime".

If your company is in wartime, it's important to pay attention to what the single focus is. You may need to realign your work (and how you talk about your work) to make sure it's related to those goals. Anything not related is at risk of being cut.

Companies don't stay in wartime (or peacetime) forever. Make sure you know where you are and how best to navigate the current situation.

So much about the practice of software engineering revolves around building software that we can read and understand. Unless you're just creating a quick script or throwaway tool, the readability of your code is important. Additionally, in most professional situations you need to not just be able to read your own code, but code written by others.

While many software engineers like to think of productivity as involving lots of code writing the reality is that fixing bugs and adding new features often involves a lot of code reading before anything can be added or changed (or, if you're lucky, removed). You need to get good at following the flow of functionality, executing code in your head, and building mental models of the system you're working with based on that reading. It can help to do more "active" reading, which might involve actually running the code and writing things down as you explore.

Reading code is also a core part of doing code reviews. If you can't read and understand someone else's code it's impossible to give good feedback and spot potential issues. Just as reading more books can increase your reading comprehension of prose, reading lots of code increases your software reading comprehension, so reviewing code can be a great way to improve your code reading skills.

As we see the use of AI generated code increase, the human skill of reading code becomes even more important. Code reading is a foundational skill that will always pay off (and be sure to consider your fellow reader as you write your code).

If you want recognition, career advancement, job security, all those good things, it's important to really understand what your organization values. Sometimes this will be very explicitly stated and it will be straightforward to make sure you tie your work to company goals. Other times you'll have to pay attention to implied values. Look at what work gets the most recognition and figure out why.

Sometimes this can be frustrating when work you value doesn't seem to be valued by your organization. Here you have a few options: You can choose to continue working on what you value and accept whatever consequences come from that. You can change what you're doing to better match what is clearly valued. Or you can advocate for your work. The best way to do that is to show how your work really does serve the organization's values.

If none of these are an option, you might have to find a new place to work that better aligns with your values.

Working hard without understanding the priorities of your organization is a great way to do a lot without getting much recognition or reward. Look up frequently and make sure you understand what is valued.

Good. Now take a second look at that list and make sure that you're not just setting up guards to prevent the exact same problem. It's important to make sure you don't make the same mistake twice but you want to make sure that your solutions are pragmatic.

You want to avoid solutions that are too narrow; they only address the very specific problem you just encountered and solutions that are overly restrictive; they overreact to the problem by making to hard to do anything.

Very specific solutions are often "cover your ass" work. They end up introducing complexity without being as effective as understanding the root cause of the problem and coming up with general solutions.

Overly restrictive solutions can end up producing process debt. It's tempting to lock things down with stuff goes wrong, but rather than putting up roadblocks to prevent problems, take the time to really understand where the gaps in your process are that can allow mistakes to get shipped. Make smart tradeoffs between safety and speed.

Things going wrong are an opportunity to make improvements. Just make sure you're making the right ones.

Teaching, while obviously beneficial to those being taught, has the additional advantage of being a great way for the teacher to learn as well. When you teach, it forces you to clarify your own understanding of the subject matter. This helps you build better mental models for yourself around the topic.

When teaching you can't assume the person you're working with has the same foundational knowledge you have, so your are often required to build up knowledge starting from more fundamental concepts, which can aid your own clarity.

Finally, answering questions is a great way to sharpen your own understanding of concepts. A students questions may even expose a blind spot in your understanding and working out the answer together can benefit you both.

Even if you don't consider yourself an expert in a subject, offering to teach can be a great forcing function to deepen your understanding of a topic.

This reflects the thinking that the only things that are impressive are the things we can't do yet. It can be easy to fall into this trap when looking at your own skills.

It's easy to forget what used to be hard. We normalize our current abilities and quickly assume that if we can do something it must be trivial. But this misses the value of all the skills we've developed. Software engineering is hard and sometimes the best way to avoid becoming demoralized is to focus on your growth.

So when you're doing something that seems well within your skill set take a moment to think about a time in your career when a similar situation would have been much more challenging. You'll often be impressed by how far you've come.

Resist that instinct.

Maybe there's a chance to work on a project that seems really cool, but you're unsure if you have the technical chops to pull it off. Maybe there's an opportunity to speak at a conference but the idea of getting on stage in front of that many people is terrifying. If it really seems interesting, just say yes. You'd be surprised how much to can figure out once you have to do it.

Often the anticipation makes these interesting opportunities makes them seem scarier than they actually are. Scariness might even be a good sign that something is worth trying. Pushing yourself like this is a great way to build confidence, making the next big scary/interesting thing that much easier to do.

In a way, this advice is a good partner to figuring out what doesn't matter. You say "no" to things so that you have room to say "yes" to the right things. So say "yes" to the interesting things, you'll be happier you did.

But still nothing is being done about the noisy alerts.

A more active response to this problem could be picking an alert, trying to improve it, and sharing the change with the team as a first step in fixing things. If you don't have the capacity to do the work yourself you can still tend towards action by creating a ticket with a detailed description and working with the right people to get it prioritized.

This also applies to how you might reply to other people's requests. If someone asks to meet with you on Thursday and your response is "Sorry I'm busy on Thursday", you have to go through another cycle of that person guessing a new time you might be free. A tendency toward action in this situation might be to response with "Sorry, Thursday doesn't work for me. How about Friday at 3:00?".

Pay close attention to your responses to problems and make sure that your actions move things forward.

Gumption traps are those little demoralizing problems that stand in the way of your actual goal; the one person who can answer your question is current on vacation, your dev environment is messed up in some way, CI is broken. Things like this can completely sap the momentum you have when trying to solve problems. Sometimes gumption traps come in the form of "hang ups", personal views that can stand in your way; "this is a stupid language to build this in", "I should be smart enough to figure this out quickly", "If this legacy code wasn't such a mess, this would be easy".

So how do you prevent these things from completely derailing your work? The simple answer is to build more gumption, but it's not an easy answer. Sometimes you'll need to step away from a problem for a bit and regain perspective. Sometimes you'll need work to come to peace with things about your system (or yourself) that just can't be changed right now. Sometimes you'll just need to focus on the big picture and recognize that all these annoying stumbling blocks are just part of getting non-trivial work done.

Honestly, there's no easy solution to gumption traps, but being aware of them can help and building gumption is one of the most useful things you can do as a developer.

"Process debt" is similar. It involves working in ways that involve trade offs that benefit present needs. One of the most common artifacts of process debt is recurring meetings. Someone may have set up a frequent recurring meeting when high bandwidth communication was important for a certain stage of a project, but nobody ever thought to cancel the meeting once that need was no longer there. Don't just keep that meeting on your calendar out of momentum.

Process debt can also come from responses to past problems. Perhaps after a streak of bad deploys, your team instituted a rule that no code could go out until a manager approved the PR. Maybe this rule is still helping, maybe it isn't. The important thing is to revisit and evaluate the costs and benefits of this policy. Rules don't just exist to be followed, they need to serve the team.

Make sure you're always paying off process debt by questioning and evaluating if your processes are still serving the team.

'No' is an important word for anyone trying to accomplish anything. At work (and in many other parts of life) there will be no end to the things you're asked to do. The only way to really move important things forward is to determine what isn't important and deprioritize it (note: "deprioritize" is typically just a nice way of saying "Nope, I'm not going to do that").

How do you figure out what matters and what doesn't? Look at what the goals are. If you're working on a really tight deadline, maybe now is not the time to introduce a linter to your large, aging codebase (even if linting is a good idea!).

In general, make sure you understand what your organization values and what you value. If you're working hard on a task that doesn't align with either of those things, think hard about whether or not it's the best use of your time right now.

Often when trying to come up with a plan for a complex problem groups can get stuck in the stage of tossing out ideas. It's great to spend time doing this, discussing the pros and cons of different approaches, but at some point you need an agreed upon plan and start executing.

A good way to get to the point where you have an actionable plan is to just clearly state one as a starting point.

For example, if the issue is "We need to adjust our latency monitors to be more actionable" you can come back with "Ok, at the end of the week I'm going to set the monitors to page on an average latency over 800ms unless there are any issues with that".

The point isn't to hold your ground and insist on your plan being the final plan, but to establish a default plan that will be executed on unless people make other suggestions. This changes the thinking from ideating about possible solutions to refining an existing solution which feels more tangible and can encourage more timely feedback (because you've established a deadline for when the default action will take place).

It's easier to discuss adjustments to an established plan than to come up with a new one from scratch, so just start with something reasonable and use as a starting point to get things going.

So how do you get good at learning? While this is a huge topic that fills entire academic disciplines there are some basic things you can do. When approaching an unfamiliar problem or codebase you can approach it like a scientist; take notes, make hypotheses, test them.

Get good at forming questions and use what you already know to compare and contrast with the area you're learning about. If you're trying to better understand NoSQL databases, think about what you know about traditional SQL databases and figure out what is the same and what is different. Use coworkers, online resources, or even chatting with AI agents to confirm your understanding of these new concepts.

This is where learning becomes a virtuous cycle. The more you learn, the more information you have to use as a basis for analogy and contrast.

By it's nature, software development involves encountering a lot of novelty through unique problems and ever-evolving technologies. Being able to approach a new system and learn enough to make good decisions about it is the foundational skill of the field.

There is only so much any individual can do with their time to create impact. It helps to prioritize well, but you're only one person. At some point to best way to increase your impact is to make others better.

This can be done in many ways. You can build tools that make it faster for your team members to solve common problems. You can write documentation and playbooks to remove knowledge silos.

Perhaps the most effective way to empower others is to help them grow. This can be as basic as sitting down to work through a problem with a coworker or as involved as formally mentoring someone throughout their career. Especially as you become more senior, more and more of your time should be spent making others better. It's the only way to scale your impact beyond your limitations as an individual.

Know what industry trends people are thinking about (AI? Crypto? Whatever is happening now that makes those things look dated?). These things shape the way your organization directs itself and having a general awareness of them is useful when they come up. If you have specific languages, frameworks, or tools that you work with frequently or just enjoy, it can be helpful to know what changes are being made and what new features are coming out.

Find a way to stay up to date that works for you. Maybe it's just looking at Hacker News while you drink your morning coffee. Maybe you've found a good digest newsletter that you like. Find something that works for you. Don't feel like you have to obsess over minutia, just keep a sense of what's going on.

Many have us have come to expect that when we want information or an answer we should be able to get it almost immediately. With email and Slack and other means of communication on everybody's phones at all times nobody ever has to be out of reach. These can be great tools but their existence means that you need to set your own boundaries.

Especially as a software engineer you need chunks of uninterrupted time to get things done. It's more than ok, it's critical to be able to put up a Slack status that says "Slow to respond, coding" if you actually want to get non-trivial work done. It's ok to not respond to non-emergency after-hours messages until the next day. Reasonable boundaries like this encourage better project planning that can't be held up by adhoc needs, plus it sets a much more reasonable working culture. This can be especially important for those who work from home as the lines between being "at work" and not can be blurry.

Obviously if you are on call or a real emergency pops up, making yourself available is important. But set your boundaries and do your best to hold them. Be unavailable. Sometimes.

Whether you like it or not, an important part of getting recognition for your work (and promotions!) is making sure other people know about what you've accomplished. You can't just rely on the quality of your work speaking for itself or expect others to just see how much you've done.

This needs to be communicated both directly to individuals (i.e. explicitly listing out your wins to your manager during a performance review) and broadly to your team. This broad communication can be as simple as posting a recent win in a public Slack channel or as formal as presenting a project to at an engineering team all-hands. The more senior you are, the more important it is to expand your audience and scope of impact.

While it can be tempting to write off self-promotion as bragging, it's important to remember that you understand your accomplishments better than anyone else and communicating is as much a part of your job as coding, especially as you get further on in your career.

But at least it's not your fault, so you might as well just have a pint and wait for this to all blow over, right?

You could. Or you could use this disaster as an opportunity to polish your incident handling skills. Figure out where the problem is being discussed. Understand the actions being taken to understand and solve it. Get involved. Maybe this means gathering information. Maybe people need help communicating and organizing efforts. Maybe you know something about the system in question that will speed things up or you can help push a fix faster.

Your involvement can be anything from taking command when you have the context to help mitigate the issue faster to taking notes so that the details are available for the RCA.

Never waste a good disaster.

A repetitive task might be something like updating a value on a few thousand records in your database or hitting and endpoint with very specific parameters over and over again. Something generalizable might a script that updates a specific customer's billing date, but if you just change it to accept a few parameters you could update any customer's billing date with it.

If you see something repetitive, automate it. If you see something generalizable, generalize it (and then maybe automate it). This way you can take the scripts and ad hoc tools you make to solve your specific problem and turn them into tools that other people can leverage.

This can be as simple as sharing some cleaned up scripts in a team folder or as complex as building new standalone data exploration and manipulation tools based on your initial work. Always make sure that your making the right time investment/payoff decisions when deciding how polished your new tools should be.

With just a little extra thoughtfulness you can turn your one-off work into something that has even greater impact.

For many people it can be hard to fully disconnect when you are taking time off. With Slack and email and other things always there, it can be tempting to "check in" or answer a quick message. Often then comes from the well meaning motivation to be helpful to your coworkers.

But when you're taking time off, you should fully take time off. Time off is valuable. It helps you recharge and give focus to parts of your life outside of work. It's an important tool against burn out and something your are entitled to as an employee. Mostly away from work is not the same as fully away from work.

Also, it is good for an organization to learn to work around bottlenecks. If things grind to a halt because you aren't checking Slack for a few days, that is a bug in the system and should be fixed. Any organization that cannot function well with one person missing is not a healthy organization. By being truly unavailable, you help the organization discover and correct these points of failure.

Never feel guilty for taking off time that is yours. Being truly on vacation when you're on vacation is ultimately best for you and the organization.

Choosing good tools and developing skill with them is absolutely useful, but don't lose site of what the tools are for; building good software. At some point optimizing your Vim config or buying another mechanical keyboard isn't a productivity boost, it's just recreational. And that's fine!

There's nothing wrong with finding enjoyment in tweaking your setup. If you spend a lot of time using these tools it's nice to enjoy and make the most of what you use. Just learn to recognize recognize the difference between legitimate productivity improvements and recreational enthusiast improvements. Try to spend time on things that help you reason about your code over changes to how you write your code.

If you love the sound of Cherry Blue switches typing into a fully customized Vim setup running on Arch Linux, more power to you. Just don't confuse customizing your window manager with getting more done.

No.

Your job is to solve problems. Understanding software is one of the skills you use when solving problems.

In a lot of situations, by the time a problem gets to you writing code might be the best way to solve a problem. A new feature needs to be built. A bug needs fixing. But sometimes if you take the time to understand the problem, not just the ask, you can solve the problem in other ways.

Maybe rather than building a custom internal tool for data, you can show people how to use off the shelf tools to query for what they need. Maybe the API doesn't need a new endpoint, it just needs better documentation. Maybe the problem isn't as important as previously thought and you don't need to do anything.

Remember, all the code you write has to be maintained, so think about the best way to solve the problem before just building what is asked.

Helping employees advance is an important part of a manager's job, but it's not the only thing on their plate. If you really care about making progress you have to help people help you. If you're up for a raise or a promotion, do the research on what your company's leveling rubric looks like and provide your manager good supporting work to build your promo packet (you're writing down your accomplishments, right?). Look for projects that interest you and ask for them, don't wait for someone to recommend you for them.

In a healthy work environment, you'll have people supporting your growth, but don't expect any of these people to work harder than you do for your advancement. You have to care the most.

Maybe some metrics from a team dashboard look weird, maybe there's a change in a PR that you might not fully understand but feels like it might have bad consequences, maybe there's just some long standing code that looks like it can't possibly be right (but it must be if it's been in here for so long, right?). Often it's easy to assume that you must be misunderstanding things because if something was wrong someone else would have surely noticed.

Don't count on that.

Assume that everybody else is busy on other things and that maybe you're just the first person to look close enough notice that something isn't quite right. Maybe you really did misunderstand things. That's fine. Now you've learned something. But maybe you just caught something early before it became a big problem.

The more trusted you are, the more you are responsible for setting your own path. Shifting from the early career mindset of needing to wait for directions or stay on a specific path can be a tough transition for some, so it's worth taking the time to think about what you value and how you want to make use of your career capital to get it.

Spending this capital can be in service of directing your career into new domains or teams. It can mean advocating for technologies or processes or culture within your organization. It can also mean enforcing the work/life balance you want. The important thing is recognizing what you value and understanding how to use your career capital to pursue it.

First, it's much harder for others to review large changes. By breaking up your work into smaller, logical chunks you increase your chances of getting good feedback from a reviewer who really understands what they're looking at.

Also it's easier for you to see the affect of your changes. When you push out a large release it can be difficult to track down where new bugs come from, but with small, incremental changes you can better isolate where the new behavior might be coming from.

Finally, by forcing yourself to subdivide your work into releasable pieces you create a habit of making sure things work end to end multiple times along the way, rather than only being able to test a working system when you think you're complete.

But documentation naturally decays. It always needs to be kept in sync with the reality of the system. The only way this happens is by developing a culture on your team that prioritizes updating documentation as part of the work. It's easy to let this slip because it takes time to do and work can feel "done" without it. But if good documentation is important to your team, you need to find a way to make it part of the process. Maybe this is through code reviews or a CI check or someone on the team that just gets on everybody's case if they don't do it until everybody does it naturally. Whatever it is, it has to become part of what your team values or you will never get the full value of your documentation.

It's ok to take on a project where you don't have a solid grasp on every skill that will be needed to complete it. In fact, it's important to your professional development that you do this. All those people who seem to know things that you don't know had to just try new things and learn about them. There's no better forcing function for learning than needing a skill for a project.

Don't go overboard with this and know when a task it's well beyond your capabilities (within the given timeline) and know how to balance out growth and productivity for the larger needs of the project, but check in on your past work every once in a while to make sure that you've been doing some things that push your abilities.

Try offsetting your schedule so that you can start and end things midweek and give yourself plenty of time to monitor the results of any new changes you introduce into your systems. Have a good weekend!

First, it provides system visibility. If you're launching something big, post a message in a relevant Slack room saying "FYI: Big change in XYZ system going out in 10 minutes!" This way if someone is going to have a conflict or wants to wait because a demo is about to happen they can speak up. Also it means more people are aware of a the change so any issues might be caught faster.

Overcommunicating also provides opportunity for discussion and learning. When you make a point to bring up something in public, it forces you to organize your thoughts clearly and put a stance on a statement. Once you have a clear stance, stated publicly, you can have a real discussion on things rather than just assuming everybody is generally on the same page. Writing design proposals before starting large chunks of work is a great example of this type of discussion-encouraging communication.

Finally, overcommunicating lets people know what you're up to and increases your visibility in the group. This also lets people know what's being worked on and invites collaboration (don't assume everybody has read or remembers all the passive communication like documentation and roadmaps).

You don't want to become noise, make sure you're saying useful things to the right audiences, but particularly in remote situations where a lot of communication happens though text, erring on the side of overcommuncation can be very valuable.

Bonus idea! Automate you're overcommunication by having bots post updates to channels on things like deploys and system status changes.

Linters are tools that you can run as part of your development and build process that analyze your code to catch stylistic or programmatic issues. Some popular linters are gofmt (for Go) or Rubocop (for Ruby).

Stylistic linters are valuable because they take the human element out of maintaining conventions. It can be easy to tell a code reviewer that the capitalization or indentation choice you made is fine and you don't want to go through another review cycle just do fix it. You'll clean it up next time, you swear. With a linter, you can catch this during development just by running a script before pushing code. You can also have your build block on linting issues. Then it's CIs fault, not your teammates!

Using static analysis (looking at code without executing it) is also a great way to maintain the health of your codebase. You can check for patterns like unhandled errors. You can put a cap on the number of soon-to-be-deprecated methods in the codebase. This can be a big help with large refactors or dependency updates.

Linters are great for offloading a lot of the things that we know we should do, but aren't always top of mind as we're writing code.

Trying to do a bunch of things at once is a good way to make a little progress on lots of things, but not really get anything done (or done well). The best way to handle the feeling that you need to be working on a bunch of tasks is to prioritize and schedule.

Work on task 1 for the next hour and then commit to switching to task 2. That way you're not neglecting task 2, you have a plan for it, so you don't need to have it hanging over your head as you're working on task 1.

Don't go for the illusion of productivity. Make sure you're actually getting the important things done. And done right.

Our lows are often more salient (and memorable) than our highs so it's important to consciously focus on your wins. Make an effort to explicitly acknowledge and write down your accomplishments. You'll need these as evidence to yourself (and others) that you can get through hard problems and to bolster your confidence when things are frustrating. If you never focus on the wins, you'll only remember the struggles.

But it doesn't have to be all bad. While things are actively broken and you (and possibly others) are working to fix them, this is a good chance to hone your ability to problem solve under pressure. You can also learn a lot about how other people diagnose and fix problems during these times.

Once things are stable, you can think about why things were able to go wrong. It's almost never as simple as "you shipped some bad code". What allowed you to ship bad code? Could there be a better review process? Better testing environments? Better monitoring? Better automated testing? Many organizations perform a "root cause analysis" for major incidents to try to figure out what fundamental things could be improved in order to prevent recently occurring problems.

Mistakes can be expensive lessons, but they're often very valuable.

Bad working conditions exist. Long stretches of hard work exist. Some people have more control over avoiding these hardships than others, but the point of this post is to not fetishize working yourself so hard that you have to quit what you do. Focus on finding balance in your work life rather than swinging from one extreme to the other. It won't make for as good of blog posts but your quality of life will probably be better.

Asking questions in public can mean many things. Maybe it's at a meeting (instead of a one on one) or a team chat channel (rather than in a private message).

When you ask questions in public you scale up the answer. More people benefit from the answer (and potential discussion). This can often lead to lots of people gaining new understanding and deficiencies in documentations being uncovered.

Asking questions in public also normalizes not knowing everything. This is especially important/impactful if you are a more senior member of your team. Nobody knows everything and it's helpful to remind others of this.

Think carefully about being clever. Clever solutions can require more work to understand. Always remember that your code doesn't just need to be written. It needs to be written in a way that is easy to read and modify in the future by someone else (or you after you've forgotten exactly what you did).

Sometimes a clever solution is justified. Maybe it simplifies things or makes the solution substantially more efficient. But make sure you understand any tradeoffs between cleverness and clarity you may be making. Clever can be good, but clear is usually better.

This should be someone patient, with a talent for discussion. You should be able to bring them ideas and talk about them in a way that helps you test and evolve your thought. This person should be able to come at ideas from a different approach that you might and be honest with you but still make you feel comfortable.

This can be helpful when you have a bold idea that seems like it might have merit but you need some help solidifying and validating it's core ideas. This process can be similar to "rubber ducking" but with a more active duck.

These should be people are you really respect and you know except a lot of others. Talking to these people should act as a forcing function to come into conversations prepared. If you're asking technical questions, put in the work ahead of time so you can explain clearly what you're trying to do and what you've tried. Articulate your assumptions. Anticipate questions. Read up on the technology in play so you have context for the answers.

Make sure you're coming in with the knowledge to get the most out of the conversation but don't use the time to try to show this person how much you know. Ask questions you actually want to know the answers to, not ones that prove you understand what you're talking about.

Purposely seek out these conversations with people who don't feel totally "safe" and use that mild discomfort as motivation to bring your best self to the interaction.

To avoid randomly thrashing around your codebase you should come up with a hypothesis, test it, keep notes about what you've learned, and keep refining until you understand why your code doesn't work the way. Coming up with a good hypothesis is crucial. You need to take what you know and come up with a good question and theory about the answer that will provide useful information when tested. You will likely need to take a few steps back and figure out explanations for sub-problems before you can full answer your original question.

You can make better hypotheses by knowing your codebase better and just getting more experience tackling bugs.

The most important part of testing your hypothesis isn't whether or not it was right but what you learned from it. To this end, make sure you keep a lab notebook (this can be anything from a text file where you keep notes while you're working to an actual notebook with notes and diagrams) and write down everything you learn along the way. As you explore your problem you might need new "lab equipment" to get the information you need. This could be anything from "print debugging" to building custom tools to get insights into how your program is running and the data it produces.

Approaching a problem in a scientific manner can be a powerful tool when faced with unknowns.

When trying to solve hard problems you need to be focused on the task at hand but sometimes this level of focus can make it easy to miss things when you feel stuck. It can be tempting to try to just "power through" these situations of stuckness but that's often a good way to waste a lot of time getting nowhere.

Learn to recognize when you're not making productive progress. Maybe you're just changing random things, hoping something will work. Maybe you're just staring at the same piece of code hoping something will pop out at you to make things clear. Rather than just sit there banging your head on the problem, get up, go for a walk. Get a snack. Maybe even go home for the night.

Just do something else. You'll be surprised how often you get some new insights just from stepping away for a bit.

Knowing how to confirm it works (and doesn't work) is about making sure that you have the appropriate visibility into the things you launch. Knowing how things are going to break is about understanding both the tradeoffs made in your work and how usage is going to change.

Did you design a drop down menu that works fine with 20 or so items (nobody should really need more than 5, right?) but it's not impossible for there to be hundreds of items? That might be fine, but it should be explicitly thought about and communicated.

You should know what parts of your system will slow down as certain database table get bigger. You should know what tables are growing fast enough that you might need to worry about capacity issues. You should even know about parts of the code that will grow untenably complex if more features are added to the current design.

There will always be problems that are hard, if not impossible to forsee but spending time thinking about where you are likely to first see breakage can help you monitor these areas and get ahead before they become serious issues.

You will likely have languages you prefer and will develop a sense of what languages will work better for different situations. These feelings can help you push for certain languages to be used but you won't always be able to use your favorite tools for every project. By thinking of languages as tools that you have developed informed opinions about rather than part of your core identity you make yourself much more versatile.

Your knowledge of your favorite language should make it easier to learn new languages. Now you can understand the new language by comparing and contrasting its paradigms with those you already know well.

The same goes for frameworks and other technologies.

Just make sure to show people appreciation. This can be for helping you out with a problem or even just getting their part of the work done. Everybody likes to feel like their efforts are noticed and being proactive about thanking people will help you keep any eye out for people's efforts.

Very few people feel like they're thanked too often. Err on the side of appreciation.

One way around this is to not start with the big thing. Have some "momentum building" work to do. This means have some tasks that have a clear approach and you can complete quickly to start with. These could be house-keeping tasks like cleaning up all your open browser tabs or sending out a meeting invite or reading a document that you know you need to look at.

You could also spend the last part of your day figuring out what you would do if you were going to work for another hour or so. Write this down, along with all the context you'd need to get going and save this work for the first task of the next day.

The idea is to quickly get going and feel productive. Once you're in that mindset, it should be easier to tackle larger, less defined work.

So how do you know it works?

At this point you should make a list (seriously, write this down) of what should be happening when your new feature (or bug fix or whatever) is in place. What metrics should be moving? Should CPU load go down? Will you stop seeing certain errors?

Also think about what shouldn't be happening. Is database load spiking? Are new errors popping up? Did load times just increase?

If you don't have visibility into these things before you launch, then you probably aren't ready to launch.

Don't expect your manager to remember all the great stuff you've done. Don't even expect to remember it all yourself. It can be very easy to forget the details of how you spent your time and going back to look at all the PRs you merged over the past 6 months probably won't tell the whole story.

Keep a running document of the things you've accomplished. This can be projects you completed (complete with metrics that show what your completed project actually accomplished) and bugs fixed. This can be internal tools you've written that have saved the team time. It should also include time you've spent mentoring other people or serving on committees or giving talks. Include links to PRs, documents written, dashboards that show improvements you're responsible for, etc.

When it comes time to write up what you've accomplished during the last review cycle, you should be able to just start with this accomplishments document as an outline. Julia Evans goes into great detail about how and why to build this record in her post about brag documents.

First off, you might just meet some cool people, but you also might learn more about what your organization really does. There are likely hard problems being solved that are totally different from what you encounter every day. You'll be likely to gain perspective on priorities and problems that you might not get just talking to other software engineers. Plus, when you have problems or questions that need expertise from other parts of the org, you'll know who to talk to.

Pop your head up once in a while and look around to get a feel for the whole organization that you're working in, it can be really enlightening.

The idea is to just have a place to keep everything you know in one place. Maybe this is writing down the flow of method calls for a certain piece of functionality. Maybe it's a place to keep some VERY quick and dirty scripts to add new test data. Maybe it's just notes from a conversation you had with a coworker that provided some clarity about the system.

In addition to the immediate benefit of just writing down what you know about the project so you don't have to keep everything in your head, these notes often become the basis for some new documentation that (once polished up a bit) can be a huge help to other people.

Going from 0 to 1 with a project will force you to understand parts of an application that you may have taken for granted and what went into making the non-trivial applications you might work with day to day. You'll get a better feel for what interfaces come with the language and/or framework you work with VS what might have been built in-house. Also, it might come in handy when you're interviewing for jobs and they want you to build a take-home project or a quick coding challenge. Don't be a web developer who can't build a website (or whatever the equivalent is for the type of software you want to write).

It can also be a great reminder that the process of writing code is messy for everyone. Too often we just see the code that people are ready to have reviewed but don't see the trial and error that goes into writing it. Seeing the way people think about a problem and how they actually work on it can be both informative and reassuring.

When this happens (and it will) just make sure you learn as much as you can from the experience. Something going wrong can be valuable to your own growth as well as identifying weakness in your organization. You might have screwed up (and you should avoid screwing up the same way again) but could there be a systemic change that would prevent screwups like this from making it to prod?