• If you know how to code, you should code
• If you’re coding, everyone else has to understand what you’re doing
• If you’re the next to code, avoid breaking the flow
• If you’re not coding, don’t disturb who is
• If you have an idea, show it with code
• If you’re stuck, ask for help
• If you liked the challenge, try it again at home

Interesting how this simple “etiquette” helped to make what I consider one of the best dojos I’ve participated so far.

It doesn’t take long to get to know a company

My biggest fear was that the time wouldn’t be enough to really get to see people working, but fortunately I was proven wrong. Even in one of the companies where I didn’t manage to actually code, in couple of hours I had a minimal knowledge to not feel lost at all. At the end I managed to visit three different companies and enjoy all of them in very distinct ways, which was great.

Bureaucratic companies can waste your time

The company I had planned to visit on the last day wanted me to sign a Non-disclosure Agreement before stepping into their doors. And although my contact was keen on the idea of having me there, they couldn’t get the paper on time (or didn’t want, I’m still not sure) and the visit had to get cancelled. Luckily when I got the news I was already in my best friend’s uISV office and working with him turned out to be excellent. In the future I’ll definitely skip bureaucratic environments.

Every company has cool tricks to share

The best aspect of this tour was seeing all the interesting stuff those companies are doing in practice, rather than through papers, blog posts or talks. Although I had no idea of what I would see in those places, it has proven to be a very rich experience. Among the things I’ve learned or played with are:

• Saw a lot of tricks for SEO and how they made a difference for a website
• Participated in a “internal workshop”, where programmers have to talk about a topic they decided to study during the week (in that case, it was about SOLID principles)
• Had a chance to pair program using Pomodoros (I had only tried alone before)
• Saw a way to maintain custom versions of a software and incorporate client’s specific requests
• Wrote my first lines of production code in C#
• Learned more about web scraping
• Realised that the combination of espresso machine and table football in the office can be very addictive!

Smart companies share their problems too

It wouldn’t be polite putting here all the challenges these companies face or practices I don’t particularly agree with but, trust me, they were really inspiring. What impressed me is that, maybe because of the nature of my visit, all the companies had no problem talking about or even showing the problems in their code/process, or even the short cuts they’ve been taking to deliver their software. And hopefully my thoughts on these problems can help them somehow.

I can’t wait to do it again

At this point it’s pretty obvious that I enjoyed the tour and hopefully I’ll be able to repeat it soon. Maybe reserving more time for each company would be better, but even just for a couple of days experiencing a completely different work environment was definitely worthwhile.

I know I have to consider that all the time, but it can still serve as a last sanity check. It makes me think: “Am I really adding a valuable change to the codebase?”

Do you agree with this approach? Think about it next time you check-in and then let me know in the comments.

It’s interesting how most of state-of-art approaches to software development are focusing on business, programming itself is still seen by many as a completely technical discipline. In my point of view it’s time for this to change.

Here are some examples of useful things I believe all programmers should be concerned about these days:

• Understanding the company’s vision and the business model where your software is supposed to fit;
• Knowing how to estimate and prioritise work based on criterion like return of investment (ROI) or competitive advantage;
• Learning about the business domain and becoming an expert in it;
• Questioning the business value of features before start coding;
• Being able to collaborate with whoever is envisioning the solution you’re creating;

All these skills represent a new challenge for programmers, and learning some of them can be more helpful than hacking the last open source framework out there.

The best programmers I’ve been in touch with lately seem to understand that and can explain not only how good their code is but how their organisations are taking advantage of their tricks.

This idea came from Corey Haines’s programming tours and the work of other craftsmen like Enrique Riepenhausen, Dave Hoover and Antony Marcano from PairWith.us. Hopefully it will be an interesting way to learn new tricks.

Unfortunately I’ll have only three days to accomplish my goal. The good news is that it took less than a day to be contacted by more companies that I’ll be able to visit, which shows I’m not the only one thinking this can be a very good experience.

To allow everyone to participate, the attendees were divided in three groups: Ninjas, Pirates and Zombies. Each group would solve the minesweeper challenge using the randori approach and at the end each group had a chance to show their solutions.

Another interesting approach for this dojo was providing a common set of cucumber stories to guide the development. Matt Wynne wrote them and also provided a rake task to help keeping the TDD flow by encouraging people to solve the tests one-by-one (source code is available here). As a result, all the groups managed to solve the challenge in less than one hour, giving them enough time to experiment alternative solutions and refactorings.

Although there was no general retrospective at the end of the session, reading the feedback on the LRUG mailing list it seems like people enjoyed the experience. Personally, I really liked the fact that everyone participated, probably because they’re used to the language and tools and knew each other from previous LRUG meetings. Well, maybe is time to start organising public dojos again.

The solution? Well, maybe we should simply be using a different word(s). For instance, my gut feeling is that “ready” could probably do a better job. The main reason is that it invites further questions (”ready for what?”), whereas done ceases the communication (”if it’s done, let’s move on.”).

For this session, it seems like once more the challenge will be how to prepare a session for more people than we’re used to. So Victor Hugo and I still have to come up with something special for this occasion.

Anyway, If you’re lucky enough to be around at the conference, please don’t hesitate and come say hi

That’s why I believe is important to be conscious about what happens during them. A stand-up meeting may hide problems if:

• It doesn’t have an exact time to start
• It doesn’t happen because someone is not present
• It’s a trigger for technical discussions
• It’s not focused on to the plan
• It doesn’t contribute to continuous improvement
• It’s a report for a single person, not the team
• People don’t stay close to each other
• It’s frequently interrupted
• It doesn’t include the whole team
• People don’t remember what they did on the last day
• It’s moment where most of the problems are raised
• It takes more than 15 minutes
• It doesn’t happen every day
• It doesn’t feel good

These are all simple issues which can easily be addressed. In fact, most of the items on this list are discussed on Jason Yip’s article about stand-up patterns. The most important thing is that it may as well be the a good starting point to identify and improve other aspects of a project.

“My colleague Sid Pinney is investigating setting up a ThoughtWorks office in Brazil – talk to him at [...]“

The interesting thing about this is not the fact itself, but the reaction it’s causing. Not only dozens of Brazilian developers are forwarding the message, but there are people already asking how they can join the company.

The biggest strength of TW is their ability to attract good developers by having on their staff people who influence the whole software development community. In my opinion that’s the result of a good recruitment process and giving opportunity for employees to publish and work on their own projects.

I really hope they open a company there because, as far as I know, very few companies have this kind of culture in Brazil. Open a company there and they can probably have the best developers around.