Sometimes you have to unlearn
If you’re a software engineer, you’re expected to write good code. There are different criteria for what is good code but basically you don’t code whatever comes first to your mind. You try to think on the best solution, make it clean, somewhat scalable and even prepared for future extensions. This sets a coding mindset that is good for your career, but not always.
All of this requires extra effort. Sometimes, there’s no time for any extra effort. Like when building a brand new project MVP.
If you try to build a small MVP with a very tight time constraint, this mindset can make you fail. You have to unlearn and reset this mindset to be successful.
You have to use whatever framework you need to (or ditch them), search for the most direct way of implementing stuff, even if it’s very bad code. It doesn’t matter, it’s not the goal.
Do copy paste, do reuse whatever code you have, do duplicate code, code no tests, do manual end to end tests like an user would do. Do whatever is faster. You will have bugs and the code will be brittle and you will have to refactor but, who cares!
The goal is to create the MVP and validate the idea. That’s an MVP about.
These are my reflections after my first Hackaton, where I discovered that this MVP mindset was the same I have when creating electronics prototypes with protoboards.
Twitter
