When you first start out at a junior developer, there are so many things to learn. Coding conventions, code review, build tools, IDEs, custom hack jobs by former "genius" coders, the list goes on forever.
But one of the things I remember most clearly was getting into battles with senior devs about code quality. Why was this method crammed into this class with 100 other methods? Why were we duplicating code everywhere? Haven't you heard of DRY?!?
Shipping is King
The thing that these senior developers knew -- that I didn't -- was in a fast-paced development environment, shipping is king. If you don't ship quickly and often you aren't providing any value to your customer. Your customer is not you. You are not writing code for you. You are writing code for the people that pay you.
The truth of the matter is, that class with 100 methods, does its job just fine. It's ugly, it's hairy, and after I look at it I need to take a shower. But, it gets the job done without any fuss.
On the other hand, the perfectly created event-driven architecture with message passing and async communication might feel beautiful, but wait until you get paged at 2am to track down the problem. In that moment, all you can dream about is having a single class with 100 methods in it.
How to apply this attitude
Here are a few questions you should ask yourself when you are coding:
- Is this the simplest possible way to deliver this feature to the customer?
- Can I cut anything out from this?
- How will I debug this when something goes wrong?
- Is there an existing workflow I can modify to support this behavior?
I ask these questions to myself on a daily basis. Sometimes I even throw away a whole day's worth of coding just because I realized I got wayyyyy too deep into a rabbit hole. Thats okay. Better to throw away code now, then ship late with bloated architecture.
Check out my newsletter if you want more thoughts, or to connect more with me. I am open to advice and mentorship opportunities with any younger developers.
Top comments (0)