The craftsman I would like to be

[AlexBolboaca]

Hi,

I'm writing to you because I need your help.

I recently wrote a blog post called "The craftsman I would like to be"- http://www.alexbolboaca.ro/wordpress/articles/the-craftsman-i-would-like-to-be. In it, I describe a few ideal features I would like to grow towards.

The reason I'm asking for your help is to better define these criteria. I have them in my mind, but I'm not sure I fully understood them - if that makes any sense :). I need you therefore to challenge me with:

• Is anything unclear in the criteria?
• Are there things you would add? Things you would remove?
• Can you name other inspiring people that I, we could learn from?

Thank you for your support,

Alexandru Bolboaca
Show your love for code.
Attend I TAKE Unconference 2014, the event where we practice craftsmanship, not only talk about it!

[Grzesiek Gałęzowski]

Hi, Alexandru,

I like the sketch you provided, In my opinion, it contains some very important factors to becoming a great craftsman. As requested, I'd like to question two of the points you make for clarifications:

1. Gather a team of craftsmen that will not only work together but also learn and grow together over the long-term.
   
   what do you mean to "gather"? At team level? Product level? I work in environment where a single product consists of many subsystems and all work through the release. Each subsystem is then divided into several feature teams. I am a developer, which is not always the corresponding role of architect in building. I view architect as someone who creates the technical vision and ties things together. As a developer, I am usually expected to execute someone else's vision (not that I don't have a say, it's just that I often do not play the lead role). Thus, I think my abilities to gather are 1) less formal - I do not have power to command people nor can I choose who I work with - have to use my abilities as a change agent to transform the environment I was given. 2) limited - Even when I manage to transform my team into a team of craftsmen, I am still influenced by people outside it, who may not value the craftsmanship. Thus, I think merely gathering a team of craftsmen is not enough - it must be a team that shares their skills extensively and promotes discussion around those skills.
   
2. Deliver working software that delights users and customers. This is not only the job of the graphical designer, interaction designer, product owner. It’s also my job as a developer.
   
   I am having some issues understanding in what way should my work delight users. I can think of: application performance, responsiveness, throughtput and reliability (e.g. lack of bugs). I think the only way I can delight customers and users with e.g. good design, is when I can deliver new features fast and reliably. Am I missing something?
3. Write only the technical and functional documentation that is useful. Favour working software over detailed diagrams. (Gaudí had to work with real materials and build 3D models; we are lucky to work with code, easier to sculpt than stone – when written so that it’s easy to change)
   
   What do you mean by "working with code"? Do you mean prototypes? Automated tests (e.g. ATDD)? Self-documenting code? All of it? Are you considering useful any functional or technical documentation that is not about "working with code"?

[Alexandru Bolboaca]

Hi,

See below

On 05/08/2014 08:19 AM, Grzesiek Gałęzowski wrote:

Hi, Alexandra,

It's Alexandru :) or simply Alex. No problem Grzesiek ;)

I like the sketch you provided, In my opinion, it contains some very important factors to becoming a great craftsman. As requested, I'd like to question two of the points you make for clarifications:

Thanks for your support.

1. Gather a team of craftsmen that will not only work together but also learn and grow together over the long-term.
   
   what do you mean to "gather"? At team level? Product level? I work in environment where a single product consists of many subsystems and all work through the release. Each subsystem is then divided into several feature teams. I am a developer, which is not always the corresponding role of architect in building. I view architect as someone who creates the technical vision and ties things together. As a developer, I am usually expected to execute someone else's vision (not that I don't have a say, it's just that I often do not play the lead role). Thus, I think my abilities to gather are 1) less formal - I do not have power to command people nor can I choose who I work with - have to use my abilities as a change agent to transform the environment I was given. 2) limited - Even when I manage to transform my team into a team of craftsmen, I am still influenced by people outside it, who may not value the craftsmanship. Thus, I think merely gathering a team of craftsmen is not enough - it must be a team that shares their skills extensively and promotes discussion around those skills.
   

You are right, this is unclear. The simple reason is that I don't exactly know what it means yet :).

I think "gather" means to me two things:
* I am fortunate to have the freedom to hire and teach developers and the privilege to influence the values of the organization. It won't be easy, but at least I have this opportunity.
* Finding the right developers that aren't working with me but share some of my ideas and are willing to discuss and challenge them. That's part of what I hope with this message.

1. Deliver working software that delights users and customers. This is not only the job of the graphical designer, interaction designer, product owner. It’s also my job as a developer.
   
   I am having some issues understanding in what way should my work delight users. I can think of: application performance, responsiveness, throughtput and reliability (e.g. lack of bugs). I think the only way I can delight customers and users with e.g. good design, is when I can deliver new features fast and reliably. Am I missing something?

I agree with your idea that, in general, delivering new features fast and reliably is part of it. I believe there's more. As software developers, we can sometimes influence the way the application behaves by looking at the application from the user perspective. For example, I never start to work from user stories. I define a complete scenario from the user's point of view, and ask questions such as: Could this be made simpler for the user? Could we skip a step? etc.

As a recent example, we recently implemented features related to a doctor that consults a patient and introduces data in the application. Instead of considering the stories (as a doctor I want to prescribe a drug so that ...), we discussed about the different types of consultations: temporary problems (such as cold or flu), acute problems and chronic problems. We then discussed with the customer these specific scenarios, thus discovering how to simplify the UI and the interaction between the user and the software. This extra step is what I'm talking about.

1. Write only the technical and functional documentation that is useful. Favour working software over detailed diagrams. (Gaudí had to work with real materials and build 3D models; we are lucky to work with code, easier to sculpt than stone – when written so that it’s easy to change)
   
   What do you mean by "working with code"? Do you mean prototypes? Automated tests (e.g. ATDD)? Self-documenting code? All of it? Are you considering useful any functional or technical documentation that is not about "working with code"?

I'm merely saying that stone is harder to sculpt into the right form than code. As for functional documentation, I believe functional documentation that's not executable is bound to become obsolete very quickly, so I prefer some form of executable specification. Most technical documentation can be replaced with good coding practices - writing simple code, using consistent and clear naming and so on. However, some technical and functional documentation is needed; I've used for example, diagrams of the functional scenarios and various types of architectural diagrams depending on the case. The key here, from my point of view, is to do the minimum documentation, but the most useful, depending on the context.

Thanks a lot, I loved your questions!
Alex

Best regards!

grzesiek

On Wednesday, May 7, 2014 9:41:27 AM UTC+2, AlexBolboaca wrote:

--
You received this message because you are subscribed to a topic in the Google Groups "software_craftsmanship" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/software_craftsmanship/GXi0Vi-KLHM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to software_craftsma...@googlegroups.com.
To post to this group, send email to software_cr...@googlegroups.com.
Visit this group at http://groups.google.com/group/software_craftsmanship.
For more options, visit https://groups.google.com/d/optout.