- What do you want to do at Alan? How do you see your ideal role?
I'll be answering this in two parts - what I'd want to do anywhere quite generically, and what might make me feel happy at Alan, given what I know about the organization.
Perhaps the biggest thing I intend to do, in any professional role, is to "bring my whole self to work", and expect and encourage others around me to do the same. I've long felt that the software industry tends to get too hung up on narrowly defined "roles" - developer, tester, architect, data person, and so on. For me, each person fits the Whitman quote, "I am vast, I contain multitudes". We each have a variety of resources we can draw upon, developed from past professional experience or from personal life - as a parent, a spouse, a friend, a volunteer, and so on - or from how other people or even fictional characters have inspired us.
For instance, while I primarily think of myself as a developer, one of my facets consists of team "coaching" tools. One such tool that I have developed for my own use is a workshop called "Chimères", designed to make teams I work with more conscious of the wealth of resources available to each individually, and if they choose, to the team as a whole. For me the purpose of work is to serve human connection, rather than the other way around, and that is also why I increasingly pay attention to inclusion and diversity as a key aspect of work culture.
Another important part of working anywhere is to feel that what I do is useful and wanted. To work on software at present is to take on far-reaching responsibility, as the tiniest of decisions we make can end up impacting people; delighting them, making their lives and jobs easier, or making them feel like victims. It's important for me to develop and help others develop the skills needed to take on these responsibilities - product design, customer support and observation, all the way to thinking about the ethics of our profession.
At this stage in my life and career it has become important also to focus on passing on the skills and resources I have acquired. I feel that there is much more leverage in helping many others grow in skill, mastery and confidence, than in striving to become the best individually. While I invest in my own learning continually as a matter of habit and principle, I want to expand the time I spend teaching others - which I have found is also a great way to enhance my own learning!
I have been acting on this intent in many ways; as an informal daily practice, or in code reviews; but also in more formal ways, including pair programming (mostly local, with a few stabs at remote pairing), hands-on teaching in "coding dojo" or similar formats, mentoring with some formal definition of objectives and progressions, mob programming on occasion, and I aim at making this a routine part of my work; not a sideline but an integral part of contributing to the effective delivery of significant technical work.
As to the challenges that might appeal to me specifically at Alan, they have to do with the particular combination of size, maturity and ambition of the organization.
The culture in which I currently work, at beta.gouv.fr, is similar in many ways to Alan's but one of the key structural differences is that beta deploys many small autonomous product teams, with little technical interdependence. This has meant that I could either take technical leadership within one particular team (as I did for instance on the OpenFisca initiative) or make mostly non-technical contributions to the overall culture. Although I did contribute to some exciting work around, for instance, "API-fication" of the State's IT, this was more a peripheral concern at beta rather than the central mission, and tended to occur at a slow pace because of the inertia inherent in ministerial bureaucracies.
The opportunity I see at Alan is to focus more on problems that are both technical and cross-cutting, because the teams there are (I imagine) interdependent to a greater extent, working on various facets a more unified value proposition. And while I'm aware that some of the systems Alan interacts with are also prone to the ossification that afflicts public sector IT, I expect that the internal technical stack is capable of faster evolution.
Speaking of evolution, I'm not hung up on caring for so-called "legacy" code. When, in Kurt Vonnegut's words, "everyone wants to build, but no-one wants to do maintenance", we end up in a bad place. I like to refactor, tweak, improve, add tests where they are needed, delete dead code and useless tests. I like to introduce modularity where it's lacking, so that pieces with value can be extracted. (I'm proud to have inspired the name of the "Mikado Method" for the strategic application of refactoring!)
Summarizing, my ideal role is one where I connect with people, get my hands dirty with the nitty-gritty of solving people's problems with software, act as a discreet leader, help others grow as creative problem solvers, and where I get to pull out various tools from my toolkit as they are needed.
- How do you want to grow at Alan?
I have lots of experience working at the team level. I would like to pay more attention now to what it takes for multiple teams to be effective together as an interdependent whole, and work on that level as well. I would like to grow as a teacher and mentor, passing on effective software development techniques I have learned. Beyond engineering software I am starting to feel qualified to engineer the skills and knowledge that make up effective software teams.
One area where I feel like I have plateaued lately and where I would like to make a fresh start is public speaking and storytelling. Despite being a frequent speaker, averaging about 3 conference engagements a year over the past 20 years, I feel that I need to rethink my approach.
- What do you want to learn with us? What can you teach us?
Learning and teaching are two sides of the same coin as far as I am concerned; in many areas I've learned most by attempting to teach what I knew, even if it wasn't much, and I love having opportunities to learn with others. Rather than a strict classification into "what I could learn at Alan / what I'm currently learning that I could share / what I know well enough to teach", the following is therefore more of a gradient with fuzzy edges.
Naturally I would be looking forward to learning a lot about the business domain of health services and insurance. (One of my favorite things about working in software is how it can lead to working in almost every possible business domain and seeing how they work "behind the scenes"!)
Among of the aspects of Alan's culture that both intrigues me and makes me a bit nervous is the reliance on written over oral communication. I am really curious to observe how that works.
Lately I have become more curious about various forms of mapping and visualizing. I would like to dig deeper into the work of Simon Wardley (https://medium.com/wardleymaps), to gain better understanding of how "digital services" fit into their markets and value chains.
Unexpectedly, a substantial portion of my work in the past two years has revolved around "cybersecurity". I learned a lot about making security analysis more relevant and more fun for Agile teams, and eventually wrote a short booklet on the topic (https://www.ssi.gouv.fr/uploads/2018/11/guide-securite-numerique-agile-anssi-pa-v1.pdf). While I have no wish to become a "security expert" this has been a valuable addition to my skillset and one that I wouldn't mind passing along.
When I took a step back from this apparently accidental learning, though, I could see that it fit into an interest of mine for the broader topic of "resilience" in software systems. I have been following the work of Nora Jones, John Allspaw and others in "learning from incidents" currently crystallizing into a new online community (https://www.learningfromincidents.io/), finding parallels with what I learned from the grand trilogy "Les Décisions Absurdes" by Christian Morel and his latter work on High Reliability Organizations.
On the technical side, my continuing love story with Haskell and functional programming, which has been ongoing for years (with a few side-trips into Elm or Purescript) is one that I'd love to share with others, just as I expect to have fun deepening my mastery of Python which I discovered while working on OpenFisca.
While I feel that my public speaking skills need to be taken to the next level, I have a lot of experience in that domain; I see it as a crucial part of being "a leader in one's field" and I would appreciate opportunities to help others less experienced break into the speaking circuit.
When I'm learning (or teaching) work feels like play!
- What is your point of view on testing ?
Testing is a very important topic to me! I'm proud to think of myself as a "honorary tester", having participated, spoken or keynoted at a number of testing conferences, and formed friendships and intellectual partnerships with leading lights of the testing community such as Jerry Weinberg, Fiona Charles or Michael Bolton.
Testing is a topic I have studied extensively, on which my thinking has undergone several "copernican revolutions", each time taking a broader view. Accordingly I have also come to suspect it is one where the software industry as a whole has significant opportunities for growth.
The broad phases of my thinking about testing were roughly as follows:
- thinking of testing as something others should do, not me
- embracing "developer testing" primarily through Test-Driven Development
- moving to a systems view of software quality
- seeing testing as a particular application of critical thinking
- most recently, placing it in a broader perspective that includes security and resilience
Early in my career I advocated consistently for testing as a critical step in development, but outsourcing it to specialist companies. At the time (early 1990s) this was still a fairly orthodox position. I later traced it to an influential 1976 book by G. Myers, "The Art of Software Testing" which stated it as an axiom that "programmers should not test their own code". His reasoning was that programmers suffered a psychological bias to think in a positive light of their own work, and therefore would not want to think of ways their code could break.
Later, I realized I was making excuses for not doing my job well enough. It would have cost money and time to find specialist testers and work with them, and I placed the burden on my employers to do this, rather than take the initiative to do it myself. I studied languages like Eiffel with a heavy emphasis on program correctness, and said that I wanted my programs to be correct, but I blamed the languages I was "forced" to use in industry settings for the bugs I was writing myself.
When I came across Test-Driven Development it was like a light bulb being switched on. By thinking of the tests before of thinking how to write the code, I could escape from the trap of psychological bias in favor of my code. I started practicing Test-Driven Development (along with as much of Extreme Programming as I could), and learned immensely from extensive conversations with Kent Beck and the Extreme Programming community, over mailing lists and the C2 wiki.
My ability to write programs that did not quickly become unmaintainable had grown significantly, but I also understood that reducing software quality to a narrow notion of "correctness" was of little use. I could write all my code using TDD but that was of limited use if I couldn't understand the perspectives of other developers around me - why they would embrace it or reject it, and why for many of them rejecting it was the most rational response given the management systems in which they worked, for example. Even if a whole team adopted TDD, that would be useless if they couldn't talk effectively with end users and "customers" to figure out what tests needed to be green. I also encountered many teams where an uncritical obsession "write automated tests for everything" had led to counter-productive results, such as huge and slow test suites that stretched feedback cycles, discouraged refactoring and ultimately led to disillusion with automated tests.
I became more interested in seeing software from a systems perspective - not just lines of code, but complex interactions between technical components and human actors who might have diverse and sometimes conflicting perspectives on what counted as "quality". Using Jerry Weinberg's "Quality Software Management" series as the conceptual backbone for this new view, I enjoyed many instructive years as a process consultant - which in my view was a form of testing, and sometimes debugging, the larger socio-technical systems that formed around the process of writing software.
Eventually that led me to look at "Software Engineering" as a whole - the academic discipline on which the profession's formal training rests - as a source of persistent errors in management doctrine. I examined several claims about issues like "the variation of developer productivity" or "the exponentially rising costs of software defects" and various founding myths such as the waterfall process, and found a troubling lack of critical thinking around these issues.
June 2023 addendum:
The above is still largely relevant to where I stand today and picking my next adventure after two years at a technical leadership role in a small service company.
The major update from those two years: I ended up picking a more explicitly managerial role. My responsibilities included sourcing, selecting, interviewing and onboarding candidates, and helping them once recruited with their professional development and job objectives. The onboarding portion (four weeks for each new hire) involved a lot of hands-on, "dojo" format training and this level of investment in the onboarding process was a major differentiator for my employer.
Part of the role also included putting my "consultant" hat back on, developing the company's "technical coaching" practice commercially, and of course carrying out the engagements as well. This gave me the opportunity to develop and pass on my Wardley mapping skills. The other major theme of "learning from incidents" was also present, perhaps slanted a bit more towards the "debugging" end of the spectrum. One of the more significant engagements was with a client in the green energy sector, where we helped a product team (staffed with an impressive number of PhDs) get a firmer grip on their incident and problem resolution, and ended up helping them achieve savings of $2M on an annual $15M cloud bill.
I'm happy to report that my talk at NewCrafts 2023 did feel like a fresh start to me. There was a lot that contributed to making a change:
I feel like there is still lots of room for improvement, in particular on the delivery aspects. But I'm much happier now with the idea of going back to public speaking than I was when I wrote the above.
My next project is likely to be a full-blown "conférence gesticulée", a French invention (cocorico) which is a little bit closer to a theatrical performance and a bit further away from your run of the mill conference talk.