Earlier this year I gave a talk at Write The Docs, in Prague. I have written about the content of that talk previously. The good folks of Write The Docs have now published the talk recordings from the event. Mine included.
Once again, my thanks go to the organisers and the attendees of Write The Docs. It's a really fun event with a great mix of different participants. I cannot recommend it enough to people (or companies) that have interest in good tech writing.
This is the first of two blog posts I will write about Write The Docs Europe. I'll kick-off by writing about my presentation, but later I will write about my views of the event as a whole.
I spoke at the Write The Docs Unconference in Berlin last year. At the time I talked about how Free Software projects emerge from an idea to success and some of the "laws" they abide by in order to get there. As part of that presentation I wanted to begin my personal journey of better-understanding the "laws" followed by tech writers. The subsequent workshops around this topic produced some interesting results for which the results can be read here.
In Prague I wanted to move from a "pull" to a "push" model and presented some of the laws that apply to software engineers (not just Free Software).
Really great talk by @therealpadams @ #writethedocs witty, packed with insights. Need to get him to London for the meetups :)
— Kristof Van Tomme (@kvantomme) September 1, 2015
Woah! Open source software is a "product". But the term contains engineeringeese, which is a cultural issue. @therealpadams #writethedocs
— Samuel Wright (@plaindocs) September 1, 2015
Point @therealpadams is making with these "engineering" laws is that they're not engineering laws. They're management "laws". #WriteTheDocs
— Karen Mardahl (@kmdk) September 1, 2015
Awwww ❄ @therealpadams #writethedocs pic.twitter.com/5rTjbS4obF
— Ancsur (@Ancsur2002) September 1, 2015
Miss my talk at Ignite Berlin 5? Well here's your chance to see the recording. A quick reminder:
This was a really difficult talk to prepare for. I would use this many slides in a talk that is waaaaay longer than 5 minutes. In this format, the speaker is basically forced to tell a 5 minute story and ensure ("hope") that the story progresses at the same pace as the slides.
If you head over to Peter Bihr's account on YouTube you will find all of the other talks from the same event. I highly recommend the talks from Claudia (on typewriters) and from Jessilyn and Neil (on how to ale long-distance work).
Also, in case you have not seen it, get yourself over here to see an article on the original concept art for Pac-Man. Cool stuff.
Yay @nigelbabu! Also, cool shoutout to @therealpadams just in time for @writethedocs Prague :-) #writethedocs https://t.co/rlxuTXJfsG
— Mikey Ariel (@thatdocslady) July 31, 2015
I spoke at the Write The Docs unconf in Berlin a year. It had been a long time since I had spoken at a non-engineering event. Even longer since I last spoke at an event without an explicit Free Software connection, too. I enjoyed the event and I obviously did not make a fool out of myself, because I am due to speak at the next Write The Docs European conference in Prague.
What are the rules documentarians play by?If you follow the link in the Tweet (above) or follow this link here you will find Nigel's report on what we concluded in that session. OK, so I learned a thing or two about how documents are prepared in the software product world. Cool. What's next?
My day-to-day contribution to Free Software has changed quite dramatically in the last couple of years. I'm no-longer as involved with any one project than I used to be. Somewhat correlated with my declining active contribution to Free Software projects is my decline in public speaking.
You wait forever for a bus and then two come along at the same time!
I shall be delivering two very different talks in the coming months: one in which I will remind the audience that PacMan is a real asshole and in the other I will talking about documentation communities within Free Software.
Thursday, July 30th at 19:00. IXDS studio, Paul-Lincke-Ufer 39/40, 10999 Berlin
"PacMan: The Original Troll. PacMan is one of the best-known, well-loved and often-copied games of all time. But PacMan is mocking you. You cannot beat PacMan; nobody can beat PacMan. He laughs in your face."I recently attended Enthusiasticon where one of the talks was about Pokémon and, more specifically, about how a programming error (almost certainly caused by an engineer wrestling with the GameBoy's very limited architecture) made the game bizarrely winnable. If you knew how. This inspired to get up and talk about PacMan; a game which has the opposite problem.
As an Ignite talk, I will only have 5 minutes. PacMan needs no introduction, so I can save some time there. So I will cut straight to the ghosts, the map and why you're doomed to never beat PacMan.
Spoiler alert: the "waka waka" noise that PacMan makes... that's him laughing in your face.
More of the event details can be found at the Ignite Berlin website.
Monday, August 31st and Tuesday, September 1st at 09:00. Club Lavka, Novotného lávka 201/1, 110 00 Prague
"Community Management in Free Software communities is still an emerging field and has produced a spectrum of practitioners: from master-manipulators of social media, to those more focused on metrics and data as a means to driving process. Either way, the state of the art is still largely driven by the needs of technical contributors to projects. Good documentation is a crucial component in a software product and yet often technical writers are overlooked as important stakeholders of the process. Within the community, there are undoubtedly common problems between engineers and technical writers. Software Engineering is full of laws; can we show that these laws apply to technical writers as a means to help bridge the chasm between developers and technical writers?? In this talk Paul walks us through a selection of his favourite laws of software engineering and explores how developers measure them and if technical writers must also obey them. Or not. And what that means for the success of documentation in a Free Software project."
This will be the second time that I have spoken at a Write The Docs event. These are very friendly events and very welcoming given my "deliberate outsider" position. As a software engineer I think it is fun and useful to engage with events like Write The Docs in order to reach and say "here is how I think document writers and engineers can work together better" from the engineering perspective.
In this particular talk I will be exploring some of the rules and laws of software engineering and showing how I think these laws equally apply to document creation. Do these common problems create a bridge between document creation and coding? A common "platform" to work from?
Spoiler alert: 90% of this talk will be crap.
More of the event details can be found at the Write The Docs Europe website.
Say what? @valoriez is surprised to hear what I am going to say about #KDE development in my talk tomorrow. #Akademy pic.twitter.com/FLPeJQYNHb
— Paul Adams (@therealpadams) September 6, 2014
David Faure is a pleasure to work with, both within KDAB and KDE. He maintains three important character traits that, as engineers, we should all aspire to:
Despite these wonderful character traits, he has a dark side... He is a lawbreaker. So are many other KDE contributors.
In this presentation I talked about David Faure, Brooks' and Conway's laws and evaluated them in the context of KDE. Some rather fascinating, but alarming results are found!
David Faure: all-round legend and nice bloke of KDE. Fun to work with, thirst of knowledge and skill and, always thinks about the end user.
Positioning David Faure within the context of the wider KDE project and the people he works with.
Introduce Brooks' and Conway's laws: it is incredible how many people identify as software engineers, but do not know what these laws are all about.
How can we measure Brook's law in Free Software projects. We need to start by discussing how we measure anything at all! What are the sources for data in Free Software development.
How we model the community: nodes are contributors, edges show that the two contributors worked together. "Work" means they both edited the same resource in the observed timeframe. Edges get higher weights if the contributors work together in multiple resources.
From this we can find "cohesion", the average length of the shortest path between all pairs of nodes. The higher the cohesion, the more closely-knit the project is. If Brook's is correct then we should see cohesion drop with increased community size...
Yup, Brooks nailed it...
...or did he? KDE is clearly outperforming expectations here. Awesome. Well done KDE! Hint: This is where Conway's law comes into interest.
Wait, if we look at the data over time, something isn't right. Cohesion grows since 2004 until late 2007 (KDE 3.5, KDE 4.0?) but then cohesion declines...
Which just so happens to be the same pattern for funding of the eV, just offset by one year.
KDE has lost its way a little bit. Nothing disastrous yet, but the ship does need righting. As a start, being more like David and enjoying our work, continuing to learn and focusing on users, will get us headed the right way.