First, just ship Software that works!
Getting into the habit of building and shipping software that just works, is easy to maintain, and then optimize and prettify it. 💥
As a Software Engineer, get into the habit of shipping software that just works and is easy to maintain.
Now, you might have heard "get it to work" often. Now, that still means you pay attention to the fundamentals of building good software to ship something that's reasonably good quality. These tips are even more important when building Prototypes!
Software that works, it might not be the best tech of capable of handling million requests per minute and is neither ready for all the problems that scale brings with itself. It solves your customers problems readily, and easily and there's scope for improvement. The first few builds might not even have all the SOLID principles implemented, and might require a few refactors, that's okay. The exception is unless you're building for scale from day 1, in that case, you need to go beyond "just works".
You don't compromise on code quality, but at the same time know when to apply certain practises or not. For instance, a DRY violation in your code might be better than introducing premature abstractions that make the code hard for developers to read and maintain. This also doesn't mean that you don't build necessary abstractions, you just know where to draw the line.
Incrementally develop and iterate. You don't build everything that's necessary on day 1. You gradually tweak the system and add improvements as the needs of the customers present themselves. Ideally, it's good to have a git workflow and a development cycle that supports incremental development. This also prevents scope creep and makes the requirements clear and precise.
No compromise on testing and avoiding regression. In my opinion, it's impossible to build functional software without sufficient testing. You might not have automated tests (e2e / unit tests) in your codebase, but you have a manual testing checklist at the bare minimum which checks out all the edge cases. It's good to have automated tests, because it reduces regression (breaking old functionality in favour of new functionality). If you're building a prototype and are tight on time, at least create a decent manual testing playbook that developers can follow before shipping new code.
Your GTM (Go To Market) time is critical, you want to ship fast to reach PMF (Product-Market Fit) and won't get time to prioritise all the "codebase improvements" that you have planned. In that case, you need to strategically take on some tech debt to further business goals. However, be watchful of tech debt, it piles up quickly!
When in doubt, focus on "getting it to work" instead of prematurely optimising for future requirements.
Remember the YAGNI principle — You Ain't Gonna Need It!
— AdiPat
If you're looking for someone to build your startup MVP, contact me!
I actively work on Open Source Software, check out my GitHub Profile. ✨
Follow me on Instagram (@adityapatange), I talk about tech, meditation, startups and hip hop! ⚡️
I write byte-sized insights on Threads to supercharge your day. 💡