On the road to being a better developer

Posted by ochronus on Feb 25, 2010 in Featured Articles, theory | 35 comments

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.

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.



 

Related posts:

  1. Top 5 trends and technologies in software development

32 Tweets

35 comments

  1. Atamert Ölçgen
    February 26, 2010

    Excellent article.

    Lesson #2: People will fail at it again and again. They’ll write inadequate docs, superficial tests and crappy code becase the deadline is near.

    [Reply]

    ochronus Reply:
    February 26th, 2010 at 08:30

    @Atamert Ölçgen, Thanks :) I still (have to?) do it many times, but lesson #10 helps with this

    [Reply]

  2. Morningtime Digital Agency
    February 27, 2010

    Good suggestions, especially #1. A lot of people can’t see the difference between a detail and the whole project, between bug and the project going in the wrong direction completely. A group of mountaineers once believed to be makign progress climbing the Mt. Everest. Until the group leader looked over a rdige and saw an even taller mountain in the distance. “Guys, we fucked up. This isn’t mount Everest.” Of course nobody liked him, but he was right. When projects are going in the wrong direction, take a break, speak up, and deal with the crap.

    [Reply]

  3. Can Aydo?an
    February 27, 2010

    Superb. Thanks for this article.

    [Reply]

    ochronus Reply:
    February 27th, 2010 at 22:22

    @Can Aydo?an, thanks for the kind words.

    [Reply]

  4. Andre Dietisheim
    February 28, 2010

    #2 (and others):

    You mostly need a good project management to be able to take your time even in tough times. Project management that’s aware of the dangers of hurries and is capable to defend against upper management/project owners. I encounter that kind of scrum master hero only once in my career.

    [Reply]

    ochronus Reply:
    February 28th, 2010 at 18:11

    @Andre Dietisheim, yes, that’s what I’m heading for. At least I hope :) Fortunately at our company we PMs have a really good relationship with upper management (actually there’s only one person above us, who understands well how projects go). This is a true blessing.

    [Reply]

  5. Kevin
    February 28, 2010

    Lesson #3 can get really difficult to follow. This is because there can be a huge gap between the estimates that the marketing folk put in and what the developers can achieve. If the estimation by the business team is rigid and things cannot be done in a particular time frame, then something has to be cut somewhere. And usually it is the patience a developer has in doing a task in a right way. Instead of going for the best possible solution from a variety, the developer ends up with a solution which may seem the best at that particular point of time.

    [Reply]

  6. manivel
    March 1, 2010

    very nice article..

    [Reply]

  7. bhu1st
    March 23, 2010

    from tip #4 Being a developer does not stop when you leave your desk in the afternoon – it’s a lifestyle. yeah, if we could accept it as lifestyle things will naturally ease. thanks for this writing :)

    [Reply]

    ochronus Reply:
    March 23rd, 2010 at 15:21

    @bhu1st, Thanks for the kind words

    [Reply]

  8. Nirav Assar
    March 23, 2010

    Great article. A blog I wrote is relative to this information.

    http://assarconsulting.blogspot.com/2010/03/5-ways-to-think-wisely-in-development.html

    [Reply]

  9. Mohammad Tinawi
    March 24, 2010

    Gr8 Article
    @Lesson 9: Performance is a big issue 50ms for 1 user won’t count, but for 1 million user viewing this code, it will count for a big delay in service time for all, however this is always under weighted in favor of business requirements, so I think such optimization is important to be done but outside the scope of the first task in hand

    [Reply]

  10. godworm
    April 14, 2010

    This is good advice regardless of who you are or what you do.

    [Reply]

Trackbacks/Pingbacks

  1. Csaba Okrona - On the road to being a better developer http://is.gd/9bb4o
  2. guillaume sempe - On the road to being a better developer, 13 lessons for developpers http://j.mp/dksOhg
  3. Atamert Ölçgen - On the road to being a better developer http://is.gd/9du84
  4. cuerty - http://blog.mostof.it/being-a-better-developer - On the road to being a better developer
  5. ???? - From Yesterday: On The Road To Being A Better Developer http://bit.ly/bxDzbW
  6. uberVU - social comments - Social comments and analytics for this post... This post was mentioned on Twitter by ochronus: On the road to being a ...

Leave a Reply

Additional comments powered by BackType