How embedding as a software engineer results in learning and empathy.
Learning Culture
One thing I love about working at Target is our learning culture. Getting better every day is, quite simply, what we do. Recently within Target Technology Services, the leadership team extended its commitment to learning by asking every person to dedicate 50 days per year – roughly one day per week – to learning. This commitment goes above and beyond the learning that happens every day during the course of a person’s normal work.
As I was reflecting upon how I wanted to invest in learning, I thought about my personal learning style, interests, and current role as an engineering manager. It was important for me to find a learning opportunity where I could learn by doing, write code, and work directly with the engineers with whom I frequently interact.
The outcome of this introspection was that I embedded as an engineer on one of our product teams for a week.
Below are my day-by-day reflections.
Day 1:
My first day was spent troubleshooting a scenario for one of our customers. I gained a tremendous appreciation for having application logs with the appropriate amount of detail. Rather ironically, my “real” role at Target includes providing self-service offerings for metrics, logs, alerts, and on-call scheduling. We often coach engineers on the value of metrics over logs and to not become over-reliant upon logs. Once you encounter a scenario where you need to perform root cause analysis, having access to your logs is important.
When I started to use the log aggregation offering, I learned that I don’t need anything fancy: many advanced features of log aggregation user interfaces just get in the way of what I really want to do, which is simply to search my logs. Furthermore, I’ll forgo advanced functionality in favor of ease of search and availability.
Day 2:
The pain of waiting for a long running continuous integration build to complete runs deep. As an engineering manager, I’m in a position to help the team obtain the time needed to have efficient CI pipelines. It can be easy to look past CI improvements and advocate for releasing new features to our customers. For the productivity of the engineers, make sure the team has the time needed to have reliable and efficient CI pipelines.
Day 3:
I’m so thankful for open source. All of the engineering work that I am doing is a result of standing on the shoulders of the giants who have already contributed to open source. We need to continue to contribute back to open source.
Separation of the product owner from another engineering role is really important for many reasons. One reason is when these roles are combined, it’s too easy to just go with what you can (or want to) code rather than what the customer needs.
Day 4:
Interruptions kill productivity. As an engineering manager, I get interrupted constantly throughout the day. Context switching is a part of the job as unanticipated situations occur regularly every day. As an engineer, context switching has a large negative impact due to the critical thought that needs to go into every single line of code.
Give engineers the opportunity to finish their thought before pulling them into another topic. Also, show gratitude when that engineer stops what they are doing to help you.
Day 5:
Celebrate your wins. I was writing a Cypress unit test and was struggling with a specific use case. After some Google searching combined with a healthy dose of trial and error, I finally created the test cases and validation wanted. Given the amount of frustration I had experienced throughout the day with this work, it was really important for my mental health to take a step back and celebrate this accomplishment.
Recommendations
If you are going to try embedding as an engineer…
Timing is important
Make sure the engineers on the team in which you will be embedded are ready for you to participate as an engineer. In a week, you’ll see precisely how the sausage is made. As a result, there needs to be quite a bit of mutual trust on the team. Reinforce with the engineers that you are there to learn, not to evaluate their performance.
You never really step away from your job
Things will come up in your normal role that you’ll have to address. I spent ~70% of my allocation as an embedded engineer. Take this into consideration when committing to deliver a story for the sprint.
What’s next
I thoroughly enjoyed my learning week. It refreshed my enthusiasm for technology and helped me acquire a better understanding of my engineering co-workers' challenges and accomplishments. Next, I plan on embedding with a different product team as part of my continual quest to get better every day.