I have a new blog. I won't be abandoning tales of interest - not that it's bustling with activity - but I'll be writing all my work/tech related stuff on my other blog. If you're interested in that sort of thing, please go to:
http://perpetualdevelopment.wordpress.com/
And if you're not interested... well, you're welcome!
The Book of Revelation
Before you read any further be warned that I'm raising a Level 1 Geek Warning: if you are not in the software development industry, you'd probably enjoy your time better here.
Today, unlike most days recently, was a wonderful day at work. I actually didn't want to leave. I'm considering going to work early tomorrow. What happened? Well, let's go back in time a few months...
I think it all started with Ryan. Now, every day starts with Ryan talking. Usually before I get a chance to sit down and read my e-mail he's already bombarding me with questions about some obscure problem (perhaps only obscure because I'm only half-listening at this point). But those days he started talking about books - or more specifically, the interesting things he was learning about from those books - and I started to pay attention. He told me about this crazy mystical practice called 'test-driven development', where not only do the developers test all their code, but they write the tests before they write any code!?!?! I don't think I actually laughed at him, but I let him know that it all sounded well and good as an academic exercise, but it couldn't really be done in practice by sane individuals.
And so we moved on. Ryan kept reading and kept telling me to read these books, and I kept deflecting and diverting. Then something happened, and I'm not quite sure what it was (hey, I never claimed to be a good storyteller!) but I finally relented to the pressure. The book was 'The Pragmatic Programmer' by Andy Hunt and Dave Thomas (not of Wendy's fame). I don't want to say that this book changed my life, because I hate it when people say things like that. So, I'll just say that this book had a profound impact on how I view myself as a professional software developer. That sounds a lot less sappy.
This isn't a technical book. It's a book about good practices and good attitudes. It's about taking pride in one's career. The book is littered with tips, but here are the first five (which I also have posted on my office door) that I feel are applicable to anyone in any profession:
In a sense, this book revealed a whole new world to me. I had been blind as to how software development could be done. I didn't realize how much more I could be (and arguably should be) doing. And thus I started to read.
I have since read (and recommend)
The book I am currently reading is 'The Art of Unit Testing'. I'm not terribly fond of the format of this book (a lot of repetition), but it's a good beginner reference. I knew before reading this of the importance of formal unit testing (even though I had done little of it myself), but it has enlightened me to some techniques, common problems, and frameworks that could save a lot of time and effort in generating new tests.
So that brings me to today. I had been working on a connectivity bug over the last couple of days and during my analysis had uncovered a few 'loose ends' in the connectivity framework that Ryan and I had developed. Empowered by the 'fix broken windows' philosophy we decided to fix the root of the problems as opposed to patching the symptoms. The root of the problem was unfortunately embedded in the original design, but as Martin Fowler says: refactoring means never having to say you're sorry.
It was this morning that we first embarked on our first voyage of pair-programming test-driven-development. We had done plenty of pair-programming before (very successfully I might add), but never true test-driven-development (TDD). We knew that one of the main classes in our framework had too much varied responsibility, and we wanted to break that up. Instead of liberally ripping apart the code we wrote test cases to help guide how we wanted to refactor. Instead of building from the inside out (i.e. implementation->API), we were building from the outside in (usage->implementation).
This shift in thinking was phenomenal. Traditionally in developing something, I would figure out generally what a component needs to do, and then figure out the best way for it to do that (i.e. figure out the best implementation). The API would then be driven by the implementation. In the act of generating the test cases however, we were thinking about what we wanted to be able to do with the class, which in turn defined how we wanted to use the class. Thus, we first defined the API, and the implementation flowed naturally from there.
Now, perhaps this is how everyone else has been developing software and I've just been in the dark. But I've been around long enough to know that this isn't necessarily common practice, even if it is common sense to define the API and interactions first. The great thing about doing TDD is that it creates a smart and usable design, and you get a mechanism to automatically verify the functionality of your component. Two birds, one stone.
If you haven't tried or heard of TDD, don't laugh and discount it like I did; I encourage you to research it to see if it's right for you. And, as Ryan has already mentioned to most of our colleagues, if you value your career as a software developer, you owe it to yourself to read 'The Pragmatic Programmer'. Let me know if you want to borrow it.
Today, unlike most days recently, was a wonderful day at work. I actually didn't want to leave. I'm considering going to work early tomorrow. What happened? Well, let's go back in time a few months...
I think it all started with Ryan. Now, every day starts with Ryan talking. Usually before I get a chance to sit down and read my e-mail he's already bombarding me with questions about some obscure problem (perhaps only obscure because I'm only half-listening at this point). But those days he started talking about books - or more specifically, the interesting things he was learning about from those books - and I started to pay attention. He told me about this crazy mystical practice called 'test-driven development', where not only do the developers test all their code, but they write the tests before they write any code!?!?! I don't think I actually laughed at him, but I let him know that it all sounded well and good as an academic exercise, but it couldn't really be done in practice by sane individuals.
And so we moved on. Ryan kept reading and kept telling me to read these books, and I kept deflecting and diverting. Then something happened, and I'm not quite sure what it was (hey, I never claimed to be a good storyteller!) but I finally relented to the pressure. The book was 'The Pragmatic Programmer' by Andy Hunt and Dave Thomas (not of Wendy's fame). I don't want to say that this book changed my life, because I hate it when people say things like that. So, I'll just say that this book had a profound impact on how I view myself as a professional software developer. That sounds a lot less sappy.This isn't a technical book. It's a book about good practices and good attitudes. It's about taking pride in one's career. The book is littered with tips, but here are the first five (which I also have posted on my office door) that I feel are applicable to anyone in any profession:
Care About Your Craft
Why spend your life developing software unless you care about doing it well?
Provide Options, Don’t Make Lame Excuses
Instead of excuses, provide options. Don’t say it can’t be done; explain what can be done.
Be a Catalyst for Change
You can’t force change on people. Instead, show them how the future might be and help them participate in creating it.
Make Quality a Requirements Issue
Involve your users in determining the project’s real quality requirements.
Critically Analyze What You Read and Hear
Don’t be swayed by vendors, media hype, or dogma. Analyze information in terms of you and your project.
In a sense, this book revealed a whole new world to me. I had been blind as to how software development could be done. I didn't realize how much more I could be (and arguably should be) doing. And thus I started to read.
I have since read (and recommend)
- Implementing Lean Software Development: From Concept to Cash
- Practices of an Agile Developer
- Refactoring: Improving the Design of Existing Code (minus the large reference section)
The book I am currently reading is 'The Art of Unit Testing'. I'm not terribly fond of the format of this book (a lot of repetition), but it's a good beginner reference. I knew before reading this of the importance of formal unit testing (even though I had done little of it myself), but it has enlightened me to some techniques, common problems, and frameworks that could save a lot of time and effort in generating new tests.
So that brings me to today. I had been working on a connectivity bug over the last couple of days and during my analysis had uncovered a few 'loose ends' in the connectivity framework that Ryan and I had developed. Empowered by the 'fix broken windows' philosophy we decided to fix the root of the problems as opposed to patching the symptoms. The root of the problem was unfortunately embedded in the original design, but as Martin Fowler says: refactoring means never having to say you're sorry.
It was this morning that we first embarked on our first voyage of pair-programming test-driven-development. We had done plenty of pair-programming before (very successfully I might add), but never true test-driven-development (TDD). We knew that one of the main classes in our framework had too much varied responsibility, and we wanted to break that up. Instead of liberally ripping apart the code we wrote test cases to help guide how we wanted to refactor. Instead of building from the inside out (i.e. implementation->API), we were building from the outside in (usage->implementation).
This shift in thinking was phenomenal. Traditionally in developing something, I would figure out generally what a component needs to do, and then figure out the best way for it to do that (i.e. figure out the best implementation). The API would then be driven by the implementation. In the act of generating the test cases however, we were thinking about what we wanted to be able to do with the class, which in turn defined how we wanted to use the class. Thus, we first defined the API, and the implementation flowed naturally from there.
Now, perhaps this is how everyone else has been developing software and I've just been in the dark. But I've been around long enough to know that this isn't necessarily common practice, even if it is common sense to define the API and interactions first. The great thing about doing TDD is that it creates a smart and usable design, and you get a mechanism to automatically verify the functionality of your component. Two birds, one stone.
If you haven't tried or heard of TDD, don't laugh and discount it like I did; I encourage you to research it to see if it's right for you. And, as Ryan has already mentioned to most of our colleagues, if you value your career as a software developer, you owe it to yourself to read 'The Pragmatic Programmer'. Let me know if you want to borrow it.
How George got his mowing groove back
As most of you probably don't recall, several Earth Day's ago -- that is to say, three years ago, on Earth Day -- we bought a battery-powered lawn mower. It was a gesture to Mother Earth, but also an opportunity to avoid gas-permeated hands. I remember those days fondly.
But, frankly, the old lady doesn't quite cut it anymore (pun intended). I can mow the front and part of the back in one evening, and the rest has to wait until the next night (which is typically not actually the subsequent evening). I happen to have busy evenings so the grass gets longer faster than I'd like it too, particularly when the weather has been as rainy as it's been. So, we come to the second problem of the mower, which is that it doesn't really like cutting long grass.
I mean, it cuts long grass, but it doesn't cut George-long grass. (Some of you may be familiar with the George-hour... the concept is very similar.) And because of this critical deficiency, I made the painful but necessary decision to seek a replacement.
Meet, the Bull. El Toro, the Magnificent.
This beautiful piece of self-propelled machinery galloped across my jungle of a lawn, dragging me behind while indiscriminately gobbling up all the herbage in its path. This was definitely a sight to see. Instead of taking 2+ hours over the course of multiple days, it took me a total of 45 minutes to cut my entire lawn!
I must admit, the decision to replace my Earth-friendly yet cojones-deficient mower with a gas-guzzling grass-eating beast was not an easy one. It took me two years to actually admit I had a problem. I had no choice but to eventually succumb to reality and accept the fact that my needs can only be met at present by the power of combustion. With that acceptance has come a sense of excitement that only comes when a man gets a shiny new toy. For the first time in a long time, I'm looking forward to mowing my lawn!
But I still hold out hope that one day I can return to friendly energy again, preferably in the form of the Bat Mower!
But, frankly, the old lady doesn't quite cut it anymore (pun intended). I can mow the front and part of the back in one evening, and the rest has to wait until the next night (which is typically not actually the subsequent evening). I happen to have busy evenings so the grass gets longer faster than I'd like it too, particularly when the weather has been as rainy as it's been. So, we come to the second problem of the mower, which is that it doesn't really like cutting long grass.
I mean, it cuts long grass, but it doesn't cut George-long grass. (Some of you may be familiar with the George-hour... the concept is very similar.) And because of this critical deficiency, I made the painful but necessary decision to seek a replacement.
Meet, the Bull. El Toro, the Magnificent.
This beautiful piece of self-propelled machinery galloped across my jungle of a lawn, dragging me behind while indiscriminately gobbling up all the herbage in its path. This was definitely a sight to see. Instead of taking 2+ hours over the course of multiple days, it took me a total of 45 minutes to cut my entire lawn!
I must admit, the decision to replace my Earth-friendly yet cojones-deficient mower with a gas-guzzling grass-eating beast was not an easy one. It took me two years to actually admit I had a problem. I had no choice but to eventually succumb to reality and accept the fact that my needs can only be met at present by the power of combustion. With that acceptance has come a sense of excitement that only comes when a man gets a shiny new toy. For the first time in a long time, I'm looking forward to mowing my lawn!
But I still hold out hope that one day I can return to friendly energy again, preferably in the form of the Bat Mower!
