Coding is a means to an end. You were not hired to write code, you were hired to solve business problems and reach business goals, usually but necessarily by writing code. If you are interested in doing the job you were hired to do well, this is the lens through which you should consider most of your technical decisions. Invest your time and energy in such a way that the return in terms of reaching business goals is maximized.
Coding for the sake of some engineering ideal is, as far as the business is concerned, a waste of resources.
This isn’t to say that you should implement everything as the quickest and dirtiest hack you can come up with. Engineering ideals play an important role, but they need to be considered in context.
Businesses typically have multiple goals, reaching which takes time. So you’ll be coding for a while, the goals will change, new goals will be added. In most cases, these real world constraints imply that implementing the quickest hack is rarely a good solution, because most quick hacks don’t do well in terms of maintainability, testability, readability, and a bunch of other abilities that become important when you have to maintain your code over an extended period of time to achieve evolving business goals.
As with most things, it comes down to finding a balance. Quick hacks are on one end of the spectrum, and perfectly malleable, configureable, pluginable, flexible, and necessarily horribly over-designed system is on the other. The rule of thumb I eventually got to is:
Implement the feature by doing the least you can get away with without shooting your future self in the foot.
Doing this well requires some lookahead. You need to know what the likely paths forward are. Is the feature a light experiment, or something we’re committed to and going to evolve for a few months? Is it part of the core product, or is it secondary[1]? What are the success metrics? How likely are you to be able to make time in the future to address the shortcuts you took now?
Besides lookahead, you need to avoid doing things the wrong way. There’s a number of ways to implement a basic version of any feature in a way that will require a lot of refactoring to grow in the future. And there’s usually a similar in terms of length solution that will scale effortlessly. You need to figure out these patterns.
Things like everything should have a home and naming do wonders in terms of cheaply making your code compatible with the future.
ROI comes up in many other areas in programming. Maximizing for ROI quite literally allows you to have your efforts produce the most result, and that seems to be a desirable way to work.
[1] Orthogonally, though, it really pays dividends to not consider any code a second class citizen. The base level of code quality has to be high across the board, otherwise bad habits will quietly start appearing everywhere, including in what’s supposed to be highest quality code.
Comments
Post a Comment