software engineering – Mina Demian

More About Code Reviews, Impostor Syndrome, and Growing from Code Reviews

April 20, 2024

Following on from my last post, I saw a co-worker gracefully apply the principles of sound code reviews. It was comforting to see someone else on the same path as me. I observed myself while reading his comments. I didn’t feel attacked or questioned. His tone was curious and thoughtful.

I’ve observed this week that seeing code reviews as a part of engineering work, equal in value to coding and delivery, is starting to influence me. My thinking used to be upon submitting pull requests:

This meets the requirements.
This is as elegant and succinct as I am aware.
This passes tests.

Then, I would feel ashamed when comments come in about did you consider this? Why did you choose that? My internal dialogue became, I should have known this.

But the truth is that I often don’t have the full picture in my head of the entire codebase, or more experience, or the unique insights of another engineer. I only know what I’m operating on right now… if I’m not growing.

It got me thinking about a recent newsletter by The Hybrid Hacker entitled Dealing with Impostor Syndrome in the Engineering World. It was a uncomfortable, unsettling read in that it hit home deeply. I put exceedingly high expectations and requirements on myself to have thought of everything before a code review. And that’s simply impossible.

However, I can start to learn what my coworkers pick up on and ask questions about. Mining that can make me more thoughtful and compel me to improve. Learn more. Explore more. Skill up.

My wish with my new role was that I would get to work with senior engineers, to really level up my game, to sharpen steel against steel. And that has been fulfilled. For that, I’m grateful!

Getting Code Reviews Right

April 16, 2024

This is a few days late, but wanted to write it anyway to keep the discipline and routine going.

I subscribe to several really high-quality newsletters and one post last week was of immense use. It was Exactly What to Say in Code Reviews by Jordan Cutler.

Getting the tone, content, and style right in code reviews is a significant part of collaborating in engineering teams. It involves many trial-and-error iterations, a lot of self-reflection, and an understanding of the culture of the team you’re on.

So, Jordan’s post was like getting a well-constructed, time-tested, and solid toolbox for Christmas, for this part of engineering work.

I applied some of the principles while doing code reviews last week. I actually brought up the post and put it side-by-side with the pull requests.

Judging by my coworkers’ replies and comments, I knew that I had carried out some effective strategies.

Thank you, Jordan!

The Curse of Over-Engineering

June 30, 2018

We have two half days (affectionately known as Freaky Fridays) at work a month, where we get to work on our own projects or explore something new. Yesterday was dedicated to exploring Angular 2.

I thought that it might be a good opportunity to test it out in a real-world application – my Flashcards app to help me learn Swedish vocabulary.

The syntax isn’t too dissimilar from AngularJS, but rather is abstracted in more boilerplate code. Getting a basic app going, by following the Quickstart Guide, wasn’t too difficult.

Then, there was a knock at the door. It was Earl, the Grim Reaper of Over-Engineering. He asked me to remember that I am a software engineer and that everything has to be TIP TOP from build one.

So, the curse kicked in and I started scrambling to get the basic setup working with Webpack. I tried cramming in a Webpack tutorial, alongside the Angular 2 tutorial. Soon, it just became about cursing the day Webpack was built and racing through Stackoverflow, hoping someone else wrote something to make everything PERFECT now.

10 minutes before the end of the day, I realized… wait.

The goal was to learn Angular 2 and use it to build an app.

That’s it.

I told Earl that there was another engineer across the street, about to do something simple. He scurried away.

I gutted out the Webpack configuration and stuck with the lite-server package suggested in the Quickstart guide.

Moral of the story: fuck Earl and fuck over-engineering.

Learning How to Work in a Team

June 29, 2018

I am working on a new feature for one of our microservices. It’s about a medium-sized T-shirt that involves working with AngularJS’s ui-router, working with new API endpoints, and writing some CSS from scratch. I’m excited! And a little daunted…

To work against being overwhelmed and becoming unproductive, I focused on tackling the hardest part first – the routing and views. I knew that I was going to work with ui-router, so I read through a few tutorials and brushed up on routing in AngularJS.

I then put together quickly some mock views to connect to the new states and routes. This felt better than starting to code markup and styling, I had to remove the unknown first.

The tutorials only got me so far, so I stopped and thought about it. I did some searches on Google. After a few iterations on this cycle, I reached out to a coworker. Instead of telling him it’s broke give me the codes!, I explained what I had done, what I was trying to achieve, and what wasn’t happening as I expected. Rather than him coming to help me google, it turned into a discussion about patterns, structuring code, and a brief pair-programming to get something working quickly. I even got some praise that my initial concept is good and that I should just find the right balance, between sound design and time spent on the solution.

I thought of this article after the whole discussion with my coworker.