DEV Community

loading...
Cover image for The Importance of Slowing (Way!) Down as a Junior Software Engineer

The Importance of Slowing (Way!) Down as a Junior Software Engineer

alexlsalt profile image Alex Morton Updated on ・2 min read

This post was originally published on January 30, 2021 on my blog.


I learned a ton this week at work. Seriously, a ton. And I loved every minute of it.

Well. I loved every minute of it in retrospect. During the week (and even the past month) it's been a bit of a rollercoaster. But I do love rollercoasters so I've got that going for me.

This week, one of my major wins was working on my biggest coding push to date (in the context of my new job) and it was a refactoring of several bits of code.

Along with the refactor itself, I was writing tests in the corresponding spec, and I seriously had zero experience writing tests.

Regardless, I took each task as it came. I submitted my code changes for review in GitHub and moved on to another task as I waited for the helpful review comments to come back with further hints in the right direction.

I pored over the comments and corrections and caught myself when I'd jump a little too quickly at making the changes - before fully and completely understanding the reasons behind the corrections.

That was a big shift from this week, actually! Stopping myself and not letting myself move forward on making further changes to my code before understanding every single word on the code review. Not only that, but not letting myself advance before I could potentially explain the reasoning to someone else regarding why a change was being suggested.

There was a certain magical moment when I consciously caught myself jumping straight into the code without fully understanding it, and I made myself restore the files, go back to the PR, and read the comment twice through, three times through, four, five, six more times through - until it finally clicked.

And that's the way it should be, too. I was so wrapped up in getting the code written and the PR merged that I wasn't slowing myself down enough to truly understand it.

But this is exactly what I mean when I say that we usually need to slow all the way down in order to actually go so much faster.

The act of me submitting more code changes that I didn't understand ran the risk of doing it completely wrong and spending more time than necessary going back-and-forth yet again with the code reviews.

On the other hand, slowing myself way, way, way down, reading through the corrections and suggestions several times through, and clarifying the suggestions in my own words ended up putting me on the right track and getting the PR approved and merged that much quicker.

This is such an exciting time, right at the beginning of this career in software engineering - I really feel like I'm drinking it all in and that every single moment at work is a chance to learn something new or take a lesson one level deeper.


Pssst! I send weekly newsletters about the self-taught coding journey and my own coding adventures (and misadventures!) Sign up here! >>

Discussion (8)

pic
Editor guide
Collapse
dzello profile image
Josh Dzielak 🔆

Great post Alex & congrats on making through your first deep dive into testing this week 🙌 The "go slow to go fast" mentality is so crucial for learning to code. It takes a lot of patience, as you point out, to dig deeper to verify your understanding of how something works especially when you can complete the story without it. Tests are a powerful tool because they will psychologically keep you from moving forward too fast, given that you write a failing test first when you're not sure how something works and want to explore it. Until the test is green, you won't be tempted to commit or get distracted by something else! "Red, green, refactor" is a mantra I picked up about the same time I started working with Ruby and RSpec and that's another one that's served me very well. Start with the failing test, write code that will make it pass (without caring what it looks like), and then go back and see if the structure of the code can be improved. Because you have a green test, you'll know if your refactoring broke anything.

Collapse
phongduong profile image
Collapse
_tewogbade profile image
OmoBamidele

Really nice post!

Collapse
javiersalcedopuyo profile image
Javier Salcedo

Great reminder even for more experienced devs! 👏🏻
I still find myself jumping to apply review changes way too quickly, specially on parts of the codebase I'm not that familiar with.

Collapse
geomc profile image
Sascha

Good point!

Collapse
codetivated profile image
Melissa Heying

Love this! Such a good reminder!

Collapse
alexlsalt profile image
Alex Morton Author

Yay!! Thanks Melissa! ✨

Collapse
eelstork profile image
Tea

Surprisingly thoughtful and well expressed.