More on this book
Community
Kindle Notes & Highlights
by
Tanya Reilly
Read between
March 4 - March 5, 2023
Ask for help from coworkers, mentors, or local experts. If you’re someone who hates asking for help, remember that by learning from other people’s experiences, you’re amortizing the time they had to spend learning the same thing: it’s inefficient to have you both figure out solutions from first principles. You
Here’s the last form of being lost and, in some ways, it’s the scariest: you don’t know if your work is still necessary. A comment you heard at the latest all-hands meeting might make you nervous that a new initiative will derail yours. Maybe you’ve noticed that your manager or project sponsor is checking in less often, and seems less interested in your results. Or there was a company announcement that listed all of the important projects—and yours wasn’t on it.
By the way, if you’re trying to run a project with a title like “unofficial lead,” that’s an invitation to fail—if you’re the lead and nobody else knows you are, you’re not the lead.
Software engineers often think of their job as writing software. When we plan projects, we often only list the parts of the work that are about writing the code. But there’s so much more that needs to happen to allow the user to get to the code: deploying and monitoring it, getting launch approvals, updating the documentation, making it run for real. The software being ready isn’t enough.
Celebrate shipping things to users, rather than milestones that are only visible to internal teams. You don’t get to celebrate until users are happily using your system. If you’re doing a migration, celebrate that the old thing got turned off, not that the new thing got launched.
Have you ever seen a platform or infrastructure team spend months creating a beautiful solution to a common problem, launch it, celebrate, and then get frustrated that nobody seems to want to use it? They’re sure it’s better: it genuinely improves its users’ lives. But teams are still doing things the old, difficult way.
Michael R. Bernstein has a great analogy for creating solutions and then not marketing them at all. He says it’s like a farmer planting seeds, watering, weeding, and growing a crop, and then just leaving it in the field. You need to harvest what you grew, take it to people, and show them why they want it. The best software in the world doesn’t matter if users don’t know it exists or aren’t convinced it’s worth their time. You need to do the marketing.
used to work in a data center, a long time ago, and one thing I learned there is that there’s no such thing as a temporary solution. If someone ran a cable from one rack to another without neatly cabling and labeling it, it would stay there until the server was decommissioned. The same is true for every temporary hack: if you don’t have it in good shape by the end of the project, it’s going to take extraordinary effort to clean it up later.
your company doesn’t have a regular culture of cleaning up as you go along, see if it’s possible for you to get momentum around having regular cleanup weeks. I’ve heard these called “fix-it weeks” and “tech debt weeks,” and I’ve also seen a fair amount of cleanup happen during engineering exploration time, like “20% time” or “passion project week.” Another option is to set up a rotation where one person on the team is always dedicated to responding to issues and making things better. Don’t get hung up on the name or whether something really “counts” as technical debt. The point is that it’s a
...more
It’s possible to get to a point where further investment is just not worth the cost and to declare that the project is “done enough.”
One of the biggest successes I ever saw celebrated could have been considered a failure. A team of senior people worked for months to create a new data storage system. Other teams were eagerly awaiting it. But as the work progressed, the team discovered that the new system wouldn’t work at scale. Rather than deny reality and search for possible use cases for what they’d created, they killed the project and wrote a detailed retrospective.
Let’s start with the feelings, because this is a tough situation. It feels bad. Even if your team understands and accepts the reason for the cancellation—even if you all agree!—it’s jarring to suddenly drop the plans and milestones you’ve built. You all might feel like the work you’ve done has been for nothing. If you weren’t part of the decision to cancel, it can feel like a personal failure. You might feel angry, disappointed, and cheated or resent that a change that affects you so much has happened in a room you weren’t in. This may be a legitimate complaint: if managers make big technical
...more
Then talk with your team or subleads. Tell them what’s happening, leading with the why. Give them time to talk about their own reactions to the news. Respect that they might be mad at you, the project lead, as the bearer of the bad news or the person who didn’t manage to “save” the project. It’s important that they hear it directly from you or another leader: don’t let them find out from the gossip mill, a mass email, or the company all-hands meeting.
It’s not fair, but a canceled project can derail promotions or break a streak of great performance ratings. Do what you can to showcase everyone’s work. If your team members are moving on to other projects, make a point of telling their new managers about their successes and offer to talk with them or write peer reviews at performance review time.
“specify the precise problem to be solved independently of the method used in the solution.” He wrote, “This can be a surprisingly difficult and enlightening task. It has on several occasions led me to discover that a ‘correct’ algorithm did not really accomplish what I wanted it to.”
If you’re mature, constructive, and accountable, you’re telling your new grads that’s what a senior engineer does. If you’re condescending, impossible to please, or never available, that’s what a senior engineer does, too. You shape your company every day, just by how you behave.
One more caveat: the tech industry is awash in advice, most of it subjective. This list is too! Best practices all depend on the situation. There will be edge cases and special circumstances; if my advice contradicts your own judgment, trust yourself. A staff engineer has the good sense to know when the conventional wisdom is wrong.
Don’t rush past your prime learning years. Some organizations encourage their best talent by offering them senior roles, like management or staff engineering, relatively early in their careers.
Being a senior engineer means having a growth mindset and a drive to improve. It’s embarrassing for everyone when a technical leader insists on a “best practice” that has been debunked for a decade or a technology that everyone else has moved on from.
You won’t know everything, and it’s vital that you don’t pretend you do. If you bluff, you’ll lose opportunities to learn—and you may make bad decisions. You’ll also waste the opportunity to set an example.
Admitting ignorance is one of the most important things we can do as tech leads, senior engineers, mentors, managers, and other influencers of team culture.
It’s much harder to explain something simply! It requires more understanding of the topic
But make that determination based on the problem you’re trying to solve, not how interesting the work is to you.
some point you will make a mistake, and it might be a big one. Maybe you reviewed code and didn’t notice a bug that cost the company a ton of money. Maybe you wrote that code! Maybe you said something in a meeting that you later found out made someone cry (or quit).
Mistakes are normal.3 Humans aren’t perfect, and mistakes are how we learn. What matters most is how you respond to your mistakes. It’s easy to get defensive, deflect blame, or fall to pieces (that someone else needs to pick up). To be competent, you need to own your mistakes.
If you hurt someone else’s feelings, acknowledge the hurt and apologize. (Even if you wouldn’t have felt bad in the same situation, their feelings are real.)
My final thought on competence is this: be reliable. One of the biggest compliments I give is, “Alex is going to be in that meeting, so I don’t need to go.” When I say that, I’m not just saying that any information I have will be represented in the meeting.
Mature engineers stand up and accept the responsibility given to them. If they find they don’t have the requisite authority to be held accountable for their work, they seek out ways to rectify that. An example of CYAE is “It’s not my fault. They broke it, they used it wrong. I built it to spec, I can’t be held responsible for their mistakes or improper specification.”
Owning decisions includes accepting that you might be wrong. Make the cost of a wrong decision as low as possible, and if it turns out that you are wrong, own that, too.
A few years ago I wrote a conference talk that went a bit viral. OK, we’re not talking otters holding hands viral, but it swept across tech Twitter, hit the front page of Hacker News, that sort of thing. The talk was about the leadership and administrative tasks that aren’t on anyone’s job ladder but are needed to make a team successful: all the unblocking, onboarding, reminders, mentoring, and scheduling. I called this kind of work “glue work”.
Why did the talk hit such a nerve? Because although projects can’t succeed without it, this kind of work is rarely rewarded or allocated fairly. It falls to whomever on the team can’t look away from the problem, often a junior person with a strong sense of ownership.
glue work is needed for your organization or your project, recognize it and understand who is doing it. Be aware that managers, promotion committees, and future employers might consider this work to be leadership when a staff engineer does it, but dismiss it when a more junior engineer does.
Unfortunately, coordinating only works if everyone knows you’re coordinating. If you don’t take charge explicitly, you’ll just be one more person making noise.
Someone needs to be brave enough to say, “I don’t know what to do with the information you just gave me!” Take charge and ask. Tech can be fraught with egos and insecurity, and it’s sometimes scary (or legitimately risky!) for junior people to admit that they don’t know something. It’s safer for senior people to ask.
“The social rules are lightweight. You should not be afraid of breaking a social rule. These are things that everyone does, and breaking one doesn’t make you a bad person. If someone says, ‘Hey, you just feigned surprise,’ don’t worry. Just apologize, reflect for a second, and move on.”
The adrenaline awfulness, she told me, doesn’t go away. You just accept the discomfort.
While the conventional wisdom for feedback is to praise in public and criticize in private, this is a time when it’s vital that you say something public: if it looks like the original message wasn’t addressed, it can create an environment where that kind of message is seen to be acceptable.
Finally, be cautious about where you share your anxieties or frustrations. While you can acknowledge that there are problems, don’t let your worries about them spill out on more junior people:
“It’s always interesting to see how new people handle their first screw-up. We’ve all been there.” It was such a relief! Of course I was still upset, but the sick feeling in my stomach was gone. If every one of my coworkers had survived their first mistake, I would too.
As a senior engineer, you have a responsibility to the future as well as the present. You will always be responsible for creating software that stands up under stress. But you’re working for a business (or a nonprofit, government agency, or other organization) that has goals. The software is the means to those ends, not an end in itself.
As the business changes, your priorities will change. Be OK with that. It’s inevitable. Growth, acquisition, new markets, or a change in fortunes will mean that your goals may get thrown out as the company pursues a new direction or even a new culture.
Don’t obsess about the budget: it’s easy to get frozen in indecision, trying to decide if one project or another is really worth the cost. But have a feeling for what kinds of expenditure, savings, or new revenue are considered big.
You’ll probably have a ton of ideas about places you can innovate, invent something new, or make one of your systems a little better. Make sure you’re choosing work that your business actually needs. Your team has finite time and energy; is this the right way to spend it?
Build the most useful thing, not the thing that would be most fun to build.
I’ve seen too many teams create a feature for a set of fictional, perfect users who don’t exist.
The final thought in focusing on the mission: remember you’re not doing this work alone. While you may be the best coder on the team, the most experienced engineer, or the fastest problem solver, that doesn’t mean you should jump on all of the problems. You’re working as part of a team, not a collection of competing individuals. Don’t become a single point of failure
“Software engineering is programming integrated over time.” Expect the impact of your software to stick around.
Every time someone leaves your company, you lose institutional knowledge. If you’re lucky, you have some old-timers storing history in their brains. But eventually, inevitably, you’ll have complete staff turnover.8 When an old system breaks, there’ll be nobody left to say “Oh, yes, I remember when we ran into this before. Here’s what we did last time.”
However you create the history, include searchable keywords so that future people have some chance of understanding what you did and why—and think about what you know that future people might not.9
My all-time favorite incident retrospective is the one Fran Garcia wrote about his then-employer, Hosted Graphite, being taken down by an AWS outage. The reason I love this one is that Hosted Graphite didn’t use AWS, so the team was quite surprised at being affected by its outage.
