How to meet other craftsmen
This is not about speed dating but I had the luck to meet a craftsman during these holidays. He is not a software craftsman. He does not work with computers, but with construction and repairs of homes and apartments. He is a master mason.
During my stay in Spain, I had to interview and evaluate the proposals of three local constructions shops to almost rebuild from scratch an old apartment there.
I observed a bunch of similarities with the craftsmanship movement of our software industry. This actually helped me make a decision to pick the right person for the job. If I ever jump into freelancing, I would try to have all the attributes that made me pick this guy.
The first thing before starting a project this big, is to get a proposal. You tell them what you want to do, leave them the keys of the apartment, meet again in a couple of days to review their proposals.
All our proposals were a few pages long. They describe what needs to be done and the price for each of those items. Their language is sometimes technical. They describe the techniques and materials that they plan on using. So I had to learn a lot of new words and the whole process that goes into this “big refactoring” of the apartment.
After getting all the proposals, compared prices, interviewed again with all of them, made revisions to their original proposals, we chose our shop. Here is what helped us made that decision:
Referrals
A couple of friends and family had recent experience working with them. They were very happy with the results. They were even proud to show the work that they did for them and walked us through all the details.
Passion
When interviewing with him, it was obvious that he is passionate about his work. He does not only do it for a living. He enjoys what he does. He took the time to explain the techniques that he would use and why he would apply them.
Professional
He listened to us and provided advice, ideas and alternatives about what could be done. He was honest about what could be done within budget and what could increase the final price.
Portafolio
Even though we did not ask for it, he was the only one that took the time to show his current work. We visited houses that his team is currently building and enhancing. We were also able to see his past work through the referrals.
Price
He was not the cheapest or the more expensive option. He was also upfront that sometimes his team is slower than others. He takes the time to finish his job correctly.
Payments
A very agile method of payment. Him and his team will work for you for a week. At the end of the week, review their work and decide if you want to continue working with them. You can then pay weekly, every 2 weeks, or monthly. You decide how long is the iteration (he did not call it that, of course). There is no contract, only a handshake to continue to the next iteration.
The other 2 companies required a 30% up front followed by fixed payments on certain dates.
He also agreed to send me weekly pictures of the progress through email and I am going to ask him to have regular phone calls to talk about the project. I guess I will secretly call it ‘a standup call’ or something like that ;)
Of course, this made me wonder about ‘agile’. Why does it seems so easy for this 4 people construction shop to behave like the best ‘agile’ company I ever knew? They haven’t heard the term ‘agile’ and probably don’t care for it. They are craftsmen with a business model that makes sense and works for them.
Something I admire and hope to copy someday.
“People don’t care how much you know until they know how much you care” - Cavett Robert
Elevator pitch of why keyboard shortcuts rule
A coworker asked me why I find important to learn and memorize keyboard shortcuts.
I wrote about it some time ago, but this time this person wanted my elevator pitch, so it came out like this:
If I have to use the mouse to reach a certain menu to perform an action, a simple refactoring like extracting method, or inlining a variable for example, I am likely to get lost in the menus trying to find the right option. I know I am not the only one…
If I am more likely to get lost in the refactoring menus (taking up my precious time before that urgent deadline), I am less likely to use the menus more often.
If I am less likely to use the menus, I am less likely to refactor my code often (because doing it manually is hard). And if I don’t refactor, my code sucks.
On the other hand (bad pun here), if I don’t have to leave the keyboard to refactor, typing and refactoring become part of the same flow. No extra effort in grabbing the mouse, giving it a couple of shakes because the pointer does not want to move exactly where I want and then finding the right option under the right menu.
My coworker nodded and smiled. The conversation drifted to another subject so I am not sure I was convincing. What would you have changed to make this a better pitch?
Mark my words, if you want to stay relevant and competitive in the coming years — I don’t care if you’re in sales, tech, finance, publishing, journalism, event planning, business development, retail, service, you name it — you will still need to develop and grow your personal brand. Everyone — EVERYONE — needs to start thinking of themselves as a brand. It’s no longer an option; it is a necessity.
— From the new and awesome book from Gary Vaynerchuk “Crush it!”
My pomodoro experience
I have been using on and off the pomodoro technique since earlier this year. It works great when pair programming but I have also used it alone.
In a nutshell, this our loop:
10 Agree on the goal for the next 25 minutes 20 Start the timer 30 Work towards the goal until the time is up. 40 Take a 5 minutes break 50 GOTO 10
After 3 loops, we take a longer break.
We use it for story work, prototyping, designing, team presentations, email, etc…
It seems easier to use pomodoros when working with a pair. Agreeing on the goal removes misunderstandings, puts us back on track if we went off on a tangent, and makes it easy to keep each other honest to stop typing when the clock goes off.
It requires a lot more of my energy and discipline to run pomodoros by myself. Distractions and shortcuts are all around me.
Focusing is like doing push ups. The more you do, the easier it gets.
After a couple of months working almost by myself, I wasn’t using pomodoros that much, I moved to a new team where we decided to use the technique on day one. The first few iterations were difficult for me to keep my focus since I was no longer used to the time constraint. The tomato would go off and I was just starting to get into the groove. Or I could not wait for the timer to finish because I wanted to check twitter, my email, etc …
A few days ago, a coworker that popped into our area commented on the noise level in our room. He was surprised that we could get any work done: a meeting was happening at the other end of our table and we were surrounded by 2 conference calls on speaker phone.
We run 5 to 9 pomodoros a day (yeah, meetings suck). When the timer starts, the whole room disappears, there is no noise but our conversation. It takes milliseconds to get into the groove. We are also pretty good at locking the screen as soon as we hear the bell. It has become an habit.
And at the end of the day, the sense of accomplishment is clearer. We can recall the different episodes where we reached our goal and how much progress we have done since we started in the morning.
This post was written in 2 pomodoros.
I am sure a lot of you are frustrated at your colleagues, not being here at this conference. Not being passionate about code the way you are. And I am sure you are trying to teach them. You are talking about design patterns, test driven development, refactor your code making it readable. I am saying that they are not ready for that. They are not aware that there is a need that could be filled by learning these things. And until we make them aware of that need, there is no meaning in trying to teach them.
— From Good to Great Developer - Chris Hedgate
The bouncer pattern
Last week, J.B Rainsberger talked at Agile Philly about integration tests are a scam and explained to the audience the bouncer pattern.
I am going to paraphrase the concept.
Imagine you own a night club. It’s pretty big with 7 bars around a dance floor. Bartenders must ask for your ID before you get a drink. Some bartenders are pretty good at remembering faces, others not that much. It’s Saturday night and the place is packed. As the night goes on you start to get pissed off at the fact that you need to show your ID for almost every drink. Getting a drink gets slow and sloppy. People stop showing up at your night club.
So you push that responsibility out of the bartenders and hire a bouncer that can check for IDs at the entrance of the club. Now, the bartenders understand that if you are the club, you pass the requirement for drinking. Not only this speed things up, it also minimize the possibility of something going wrong (null pointer if I don’t have my ID anyone?).
So that’s the bouncer pattern. Instead of doing defensive programming all over the code base, check for basic correctness at the edge of the class/module/service. The code becomes easier to read and simpler to maintain.
If we use constructor dependency injection to construct objects/module/service, we can help out our bouncer keep the junk out of our code.
sundayconf
For this sundayconf, I have a good selection of music, no, videos, no, code, no, music!
Unclebob’s prime factors Kata
Even though the video is called “Prime Factor Kata (Rough)”, the flow of the kata is perfect. The music matches Unclebob’s movement from the spec to the code and back. I had mixed feelings about the choice of IntelliJ but was surprised with the “introduce variable” popup. I wished I could have seen more refactoring tools. After hearing great things about this kata on twitter this week, the video lived to his expectations.
Corey Haines’ Number to LCD
Corey’s kata was more challenging that Unclebob’s and turned out to be great. The resolution of the video could have been a little better but it was easy to follow what was going on. The music choice was on target: crescendos and allegros kept me wondering about what was going to happen next. But I wish I could hear Corey’s narrative for some portion of the kata. Especially at the beginning. With 2 examples, Corey focuses on refactoring his code for a few minutes. He moves blocks of code, create structures, extract variables and keeps running the tests. The beautiful thing about all this refactoring is that adding the next 8 examples was a breeze.
That reminded me of a quote I saw this week about sharpening the saw:
If I had eight hours to chop down a tree, I’d spend six sharpening my axe. - Abraham Lincoln.
Starting a code study group
We are starting a new code study group at work. Here is the email that I sent to the group to kick it off:
Starting a code study group
What is it?
A code study group is a bunch of people that choose an open source project or library and read it like a book.
As they go through it, they take notes; identify patterns, critique techniques and post a report.
They look at code with a critical eye. Various style of code will amaze them, amuse them and challenge them. They learn new paradigms that completely changes the way they approach problems.
They study the work of masters to improve their skills.
They meet twice a month and nominate 2 to 200 lines of code to study.
Why study code?
- To sharpen the saw
- To use existing code to reflect on our own capabilities
- To understand new code quickly
- To identify code patterns quickly
You can even learn from bad code.
This is not something new. Musician, painters, poets get together to study the work of masters. They learn their work and quiz each other.
Since we are heavy on the java side, I created an online survey with 4 open source libraries that could be interesting to study:
- Mockito
- FitNesse
- Spring
- Jakarta Commons
I can’t wait to see what are the results of the survey. I am going to keep it open until Monday.
Philadelphia's code retreat
At code retreat, we retreat from the world to advance in our craft. We sharpen our saws, together.
We retreat from production and business value to increase our production capacity, our quality, our velocity, our ability to produce business value.
We retreat from immersion in deep technology issues to advance in our ability to learn and adopt to any technology well.
We retreat from our fears, and embrace new practices and patterns.
We retreat from our local ponds and swim in a larger pool. We connect with other passionate coders who we seldom get to code with. We make new connections and learn new lessons.
At code retreat everything is about the journey and nothing about the destination.
Join us on Sunday November 1st, 2009 in Philadelphia at indyhall. We will start at 9am and will be practicing Conway’s game of life in Java.
Here is a approximate agenda of the day:
We’ll spend 15 mins introducing the event, drinking coffee, thanking the sponsors, answering questions and describing the game of life problem.
We will break down into pairs and run an iteration of 45 mins.
Take a 10 minute break and throw away the code (this could be hard!), switch pairs and get ready to start the next iteration.
Run another iteration and throw away more code.
We will be exploring new things to try: coding with no if statements, using TDD as you mean it. 1-line methods, interfaces everywhere, etc…
We have lunch when it makes sense and see if we have something to demo.
After lunch, iterations might run shorter switching pairs after each iteration and always throwing away the work.
Finish the afternoon around 5pm or so and head for beers across the street to National Mechanics
Be ready
Bring your laptop with:
- Java 1.5 (minimum)
- Git
- An IDE (Eclipse, intelliJ, etc…)
- If you use Eclipse, consider getting J.B Rainsberger’s game of life template for eclipse
If you use intelliJ, consider adding an empty template like JB’s.
We will have coffee, soft drinks, and snacks available. Lunch will be supplied. However we are still looking for a food sponsor. Help us out!
If you are going to attend, please RSVP at http://coderetreat.ning.com/events/code-retreat-philadelphia-java or at coderetreatphilly@gmail.com. We may be overbooked, so the RSVP is required to determine headcount.
Please send any questions you might have to coderetreatphilly@gmail.com.
Hope to see you there!
