Ivan Sanchez

It’s been exactly one week since I came back from Brazil and now it’s time to share some of what happened there. Like I said before, this tour supposed to be a “mini” tour of three days in companies from Florianópolis, city hosting the Agiles2009 conference. Here are some of my findings:

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.

Writing check-in messages is normally a reflection time for me. And lately I’ve been inclined to describe why I changed the code, instead of just describing what I’ve changed.

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.

Most of recent software development approaches bring code closer to business. According to Agile we should write software with customer collaboration, responding to changes and constantly delivering business value. Lean is all about creating a flow of business value and removing waste. Even Domain-Driven Design advocates having an ubiquitous language between programmers and business people.

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.