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.
Top comments (7)
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.
Nice
Really nice post!
Yay!! Thanks Melissa! ✨
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.
Good point!
Surprisingly thoughtful and well expressed.