Originally published on the BigCommerce Developer Blog.
The idea for this post started over a beer.
I was catching up with Dan Murrell, Software ...
For further actions, you may consider blocking this person and/or reporting abuse
❤️ I can't say enough great things about this post. You've put so much that I just feel into words. Getting to the point where your code is written to benefit your current users as well as your future self/team is pretty close to dev nirvana.
The trick, I think, is finding the balance of what's good enough / acceptable to put out into the world right now, and that is incredibly sensitive to the team, the complexity of the features being developed, and the realities of building on a budget and a timeline.
This is so good. I want to get this post tattooed on the inside of my eyelids.
Thank you! It feels good to know this resonated with you 😊
Absolutely agree with your post, Karen. I know this from my own experience at my first tech company. I started working there straight after college and wrote code for an entire project as most freshers do; not following any clean code principles.
Fast forward a year, I was struggling to add new features or solve bugs in the existing code because it was so messed up.
Now, I try to keep my code as clean as possible right from the beginning. Refactoring is not a good excuse because people hardly take the time or the effort to refactor later.
On a side note, I support this idea 100%:
While abstractions are good and keep your code modular but too much abstraction can actually do more harm than good for you and for anyone coming in later.
Awesome, thanks for sharing your experience!
Thank you for this nice and "on spot" article.
It made me realise I did a lot of katas and dojos, however, readibility was never such a thing. We were more interested by TDD and finding nice algorithms. However, readability was not such a focused objective.
I think I should go back to wearing the white-belt and practice more explicitely the readability of the code.
Actually adding a linter later on a project is not a bad idea. Most of those tools offer a
-fixoption that works really well. At least as a starting point.Nice--that's a good tip :)
Great post. When we only focus on making code work we give future developers (or our future selves) a debt of maintainability and understandability.
Thanks, well put!
This Dan sounds like a smart guy, must be the name 🤣🤣. Thanks for the write-up Karen, good read 👍👍