Often as a SWE, we have to meet deadlines and to deliver on time the code quality can decrease. Or worse, it is much harder to refactor bad code later.
How do you balance between doing things right and doing things fast?
For further actions, you may consider blocking this person and/or reporting abuse
Shwet Khatri -
Ron Northcutt -
Nick Tchayka -
Sagar Kava -
Once suspended, rattanakchea will not be able to comment or publish posts until their suspension is removed.
Once unsuspended, rattanakchea will be able to comment and publish posts again.
Once unpublished, all posts by rattanakchea will become hidden and only accessible to themselves.
If rattanakchea is not suspended, they can still re-publish their posts from their dashboard.
Once unpublished, this post will become invisible to the public and only accessible to Rattanak Chea.
They can still re-publish the post if they are not suspended.
Thanks for keeping DEV Community safe. Here is what you can do to flag rattanakchea:
Unflagging rattanakchea will restore default visibility to their posts.
Top comments (7)
Do things right first, and by right I also mean only the things you need to do.
YAGNI.
DRY.
By cutting out what you don't really need the things that you do right will be faster.
So true. The first time I came across YAGNI, I wasn't convinced. The second time -- with more failures behind me -- the concept clicked. Then it changed my whole outlook on work.
I usually present information to management and product owners that "if we do X it will be fast but have Y thing happen later" and "if we do Z then that it won't happen BUT will take longer". There is a really nice freedom in being senior enough to advise but not to decide.
Seems a false dichotomy. If you don't do things the right way, you will inevitably have to go back and fix them. Which is another way of saying, "you'll have to do the work twice" ...which is generally slower than doing it once.
Do both. Have a framework or design pattern in place to remove the "doing things right" aspect. Then if you have that framework or design pattern already, "doing things fast" is a natural outcome.
Now if you have all this, of course you charge double!
When I am clearly in this time-crunch situation, like getting prepped for a conference where we are showing new products, I typically skip the documentation side with a promise to come back to it later. So I do skip non-code dev stages when needed.
If the time crunch is super silly, I plan out the feature-set and split it into phases. Then I communicate with the client on what their priorities are and prioritize.
I tend to make things right first so it's easier to make things faster afterwards. A good software foundation is a must for incremental development.
Saying its a false dichotomy is quite easy when there is no deadline. But its quite a different story when deadline hits hard.
So, handling this topic is the most hardest thing when you're in a leading role of a project. For me, it is more a prior subject to hold a deadline. You can always refactor code later on. But you can't refactor time. So when it comes to this point, my advice would be: hold the line, refactor later.
A customer is more impressed, when your team can do its job even if the pressure is hard. But no customer will value the code you or your team will deploy. As long as it works as intended.