On Shipping Working Software
Working software is not easy to ship and takes alot of effort to get right. The good news is that with practice you can learn the skills needed to ship software that actually works well. Here are some of my thoughts for completing projects and getting them out of the door:
Often, we software developers feel there’s a better solution in another language that gives us a distinct advantage. Often, it’s not worth the extra effort to become proficinet with another tool. Remember you’ll have to learn the end to end process which includes production and deployment.
Surprisingly you spend a lot less time actually coding versus the time you spend configuring and picking the libraries that you need - I’ve called this decision fatigue before, especially for independent developers using mono repos. It might save you alot of time to sit down and write the code from scratch instead.
Think about tracking the time you take to do various jobs while programming, from choosing libraries, picking tools, writing tests and building prototypes. Concentrate on programming not configuring.
Fight code and system complexity every day, and in every aspect within the solution you or your team who represent the people you’re building software for. It goes beyond simple technical debt - in fact paying the technical debt often increases the complexity, because now you must cover more edge cases. The complexity usually creeps in unnoticed and unintentionally; yet another tool in the pipeline, another small prerequisite library, a few more steps to run through before one can test the application, yada yada.
Left unchecked, the simple prototype or new application slowly grows to be a monster.
Doing ones job is pretty easy. Code a little, test a little and maybe even demo the completed feature once in a way. The fact is, it’s much harder to actively share knowledge among team members. As time passes, we become insulated in a tiny bubble seeing only a part of the code and tools. Members of the same team might have overlapping bubbles and are slowly drifting away.
The key take away is, to really understand something, you need to teach it to others.
You have to stay sharp, and you can do that by doing side projects from time to time - contribute to open source projects or even micro libraries. Never lose the enjoyment you get by creating things out of nothing.