Internal Engineering Manager

The Motivation

Career paths are very individual things. Companies create career ladders to suggest collections of competencies an employee might meet to reach a certain step, but even people with the same title may excel in different competencies on that rung and may need to work on others. A good manager of course can help someone identify what areas they can grow in and how. However, in my experience, even good managers don't always have the time necessary to monitor growth all the time or full transparency into their reports' work.

One strategy I've used to grow as an engineer is to keep a checklist of questions I ask myself at different points in my day to day work. I use the checklist to remind myself of areas of growth that I'm trying to focus on at any given point.

How it Works

For instance, one of the questions I had on my checklist earlier in my engineering career was, "What's my hypothesis?".  I noticed sometimes, when debugging, I would try making a change to solve a bug without having a clear idea of what the problem was. So, any time I was making a change to existing code, I would ask myself, "What's the hypothesis?". What I meant by this is, "What do I think is the problem? What outcome do I think my code change will have? How will I know if I'm correct?" Trying to follow this line of thought whenever I didn't have a clear understanding of what was happening in the code increased my ability to read and reason about code as well as improving the quality of the tests I wrote.

I keep this checklist somewhat short, cycling in new questions as I identify areas of potential growth and cycling out older questions when I feel I've internalized them or they no longer serve me. So, the list is never a comprehensive collection of my engineering practice, just the things I currently keep front of mind. Whenever I encounter a situation that I feel like could have gone better or see someone solving a problem a more effective way than I might have, I'll try to add a new question to the list to learn the lessons of those situations.

Example CheckList

Below I've included my current list. Its broken up by what I consider to be breakpoints in my daily workflow. Obviously, not everything falls neatly into these moments, but I find them to be good inflection points. Also, while this list is engineering specific, I think the strategy can be applied to other jobs.

Starting a Story

How can I move work in progress forward?

  • I use this to check in on code reviews, see if someone could use help with a story in progress, if any of my own stories could be QA'ed, or anything else that can help get work currently in progress delivered more quickly.

How can I move work in progress forward?

  • I use this to check in on code reviews, see if someone could use help with a story in progress, if any of my own stories could be QA'ed, or anything else that can help get work currently in progress delivered more quickly.

Do you think you have an understanding? Or do you have an understanding?

  • Make sure I understand the requirements of a story as written and haven't made any assumptions based on how I think it should work

Are these the correct requirements?

  • Make sure the requirements seem like the right ones. If it seems like requirements are unclear or maybe don't fully make sense in the context of a larger epic or feature, I'll follow up with the steakholders to clarify, confirm and possibly suggest revisions to those requirements.

Coding

Some of these are have obvious times to ask, but for other it varies. If there isn't a clear point when to ask it, I usually try to ask myself the question after returning from a break. I find myself less likely to have tunnel vision after I've stepped away from the code for a few minutes.

What's the immediate goal?

  • I use this one to remind myself to break big, fuzzy tasks, into small tasks that have a clear output and usually an obvious implementation. I try to keep set a goal that can be met within 20-30 block of coding.

Is the abstraction obvious?

  • I know there are other rules of thumb for when to make something re-usable, but this is a question I like to ask myself before abstracting. If the implementation still feels fuzzy at all, it's premature.

What change would it take to fail this test?

  • I like to check if my tests are valid by making change and breaking them once I have them passing. Sometimes, you're not actually testing what you think you are.

Could this solution be simpler?

  • This is a check in I like to make once I've started to make some progress on a story, and definitely before I open a PR.

Opening a PR
  • Try to go through my own PR reviewing list when opening a PR. See below for details.

Reviewing Code

I'll read the story and ask myself the same question I ask when I start a story, "Do I have a correct understanding of the requirements and are the requirements correct?"

Does this pass the grep test?

  • When it come time to refactor or delete this code, how easy will it be to find.

What types of coupling does this introduce?

  • This one is a bit of an experiment, a checklist within the checklist I've been using the types of connascence introduce in the article below to get better at identifying how things might be less coupled. https://practicingruby.com/articles/connascence

Is this following the idioms of this team?

  • Best practices and preferred design patterns can vary team to team and evolve over time. I like to consider if a PR is consistent with the current idioms of the team and if intentionally introduces new, to start a discussion about it.

Conclusion

If you do create a checklist for yourself, your questions will undoubtedly be different than mine or anyone else's, and even different for yourself over time. Perhaps a checklist isn't even the most helpful format for your learning style or workflow. However, if you agree that software engineering is more than just technical competencies, that it is equally a set of practices that can be applied to designing, building, and debugging systems and collaborating effectively on that work, then perhaps give this approach a try.