Growing up, amongst all the superheroes, I was most inspired by Batman. The top reason was that he was an ordinary person, but his tools made him extraordinary. As a software engineer, I loved tools/apps that gave me superpowers - going from vim to IntelliJ - superpower, switching from
Early on as an engineer, my default mode of operation was - to write code and follow it up with unit tests to ensure the code is working as expected. If needed, add additional tests to ensure the highest possible code coverage, and build confidence before pushing code to production.
“But I don’t know how to make time to do code reviews, I am super busy executing on my own project”. Does that resonate with you? Read on to learn how I put systems in place to break the cycle and make code reviewing a daily habit early on
While I was busy getting stuff done, I often wondered and asked my mentors how I could go that extra mile to create leverageable work.
Similar to writer's block, that authors experience, early on as an engineer I struggled with ‘reviewer block’ i.e. having a hard time providing valuable feedback when reviewing an engineering design. Here are some tricks that I’ve picked up over the years that proved valuable. Build it I start
Contrary to popular perceptions, I’ve come to realize engineers do not exclusively work on building new products. Engineering sometimes involves designing new systems, but can also entail evolving older legacy systems, scaling products, and maintaining good hygiene by cleaning up unused modules. It’s not only about solving problems