Code the shortest path first
evanlh.com
Code the shortest path first
1–10 of 115 posts
Re: Code the shortest path first
#2This is a balancing act. Spending the time later to undo all of the technical debt accumulated can take even longer.
Re: Code the shortest path first
#3This is excellent advice. I would only modify it to say that one should first focus on getting something working, not necessarily the shortest path Then you can refactor and improve the code before you actually deploy it to production.
Re: Code the shortest path first
#4This is a balancing act. Spending the time later to undo all of the technical debt accumulated can take even longer.
Yeah 100%. I'm not suggesting land technical debt, it's more about the approach to solving the problem in the early stages while you're still seeking a solution-- don't get bogged down by perfectly conforming to a bunch of intermediary abstractions on your way towards the goal.
Re: Code the shortest path first
#5tl;dr: long form version of "make it work, then make it pretty"
Re: Code the shortest path first
#6This is great, one modification that I would make is to add CI/CD and testing when there's a regression that was not expected, or when it makes development simpler. That way I don't have to think about the ,,right time'' to introduce these.
Re: Code the shortest path first
#7This is a balancing act. Spending the time later to undo all of the technical debt accumulated can take even longer.
And my cynical response is that, if you demonstrate something working too quickly in certain organizations, you will be voluntold to work on a new project before it has been factored at all.
Re: Code the shortest path first
#8You’re mixing product decisions with code decisions.
Product should make sure to create an MVP aka the fastest solution for A-B.
Code should be done right no matter what, you’re being paid as an expert to do that, if they would want whatever crappy code gets it done they would do it themselves with some nocode solution and test the hypothesis.
Re: Code the shortest path first
#9An alternative: Build a PoC first.
The reason coding the shortest path first feels better is that you hit milestones early. However, it is a major generator of technical debt, and fleshing out the project is the hard part that takes longer and introduces breaking changes.
Taking time to plan, getting the API planned in advance, generalising the code (obviously not TOO much), and so on might feel less rewarding at first, because the early milestones are the hard part. But do it right and you end up seeing everything fall into place in quick succession, according to plan - and that’s a much greater sense of achievement IMO. It is often also a quicker way of seeing large projects to completion, though it doesn’t always feel like it at the time.
Building a Proof of Concept allows you to get the best of both worlds. It allows you to be naive, it allows you to write the bare minimum, and it gets something working that others can try out and give feedback on. As a bonus, it doesn’t generate technical debt, because you don’t build on the PoC - you use it as a reference while building the actual thing.
Re: Code the shortest path first
#10You’re mixing product decisions with code decisions. Product should make sure to create an MVP aka the fastest solution for A-B. Code should be done right no matter what, you’re being paid as an expert to do that, if they would want whatever crappy code gets it done they would do it themselves with some nocode solution and test the hypothesis.
> Code should be done right no matter what, you’re being paid as an expert to do that
As I've written in a recent thread... that may be the case in the academic world, but certainly not in the business world, where time-to-market and profitability always trump code quality if not explicitly required / audited by client contracts.