All Case Studies Design Development Interviews Our Way Project Management

Insights from Code Europe 2017 Krakow - Was it Worth Going?

Some time ago, I participated in the Code Europe 2017 conference, Cracow edition. As much as I love going abroad for such events, being able to attend a conference in the city I live in, without having to plan anything else than a lunch break, was a nice change. The event was held at ICE Krakow Congress Centre, a modern and elegant building in close proximity to the city centre.

Code Europe had a very rich schedule. The day was filled with lectures and workshops, and as some of them took longer than others, they overlapped a bit. Most presentations were primarily concerned with programming (development, testing, devops), but there were some interesting presentations about communication and project management.

Lectures

As I said, there were a lot of topics to choose from. I, for instance, attended lectures on good practices in Object Oriented Programming, hardware hacking for web developers, advanced search (presented by elasticsearch team member), and many, many others. I’d like to draw your attention to two of them and give you a brief overview of what the speakers said.

A New Design Mindset - Breaking the silos (by Ricardo Brito)

Ricardo, a senior designer in Futurice and the only presenting designer at Code Europe Kraków, started his lecture by describing the history of the Internet. He emphasized how fast the Internet developed and how seamlessly it became part of our everyday lives. We’re currently surrounded by the “Internet of Things”, from which the next step is the “Internet of Thoughts”. Ricardo pointed out that this change is already taking place in the world but has not been popularized yet. He brought up the story of David Vintiner, a human cyborg.

 

Why did he use such an opening? Brito wanted to point out that the work of a designer is no longer linear. Even if it was possible in the past to keep a nice separation between designing real objects (e.g. chairs) from the ones designed for displays (e.g. web application interfaces), nowadays their job often refers to both of these spaces (e.g. an interface for smart home management). The relation between a designer, who presents his ideas for user experience, and a developer, who verifies the possibility of implementing the designer’s ideas, has become more and more important. Brito emphasized the importance of communication between the two. According to him, here’s what impacts the quality of a team’s work:

  • Respect, which we should give to each other. Everyone is an expert in their department, and we shouldn’t undermine other people’s knowledge. Yes, challenging each other with asking questions is a good practice, we should trust the expert’s opinion in the end.

  • Language: “What are you saying?”, meaning the communication as a whole. It’s very important that we learn to speak a common language and explain to each other why and how something works. It adds value when we use the other person’s tools when we explain something to them. The example was an Android developer who used sticky notes (the favourite tool of designers, according to Brito) to explain a backend process.

  • Mindset: empathy, understanding each other, and the ability to put oneself in the situation of the other person.

  • Taste in music: there was no pun ¯\_(ツ)_/¯

Brito described the story of his collaboration with an engineer who had a completely different idea on how to accomplish the task they were given. He pointed out how hard it was for them to agree on anything. It was so hard, that at some point it influenced the implementation of the whole project. Working their ways to find a common language, they developed an IoT Service Kit, a board game whose aim is to make it easier to work on projects related to the Internet of Things.

Fighting the controls: Madness and tragedy in programming (by Daniele Procida)

The lecture revolved around the process of debugging and application from the developer’s perspective. It was presented by Daniele Procida, who very originally started the topic by comparing a programmer to a pilot. His idea was based on the fact that as developers, we fulfil our tasks following some procedures and guidelines, expecting positive results when we meet some unexpected critical situations sometimes. Yes, in the case of web-developer, there are probably no lives in danger, but the most important part of the concept was that as programmers, we could learn a lot from the pilots about dealing with stressful situations and prepare for them before they occur. He also compared pair-programming to the co-piloting of a plane, when one person is responsible for the piloting (programming) and the other one for communication (verifying actions, reading the manuals).

In the second part, Procida explained the difference between programming and debugging:

  • Programming -> a creative process (similar to writing a novel) – “making stuff happen” and defining the place we’re in.

  • Debugging -> an analytic process – understanding why we’re here. “A dev feels the need to suffer the pain alone” – no developer wants to admit that there’s a problem before it gets solved.

Let’s take the example of finding a critical bug in the production environment on a Friday night. What do we do?

  • We don’t tell anyone but search the server logs for any clues

  • We enter the server via SSH, restart everything we can, and it doesn’t help

  • We start changing the configuration code via an SSH connection (something we wouldn’t even think of doing), and still has no results

  • We panic

  • It turns out that we connected to the wrong server

All the errors we made in this case were caused by our loss of situational awareness. Our ability of accurately analyzing the situation was reduced by tiredness and stress.

Here are some suggestions he made on how to learn from pilots:

  • Private decision making is of poor quality -> Communicate explicitly. Let’s take advantage of the fact that we’re not completely alone and try to make important decisions after discussing it with other developers. It’s usually good enough to post a question online, and the minute it’s up, someone will usually post a solution to our problem.

  • Stop fighting the controls -> Sometimes the best thing is to not do anything for a moment. We don’t have to decide about the solution the second we discover some problem. Sometimes, we just need to leave the problem for some time and take a deep breath before fixing it.

  • Adopt checklists. Procida says that it would surprise anyone to know how much time a pilot has between recognizing a critical situation and deciding on how to fix it. They have enough time to go through manuals (checklists) and follow the step-by-step instructions on how to behave in a given scenario. Procida emphasized the fact that we rarely see such checklists in the IT world and this is something that could and should be implemented.  

Procida rounded up his presentation by saying that he hopes to change the image of debugging in our community. He would like to see us talk about it more often and embrace it, instead of treating it as an embarrassing and lonely endeavor.

Summary

Code Europe 2017 Cracow edition was organized very well. Choosing ICE Krakow as the event’s venue added more prestige to the conference. The agenda was rich and diverse, and most of the talks were delivered in English. Everyone received a welcome pack with all that was needed: a schedule, a water bottle, an energy bar, a notebook with a pen and stickers. :) The event’s sponsors had their stands where you could talk to companies’ representatives or win a cool gadget.

I’m looking forward to the next edition!

Why it is impossible to hire quality engineers in London and how to deal with it
Follow Netguru
Join our Newsletter

Scaling SaaS
READ ALSO FROM Events
Read also
Need a successful project?
Estimate project or contact us