Lessons I Learned that Made Me Better Software Engineer
I am sharing few lessons I learned over the 10 years of my career as an engineer, that changed the way I work and made me a better Engineer.
- Organization and Culture
At an early career most of us get so overwhelmed with the work, the sprints, meeting and not looking stupid. It does not occur to think about why we are doing all that work in first place, who needs this work? I never understood in my early career why was I invited to all hands meeting where they talk about all the “big stuff”. After all, these meetings do not concern the query I have to write, for which the eta is tomorrow. I will always be like — lets skip the all-hands and focus on the tasks in hand. That was a mistake. Work is as important as the knowing why the work is required in first place. It helps is prioritizing the tasks as well as understanding others perspectives. The knowledge guides us in weighing which tasks are important for the org/team and up to what extent.
There is other aspect of understanding the organization beside the work — and that is culture. I often hear on the lunch tables coworkers comparing their previous company or some other company to the current. We all heard someone saying “Back then we used to do things this way. It was so much better.” It’s important to understand why a company works like the way it does, whether the company is open vs secret, top-down vs bottom-up and front-doors vs back channels. Mike Sage as well explains here difference in the organizations led by Engineering vs product. Often times there is no right or wrong way, but it’s just how it works for the business for your org. It’s important to know the culture to navigate the organization. Know what would be appropriate and appreciated, and what is not encouraged. Should you keep this project knowledge on need-to know basis or evangelize to everyone? Should you pitch your ideas to first to your direct colleagues or your skip? These all things and more depends on your organization culture.
2. To be Right
“When acting as a role model, your review comments should make code and designs better, and your opinions need to be well thought out — you need to be right!”
— The Staff Engineer’s Path: A Guide for Individual Contributors Navigating Growth and Change by Tanya Reilly | Goodreads
While it’s very easy not to be right, as an entry-level engineer you have liberty to be wrong and not have consequences, but as you grow yourself to higher levels a lot of things are at stake. People are not only looking up to you but also trusting your decisions. It is very essential to think thorough before putting anything out there — a comment on someone’s question, a question, a suggestion or a full-fledged execution plan, to think through all angles is essential. Of course, that does not mean that you will never be wrong. A better approach is to be better in recovering from being wrong and find the right solution.
3. Finite time
At some point of our career, we all kept some grudges from the senior engineer for not replying to our messages as soon as we reply to theirs. From my PR review requests to the customer issues that require urgent attention, getting their replying on anything is always a challenge. In the book The Staff Engineer’s Path: A Guide for Individual Contributors Navigating Growth and Change by Tanya Reilly puts things in perspectives, they have probably hundred other PR reviews, and tens other urgent issues are asking for their help. If they started responding everything with urgency, they won’t be able to get to where they should be. Its also important to manage the work of our own. As we grow our career, we will have more and more things and less and less time — urgent incident mitigation, the side study of new technology, presentation of the project, project deadline, mentorship requests — what to do when, if we gave all our time to incidents and urgent issues, we probably become good at crisis management but won’t be learning anything new. A balance is required. Will Larson in his book Staff Engineer: Leadership Beyond the Management Track by Will Larson | Goodreads presents a great model to help manage time.
I found the matrix really helpful in prioritizing the tasks. First category is Low-impact low efforts: an example could be code clean-up tasks while it’s useful to clean-up redundant or un useful code, it's easy and low impact, it does not generate much business value. It’s also called snacking; you eat without much nutrition value. It’s okay sometime to snack to satiate hunger, but be aware of the empty calories you take in. There is another subset of it Low-impact high visibility, also called preening. In some companies your success will depend on how much visibility you have, whether it’s through low impact or high impact, hence it’s important to know the culture of the companies, if it values the impact or vanity.
Another category to avoid is low-impact high effort tasks: an example could be re-factoring code just to make it look pretty and readable, debating on a feature design that is just a second precaution for a highly improbable failure incident, setting up an API with all the fancy design patterns but won’t be hit except for few times.
Next is high impact low effort and high impact-high effort. Thats the quadrants where your most work should be, work where there is value or need. It could be area existential crisis for the company, or something that will drive value in the future.
4. Software Engineering is human Engineering
In my early career, I was always focused on learning the top technology, the state of the art. But as I grew in level and experience, people skills were the one that helped me the most. Whether it is asking for help, conveying my concerns in a way that everyone in the room cares, asking client team to check if the issue mitigated or working with manager for getting the presentation out to the senior leadership, working with reportees to get the features out — it’s all about interacting with humans.
One of the biggest signs of respect for your coworkers is listening to them and then changing your mind afterwards.
— Staff Engineer: Leadership Beyond the Management Track by Will Larson
One of my colleagues once told me casually on coffee, “No one wants to be that person who could not deliver the things on time. We are all trying.”
And as much as you, everyone is trying to figure out, everyone is for the first time this-day year old. Even someone not acting the way you intend them to try learning about it rather than questioning them. When someone just cannot agree with your proposal, try meeting with them personally and learn about their concerns. If you want people to care about what you care about, better care about them.
Feedback is great way to be better at working with others. Ask for feedback, not only from your manager but also from the colleagues. One time, one colleagues told me that I do not give him full context of the issue when I add him for his expertise in the thread with full of people. He has to go through the whole thread, and it delays him from providing input. I was so thankful for him giving me this feedback, there was no way for me knowing this, unless someone tells me upfront. Being open and welcome towards the feedback enables working with others more efficiently and effectively.
Thank you for reading.
