Today I bought The Passionate Programmer from the Pragmatic Bookstore; this is the 2nd Edition of My Job Went to India: 52 Ways to Save Your Job and has been re-targeted more clearly at becoming an ‘awesome developer’ rather than ‘doing enough to not get fired’ which the earlier title implied. While buying this I was distracted by a post on The Pragmatic Life blog called Share Your Passion which inspired me to share what it is that makes us (the bloggers here) passionate about developing software. BTW: So far the book is great – thanks Chad.
There is synchronicity at play here; when we started this blog the other day we were toying with subtitles and one of the ones we considered seriously was a tongue in check ‘awesomeness codified’ (personally I still like this the best even though I didn’t come up with it :-P). Part of the reason we started this blog is to put stuff out in the public domain to get feedback. To reach out to people who know and understand more than us in the public domain and to share what we’ve found to those close behind us on the curve. We are hoping to get the sort of feedback that will help us move closer to ‘awesomeness’ in software development. We also want to have a place to whinge about things we find annoying :-P.
Each of us is near the top of the chain in our organisation; we have broad and deep skills in many areas of the Java and Java EE space and have been around the block many times in both successful and failed projects; we’ve been shouted at, we’ve worked all night, gotten depressed and received accolades and glory. Also, a large part of our experience has been in banking – which has it’s own world of pain points but can also be a glorious industry to work in for a software developer.
Obviously you take the good with the bad – but how have we kept our heads above water (psychologically) during the bad times – it is because we are passionate about what we do and deep down we are still enjoying the cut and thrust of software development it even when the poo is hitting the fan.
We were discussing recently how much we enjoyed one night a few years ago where we were in the office all night and most of the next day (after a full days work too) because of the intensity of the situation that the business was in. Basically we received in one night far more volume than was expected and we had to ‘massage’ it through systems that were in their infancy and in no way ready to scale to the level of data we had to process. Regardless of how we got into this situation (obviously in an ideal world we might have planned better) we had to now manage it and were on the critical path of a successful or failed year end process (i.e. make or lose lotsa money). This meant that we had some very senior executive director level people in the business right down to the current season of graduate interns and us all working as a unit, in the zone, to get over the line. It was stressful, difficult and tiring but we felt a part of something; we were able to display skills and aptitudes in a very visible way and deliver results instantly, not just the results in managing overburdened systems but in joining business decisions using peripheral skills gained in building software for the business we were a part of. It was an environment of mutual trust and respect with everybody intensely focused on a positive outcome regardless of position or role in the business. This is awesomeness codified.
Anyway, back to the point – we want to become ‘awesome developers’. This doesn’t mean ‘they who know the most api calls in the java.lang package’ or ‘they who can make JBoss sing the national anthem – in a language of your choice (while washing the dishes)’*; it means we want to love what we are doing and to inspire others (in the space) to love what they are doing; it means we want to be able to deliver robust, reusable, reliable and ‘awesome’ solutions better and better every time; it means we accept that someone will always know more than us and that we will strive to meet those people that we might incorporate what they know into delivering better and better solutions; it means we want to be a part of and understand the businesses we work with and within, again so we can deliver better and better solutions; it means we want colleagues (it & business) to say ‘wow, they really care about what they do’.
So this is why we blog. We want the feedback; we want to attract developers who are already awesome – though they may not know it – to help us improve. However, to be brutally honest maybe we just want to be famous :).
* we can though, well – maybe not the dishes bit.