April 2nd and 3rd I spent (at the Microsoft booth) at Codemotion Amsterdam. Codemotion is a (very) large tech conference, covering a range of topics, and I believe they welcomedover 1200 visitors.
Friendly co-workers came by to help me out at the booth, and I could attend some of the sessions. I tried summarizing those below.
Day 0 — the mood
Coolblue: From 100 to 1000+ deployments a day
Pat Hermens is the Development Manager at Coolblue. Coolblue is a Dutch company, with a large internal development department. Coolblue is seeing some 1000+ deployments a day, and Pat guided the audience through what enables them to move so quickly, the tools they use, and most importantly, the mindset required to enable development teams to deliver at rapid pace.
Pat Hermens, Development Manager at Coolblue
Why 1000+ deployments a day even? With 1.13b revenue in 2018 (and 14% growth year over year), and development teams doubling with each year (they’re at 18 teams now) the question of “will it scale” is beyond legit.
Apparently we are too much trained to disregard differences in scale, to treat them as “gradual differences that are not essential.” We tell ourselves that what we can do once, we can also do twice and by induction, we fool ourselves into believing that we can do it as many times as needed, but this is just not true.
In a talk titled “Faster to master” from a few years back, was an exploration of DevOps practices being put in place at Coolblue. Pat collected the buillding blocks for a good DevOps practice in a “Faster to master” checklist:
“Faster to master” checklist
Over time Coolblue ticked off ever more checkboxes, and defined the 4 prerequisites for their dev teams to do their best work:
+ Responsibility
+ Autonomy
+ Ownership
+ Failure (addressing it as it is, a learning opportunity)
Responsibility
The Hosting & Deploment (DevOps) team used to be the core blocker for delivery. As the number of software teams grew exponentially, so did the informal networks between teams, exchanging strategies on how to circumvent DevOps.
By enabling the teams to take responsibility for Ops themselves — and by using linters, and an automated CI/CD process — Hosting & Deployment are now a team just like any other, and no longer bottleneck.
Autonomy
Coolblue has a lot of services, all called Vanessa (something). While services that have been broken apart from the delphi monolith aptly named Vanessa Optima Prime are more fit to use applications like Splunk, Datadog and thus logging, and alerts, Prime took the company to where they are today.
One team got the honour and the priviledge to make Prime integrate with modern tooling. While they certainly weren’t succesful at the first try, they had the unequivocal freedom to try solutions as they saw fit.
Ownership
At Coolblue they take ownership very seriously. Like a contract, it is well documented who owns what, and the team that owns a topic is free in the tools they want to use. Pat confesses he doesn’t know whether or not Coolblue “does” Kubernetes, or Serverless, because it doesn’t matter.
Failure
Coolblue is serious about error reporting. When a campaign (buy a coffee machine, get a milk frother for free) f-ed up the provisioned space planning for their bike couriers, Coolblue knew about it in the instance it happened.
Fail early, fail often, but always fail forward.
In a RFO (Reason for Outage), the people responsible are to explain why instances are terminated. In RFO meetings that take place once a month the teams discuss how to mitigate issues moving forward.
And because we all like a good checklist, Pat shared the one for the “100 to 1.000” journey:
The “100 to 1.000” checklist
Diversity in tech panel: understanding what WE can do every day
Diversity in tech: what’s actually being done to make the community more inclusive? We all agree that education, careers, and opportunities in technology should not be limited to any one demographic or sector. At the same time, there are underrepresented groups who are struggling to break into the field.
MC-ing the panel is Eliza Camber, Android Developer at Pixplixity, and GDE (Google Developer Expert). She’s an organizer for the GDG (Google Developer Group) NL and the lead for the WomenTechmakers program in NL. Joining Eliza, Qa’id Jacobs is a UX Strategist at Constellation Design. Born and raised in New York and New Jersey (USA), Qa’id moved to Amsterdam in 2013. He has worked with both large, global corporates and small, bootstrapped startups. Using an empathetic design approach, he takes on challenges of class, locale, and context. Lian Li is a Software Engineer at Container Solutions. She recently co-organized Serverless Days Amsterdam. And Jean Volski is the Global Support Product Lead Developer Tools at Atlassian, with over 15 years experience managing support and services teams across diverse cultures and technical expertise.
Eliza asked if harmful product decisions could be omitted by creating diverse teams. To which Qa’id said that you never know what a product will do “until the thing is out there” and that making assumptions is hard.
Jean: “When you bring people from different walks of life together, the conflict it naturally brings is very healthy. It forces everyone to challenge ideas and assumptions, which pushes the collective forward. But it’s not a silver bullet, if a leader doesn’t know how to manage a multicultural team, that could actually harm productivity.” You can’t just put diverse people in a room and expect it to benefit the bottom line.
Lian started her career in gaming, which made for a rocky start especially. “At first I tried to be one of the boys, I’d overcompensate in the sexist jokes and devaluing other women.” After therapy, she realized that she hated everything about being a woman in this society. “White men get to represent everyone, but as a woman or person of color you represent whatever box you’re put in, and your actions are put under a magnifying glass.”
Qa’id: “We need more and more diverse role models, so that we can mix and match and take away what inspire us.
Lian on how we need to start (with the) young: “Children are so impressionable, and we can’t expect venture capitalists to do right by our kids. Instead we need to educate the parents so they can support their children’s curiosity.” Qa’id: “All of our actions teach our kids about gender, race, and class. We need to be very conscious about what those lessons are going to be.”
Qa’id on promoting women: “I like to use the metaphor of someone going to the hospital and their leg is broken. The medical staff will care for their leg and no-one will ask them why they’re being so leg-centric. That’s where the problem is, and that’s what needs to be cured.” I loved how Lian brought up that with the prominence AI is gaining we need to have the conversation about diversity and inclusion now.
Obviously I didn’t make it to Douglas Crockford’s keynote…
Breaking into DevRel
Thiago de Faria from LINKIT led a panel on Developer Relations with Don Goodman-Wilson from GitHub, K Rain Leander from Red Hat, Jason Yee from Datadog and yours truly (from Microsoft).
Where our roles differ on certain aspects — like what department we report to, if at all — we share many definitions and values. Like how we are an advocate for our product’s and solutions’ users, more so than for our employers. And how integrity and authenticity are paramount. Neither of us would push an unethical product, because no compensation is worth sacrifing our careers over.
To effectively communicate with your company (or a prospective employer) about what the Developer Relations role entails, we unanimously recommended Mary Thengvall’s ‘The Business Value of Developer Relations: How and Why Technical Communities Are Key To Your Success’.
From left to right: Thiago, Rain, Don, Jason and me
Chinese food, motor scooters, and open source development
Don Goodman-Wilson is Developer Advocate at GitHub, and a philosopher-engineer who has previously worked with/in web security, chatbots, streaming media, embedded hardware, the model railroading industry, and academic philosophy.
There are *some* problematic figures within OSS
Don says OSS is sick, and compromised NPM packages are just a symptom. We strongly identify projects with their maintainers, which is problematic when more often than not these people — overwhelmingly white hetero cis men — are problematic. Case in point: Linus Torvalds. Don suggests we move away from the tight coupling of projects and their maintainers, adopt the Chinese restaurants’ model and share excess demand. Say what?
Forking is considered a bad thing for power conflicts reasons. But that’s really mainly a culture thing. The opportunity to make copies freely and do with those whatever we please doesn’t play well with our instinct to keep the keys to success to ourselves.
There’s roughly 4 ways the fork goes:
1. The death of the fork
2. Fork merges with the original (egcs)
3. The death of the original (x.org)
4. Two competing projects (libc/glibc)
Chinese food exploded across America in the early 20th century, rapidly adapting to local tastes while also spreading like wildfire. How was it able to spread so fast? A distributed open source-like development model, that’s how.
Whenever in the US you go to a Chinese restaurant, you’ll get the same exact experience. The north star of Mc Donalds (13.677 locations in the US), is what 41.000 Chinese restaurants achieve with no central coordination. It’s the most successful restaurant model in the world.
When Nixon went to China in 1965 and ate Chinese food on television, that sparked a huge interest, causing these entrepreneurs to look to alter dishes to appeal to this curious audience, and use locally available ingredients.
In our culture we have the urge to attribute success to one originator. Instead migration associations in the US that help Chinese immigrants land a job, know where there is demand for a new Chinese restaurants, or chefs. Via these networks restaurant owners share dishes that work with their audience, reducing risk because it’s in their benefit when Americans have a favorable attitude towards foreign food. A powerful open source at work.
The benefits of decentralization:
1.Removal of ego
2. Democratized access to contribution
3. Increased diversity of experience and opinion
4. Better localized product-market fit
Copies are cheap, says Don. We know this from open source software. Share excess demand, and decentralize production, to reduce risk and benefit as a community.
Ethical questions in software engineering
“Software is eating the world. We, developers and architects, are a major force influencing software, technology, and the world it creates. We don’t have the privilege of being unaware of our actions.” Rotem Hermon is a Lead Architect for Customer Data Cloud at SAP, and asks us whether we’re ok with relying on privately developed and owned software systems deciding who gets a loan, or who’s killed in favour of sparing another person’s life in case an autonomous car needs to make a split-second decision.
“Technology is not a get out of jail card.” Facebook , Uber and Airbnb can label themselves as technology companies but that doesn’t exempt them from taking responsibility for the industries they disrupt.
Rotem encourages us to “keep asking questions” and “not take things for granted”. “There’s a scarcity of IT talent, which means we can influence how our companies move forward.” One thing we should not be doing is simply using more software to fix technology.
That’s us at the booth!
