The unexciting GOTO Berlin 2017

Unexciting. That’s the one word I would use to describe this year’s edition of GOTO Berlin. And I’m suspecting it’s a sign of advancing maturity. Just not sure whether it’s the industry’s, or my own.

This year was my second time at GOTO Berlin, after I attended in December 2015. I came back because the first time I was really satisfied with the content. Lots of fresh, practical, accessible ideas, well-presented (unlike, say, QCon London 2016). Plus, the keynotes were tremendous fun.

GOTO Berlin 2017 Convention Hall

Keynotes are always tricky for the organizers, because you want them to be somewhat abstracted from the low-level themes of sessions, but not too far away, so that the audience can still relate. Plus, they need really engaging speakers. GOTO Berlin pulled this off perfectly. The 2015 edition had space-themed keynotes about the Apollo and Space Shuttle programs, mighty interesting. This year featured a variety: Mars exploration, data science, autonomous systems and data security. Really, really good content.

This year’s sessions, however, surprised me with how little new stuff there was. Nothing really bleeding-edge. Same topics I keep hearing about for the last two-three years: microservices, DDD, containers (and agile, of course, but I staid away from “soft” themes). Even serverless, that I thought would be the buzzword of this year, seems ubiquitous and long-tamed.

Not that any of these are boring—to the contrary, they’ve now reached mainstream adoption and presenters have a lot of real-world experience to share (as opposed to theories and hopeful evangelization). It’s just… what happened to the breakneck speed of “innovation” in this industry?

Granted, there was a lot of talk about AI, which seems to be the bleeding-edge stuff these days. But I staid away from those sessions too. We still need to prove we can deliver well-structured “dumb” software before we can think of constructing anything “smart”.

So, what did I see?

Rust and WebAssembly were the only real, new things for me. Emerging languages and platforms, the first one may help us make proper use of concurrency and multi-core processors:

and the latest Firefox release already benefits from it. The second might help us build advanced applications for the web.

The rest of the sessions I attended were all about: how do you deal with the real world? Not some fresh, hot framework or cloud service, but the day-to-day grind of working in a business environment, modeling a highly irregular world in code, maintaining multi-year- and decade-old legacy code. All of this in a time of cheap networking, favoring distributed systems, where failure is the rule, not the exception.

It may be that the industry has changed. Reflected on itself and found that technological novelties are fun, but often leave real-world problems unsolved. Came back to Earth and asked itself “what are we really trying to achieve?” Or… it may be that I’m the one who changed. I still enjoy new toys, but there’s work to do down here. An approach that informed my choice of sessions to attend, and so influenced my impressions.

Programming with a thesaurus

Source code needs to read like a book, with characters introduced in proper order and the plot unfolding logically for the reader to follow. Naming is key. The right word used in the right place—a function, class, variable name—will help avoid many a bug. That’s where a thesaurus will come in handy.

A thesaurus is a reference of words with similar meanings, used “to find the word, or words, by which [an] idea may be most fitly and aptly expressed” (as the architect of, apparently, the best-known English thesaurus wrote). That’s exactly what we aim for in code—express our intent for future programmers, including ourselves, to precisely understand. It’s easy to write code computers understand. When they don’t they tell you at compilation time.

A function or class name must “most fitly and aptly” match what it’s doing. A variable name must likewise accurately describe what it holds.

How many get...() functions did you see in your life? How many of them were actually “getting” things, and only getting them? How many were additionally storing data, creating entities, causing all sorts of side effects?

It’s not just a matter of sloppy programming. Naming creates the boundaries within which a programmer will naturally try to navigate. If you call a class a CompanyManager then anything you try to do with companies will fit into it—retrieving, storing, filtering, listing, sorting etc. That class will eventually evolve into a multi-thousand-line monster.

Help yourself to a thesaurus. Any old one will do, and I personally use thesaurus.com whenever I have trouble finding the right word. For instance, try “create“:

build, construct, discover, establish, form, generate, initiate, shape, start, compose

… and many other alternatives. These are just the ones I thought might be useful in a code base. Say, you want a function to setup a connection to a remote service. You could name it createConnection() but from the above list I’d prefer initiateConnection(). A factory method could be named createInstance() but I’d rather use constructInstance()—referring to the well-known constructor pattern. A function that’ll search for a specific service to connect to, could be called discover...() and so on.

It’s fun, though perhaps I’m biased here, as I find great enjoyment in playing with words, where others will prefer to get on with their work. But it’s worth the effort.

It’s his job

Perhaps it is. But does he know it? Have you told him? In teamwork, as in marriage, implicit expectations create tension that’s bound to explode at some point. Disarming that bomb is as easy as saying “could you?”

Some jobs have tighter-defined responsibilities than others. Across the spectrum of employment that’s obvious—if you’re, say, a train driver your job is to safely steer a few thousand tons of steel, carrying a few hundred human lives to their desired destinations. If you’re an artist, there’s much less specificity.

Even within the IT industry there are vast differences in job descriptions. A DBA is tasked with maintaining dabatase servers, often including developing data models and optimizing queries for efficiency. For a developer, things get a bit more blurry, being expected not just to write code, but these days often also setting up server infrastructure, configuring deployments, monitoring service health and, perhaps hardest of all, understanding and catering for user needs.

Then there are the managers, whose job descriptions are becoming increasingly confusing. Ensuring timely delivery, supervising quality, motivating their reports and caring for their career development. Everybody nods their heads in agreement on those, but what do these mean in practice?

In the (inherent) absence of specifics in one’s listing of responsibilities, both the manager in question as well as everyone around them will develop their own image of what these should be. In particular, their reports will have varying expectations. Some will want them to be a communications bridge, others will prefer communicating directly. Some will want vision and guidance, others will want to have their own say. (I’m singling out managers here because of the evidence of the problem here, but the same concerns every job with a blurry description.)

The issue? Nobody tells them! The manager have their own view on responsibilities, obviously, and will execute against those. (Plus there are the manager’s managers to cater for.) They will, regretably, often not sit down for a frank conversation with their team to talk out what everybody’s role is. The result is frustration buildup. Reports holding watercooler conversations, complaining about their manager not leading this, not reacting to that, not talking to someone, etc. And they won’t tell the manager because they feel it’s inappropriate or for fear of retaliation.

I made a sport of calling out these situations. My lovely wife had thaught me from the outset of our relationship that if either of us wants the other to do (or not to do) something, we better voice it. Otherwise it’ll pile up over time, explode at the least opportune moment, causing irreparable damage.

It’s the same at work.

Take your manager out for coffee (if it’s your first time, the setting should help loosen up everybody), then tell them: “Bob/Kathleen, could you ask our CTO for help with resolving the issue we’re having with this vendor? Could you tell me how you see our priorities for the next three months?” No “I expect you…”, “it’s your job to…” crap. Just a human to human request—firm, direct, but very much considerate. You’ll be well on your way to deflating the baloon of unmet expectations that would’ve blown you both away when (not “if”) it popped.

Teamwork is lesser work

The whole is greater than the sum of its parts—that’s not true. Not universally, at least. Science has known this since the 19th century, that a proper team working together will often deliver less, and of lesser quality, than if the same individuals were working on their own. It’s high time we question the holy grail of “teamwork” to see exactly where it works and where it fails.

I had an eye-opening moment reading Professor Richard Wiseman’s beautifully practical book 59 Seconds: Think a Little, Change a Lot:

In the late 1880s, a French agricultural engineer named Max Ringelmann became obsessed with trying to make workers as efficient as possible. (…) One of Ringelmann’s studies involved asking people to pull on a rope to lift increasingly heavy weights. Perhaps not unreasonably, Ringelmann expected people in groups to work harder than those on their own. But the results revealed the opposite pattern. When working alone, individuals lifted around 185 pounds, but they managed only an average of 140 pounds per person when working as a group. [emphasis mine]

How is that possible? It’s due to diffusion of responsibility:

When people work on their own, their success or failure is entirely the result of their own abilities and hard work. If they do well, the glory is theirs. If they fail, they alone are accountable. However, add other people to the situation, and suddenly everyone stops trying so hard, safe in the knowledge that though individuals will not receive personal praise if the group does well, they can always blame others if it performs badly. [emphasis mine]

Lest you think this applies only to physical work—not at all. It’s the same for blue- and white-collar jobs, physical and creative alike, and across cultures:

Ask people to make as much noise as possible, and they make more on their own than in a group. Ask them to add rows of numbers, and the more people involved, the lower the work rate. Ask them to come up with ideas, and people are more creative away from the crowd. It is a universal phenomenon, emerging in studies conducted around the world, including in America, India, Thailand, and Japan.

Our experience with teamwork

My manager once said in a loose conversation “remember how we were thirty people total? I’ve a feeling we got much more work shipped back then than we do now with 200 people”. Can we test his hypothesis? Can we measure it? Hardly, since to measure correctly would require lots of metrics which we never have nor probably ever will collect.

My personal, best experience with teamwork was in preparing several conferences for Toastmasters in Poland, from the country-scale Toastmasters Leadership Institute to the half-continent scale of the biannual District 95 Conference. All of those teams truly rocked.

  • everyone had their own, individual space of responsibility. I did the website and all of IT—if I blew it, I had myself to blame.
  • we all respected boundaries. I had the final say on the website format and content, but I might’ve merely expressed my opinions on marketing.
  • we worked individually, collaborated on a case by case basis as needed and met every few weeks for two hours total to synchronize.
  • we were all volunteers with no formal ties, so the two or three persons who couldn’t keep pace with the rest were promptly removed and replaced.

Contrast that with the reality of Scrum or any other Agile teams in a typical company—large and small:

  • you’re supposed to share responsibility for the work; all code is everyone’s code.
  • every sprint you’re asked to spend a half-day to a day in meetings, drilling into everyone’s performance (also called a “retrospective”) and collectively brainstorming the work scope (known as “sprint planning”).
  • everyone is on some contract and even in countries were it’s legally easy to fire someone, it’s still psychologically and organizationally taxing.

I did way too many “sprints” like these, and I’ve been in every role: developer, product owner, scrum master, team leader. Every single time people were dying to get out of the meetings and get back to doing productive work on their own. This never worked the way it was supposed to.

Agile is simple, but it’s not easy

The traditional response to “Agile doesn’t work” is usually that, to the contrary, it does, you’re just not “agile enough” or you have diverged from Scrum. That indeed, it’s hard to do agile right and it requires practicing all the great virtues of discipline, courage etc.

Just because some people can finish an IronMan race in 8 hours, that doesn’t mean everyone can, and in fact, very few people will ever be able to complete the distance in any time. It’s a very personal experience, of talent, character and choices, just like work style.

Fair Exam

Why then do we continue to try and swim upstream? Work against human nature?

The solution to fight the western world’s epidemic of obesity is not to ask people to be more disciplined with their diets, but to find out what the natural eating habits of people are and to create food that accounts for them and is healthy. Starting with less sugar and processing would already fix the most outstanding issues.

At work, instead of asking people to “try harder”, study them. Find out what turns them on or off, and change the work environment to account for it. Are they not empathetic enough? Perhaps that’s because we’re not built for empathy in large groups. Try making the organization smaller.

I look back at some thinking I did years ago on teams and realize now I got it only half-right. Yes, teams need to share goals, otherwise there’s no point in calling them “teams”. But “sharing work” is not about collectively executing tasks—that’s counterproductive. It’s about agreeing on outcomes where many individual streams of responsibility come together and yes, we can and should confront anyone who doesn’t deliver their portion.

Too long in one job

“What have you learned from maintaining your own code?” is a pretty decent question to ask candidate programmers. Many people we interview have never staid longer in a job than 2-3 years. That’s enough to build something of size, but often leave without seeing whether it’ll stand the test of time.

I’ve been with my current company for seven years now. It’s enough to let me see how my earlier ideas played out in practice. And boy, have I been wrong at times. Several of the components I wrote are now part of our technical debt and when I do a technical introduction for newcomers, on several items I repeat “that one’s my fault”. What I thought will ease maintenance and development, either doesn’t anymore or never did. It’s been seven years of excellent education, and one that I was being paid for.

There are a lot of good reasons to change employers. Abusive work environments and dead-end, repetitive, I’d-rather-die-boring positions top that list, and if you’re in one of these places, you cannot leave too soon. But my approach was always that once I agree with my employer to a set of conditions, including fair pay, humane work environment and, importantly, lots of space to grow, I become committed to that relationship for as long as these conditions are upheld.

On the other hand, some of my colleagues left, lured by offers “too good to refuse”, presenting massively interesting challenges to tackle. Modern technologies, booming industries, novel approaches. Often sweetened with better pay. I cannot blame them and I cannot say myself what I would’ve done if presented with such an offer.

One can certainly also make the argument, that others’ work is just as good a source of learning, as one’s own. That going to a different place, working with different people will expose one to other, often better approaches. Of course. I’m just afraid of this turning into a cargo-cult spiral, where you acquire new ways of working without taking the time to understand them—why they succeed and where they fail—before moving on to the next big thing.

Instruction vs. Experimentation
From Jessica Hagy’s Indexed

It’s complicated. There’s no good number or even range of years one “should” spend in a single place. Not without considering the context of this time—the company, the people, the work and alternative opportunities. And in a world of abundant opportunities, such as the one we have now in IT, it’s crazy difficult to decide whether and when to make a move.