On 'Expert Generalists'

I enjoy being a software engineer. Despite the general image of a developer, I found myself reading a lot more than I write. Be it a blog, an api doc, or even the code itself. One of my greatest joys in these readings is encountering an idea, a comment, or a piece of information that makes me say, 'aha!' As a curious mind, I like to pass that content around and hear people's perspectives on it. It's the same motivation that made me curate Signals & Noise.

Recently, I read an article that I'd classify as provocative, as I described above. It's Expert Generalist by Martin Fowler. I assume that if you're a person in tech, you already know that name; otherwise, search that on the internet, you will not regret it. In this article, Martin Fowler explains the term that they came up with at Thoughtworks. They come up with this term to object to the tendency to separate effective software developers from the chaff by the specifics of tooling. I agree with the observation of the industry-wide push for narrow skills. I see lots of job postings with specific requirements, such as '+5 years of experience with Python'. Sometimes even more specific, like '+3 years of experience with Django'.

On the contrary, Martin Fowler says we need more expert generalists. He defines expert generalists as individuals with a detailed command of one domain's inner workings, who are also quick learners with solid understandings of the underlying fundamentals that run beneath shifting tools and trends. That definition made me think. What are the fundamentals behind my tech stack? Do I have any idea about them? What kind of needs triggered the development of those techs? My answers are not important. The importance is the shift that those questions invoked. Up until this moment, I was also caught by the general trends. While searching for jobs, I was using the same narrow skill set as a filter. While developing my skills, I was more focused on the tools themselves rather than the problems they solve.

However, while working in a team, I have never hesitated to take on a task that is outside of my expertise or responsibility. I focused on end-to-end development experience by contributing to CI/CD pipelines, infrastructure-related updates, and even frontend development, although my expertise lies in backend development. For example, I'm currently trying to acquire some ML skills to be more valuable in my team as an MLOps professional.

Finally, this article made me realize the value of extending my existing curiosity not only horizontally across domains but also vertically within a domain, using a detail-oriented lens to see the underlying fundamentals that are shared across domains, which I already have an interest in. Here are some takeaways I noted from the article for myself:

• Perspective change from "what tool" to "which principles".
• Keep an eye on the intersections of the systems where the faults often sit.
• Building the miniature exercises can lead to a better understanding of the underlying principles.
  • Building your own Kafka.
  • A miniature Delta Lake.
  • Writing your own Kubernetes components.
• In our field, the flexible mind is not a nice-to-have but a must-have.