It was only yesterday that I incurred into this old tweet by Kent Beck:
the *craft* of programming begins with empathy, not formatting or languages or tools or algorithms or data structures
— Kent Beck (@KentBeck) February 13, 2015
This message resonates with many reflections I have been through lately.
Tree huggers
First, this made me think of all the comments hard core programmers do about the people trying to fix dysfunctional teams, or better: trying to fix dysfunctional IT teams. “What is this? Psychotherapy? We just need more unit tests!” is just an example of the comments I read and heard about people trying to address the problems of a failing team.
Unfortunately, if we agree on solving problems with the right tools, people problems can’t be solved with solutions meant to fix programming problems. That’s easy like that.
Sure, adopted solutions must be evaluated too and it may happen that some get a bit over the line. Sure, we don’t need – and can’t afford – 10 years of psychoanalysis to deliver our next project. Sure, many are trying to oversell the tools they just know about to fix a broad range of problems which may just be too broad.
But please do remember: people problems are to be addressed with people solutions, be it a user requirement, a collaboration issue or a learning resistance.
Programming languages are for human beings
This is a topic which once in a while brings the teams I am working with to an a-ha moment: programming languages were not invented to talk effectively to machines. Programming languages are meant to bring people on the same page in the cheapest way when facing a programming problem.
Amazingly enough the tweet by Beck is a perfect brief reminder for all of us. Programming:
- Starts with understanding a set of requirements (people’s needs)
- Making them clear to a bunch of developers (people needs!)
- Turning them into working software crafted by a group of professionals (OMG people again!)
- Validating the deliverable with all the stakeholders (I. Can’t. Believe. It. This is people again.)
- Finally satisfying the needs we were starting from, by making our tool clear and easy to use to users (peo… ouch!).
Programming languages are a tool to help with step 3. Sometimes with steps 2 and 4 too.
If programming languages were optimized on the machine side of the human-machine relationship we would all be writing assembly code today, OK?
Linguistic skills are the key skill for a team worker
The third thought triggered by Beck’s tweet is about linguistic skills in developers and, more in general to all team workers.
If we understand that innovation bottleneck is learning, then we must agree that talking and communicating the slightest nuance of meaning is a key factor when learning together with a group of co-workers.
If we agree that a team is built around a goal – and maintained around a vision, then we must agree that fostering cohesion with the right conversations is a key skill for all the people belonging to the team.
Thus, if we want our conversations to be effective, we must recruit people with good linguistic skills. If we want our conversations to even be efficient, we must recruit people with great linguistic skills.
I have no doubt on this: when hiring a new coder I am willing to trade some of their hard skill for a very good linguistic skill. You think what you talk, you talk what you think.