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:
Master a Few Languages and Stick To Them
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.
Coding Vs. Configuration - Track Your Time
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.
Use the Style You Feel Comfortable With
If you’re a JavaScript developer you know the way you use the language changes exhaustively - one month it’s using Common JS with browserify and the next Require JS woth AMD. Try and reduce your cognitive stress by sticking to a plausible style while coding and debugging. Most importantly keep focused on solving the problem at hand.
Actively Fight Complexity
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.
Share Knowledge
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.
Never Stop Learning
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.
