There’s no point in hiding the fact that quite for a while I’ve been dealing with a few rather messy projects — and in doing so, together with others working on these, I have found come across all sorts of shenanigans and oddities (caused quite often by myself and not just the others) which, with a bit of fore-thought and a bit of “voice of experience”, I feel could have been avoided. As such, what follows is just a random set of thoughts on various coding and IT-related matters from yours truly (the angry mob — as The Kaiser Chiefs have put it 🙂 )

I suggest you put together a similar one, if you’re a coder yourself, and revisit it often — being reminded occasionally of the simplest things does seem to help! And when you’re buried deep in the guts of a complex project, you quite likely won’t remember all of these — having them “there” in front of you, I found it helps…

Last but not least — this is advice I give myself, might work for others, but since we’re all individuals (like everybody else :D) things might work out different for you, so filter before applying!

• Really simple code is really hard to write
• A high level overview will always hide away the important details
• If something is easy to understand, it simply means that someone put on a lot of hard work in designing and implementing it, so more than likely it wasn’t easy to build! Even more so, it didn’t take 2 minutes to put together.
• Remember perl? There’s more than one ways of doing it — that holds true for pretty much everything nowadays. Don’t let anyone tell you otherwise — and if they insist on that, just know they got no idea what they’re talking about and smile.
• In line with that there is no best way of doing things — just a lot of good ways of doing so. This is where I agree with Thomas — it’s right to do something that will get you past the finish line quicker and easier, so disregard the idea of “industry standards” and other buzzwords created by idiots in board meetings and choose the one that works for you.
• Still, keep in mind that the first thing that will probably come to mind, when faced with a problem, will be just a “draft” of the solution — sometimes that won’t even be the easiest or the most elegant way of doing something!
• It’s OK to dump the initial approach to a project on the basis that it was wrong — or at least not so good; ultimately your goal is not to prove (to yourself or others) that your initial gut instinct was correct, but rather to deliver a solution.
• Because there is no such thing as a “best solution”, this simply means there is always room for improvement — that is not a bad thing! It simply means you always have space for innovation, not that you haven’t done your job.
• If you think you’re the best amongst your peers/colleagues/friends, it simply means you don’t know enough people.
• There’s no such thing as a “small patch” or a “one line fix”.
• Always tag your source repository (or create a backup if you haven’t got one) before you start refactoring — it will take you lots of go before you get it right.
• Using Spring won’t solve your development problems — nor will switching to Maven; it will simply alleviate the infrastructure ones.
• “Latest technology” quite often reads “no manuals and how/to’s” — plan a lot more time around integrating that in your platform.
• Before you plan for “cloud agnosticism” make sure you have deployed a fully working system on a cloud.
• And also remember that “cloud-based” doesn’t read “better”!
• That library/component you need, someone else quite likely needed it before — have a look at the open-source community first and see if it’s not out there before re-inventing the wheel.
• Standards are out there for a reason — try to follow them.
• Beware of the coders who prefer public variables to get/set pairs.
• Unit tests help you eliminate errors — however, it’s better to release a version with bugs in it than not to release at all! In the wise words of Jamie Zawinski, if you have to cut down on code you write to meet the deadline, cut down on your unit tests.
• Development processes and procedures are there to help you do things better, not to slow you down — if you find yourself that’s not the case stop turning up for those meetings and calls that waste your time: quite likely they will disappear in time if everyone else does the same.
• You cannot measure productivity based on number of issues in your issue tracking system or the number of lines written.
• Just because an approach looks unusual it doesn’t mean it’s wrong — sticking to the beaten track might guarantee less failure but it will also block innovation!