Resist the quench for coding
We, software engineers, love to build.
The thrilling sensation of adding a feature or creating something new from scratch. The excitement of using the latest technology that we've been reading about on Hacker News for so long.
And thus, we build.
We dive into coding, into architecture, into design. Quenching another dose of the thrill.
I am guilty of this.
Yet, I came to believe that blindly following the thirst is by far the largest productivity killer. I believe that coding should be considered the very last resort, used only when all other options are exhausted.
Let me explain.
Development is very expensive. It takes a long time to finish. It requires future time investment. It requires maintenance and bug fixes. There is an opportunity cost, and there is a probability that our work won't be used in production, because the priorities have shifted.
No matter the team, the agile process or the technology stack, the development will always be this way - resource intensive. Coding slows down the company, drains the IT budget and creates technical debt for future.
So before blindly jumping into coding, take a step back. Understand arguments why the problem or the feature at hand needs to be built in the first place. Find if there is a way to simplify the problem. Find if there is an existing solution in-house or off-the-shelf that can be reused to solve it.
Fight that internal thirst as much as possible.
Only as the very last resort, only when all other options fail, start thinking about the very minimal coding solution to the problem you have and very cautiously take that first sip.
- ← Previous post: How a newline can ruin your Hive
- → Next post: Transition your career to big data
This blog is written by Marcel Krcah, an independent consultant for product-oriented software engineering. If you like what you read, sign up for my newsletter