When I originally published this article on dev.to, I had exactly 1 year of professional experience as a software engineer. In the meantime, I've hit the 2-year mark but I believe what I wrote is still relevant so I've decided to resurface this article. 👩🏻💻 Enjoy reading!
As my skills improve, the expectations (set by myself as well as by those around me) are increasing too. Based on this as well as continuous self-reflection and introspection, I have identified a few things I want to change about myself and my working style in order to level up as a developer.
The purpose of this article is to inspire you to think about your own room for improvement, or perhaps you can relate to several of my bad habits and have some additional ideas on how to adjust them. Oh, and I guess it’s partially to hold myself accountable as well. 😉
I'm going to kick off with one of the habits that I want to develop most: spend less time stuck on problems, no matter how big or small it is. Within the past 12 months of writing production code, there have definitely been a few days where I have honestly wasted more time than I would like to admit.
I suppose the good thing is that I can be extremely persistent whenever I am stuck on a specific problem. I know with 100% certainty that I can solve the problem at hand (eventually, ha!). The downside, however, is that it can of course come at the cost of efficiency. I will try to be more result-driven rather than repeatedly trying to prove to myself that I can handle something individually. I was once told to never spend more than 1 hour stuck on something, and sometimes the faster and more efficient way to learn something is to simply ask someone.
Ironically enough I wrote about this in one of the articles of my junior developer survival guide series, but catch myself not doing this often enough at all. Especially as a front end developer, I love seeing my changes come to life on my screen. I love to immediately dive straight into the codebase and get my hands dirty. Unfortunately, every once in a while this happens without really thinking about what has to be done and where changes have to be made, and in which order, etc., leading me to have to undo or revise my changes again. From this point onwards, I would like to slow down where needed and view the problem at hand from a bigger perspective.
I am incredibly grateful to be surrounded by talented and skilled engineers. Engineers who sometimes work on rather advanced features, which I am then being asked to review. Yikes.
To be honest with you, I used to stay away from reviewing these PRs because I was having thoughts such as “this implementation is quite complex, I highly doubt my knowledge is sufficient to review this properly” or "someone else will leave more helpful feedback". However, from now on I will no longer let some PRs by peers intimidate me and instead I'll focus on reviewing the parts that I am comfortable with. Then, I am going to ask as many questions as I can about the parts I feel less comfortable with, and will challenge my colleagues to verbalize their thoughts and logic.
On top of that, I am going to pay more attention to the feedback I see in the PRs of my colleagues (which is left by others). It’s not uncommon for there to be a lot of knowledge sharing and if I don’t understand the comment, I will simply ask. :-)
While going through the tickets in the current sprint that still have to be picked up, I noticed that I tend to gravitate towards simple or small tasks that I know I can solve quickly and without difficulty. I believe a contributing factor to this may be the fact that when I first started writing code during my internship, my tickets would often be the only ones still in progress (or waiting for acceptance) on the last day of the sprint and I would feel seriously guilty about this.
I’d love to start embracing new challenges without being afraid of the unknowns, and to pick up work that’s in my stretch zone rather than my comfort zone. The less you know, the more you can learn, right?
Confession time! Unlike many other engineers, I hardly have a side project graveyard (spoiler: it's not because I finish all of my projects 🤪). I always had the urge, this inner requirement, to build side projects that are useful, beautifully designed, and could add value to my life. I was severely criticising every single project idea I came up with so naturally, I often ended up building nothing at all.
In the coming months, I am going to simply build projects solely for my own eyes to see and to place focus on my own learning and development rather than trying to put the next big thing out into the world.
Copying and pasting is something that greatly simplifies our lives as engineers and it's probably also our most used keyboard shortcut. Truth be told, I may or may not use this handy-dandy shortcut more than I should. Being extremely focused on the implementation of a ticket (once again, gotta move that ticket from the ‘to do’ to the ‘done’ column), I used to often copy and paste code without truly understanding what was going on. Even though my feature would work perfectly fine, I never really knew exactly why (yikes, way to feed my own imposter syndrome 😅).
Moving forward, I will take my sweet time to be more cautious of what and why I am re-using certain pieces of code.
If you’ve made it this far, thank you so much for reading! 🙌🏻 Now I'm curious to hear from you — what is a new (developer) habit you would like to adjust or create?