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.
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.
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.
How can I move work in progress forward?
How can I move work in progress forward?
Do you think you have an understanding? Or do you have an understanding?
Are these the correct requirements?
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?
Is the abstraction obvious?
What change would it take to fail this test?
Could this solution be simpler?
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?
What types of coupling does this introduce?
Is this following the idioms of this team?
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.
Are you ready to build something brilliant? We're ready to help.
.jpg)
