Dear new developer,
I was reviewing a book outline for a friend who is writing a book on software development. As I read over his (quite detailed) outline, I realized he was missing this concept, which I feel all devs should learn: It is far better to build the correct piece of software than it is to develop software correctly but not ship it.
You may think I’m exaggerating–of course these high paid software engineers deliver code. But the tendency to fart around and not ship is pretty strong. It can be political, it can be because tasks are overwhelming, or it can be cultural. Shipping is hard, and it is way more fun to focus on tabs vs spaces, design patterns, or other shiny things. New programming languages and frameworks are especially easy for me to get wrapped up in.
I find it so so much easier to start things than to finish them.
But if you don’t finish, if you don’t ship, you never get feedback and your users never get the thing that they actually want.
In other words, the perfectly architected piece of software that is 95% complete, never exposed to the harsh real world, is pretty worthless. At best it may be of academic interest and the author may have learned a few things that can be applied to other projects.
It’s the collision with the real world, with the users who want features and bugfixes, who complain and push, who buy or ghost, who actually put your software to use, that makes software great.
I’ve never felt more joy at work then when I was at a startup and I read a bug report and ship a fix the same day. The users were delighted, I had a visceral understanding of the value of my role, and the software improved before our very eyes.
To sum up, it is good to focus on the tools of your craft. (See these posts for more on that.) But at the end of the day, shipping necessarily imperfect software is more important than choosing the perfect framework, building the best abstraction, or documenting the heck out of a fiddly bit of code.
Sincerely,
Dan
Letters To A New Developer 