Building software is HARD work. My job as a software engineer is no exception to this rule. There are definitely days when I shut my laptop at the end of the day feeling exhausted.
I am now at the point in my career where my responsibilities have broadened. The days of simply taking on a collection of stories and implementing them sprint after sprint are long gone. My responsibilities now include….
- Implementing user stories
- Reviewing code and testing other engineer’s work
- Technical design of features
- Backlog grooming
- Pairing with and mentoring other engineers
- Working with Product to come up with high-level work estimates of upcoming projects
- Stewarding my team’s engineering process
All of these responsibilities come with their own set of interesting challenges. Here are some of the biggest challenges I face with these responsibilities:
Decision Fatigue When Writing and Reviewing Code
I think there is a difference between writing code and writing good code. Most engineers can take a moderately complex user story and come up with a working solution. Sometimes the first pass on coming up with that solution will not take into consideration how nicely the code is written. When I am trying to write good code or reviewing code written by others, each line of code sometimes feels like the result of a collection of micro-decisions. I am constantly asking questions like:
- Does the variable or function name properly convey the intent?
- Could this function be written in a way that is more performant?
- Could I condense this code into fewer lines of code? Would that make the code more readable?
- Does it make sense for this class to contain this logic?
- Does the code style I am using align with the style of the rest of our codebase?
This is definitely not an exhaustive list of considerations that need to be made when writing code. That being said, I think I listed enough questions to prove the point that writing good code takes a deep level of critical thinking that can be mentally taxing. Even though I am getting more experienced every day I work, I still recognize that analyzing all of the micro-decisions that go into writing good code is really hard.
Communicating in a Way That Effectively Conveys a Team Minded Approach
I look at building software as a team sport. A software team’s goal is to come together to implement high-quality code as effectively and efficiently as possible. That being said, whenever I come across code that I think could be written better or think of a technical design that could work better for our software system, I find it easy to think about the problem from the standpoint of why “I” think the solution could be better. While it is fine to think from this perspective to come up with new ideas, communicating with others from this perspective with phrases like “I think this is wrong because….” assigns responsibility to an individual instead of collectively taking on the responsibility as part of the team. I find that simply coming up with the reasons for why something could be improved can be hard, so coming up with a clear, effective way to communicate that idea in a way that makes the experience of being an engineer on the team better is even harder.
Effectively Estimating Upcoming Work
Software engineering is inherently a creative discipline. There are usually many ways a problem can be solved, and the engineer’s job is to use their creativity to come up with the best way to solve a problem. Because the job takes creativity, it is hard to estimate the size of upcoming projects. As an engineer, I want to be an advocate for the other engineers on my team to give them the time they feel they need to get their work done. On the flip side, the business needs timelines so that they can set expectations with customers and keep them informed about the features we are building. It is really hard to make an educated guess on project complexity that will keep the business and customers happy while giving the software team the time they need to come up with good solutions that do not add technical debt to the software system.