5 things I wish I knew about software

Hindsight is always 20/20. There are a ton of things I sometimes think about that if I knew this when I started out coding I would have done things differently or I would have saved myself from so much hurt. This is a short list of a few things about software development I wish I knew when I had just started out.

Software is never finished only abandoned

I used to have fantasies of creating social networks that after designing and coding all the features I could leave it and it would run by itself forever while I pursued other things. That is so not true, every app you create is like a child. There is always a cost to it, it is always nagging you to update this or tweak that. There is always something to do on it and fully understanding this actually allows you to cut back on non-critical features in the beginning because you know if something is important you will have to build it eventually.

You will never know everything

This is one that took me sometime to accept. I always had this idea that one day I will wake up an be an expert coder. I will know all the answers to all the hard problems, build anything in any language and people will migrate from all over the world to hear me impart my sage coding knowledge on them. From my experience, there is such a variance in software and where it is used it will be insanely difficult to master it all and also a waste of time. Yes I have been doing web development for about 10 years now and yeah I know a few things about that, but when it comes to building games on the Xbox, I have not idea about that, coding a remote control for drones. I would not even know where to start. Making websites and would give me an advantage over someone that has never coded before in these things but I am far from ever knowing everything, just keeping up with my little piece of the pie is hard enough.

Do not join holy wars

A lot of people in the tech industry love to pick sides. Android versus iOS. Ruby versus Python and so on and so forth. Picking these kind of sides is only to your detriment. I have found being open to using whatever tool suits the job (after adequate research and not laziness) is the best approach.

Communicate a lot and often

You can never over communicate in a project. If you are working with teammates always keep them in the loop. Write clean git commits, message them when you need help, talk about your approaches to certain problems with them etc. If everyone on the team has an idea in what way the code is growing there will be less friction. This is something that is easier said than done. I struggle with it sometimes cause I am to focused on the code in front of me but the best projects are the ones where everyone is in sync. Oh but you always code alone? Document your code well. Your future self will thank you.

Fuck it ship it

One of the quotes I read a while ago that touched me was "You should always ship something you are ashamed of". If you are shipping things that you are proud of you have already spent too much time on it. I find this to be a very effective guideline, combined with my first point that software is never finished, shipping usable but imperfect code is a good way to get things to the hands of users as fast as possible and make sure you are creating the best code for your users buck moving forward.

Software is a process, it's never finished, it's always evolving. That's its nature. We know our software sucks. But it's shipping! Next time we'll do better, but even then it will be shitty. The only software that's perfect is one you're dreaming about. Real software crashes, loses data, is hard to learn and hard to use. But it's a process. We'll make it less shitty. Just watch! ~ Jeff Atwood