Reflections at 6 months in indus

I recently reached a turning point in my career after finishing a rotation program. It has been a tumultuous experience with many ups and downs. Without going into too many specifics, these were some lessons and takeaways from my first 6 months in industry. If you can relate, please feel free to reach out and chat. I'd love to hear about and exchange experiences and stories.

Always ask and understand the root cause (e.g. business value, reasoning for architecture or procedural decision) of why something is being done—it will help you prioritize the things and projects that you are doing; it will help your team realize that sometimes ineffective practices are merely vestiges of legacy and open to change. Software should never be built in a vacuum— understand who is using your software and what purpose it serves.

Competence has very little to do with what it is usually associated with: prestigious educational or professional experience, years in industry, experience at company, intelligence, etc. Just because someone comes in with 10 years of industry experience and is ex-FB, ex-Google, or graduated from some prestigious university doesn't mean they are more qualified to do x. Similarly, the lack of such associations does not imply incompetence. In the short term, having the right set of skills and experiences is very useful. In the longer term, the willingness to work hard, learn, and teach is invaluable.

Try to understand the interests, skill sets, strengths, weaknesses and motivations of the people you work with. Try to respect and leverage that knowledge to the extent that you can. This will help you have a much better working relationship and likely a more productive team.

Tech debt and firefighting have many side effects that are often not fairly accounted for. For example, tech debt or the wrong architecture makes adding new features, on-boarding new team members, and debugging, much more difficult. For example, constant firefighting (e.g. manual intervention for something that can be automated) usually takes away from engineering velocity, achieves very little, teaches the firefighter very little, which will generally detract from the pleasures of working. When evaluating the cost of fixing tech debt vs. firefighting, you should not only take into account the lost engineering time from firefighting itself, but also the fact that it detracts from the efficiency and productivity of engineers, that the firefighting vs. meaningful work ratio will impact how much people enjoy working on the team, and the potential cost of high turnover and team's desirability reputation. Google's SRE book includes an excellent discussion on this subject: Eliminating Toil.

At an individual level,** taking care of yourself** is something that people do not sufficiently prioritize. Are you physically and mentally healthy? Are you happy with what you are learning and achieving? What do you need / can you do to get there?

Giving feedback to superiors is something that people do not do enough of. Misinterpreting superiors is something that people do all too often.

Don't be an asshole. This seems like common sense, but it is surprising how many people end up being an asshole to other people without intending to. Give constructive feedback timely, often, and privately. Acknowledge good work done publicly. Acknowledge effort and guide effort towards achievement. Avoid pinpointing blame on individuals. Look for process level changes that can prevent crises from happening again.

For a more nuanced treatment of maintaining a tech stack: Google SRE Book
For context on understanding business value: Mastering the Complex Sale