This week’s reading, including “Useful things to know about engineering levels,” “Enable learning in technical writing,” and more.
Useful things to know about engineering levels by Charity Majors, whose blog posts I’ve been reading more and more lately. The main point is that not every opportunity exists at every company at every time, which is a non-obvious part of leveling up one’s career.
She gives some advice—to find out if there is oxygen at the next level, meaning if the company needs people at the next level (there’s only so much high-level work to do). And a laundry list of nuggets of wisdom, like “generalists level up faster than specialists” and different ways to focus on impact.
6 things I learned interviewing for Staff positions by Amy Unger discusses her job search for a staff-level engineering position. Starting with the reality that everyone defines Staff differently, she wrote about how this meant that everyone interviews for these positions differently (or not at all). This was quite long, but worth the read.
Enable learning in technical writing by Marcus Kazmierczak opens with the goal that technical documentation should “enable a student to learn, give them confidence they can learn, and not just copy-paste their way.” A noble goal!
The post has great advice. Upon reflection, I think that a lot of technical documentation that I like is documentation that keeps this idea in mind. Things like the pandas user guide or Pyro examples are written with the goal of helping me learn, and I refer to them as often or more than the API references.
The goal of your documentation is to enable people to learn your system.
Reading code is a skill by Trisha Gee argues for exactly that point. Writing code is important, yes, and writing readable code even moreso. But more important than both of those is the act of reading code itself, which we spend far more time doing than writing.
Next time we see code that we don’t understand, we shouldn’t beat up the author for “not writing readable code”. We shouldn’t beat ourselves up for being stupid for not understanding it, because we all come with our own unique experiences. We can instead see it as an opportunity to practice reading this particular code, and leveling up our “reading code” skill.
Other articles:
- Building Great Engineering Teams, with Gergely Orosz
- Leading senior engineers: lessons learned by Adrienne Lowe