“So when you hear people say that change is hard because people are lazy or resistant, that’s just flat wrong. In fact, the opposite is true: Change is hard because people wear themselves out. And that’s the second surprise about change: What looks like laziness is often exhaustion.” — The first few pages of the book “Switch, how to change things when change is hard” are priceless. Get it! By Chip Heath & Dan Heath
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
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!”
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
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.