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.

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.

Lesson #4 – Keep your brain trained

Don’t settle with everyday tasks, do some extra training. Look for problems at sites like Code Golf or Project Euler and try as many solutions as you can think of and compare them. Also practice maths, especially set , graph and group theories, they can be real life savers when you come across some harder algorithmical problem. Being a developer does not stop when you leave your desk in the afternoon – it’s a lifestyle. Also, good ideas usually come when you’re not working, so:

Lesson #5 – Have/get a life

This is probably the most important one. Young geeks may seem like programming gods, but that fire can burn out fast. Without proper rest and motivation you won’t last long in this business. Minimize overtime working by doing your job well and having a decent relation with project managers, thus encouraging proper planning. Sleep, sleep, sleep. Staying up one or two nights can be inevitable sometimes, but watch out because this can easily harden into a pattern – and your brain needs sleep. You won’t get far with sleep deprivation. Also be social, have a family, friends and have as much fun as possible, your brain also needs diverse activities.

Lesson #6 – Focus

Focus on one thing at a time (without losing the big picture). Avoid multitasking (and thus interruption) as much as you can. Sometimes it’s just not possible in your office environment, but multitasking in your brain has the same price tag as in parallel programming: task switching is a tedious work for our brain too. You lose focus and subtle ideas and need much time getting back on track.

Lesson #7 – Be persistent

Don’t give up at the first failure. Or at the second. Try again. You can learn the most from your mistakes, not from your success stories. If all else fails, try to find a way around the problem (this is related to Lesson #3). In most of the cases you will find the right solution with time, trust me. Don’t be afraid or shy to ask for help – a fresh look at the problem might do miracles!

Lesson #8 – Measure

Always measure whatever you can. Don’t just ‘think’ your solution will be good enough. Don’t assume, see for yourself. Will that new color scheme attract more users to the sign-up form? Do some A/B testing and you’ll see. Human judgement and forecast is faulty. You’ll be surprised how far your estimate is from reality sometimes!

Lesson #9 – Don’t focus on code performance

Most of the times it’s irrelevant. Don’t spend two more days optimizing that page so it loads in 500ms instead of 550ms. It’s not worth it. Your users won’t see the difference and you’ve lost valuable time, you should have been working on your next task. There are other factors which are usually much more important – clarity, simplicity, elegance, for example.

Lesson #10 – Be ready to chop off features

Sometimes you just can’t complete the task in time. Be ready to make some sacrifices, reorder your list of to-do features by importance and just chop off the least important ones if you can. Later you can schedule an ‘after-party’ and complete those nitty-gritty featurettes. Don’t consider this as failing. It’s how our job is.

Lesson #11 – Have ‘coding standards’

Even if you’re not on a team – be consistent with yourself. That list of standards can and will evolve, of course, but always try to be consistent. It will save much time for you and your team .

Lesson #12 – Test

Consider testing as part of the job and plan, not some tedious extra work. Dedicate time for proper testing. Test on multiple levels. Test code consistency but more importantly do functional testing. Test with many people. Have a testing toolset at hand – a testing/staging server, software tools (RSpec, Cucumber, PhpUnit, etc.).

Lesson #13 – Usability

When doing UI development, keep usability principles at the top of your importance list. It’s hard, we all have our concepts but accept that a developer will never be able to see the UI as a normal user. It’s a fact. Do mockups, design plans, show them to many people – especially your future users if possible. Embrace criticism, it’s part of the process and it’s not personal insult.

Hello there! If you are new here, you might want to subscribe to the RSS feed for updates on this topic.Everyone wants to be good in what he’s doing –...

Tagged as: development, opinion, philosophy