Meet Fionn Kelleher, Daytona's passionate Technical Writer who is on a mission to make Daytona's documentation the best in the industry. With a unique background that blends software engineering and a love for the English language, Fionn brings a fresh perspective to technical writing.
This unique amalgamation of skills enables him to approach documentation with a programmer's precision and a writer's flair, setting a high bar for quality and user-centricity in our technical docs.
The Intersection of Programming and Writing
My approach to writing docs is very much like that of a programmer. I enjoy automating processes and treating documentation as code.
Fionn Kelleher
His perspective on documentation as a critical component of product success resonates deeply with our ethos at Daytona. Fionn emphasizes the importance of understanding the user's viewpoint, a philosophy that guides his approach to creating documentation that not only informs but also enhances the user experience.
A development tool's value is only realized through clear, comprehensive documentation that enables users to harness its full potential.
Fionn Kelleher
A Conversation with Fionn
Fionn, can you tell us about your journey into technical writing and how you ended up at Daytona?
I have always had an interest in computing since I was tiny. When I was in secondary school, I knew I wanted to study computer science. So that's the route I went down.
My journey into technical writing began as a teenager, contributing to open-source projects. A turning point came when I participated in a competition organized by Walmart Labs in the United States. The prize was an iPad, and the challenge was to create a getting started guide for a JavaScript framework. I completed the task, which not only led to winning the competition but also landed me a job at a JavaScript consultancy. That experience marked the beginning of my professional career in the field.
Initially, when I got interested in computing, I wanted to get into software engineering more than anything. But I stayed away from it because I liked doing that as a hobby. I felt if I did it for work, it would sort of take it away from it a little bit. And yeah, I love English. I've always been very good at English. So it was pretty natural for me, I think, to mix writing and software engineering into technical writing.
The process of writing in natural language and programming share many similarities. In both cases, you need to maintain a coherent thread of thought throughout your work. Your ideas must be expressed with clear logic and make sense to the reader. Whether you're writing an article or a software program, the goal is to create something that can be reproduced and understood by others. The main difference lies in the language used, but the fundamental principles of clarity, logic, and reproducibility remain the same.
Your perspective on comparing technical writing to programming is quite fascinating. Could you share some insights on how you approach writing documentation? What is your process like?
I think because I come from a background in software engineering and I love to automate things, that's always my mindset when it comes to docs. So I'm very interested in more broad effortswithin the technical writing community, such as docs as tests, where the idea is if you have code blocks in your documentation, you can do automated tests on them to verify if they actually work.
My mindset when it comes to docs is very much the mindset of a programmer. I like to hack things. I like to automate things as much as I can. And then the actual content - at the end of the day, it comes down to putting yourself in the mind of a user and figuring out what it is that they're going to want to be able to do with your product, and the edge cases where they might be missing some knowledge, or they might struggle to connect certain concepts together.
I spend a significant amount of time planning and preparing before I start writing because you can easily waste hours producing useless documentation. For me, the planning and preparation phase is crucial. It's important to be the first consumer of the content you create. You need to understand how to do the task yourself before you begin writing about it.
That makes a lot of sense. Can you share a bit about your previous experiences, especially in open source? Why do you think open source is important?
I started using Linux when I was around 11 or 12 years old. Whenever I attend FOSDEM and catch up with people slightly older than me, it's interesting to hear that they share a similar experience. They often mention starting with Linux at the age of 11 as well. However, when I ask them about the distribution they used, they usually name something like Slackware, which I’d never even heard of due to its age. In my case, I began my Linux journey with Ubuntu, and today, I spend a lot of time in the Fedora and NixOS communities.
And from there the reason I started using Ubuntu actually was that we tried to upgrade our family computer from Windows XP to Vista. I was really excited about it at the time. But ultimately, our computer wasn't powerful enough to run it. And I got a bit frustrated. So I was like, forget this, I'm going to install Linux and see where it takes me.
From that point forward, I began digging deeper into the world of open source, learning more about its inner workings. For me, open source is important from both an ethical and political standpoint, and it's also enjoyable to collaborate with friends on various projects. I believe open source is crucial in our rapidly evolving tech landscape.
Shifting gears to Daytona - what's your vision for Daytona Docs? Where do you want to see it go in the future?
As I collaborate closely with Ivan, we often find ourselves engaged in thought-provoking discussions, exploring ideas that sometimes conflict. However, I believe these conversations are incredibly valuable, as they allow us to reach a compromise that ultimately leads to a better version of our work.
In my opinion, documentation is an integral part of the overall offering and needs to be completely aligned and in sync with the product to ensure a seamless user experience. You can have the most exceptional dev tool ever created, but without comprehensive documentation explaining how it works, how to install it, and how to onboard people, the product loses its purpose, and customers are less likely to adopt it.
Personally, if I come across a tool, whether it's a command line tool, an app, or anything else, and it has subpar documentation, I am less inclined to invest time in learning how to use it. This is the main reason I want to focus on creating excellent documentation for Daytona, both for the enterprise and open source versions. While my current efforts are primarily directed towards the open source docs, I envision them being highly useful and, hopefully, superior to those of our competitors. However, it's not for me to judge.
Speaking from my own experience, documentation is usually the first thing I examine when evaluating a new tool. I might briefly glance at the landing page, but I quickly dive into the docs to determine how the tool actually works, if it functions as expected, and if it makes sense within my workflow.
One more question - what's your opinion on the role of AI in docs and tooling in general? Is it possible to replace technical writers with AI?
Although I had great professors during my time at university, AI wasn't a field I studied extensively, so my opinion is only somewhat educated on the matter.
In my opinion, AI or machine learning is unlikely to replace the art of writing documentation in the near future. For that to happen, a model would need to be capable of learning and comprehending how a codebase functions, and then explaining it in a clear and concise manner to new users. While I could be mistaken, I believe that at present, this level of sophistication is not achievable.
AI could potentially play a role in user experience by leveraging documentation. For example, a chatbot could be developed to answer questions and provide information based on the available documentation.
Mozilla attempted to implement a similar feature in their developer documentation, but it faced significant backlash due to the system providing highly inaccurate answers. As a result, the Mozilla Developer Network (MDN) documentation, known for its accuracy, was jokingly compared to the historically unreliable W3Schools in some spaces.
But yes, AI has the potential to play a significant role in assisting users with discovering relevant documentation and quickly finding answers to their questions. I also believe that documentation is the essential foundation layer, acting as a crucial input for AI applications to build upon and enhance the user experience.
Connecting with Fionn Kelleher
Anything else to add? Have we missed something important you'd like to mention? Where can people connect with you?
Not really, I'm excited to build out our docs to be best-in-class and make Daytona the go-to solution for dev environments management. If you'd like to connect and exchange ideas, feel free to reach out to me on LinkedIn or Mastodon, where you can find me under the handle @osslate@mastodon.ie.
Thanks for the great conversation!
...at the end of the day, it's about putting yourself in the user's shoes, anticipating their needs, and bridging any knowledge gaps they might have.
