On the road to being a better developer

Everyone wants to be good in what he’s doing – that’s human nature, that’s how we’re raised. The key is constant improvement without being disappointed by small failures and bumps on the way. In the last 10 years I’ve been working as a developer and I feel I’ve learnt a lot of valuable lessons – many of which can be applied to other areas of life and work. Let me share my lessons with you, dear reader.

Without specific order, a’la ad hoc:

Lesson #1 – See the big picture

It’s very easy to get lost in details, focus on small things and lose the vision. The whole is always more than the sum of its parts. Even if you’re only a rookie coder, try to look for other aspects of your projects – business, social, whatever those aspects might be. When you’re working as a professional, coding is not l’art pour l’art anymore – it has a reason and a goal. The goal is never ‘completing coding tasks’. It is the same thing as the concept of ‘done done’ in agile development – a project is only done when it is tested, accepted, goes live, tested in the wild again and regressions are fixed. The final test is rarely technical rather has more to do with management and concepts like profit, brand building and customer/user satisfaction. To be successful in this manner, you must always have the global vision of the project in sight.

Lesson #2 – Take your time

It might sound easy and natural, but it’s usually really hard when deadlines are closing in. Don’t go for speed, though, speed will give birth to lost focus and neglect – bugs. In the end it will cost you more time, energy and morale. Speed will naturally come with good design and architectural choices and solutions, plus with experience and proficiency. These things you cannot achieve while rushing. Note that it has nothing to do with being lazy or mooning around, those are bad habits.

Lesson #3 – When things go wrong, be ready for a paradigm shift

This also takes time and experience, but it’s an invaluable thing. When technologies and solutions become slow or unusable, you should stop trying to fit new problems into old schema – look for alternatives. The recent NoSQL ‘movement’ is such an example – but also, where a proven old solution is good, don’t go for the hype and use a trendy lib or software. If your good old relational DB scales well for your problem, there’s no reason to use a NoSQL server. The same goes for functional languages – just because you can have a more elegant solution, don’t introduce a new language into your codebase. If, on the other hand, your OO paradigm seems unnatural and ineffective for the problem, look for a functional solution. For this, stay up to date with new trends, read a few interesting articles about new technologies at least weekly. See my ‘Top 5 trends in sw tech‘ for example.

Read more: implements Developer {

Posted via email from Jasper-net