In the grand scheme of things, remote work is still a relatively new phenomenon. This is easy to forget when it’s part of one’s everyday life — which is why it’s all the more important to remind oneself that nobody has it figured out perfectly yet.
People and organizations are still experimenting — succeeding, yes. But also: struggling. Failing. We’re all exploring and negotiating the future of work.
Software developers use computers not only for writing programs — they also use them to communicate and collaborate with one another. Software development is very much a social activity: collaboration and communication activities can have a powerful impact on the success of software projects.
Computer-support for these activities is not restricted to remote companies or distributed projects — even co-located teams use software that supports group communication and collaboration in their daily work.
When you build software, sooner or later you’ll 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-game currency” games or in casinos.
Instead, I want you to think about human motivation in a sustainable manner that is also good for your users. Making them addicts isn’t the way.
If you build software products, chances are 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?
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?
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 challenges do they have to cope with in return?
Studies have shown that about 30% to 50% of what we do in a day can be called habitual. 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.
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 and channels are built by people who are software developers themselves.
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?
A few days ago, my piano teacher recommended a book to me: Play It Again: An Amateur Against The Impossible by Alan Rusbridger, formerly editor-in-chief of The Guardian. I devoured it within three days.
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 process to create software for a customer. This course wasn’t about programming, really: it was about working on a team, communication, and good practices. That’s what made it so memorable.
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.
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 for these four days I spent in San Francisco.
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 I was no longer obligated to correct someone else calling me a doctor. However, I was not allowed to call myself that until I had published it — again, adhering to some regulations. Due to the power of self-publishing / print-on-demand (I used lulu.com), I obtained several copies of the book and my certificate only 8 days after the defense.
Previous research suggests that the publicity on GitHub that is making developers’ actions and interactions more visible might have an effect on how software development practices are communicated and how they diffuse in projects.
My colleagues (Raphael Pham, Olga Liskin, Fernando Figueira Filho, Kurt Schneider) and I wondered: which influence does this have on testing practices? Does this create new challenges, and if so, how do developers cope with them? Which strategies do members of GitHub use to create a beneficial testing culture in their projects? To investigate this, we conducted interviews and questionnaires with diverse users of GitHub.
Developers use social media sites to communicate, collaborate, connect with each other, and even for competition. These sites and their users create a social programmer ecosystem with dynamics that are the subject of ongoing research.
Recently, websites have appeared that create profiles from developers’ content and activities on other sites — they are developer profile aggregators. Examples are Masterbranch and Coderwall. Among other mechanisms, both services award achievement badges to developers for specific accomplishments — such as being the most active committer in a project, or having a project forked by others.
With colleagues from Brazil and Canada, we studied users of these sites, providing us with a window into the social programmer ecosystem.
HannoverJS is a local JavaScript user group that I’ve been attending. We meet once a month in rooms provided by a local school. Founded in August 2011 by Christoph Burgdorf, we now usually have around 10 to 15 attendees and two presentations each month.
Whenever a student or colleague asks me about getting started with git, I look up a set of resources I found quite enlightening and / or useful and give them a bunch of links, often with a hand-crafted description of each. To repeat myself less often in the future, I’m now using the power of a blog post that consolidates that material.
When pulling in the latest changes from the Cappuccino repository, I often ask myself what changed, that is, in which places I can expect improvements or differences. I found it therefore favorable to have git show me just that. After some searching, it turns out this is quite easy.