My Responsibilities that are Not Writing Code

4/23/24

Go back to all articles

My primary professional responsibility is to write code. As an individual contributor and a software engineer, I work in a larger system other than myself and that inevitably means I have more responsibilities other than writing code. I wanted to define some of those other responsibilities I regularly perform that allow me to be successful:

1. Pointing Work - Pointing work is when I and my engineering teammates prescribe an effort or difficulty to a given fully scoped task. This a common task among engineering teams and allows product to estimate how long a given task will take to be completed. Pointed tickets allow product and design to prioritize tasks given their perceived importance. The success of the product team relies on the accuracy of my ability to correctly prescribe points and without an array of pointed tickets they cannot complete their assignment of providing prioritization. Because the product team is relying on my pointing, I will always make sure I am available to point fully scoped tickets in order to keep them unblocked.

2. Training and Up Leveling Team Members - I work with a team of engineers. The success of our product depends on the success of all of the members of the engineering team working in coordination. The biggest impact I can possibly make as I continue to develop as an engineer is to improve the quality of code my teammates are producing. This means I need to be deliberate about teaching and training those around me and I need to make sure I always make time to train others.

3. Documenting My Work - In the same breath as the above item, I need to make sure the code I write is helpful to those around me. This means I must write good documentation and notes so my teammates can follow my work and easily work alongside me. While writing documentation is not as fun as writing code, it is an important practice that I cannot deprioritize.

4. Interviewing and Hiring - A healthy and mature engineering team will need to always have represented in it all levels of engineers. That means a growing organization must always be hiring and promoting its members. Consequently, we are always interviewing and my help is needed to conduct those interviews. My skills as an engineer here are unique, the other peoples in the organization cannot determine the candidates engineering prowess, so I am happy to provide my guidance.

5. Grooming the Backlog with Technical Tickets - In order for the product to continue to operate, there will be technical maintenance required. An examples of this could be, we need to upgrade Node versions because the current version is being deprecated and could be a security concern. The product team will never come up with such a ticket and I need to ensure it is part of their expectations.

6. Cultural Involvement - I think this item is often overlooked by engineers but I believe it is important to both my success and the company's success. Engineering is one part of a successful company. It is important that the engineers be at the table with the other company members when teams collaborate. I try my best to involve myself across divisions so I can teach others more about engineering and I can bring back with me domain, industry, and cultural knowledge.