There's been a lot of discussion about Agile Certification, a Rails Maturity Model, and some such. Are we always doomed to repeat the mistakes of the past? Remember the MS/Java/Sun/Linux certification craze of a few years ago? Yeah, same thing.
I did some hiring back then. I'd float right over any resume that prominently listed a big set of certifications because I thought people that misguided couldn't have a clue as to how real software systems are built. Mostly I think I was right. The first resume I see sporting a Rails or Agile certification is going to get framed and put on The Wall of Shame. I don't have a Wall of Shame, but I'll create one just for it. I promise.
For those of you coming into this industry, coming into Agile or Rails. Or for those somewhat experienced fellows looking for what to do next. Certification is not the answer. Let me now bestow upon you the few truths I know about this:
First. I can tell you with much certainty that there is only one way to learn how to build great software: from a master. I read this Chinese proverb once and it stuck with me:
A single conversation with a wise man is better than ten years of study.
A bit of an exaggeration, I know, but truth none the less. Nothing compares to working day in and day out with a master of the craft. Literature, conferences, training. They're all good places to start, but they are not enough. You need a mentor, the best one you can find.
Second. It will take you years of hard work to become generally competent. I've been at it for about seven years now and I feel as if I've climbed to stand upon one great peak of knowledge only to look down on the vastness of my ignorance. Yes that was as bit dramatic. I apologize.
Third. The only way to gauge the true skill of a craftsman (that's you) or organization is by their work and the opinions of their colleges. Not where you got your graduate degree, especially not the number of certifications pinned to your wall.
Now that I have you convinced. What can you do? How can you apprentice yourself to a master?
Most are not terribly hard to find. They write lots of books, they have blogs, they speak at conferences. Find one who's style resonates with you, then figure out how to get your foot in the door wherever their opinions hold sway. If it does not work out, find someone else and try again. And again.
If you wanted to get your foot in the door with us, for instance, you can undertake an apprenticeship. Otherwise, There are a lot of great places to learn this craft beyond our doors. I know this list is short, but here's the few companies I can recommend (mostly in the Chicago area): Obtiva, 8th light, Atomic Object, Object Mentor, ThoughtWorks.
Tuesday, March 31, 2009
Friday, March 6, 2009
Join the Software Craftsmanship community!
Interested in Software Craftsmanship but haven't found a good peer group to share your thoughts with? Then this google group is for you.
http://groups.google.com/group/software_craftsmanship/
http://groups.google.com/group/software_craftsmanship/
Thursday, February 26, 2009
Watch Paul Graham write an essay
Neat technology. It is fascinating to see how often phrases are re-worded and paragraphs completely restructured. The essay isn't half bad either.
http://etherpad.com/ep/pad/slider/13sentences
http://etherpad.com/ep/pad/slider/13sentences
Wednesday, January 28, 2009
Expand your mind into the Tenth Dimension!
http://www.break.com/index/how-to-imagine-the-tenth-dimension.html
Monday, August 4, 2008
Spotlight update
I've deployed some new code for the spotlight app, which you can find at http://spotlight.heroku.com. I'd like to point out two updates in particular: There is a new Javascript parser thanks to Fred and I've changed the html rendering scheme to allow you to highlight the code without highlighting the line numbers as well.
Thursday, May 15, 2008
What makes a pattern?
Every Tuesday the Obtivians have a lunchtime gathering at our Chicago office. These gatherings are pretty informal and usually start off with a few folks presenting technical topics followed by the general sort of heckling and mischief that you'd expect a room full of guys to get into.
This last Tuesday found us with no one prepared to present a topic, so we broke off into small groups and quiet conversation. I sat down with my lunch among a few of my colleagues and engaged in the conversation they were having. About exactly what I can't remember now, but trust me - it was geeky.
I finished my lunch as the conversation wandered toward design patterns and Ruby on Rails. I made the casual comment that I thought it was a bad idea to name a framework after a design pattern (Rails ActiveRecord, I'm looking at you) and that sparked a furious debate.
My argument was that somewhere along its evolution ActiveRecord the framework ceased to incorporate Active Record the pattern as it had evolved into a Data Mapper which eventually became a full ORM framework, having heritage in the Data Mapper pattern . Thus rendering the name "ActiveRecord" quite misleading if you're familiar with the PoEAA definition. A few of my colleagues believed otherwise.
However, the core of this debate and the topic of this blog post is not about the implementation of ActiveRecord. It is about what defines a design pattern in software and how you identify code that implements a particular pattern in the field. So let's get to that, we'll finish the debate later.
I'm fairly young as programmers go, but I've read most all of the current literature on patterns as well as having the opportunity to work with some truly exceptional individuals. So while I may not be prepared to give a three day lecture on the topic I do believe I've formed some worthwhile opinions.
My belief is that a design pattern in software is defined by two things: The particular problem the pattern addresses and the manner in which that problem is addressed. In my mind the interface, the UML diagram, and the implementation in code that often accompany the patterns in a book have very little to do with the definition of the pattern itself. All of these things are the artifacts of one specific implementation of said pattern. If you read the GoF book carefully you'll find that they point this out directly. They warn us against misinterpreting the examples as the literal pattern. A lot of us didn't listen very well.
Patterns are conceptual entities and that can make them especially difficult to grasp for the newcomer. Examples help with this, I get that. However, the unfortunate side effect being that these early students often latch on to the well-meaning examples and miss the underlying concept of the pattern itself, the one thing that really matters. Even worse, it can take a long time to get out of this rut.
What I try to do is identify what makes a pattern's solution conceptually unique among its peers. Let's take PoEAA Active Record versus Data Mapper, which was the topic of our debate. An Active Record is a simple row-level representation of a table in a relational database. What makes it unique is that the data to be persisted and the logic that handles that persistence all reside inside the same object - the Active Record.
In contrast, the Data Mapper creates a separation between the data and the logic that persists it. How that separation is achieved, to me, is unimportant. How I interact with the persisted object is unimportant. The UML definition is unimportant. What is important and what makes Data Mapper different from Active Record is the separation of the data to be persisted and the logic that handles that persistence (yes, I said that twice). That is the essence of Data Mapper.
Therefore, Rails' Active Record is more of a PoEAA Data Mapper than it is a PoEAA Active Record.
Now let's entertain the counter argument for a minute. What if a pattern is defined by the way in which you interact with it (its interface). And what if we apply that to patterns we see in another field, say architecture?
In your lifetime, how many thousands of doors have you interfaced with? How many of those doors had the same interface? Not many. The doors in my house have a knob to engage the latching mechanism and a hinge at one side, but the door to my garage curls up over the cars on rails when I push a button. The door at the grocery store moves out of my way automatically.
Are we wrong to say that all of these things are Doors? That there is One True Door and all other impostors must be called something else? Of course not, that's silly. Why? Because the concept - the pattern - of a door has nothing to do with its interface, or the materials it is made of, or its picture in a book. A door is a conceptual thing. If I was to define Door I would say it is "An easily removable barrier between two spaces".
What I really want to know is how each of you feel about this? What defines a pattern in your mind? Please, leave a comment.
This last Tuesday found us with no one prepared to present a topic, so we broke off into small groups and quiet conversation. I sat down with my lunch among a few of my colleagues and engaged in the conversation they were having. About exactly what I can't remember now, but trust me - it was geeky.
I finished my lunch as the conversation wandered toward design patterns and Ruby on Rails. I made the casual comment that I thought it was a bad idea to name a framework after a design pattern (Rails ActiveRecord, I'm looking at you) and that sparked a furious debate.
My argument was that somewhere along its evolution ActiveRecord the framework ceased to incorporate Active Record the pattern as it had evolved into a Data Mapper which eventually became a full ORM framework, having heritage in the Data Mapper pattern . Thus rendering the name "ActiveRecord" quite misleading if you're familiar with the PoEAA definition. A few of my colleagues believed otherwise.
However, the core of this debate and the topic of this blog post is not about the implementation of ActiveRecord. It is about what defines a design pattern in software and how you identify code that implements a particular pattern in the field. So let's get to that, we'll finish the debate later.
I'm fairly young as programmers go, but I've read most all of the current literature on patterns as well as having the opportunity to work with some truly exceptional individuals. So while I may not be prepared to give a three day lecture on the topic I do believe I've formed some worthwhile opinions.
My belief is that a design pattern in software is defined by two things: The particular problem the pattern addresses and the manner in which that problem is addressed. In my mind the interface, the UML diagram, and the implementation in code that often accompany the patterns in a book have very little to do with the definition of the pattern itself. All of these things are the artifacts of one specific implementation of said pattern. If you read the GoF book carefully you'll find that they point this out directly. They warn us against misinterpreting the examples as the literal pattern. A lot of us didn't listen very well.
Patterns are conceptual entities and that can make them especially difficult to grasp for the newcomer. Examples help with this, I get that. However, the unfortunate side effect being that these early students often latch on to the well-meaning examples and miss the underlying concept of the pattern itself, the one thing that really matters. Even worse, it can take a long time to get out of this rut.
What I try to do is identify what makes a pattern's solution conceptually unique among its peers. Let's take PoEAA Active Record versus Data Mapper, which was the topic of our debate. An Active Record is a simple row-level representation of a table in a relational database. What makes it unique is that the data to be persisted and the logic that handles that persistence all reside inside the same object - the Active Record.
In contrast, the Data Mapper creates a separation between the data and the logic that persists it. How that separation is achieved, to me, is unimportant. How I interact with the persisted object is unimportant. The UML definition is unimportant. What is important and what makes Data Mapper different from Active Record is the separation of the data to be persisted and the logic that handles that persistence (yes, I said that twice). That is the essence of Data Mapper.
Therefore, Rails' Active Record is more of a PoEAA Data Mapper than it is a PoEAA Active Record.
Now let's entertain the counter argument for a minute. What if a pattern is defined by the way in which you interact with it (its interface). And what if we apply that to patterns we see in another field, say architecture?
In your lifetime, how many thousands of doors have you interfaced with? How many of those doors had the same interface? Not many. The doors in my house have a knob to engage the latching mechanism and a hinge at one side, but the door to my garage curls up over the cars on rails when I push a button. The door at the grocery store moves out of my way automatically.
Are we wrong to say that all of these things are Doors? That there is One True Door and all other impostors must be called something else? Of course not, that's silly. Why? Because the concept - the pattern - of a door has nothing to do with its interface, or the materials it is made of, or its picture in a book. A door is a conceptual thing. If I was to define Door I would say it is "An easily removable barrier between two spaces".
What I really want to know is how each of you feel about this? What defines a pattern in your mind? Please, leave a comment.
Wednesday, March 19, 2008
Pretty code snippets for the masses
In my last blog entry I pointed out a tool called Coderay for generating syntax-highlighted html for blog posts. Two train rides later and I've launched an application that should make life a whole lot easier for folks who want pretty code on their blog.
I give you Spotlight:
http://spotlight.heroku.com/
In other news, heroku is
I give you Spotlight:
http://spotlight.heroku.com/
In other news, heroku is
Subscribe to:
Posts (Atom)
