This section has good descriptions of how to classify certain types of work a software engineer does, and how to prioritize for higher impact.
What I liked especially was thinking about the work in terms of effort, impact, and visibility.
“Snacking” is work that is relatively easy and low-impact. Some things that came to mind in Ruby on Rails web development for me were:
- Updating a minor or patch version of a gem dependency
- Updating a patch version of Rails
- Adopting a new well documented API
These things have some value, but are also easy and probably low in business impact, and low in visibility. As the guide says, snack sized work is good to fill in gaps or could be good to hand off to someone with less experience performing these tasks in general, or at the particular organization.
These can also be useful to build some “momentum” or inertia as a new contributor, with a new technology, or on a new team.
But just like in real life though, a diet should not consist solely of snacks.
“Preening” is lower impact work like snacking but instead of low visibility it’s high-visibility work.
This made me think of taking on a pet project for a boss. It might be highly visible work because the boss has asked for it, but it’s also lower in impact to the business.
Preening projects might still be useful to help build trust (“right hand man”) and reputation, but may not benefit an individual’s skill growth or development.
The author encourages the reader to strike a balance between work that is valued at the org, and personal growth.
Chasing Ghosts 👻
Ghosts are low-impact but very high effort projects that aren’t quite done. A new person may be brought in to try and solve these problems!
Taking the time to understand the status quo before shifting it will always repay diligence with results.
What should you work on? Existential issues.
Running out of money is an example listed. Another example listed was something we discussed recently, we’d scaled vertically to the largest instance class available for the DB server, and there was concern additional load would exceed capacity.
Since there was no additional purchaseable headroom available, working on code and data solutions internally to optimize further while not a guaranteed future crisis, was a possible one, and therefore it was easier to sell the engineering effort involved in working on that.
Work where this is room and attention
The guide suggests working where there is both room to work (things to be done, in other words problems that are not fully solved), and attention to the work.
This makes sense to me. Bringing someone in new but with nothing really to do is unproductive. Bringing someone in new to work on something that has been ignored for a long time, will probably result in their effort being ignored.
Some questions the book suggests:
- What might become priorities in the future where you can work in advance of that?
- Areas that are “ok” , but could be great(!) 📈
- Be mindful of working in a company area that is not well supported. It may be personally interesting, but not visible or rewarded.
These are just copied from the source material with my own quick summaries.
- Foster growth. Growing the team around you is always appreciated and valuable.
- “Edit” - improve something that was good that could be great.
- Finish things (be a closer)
- “What only you can do”. Leverage unique skills by brining them to the team to level everyone up.
The StaffEng book is very energizing to me, I highly recommend it!