Discovering new and better ways for engineering teams to work at Ghost. PhD of CS; student of life. Prev. Automattic, iDoneThis, academia, founder. Remote since 2013. Say hello!
When you build software, sooner or later you will want to think about human behavior — most notably about what motivates humans. I don’t mean Skinner boxes, points and ladders, variable reward schedules and the like as you might find them in “free to play but we have an in-
If you build software products, chances are that you’ve worried about adoption before. Will anyone use what I’ve built? How can I get more people to use it? And why do people leave after a few days? Many people have written about this problem, and there are indeed
Developers use many, many tools to collaborate. Those tools solve problems, but also create new challenges: distractions impede productivity, developers struggle to keep up with everything, or partially adopted tools — those are just a few examples. But how can we tackle those problems? In this post, I share six recommendations
Software developers use many tools to support their work. They coordinate with their teams on code hosting sites, interface with non-developers in project management apps, use microblogs to network, and learn through Q&A sites and podcasts. They do derive value from those tools — but what problems and
Studies have shown that about 30% to 50% of what we do in a day can be called habitual [1]. However, adopting new habits is hard: at least I have always struggled with making things stick. But now I think I’ve found something that works for me. It’s
Software developers use more and more tools in their work. Some are directly aimed at creating software, such as IDEs or editors, but many tools play more supportive roles. They help developers communicate, collaborate, and coordinate with others, find new work, or keep up with new technologies. All these tools
Lots of research in software engineering is using publicly-available data from GitHub nowadays. But do findings from such studies translate to closed-sourced development projects? After all, open source development has established a few practices and social conventions that might not be found in companies. In addition, GitHub lends
A few days ago, my piano teacher recommended a book to me: Play It Again: An Amateur Against The Impossible by Alan Rusbridger [commission earned], formerly editor-in-chief of The Guardian. I devoured it within three days. Rusbridger recounts how over about 18 months, he learned playing Chopin’s
Back when I was at the University of Hannover working on my PhD, I was also involved in teaching. One of the most memorable experiences was organizing and managing the “software project” course four years in a row. Every year, multiple teams of five students each went through a waterfall
Many software developers use Twitter in their work, but how and why exactly do they use it? Why do some developers choose not to use Twitter, and what — if anything — do they use instead? We conducted a qualitative study to investigate these questions in depth. TL;DR: Twitter can help
From May 22 till May 25, I attended ICSE 2013 — the 35th International Conference on Software Engineering — in San Francisco. Apart from learning about new research and connecting with colleagues, I interviewed local practitioners, hugged the Octocat, and was ON A BOAT. This blog post provides some (non-comprehensive) details
On February 11 2013, I defended my PhD thesis with the title “Improving the Adoption of Software Engineering Practices Through Persuasive Interventions”. Thanks a lot to Felienne who live-blogged my defense talk and the questioning by the committee. Due to German regulations, having defended my thesis merely meant that