In a marketing consultancy devoted to project work and a development team in the role of supporting and enabling consultants, establishing and keeping up a tech culture is a difficult task. There is always the (justified) struggle of producing features as quick and cost-efficient as possible on the one hand and the need for containing technical debt and achieving a reasonable quality on crucial components, not visible to clients, on the other. The first is a rather short term goal for immediate client satisfaction, the second more long term for achieving competitive advantage. Both have to be balanced carefully with the pendulum swinging back once it was pushed into one direction too far. Everything which does not fit onto a roadmap, e.g. engage software developers in knowledge exchange, reduce fragmentation or beeing creative and try new technologies, needs to be dealt with in a separate way.

In this environment, the development team at trommsdorff+drüner (td) used to have a weekly tech meeting, which was supposed to bring all developers from different projects together with the following intention:

• share knowledge
• have a stage for lighting talks
• discuss technologies and architecture
• establishing a tech culture in an otherwise consulting focussed company

The agenda was provided by the developers and the meeting only done with little management and organization. Sometimes it was OK, but overall this turned out to be a bad choice for several reasons:

• most of the times, nobody was adding any topics or bringing them up only spontaneously when asked during the meeting
• if there were topics, they weren’t prepared, so the discussion went often into the wrong direction and led to almost zero outcome
• developers not talking were checking mails, reading news or continued working on their tasks during the meeting

Why it failed for td, we only can guess: It’s probably lying somewhere between the company philosophy, personal preferences or a missing common goal when writing software.

Anyway, we discussed during a retrospective meeting about how to change this and agreed at first step on doing coding challenges as more playful way of achieving the mentioned aims and spending some creative time. Meetings about specific topics like architecture or organizational purpose were from there on only done on demand (which turned out to be sufficient).

Setting and preparation

We selected one person, who would prepare the first couple of meetings and then after the flow has been adapted, every team member was supposed to take over control. The base setting looked like this:

• two teams with 5 - 6 developers each
• timeline (75 - 90 minutes altogether, friday afternoonish)
  • challenge (and sometimes sample solution) pushed to github
  • questions? answers
  • coding (well, sometimes )
  • review and discussion
• one challenge per week, weekly rotating (so each team biweekly)
• time and effort is scheduled, so team velocities were reduced

The preparation was mostly searching for tasks fitting in this environment. Also, it should be a little inconvenient: Instead of giving normal coding dojos, we wanted to get the developers out of their comfort zone, at least from time to time. Everybody had this experience of picking well known problem domains and use similar approaches to solve problems. We presumed we would gain something when breaking with these habbits.

Sample challenges

In the following section, we will present two of the challenges. One was not very well accepted and led to grumpiness and no satisfactory results. The other on the contrary was happily solved and discussed in less time then anticipated. You will also find some of the other approaches we took at the end of this section.

1. Number converter

Write a number converter, which can transform roman into arabic numbers and vice versa (range 1..3999). This is a team challenge, so everybody is working on one single program and it is to be written like this:

• developers can discuss freely all the time, but code change is round-robin per developer only
• developers can change (add, remove, update) only one line of code at once or execute
• length of a line has to comply with normal coding standards

This was a nightmare. Everybody involved was at senior level and it should have taken not more then 20 minutes to solve the task alone. But this one-line-per-developer-restriction crashed everything, though the problem was actually very easy to understand. We could not agree on things like class names, data structure or loop types and instead of going quick from step to step, one line of code took almost a minute on average. One of the first challenges, which was thought of as train your skills by limiting one specific part and still trying to compete, showed us the limits.

2. Pile of paper

• Pile of paper from dailyprogrammer on reddit
• tl;dr: Calculate the color allocation of sticky notes you paste on a white board.

An awesome example! There is a little bit of reading and planing required, before we could jump into coding. But in the end, everybody could solve the problem and we had three completely different approaches all having advantages and shortcomings. There was enough time for discussion and even test performance with gigantic boards and millions of virtual post its.

3. Other examples

For reference and inspiriation, we want to shortly adress some of the other challenges we had.

3.1 Choose other problem fields!

There is more to our jobs than just programming. Especially source code management and collaboriation tools take an important place in our daily work. So why not challenge / strengthen the skills needed for using those tools?

At td we heavily use github. The git-game is a terminal game designed to test your knowledge of git commands. We approached the game as a team using a single computer.

3.2 Choose different programming languages!

When doing the coding challenges, we aim for creating room for creativity. A good source for inspiriation is to choose a programming language which you are unfamiliar with. Most of the time we use Ruby to solve tasks, some of us do that for many years now, so one can sense that whenever we are given a specific problem, we think in Ruby about it.

In one of our challenges, solving the task it self wasn’t mandatory, whereas the main focus was put on using and experiencing an - to the participant - unknown language. Most of us couldn’t finish the task on time. But more important, some caught fire on digging into a new technology and gathering knowledge about other concepts. Eventually this will pay off some day, because we might be able to pull those experiences into decisions, like choosing a technology other than the ones we are already using, which could be a much better fit for solving a specific problem.

3.3 Set different goals!

Most of the times the main goal of a coding challenge is to solve a specific programming problem. Dimensions like performance, complexity etc. are often not taken into account, which is okay since the solution to the problem itself is nontrivial. Another goal, rather than for example generating the desired output for a given input, could be to measure the mentioned dimensions. When the focus shifts from quickly flushing code from your brain into the computer to programming a more thought-through solution, the problem itself should be a little easier.

Example: Find the first 1.000.000 prime numbers. We had both, those solutions which used a naive, slower approach and those which used more sophisticated, more performant algorithms.

Conclusion and outlook

It turned out that coding katas or dojos are a simple and fun way for us to get variety in our daily work. The environment is small and straightforward with very little preparation time. Discussing different solutions to the same problem helps for widening mindsets towards approaching tasks. Most of the times, developers left the meeting with a smile on their faces. As mentioned above, this wasn’t always the case. From time to time, challenges were not perceived positiveley by all participants. Failures are always part of the deal, no matter what one is doing. Embrace them and build your experience upon them, time will show what does work and what not.

In the future, we will apply challenges also to other fields of our work, for example developing technical concepts and architectures or working in cross functional teams to build something bigger.

This is the first attempt in a series to achieve a more tech centered kosmos in a non-tech company. The next articles will cover other approaches which we want take on that journey.