By the end of this month, I will have exactly 1 year of professional experience as a software engineer. 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. 😉
Let's start!
I will ask for help faster.
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.
I will think first, build second.
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 will use code reviews and pull requests as a learning environment.
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. :-)
I will not be afraid to tackle something new.
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?
I will build more side projects.
Confession time! Unlike many other engineers, I hardly have a side project graveyard (spoiler: it's not because I finish 99% 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 criticizing every single project idea I came up with, and guess what? Most of the time I 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.
I will no longer copy and paste mindlessly.
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.
That's all for today! 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 create?
Oldest comments (26)
Good one, Take care of your health too , Read this and this, hope helps.
The golden rules, nice reading Pauline!
Thanks for sharing that. You posted things that I will definitely incorporate as well. I'd like to learn something new about development everyday. It can be something small but I think it will build over time. This Ted talk is really what I'd like to be able to do.
youtube.com/watch?v=TQMbvJNRpLE
Very nice thinking, I like it and I will apply some of the habits you have mentioned.
@httpspauline of course all those habits you mentioned are very noble and would be great for your progress but, the best thing for you to improve you are already doing - self-reflection and introspection.
I think the moment we believe that we know everything and stop searching for improvement it is the time our decline starts, the moment that we start being less effective and stagnant as the world around us changes and improves at fast pace.
Keep up the spirit.
Take more energy drinks.
That's a lot of self-awarenesa after just one year, mad props for realizing those conclusions! In addition to PRs, I would encourage you to go to co-workers before you start coding and share your design with them. I think that's where I learned the most: figuring out how our Enterprise architect envisioned a problem vs my perception and learning why we can't to different conclusions.
Since you've demonstrated self-awarenesa, apply it here as well. See if you can put together why co-workers think the way they do. Some people get so absorbed in programming they forget about the user. People who have lost a business venture before tend to be very risk-adverse. Some people just parrot whatever they read about online.
You have your entire career ahead of you. There's a lot of things I wish I would have done differently over the past seven years of my career and coding more is not one of them. Definitely find something that fascinates you to tinker with, but it sounds like you're on a good path. Burnout is very really and it sucks ass and hopefully you don't get to know it as well as I did.
Pretty sure I use alt-tab more religiously than ctrl+c/v now that I think about it.
Excellent post, thank you for writing it!
One thing worth trying with copy-pasting: It's fine to copy-paste just to see if something works, or just to see how it works. But then once you do that, comment out everything you've copy-pasted, and put everything back one line at a time, while writing some notes on how each step works (and/or some questions to ask others to sharpen your understanding)
In other words, it's fine to copy and paste as part of a spike, especially if done on its own branch that you don't intend to merge into your production code. Then you go back, try to understand it, and do the thing for real after that.
All that said, it seems like as long as you follow your own advice, you're in for an awesome year of growth!
Great items! I loved the matter fact you described your issues. "These are not faults just items I can change." Great attitude!
Pauline,
Thanks for sharing from your experiences. I am self teaching and I may never get to code professionally because I'm already in my 60's, but I am going to follow you and your progress and try to imitate some of the lessons you have shared.
Thank you,
Donald
Its never too late to learn. You are the living example.
totally agree with you never !
What do you mean by never never get to code professionally. You have a lot of experience in life. You may still be successful in this new field. You may encounter something new by combining tech with your experience. You never know. Mindset is the key
Thank you Joao. What I mean is that I am likely to not look for a job coding. I have several ideas that I would like to implement. If they become profitable all the better. My wife and I retired last year and we want to take summers off to travel.
But, your concern is very much appreciated because I do wonder sometimes if I'll get there.
very good article! in the part about side project i feel the same, never finish my own projects because i think its not perfect... then i try to do simple solid projects. Even though the project is simple, i try to use new ways to train and improve my own knowledgement about what im working on
I just keep on working, studying and learning stack being used in the company. and of course on my free time I try to learn things that are not included in the company's development stack, and i always keep in mind that dont just learn to code, but learn to create. So always do create stuff and try to implement things/tools you are comfortable with. In that way you'll grow as a software developer.
Reading one blog everyday, which is not directly related to my core skills.
I often skim through the blogs or read parts of it. I decided to read every single character of that blog and try to really understand rather than skimming through dozens of them.
Hey Pauline!
First of all, thank you so much for sharing your experiences, I enjoyed reading your article.
If you have not implemented some active time (workouts, runs, any kind of exercise) into your weekly routine, make sure you do! You would be surprised how much it increases your productivity and creativity!
V/R
Oliver
Some comments may only be visible to logged-in visitors. Sign in to view all comments.