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.
