Coaching is language-agnostic
Working on software quality means working on architectures, paradigms, and methodologies, particularly clean code. The programming language doesn’t matter.
A technical coach can perfectly well support teams without knowing the languages those teams use. How surprising is that?
Take me, for example: I sometimes coach people who code in Python, PHP, Go, or whatever, even though I “speak” TypeScript, Node, and React myself. There’s no problem with that.
There are several reasons for this.
Architectures and methods transcend programming languages
The first reason is that a coach is more interested in architectures and methods, the fundamentals of software, than in technologies. A hexagonal architecture remains hexagonal, whether it’s implemented in Java or PHP.
Extending this idea, Test-Driven Development (TDD) will always be applicable at the core of the domain, whether it is implemented in C# or Scala. While unit testing frameworks may differ, the breakdown into “baby steps” is based on business considerations.
Speaking of the business domain: isn’t the search for the boundaries of modularity in a system based on a detailed study of the domain—as opposed to the technology? Yes, that’s exactly what Domain-Driven Design (#DDD) tells us.
Problems are rarely purely technical
It’s also very common for a so-called “technical” problem to actually be of an entirely different nature. If deployments aren’t frequent enough, perhaps there really is a CI/CD issue, but I’d still want to look into the specifications, the breakdown, and the prioritization.
Software quality is about code, yes, but not only that. Focusing solely on the code while ignoring everything around it, and especially the upstream processes, would be futile. We must take into account the product (it all starts with the functional specification), Agile (minimizing tunnel vision), and the organization (staying as close as possible to observed communication patterns).
It’s also essential to be able to rely on the right people by attracting them and making them want to stay (the importance of company culture, which also takes work to build), and sometimes helping people reach their full potential as expected by the organization through individual coaching.
Only then can we talk about technical expertise. All this to say that whether it’s Rust or Erlang, that’s not really the point.
A measure of clean code
If we take “Clean Code” literally, it would even be an achievement to understand what code written in a language you don’t master actually does. That would be proof that the code conveys business intent without being obscured by technical “noise”—the language’s keywords.
This would be a great way to test the quality of the core business logic: give it to someone from the Product team to read. If they understand it, that means you’ve done a really good job 😊