Tuesday, 1 December 2009

How to be a Rock Star Developer

Here is the Google Wave text that was taken down by some helpful community members from my talk at the recent London Java Community Unconference.

I plan to expand greatly on this talk with hard examples of the various points, let me know if you've got any useful examples you'd like to add!

Get the Rock Star attitude

  • Be passionate, care about the code
  • Be a leader - look at new approaches e.g. BDD, New JVM Languages
  • Be personable, stop and listen! - The person who directs a project the most is one that is the most effective communicator
  • help newcomers, they give you a fresh perspective - explaining things helps your understanding

Be inspired by the rock gods

  • Don't reinvent the wheel, covers are rarely as good
  • Read blogs and community sites - stuff that is not part of your every day blogs - e.g. Kathy Sierra - high level thinking
  • Stand on the shoulders of giants - smart people have tread that path before, so use their insights

Be part of a band

  • dont code in isolation - everyone needs a team - coding in isolation leads to be lost in your own little world - very few ideas / service that you can build that a team can't do better
  • Talk to the users early
  • The developer who communicate has most influence - many ways to communicate, try do it as clearly as possible to be effective
  • Bounce ideas off others - a wider audience can give you a wider range of feedback than your local team

Play a Fender Stratocaster

  • Do development on a fast PC
  • Use a big tft screen or have several screens
  • Make your environment comfortable

Open your mind

  • Learn how to look up reference material, trying not to learn api's verbatim
  • Read books on development - podcasts, video clubs etc
  • Read code by the experts - many references externally and internally
  • Learn a different type of language e.g. if you work with an OO language, dabble with a functional language, shell script - avoids the Golden hammer

know your studio

  • Learn your ide inside out to be as productive as possible - saves 5,10,30 mins then hours a week
  • Run a continuous integration server - early feedback
  • Use source control - don't lose those songs - big investment bank lost all source code because of 2 primadonas keeping code locally and had a power glitch.
  • Know your OS/Hardware/System Architecture - sockets open, threads, etc


  • Go back and enhance your old code - how do you convince the management - discuss financial impact of leaving bugs / features in the system - continuous cycle of self improvement
  • Get cold hard feedback - dont be too precious about your code - OSS has the source of a thousand eyes - commits go to a committers mailing list so people know what to review and can give feedback early - using patch files - fisheyes - no one writes perfect code
  • At least briefly research yourself before asking others - use google instead of embarassing yourself on a public mailing list
  • Run test suites

Polish your songs before the album release

  • Keep source code neat and tidy (Checklist) - read The Daily WTF website for examples of bad formatting
  • Reduce the simple bugs (PMD, Findbugs and more) - use Find bugs to give you better ways to do things, like an expert on your shoulder
  • Comment you public apis (Javadocs) - if you provide an API define at least what to call and what to return, to otherwise people will not want to use it


  1. Great article. Good points, all of them. WRT learning the IDE, be sure to learn the hot-keys.

  2. It's really a Nice article Martijn. Thanks for sharing those great points.

  3. Thanks for the comments guys, I didn't even realise that they were there! Must look at my comment settings :).

  4. The successful developer is a problem solver.
    The successful developer is a learner.
    The successful developer is a listener.
    The successful developer is a researcher.

  5. Good points, anon! I like how's it's laid out like a poem :)

  6. Great post. I love it. Need to mark it somehow to be able return back to it time to time.