Mentoring in Software Craftsmanship

Maria Diaconu and  Alexandru Bolboaca are both strong supporters of Software Craftsmanship and Agile movements in Romania, with years of experience as developers, leaders, architects, managers and instructors. On their lecture at Agile Central Europe Conference they were talking about Software  Craftsmanship movement. While Sobótka at 4Developers was showing what Craftsmanship from the code point of view is, our guests from Romania gave us a brief introduction into the process of becoming a Craftsman.

The fact, that university education for programmers doesn't give us skills suitable for professional environment is old news (at least in Poland and Romania). While steps are being taken in the right direction, it's going to take a while to get there, and that's where  Software Craftsmanship movement comes in handy.

The core concept of the presentation, was that if you want to go pro, you should understand the way you need to follow. In other crafts, there are practices recognized as the core of a profession. Programming is so vast, that you may get lost on the way, and certifications like SCP do not help much, as they are too technology oriented, looking more like a “technological masturbation” (technology for itself) rather than a way to really learn something useful. Software craftsmanship has a concept of mentoring, which is based on one of Agile  principles: “individuals and interactions over processes and tools”.

How does it work in practice? To become a craftsman you start as an apprentice at some master of your choice. If you're lucky, you'll find someone to work for and learn from. If not (you have to work in a bad environment to get by, or everyone around doesn't have more experience than you do), you can choose a well known writer, such as Martin Fowler or Robert C. Marting (Clean Code is a great start) and learn from him (all of them, even better). But that's not enough. Next step would be to participate in the community (local language user groups, etc.) and finally, to get your ass to other places and learn from people out there. That means conferences, but also a week-out pair programming in another company, far, far away, an idea more and more popular in US, as you can see at software_craftsmanship google group. After all a journeyman has a “journey” part in it, doesn't it?

So easy so far, right? Nothing new and mind-shaking?

The thing is to understand, that while official certifications are a great magnet for potential employers, skills of a good programmer don't come from certification books. Skills come from work experience with other good programmers. That's why Pair Programming is so important. That's why you should start going for local language/craftsmanship group meetings even if you do not understand everything they are talking about. That's why it's more important to work WITH a great programmer than to work FOR a well known company.

I've seen so many people understating the technology to the ground, yet failing to create a good software solution,  because they've never ever seen, how a good solution is build. I've heard opinions that “no software is maintainable” from people with 10+ years of experience in Java.

All you really need is a mentor. A master, that can show you, what a great software is written like.

Sławomir Sobótka, answering the question “How to start with Java” on Jacek Laskowski's blog, wrote lately: “I'd leave SCJP and similar sadomasochisms for later, maybe in a few years time, or even better, I'd boycott it all together”. He is damn right.

Robert C. Martin has a very interesting entry on his blog “Developer Certification WTF?”, where he is explaining why  official certification programs are so much bullshit these days. Beware of big companies as well, remember that “big and successful company” doesn't mean “a good place to get better”. On the contrary, it sometimes means: “a place where an apprentice is treated like shit and a code monkey”. Check the company for people and methods that you're going to be involved with on daily basis, before you send your CV. Ask a lot of questions, talk to the guys working there, if you can, ask to spend some time with the team, do some pair programming, and see what they are up to.

While chances are, in most companies your CV is going to be processed forward basing on buzzwords and certificates, the most important thing is to check whether the people you are going to work with can inspire you, bring you to the next level. And vice-versa. This is exactly what Thoughtworks is doing. Don't be afraid to risk you stability and position to get more knowledge and experience. If you've been playing Heroes of Might and Magic, you probably know damn well, that to choose experience is better than to choose money in the long run. Always.

If you want more tips what to look for when searching for a good employer, have a look here.

Mentoring should not to be underestimated. When Piotr Jagielski began his speech about refactoring test code, at Agile Central Europe Conference, he started with saying that he was very lucky to get a great mentor at the very beginning of his work. I'm sharing similar experience: while I've started my carrier as an analyst in a long waterfallish kind of a project, when I've moved into programming I was extremely lucky to work with Piotr Szarwas, the guy who in one year taught me more than 5 years of university and two years of former software experience all together.

And if you already are a good programmer, remember that learning never stops. When you are a master, you are a student as well.

“Even today, I dare not say that I have reached a state of achievement. I'm still learning, for learning is boundless.“ [Bruce Lee, Tao of Jeet Kune Do]

ACE Conference: Reachel Davies – Retrospectives

Reachel Davies, author of “Agile Coaching”, with ten years of experience in XP, Scrum and Agile (seven on the board of directors of the Agile Alliance), and 19 overall in IT, is a serious girl in this industry. Funny, I'd think she has some psychology background, but no, she's an engineer to the core. I'd think that because her presentation made so many points on the psychological part of our line of work, that my sister (who is a psychologist as well as a jazz singer) may be interested.

Her talk was about the underestimated art of retrospectives in our agile methods. Teams tend to forget about it or do it a wrong way, while it's the main thing that can help them get better.

She suggested another technique for retrospectives, to create a constant time-line where the team would put their sticky notes, writing:

• what happened
• what was frustrating / stressful
• what was useful / fun

That can give you a very interesting insight in what was happening during the project. She also pointed out that people's moods take a big part in the efficiency of the team, and to have a valid historical view, you should include them as well (like biorhythms). To get that, anything would be good, from putting your spirit level on a scale, up to drawing a picture. Back to kindergarten anyone?.

That may seem silly, but the team is the most important part of the project, and as such, we need to pay attention to everything that happens within. For example, while voting on things to change during a retrospective can help, we should beware of serious disagreements. There are things, like personal values, that you cannot change with a simple statement, and there are things (personal values again for example) for which people would rather be fired than give up on.

That was pretty familiar to me, as I cannot agree to include chaos and lose quality for the sake of other things. And don't talk to me about quality versus work performance dilemma. It's a myth. You'll never be faster by writing uglier. In the long run, bugs and accidental complexity will bring you down big time.

It's quite an interesting twist to think about retrospectives in a more general sense. You can (should?) use them outside of IT as well. About three years ago, I've been to a sailing camp at Mazury where my trainer, who was a youngster, after every not-so-perfect maneuver, would ask: “What went wrong?”.  As simple as it is, the question generated a lot of afterthoughts that helper us pass the exam in the end.

Now, think for a while, what else could also benefit from a well performed, regular retrospective?

A marriage, perhaps?

ACE Conference general impressions

Getting up at 4am is never easy for me, and so it wasn't this time, especially after getting to bed only three hours earlier. Nonetheless, on the 8th of April, thanks to TouK, I was getting myself on a train to Cracow for 2 days long Agile Central Europe Conference, when out of a sudden I saw a man walking out his dog. That made me think: if this guy has so much love for his pet to walk it out in the middle of the night, then I definitely have enough passion for knowledge to stop complaining and be extremely happy that I have a chance to learn something.

And boy, how happy I am that I've been there.

While both 4Developers and Winter Agile Tunning, that I've attended last month, were really great (I can recommend both and I'd like to be there next year), ACE conference was simply fantastic. It seems that it's not only my opinion. Kuba Kurlenda, to whom I gave my free conference pass, that I got (won?) on Winter Agile Tunning for asking Szczepan Feber a hell lot of questions, was also delighted.

There are two organizers mentioned on the site, but as far as I know, it was put together by one man, Paul Klipp, who is a president and Scrum Coach at Lunar Logic Polska, and founder of half a dozen different groups and other undertakings.

So what was so special about this event? Apart from great speakers, that is. First of all, there were only two tracks, but you wouldn't be bored, because as a “bonus third track”, there was an Open Space, where everyone had a chance to put his favorite subject and get some people to talk about it. Breaks between presentations were half an hour long, which was also motivating to get to know each other and start talking. That was what I missed the most on Winter Agile Tunning, a chance to talk with everybody. Finally, Paul was aware that people are getting tired at the end of a day, so instead of putting not-so-hot topics on late hours, he got us the most funny/innovative to wake us up, and after that, we had Lighting Talks, lasting for 5 minutes each, which is precisely as long as you can keep your focus on the subject when you're exhausted.

Big kudos to Paul for all of this. The only two things I'd change were, that we didn't get any pens/notebooks together with conference materials, which is something of a surprise (I wasn't prepared for that and had nothing to note with, except my phone), and that it could've started at noon, so people from other parts of the country would have a bit more time to get there (and to sleep at night).

I had a chance to talk with Paul about it, so chances are, he'll use those ideas next time, as I'm sure there'll be more ACE Conferences in years to come.

So much for the general impressions. I'll have to make one post for presentation, for the sake of readability. Stay tuned.