Day #2 of Codemotion Amsterdam 2019

I recently visited the Codemotion conference in Amsterdam. In this post I'll share some noteworthy ideas I heard on day two and my thoughts on them.

Day #2 of Codemotion Amsterdam 2019

On my second day at the Codemotion conference there were also plenty of noteworthy and interesting things. These included:

You can take a look here at the first day of Codemotion, in case you missed it.

What we learned from 20.000 attacks bypassing defenses in 2018: secure coding is not the issue

Eward Driehuis works for SecureLink. Their company has experience with and statistics about a lot of attacks that happen. The key point of his talk was that secure coding of applications, is important, but it isn't the most important thing right now. Most successful attacks don't target the application level, instead they target the "system" level. Examples of this that Eward gave are:

  • Social engineering
  • Configuration errors, especially often on websites or CMSs
  • Not spending enough budget on security
  • Supply chain attacks, where another company in your supply chain is breached and you are too tightly integrated with them, so you're also attacked.
  • Unpatched operating systems, such as those vulnerable to Wannacry

Eward also told us that more and more attacks are more long term. Attackers get into some of your systems and then analyse the data they find. For example, when they find the company's financial data they use it to determine the amount they can extort the company for after encrypting all their data at a later time. The attackers also make more use of cloud computing to analyse and determine the best attacks per target.

All in all it was an interesting presentation. The most important note, which probably is a sales pitch... There are two kinds of system intrusions, those that have been detected and those that have gone unnoticed. Don't assume that the latter means you've not been breached.

Chinese food, motor scooters, and open source development

What's the relationship between (American) Chinese food, motor scooters and open source development? In this awesome talk Don Goodman-Wilson of GitHub told us that there is something wrong with the way forking open source repositories is oftentimes seen as a bad thing by the original creators. It's probably due to our more individual western view on things that we try to protect our inventions and don't like other people creating slightly different variations using our designs. But, creating these slight differences can help in providing the best possible product for local markets and niche areas.

Don showed us that the way Chinese food spread and got popular in the United States was a process of sharing the recipes that best catered to the tastes of Americans between Chinese restaurants. This then benefited the Chinese restaurant industry as a whole. It is in fact a process that still continues today through Chinese association organisations in the US. Where these organisations even help Chinese immigrating into the US by telling them where good places to start a Chinese restaurant can be found.

The GY6 motor scooter engine was another example that was perhaps even closer to forking. The GY6 is a single-cylinder four-stroke engine which is mostly manufactured in China and South East Asia of which many variations have been created. All of these variations are like forks of the original design (the source of which isn't really known). It is cheap and reliable.

The final question Don asked us was how we can improve the acceptance of forking on GitHub and other platforms as being a great thing, not something that harms our egos? He doesn't yet know the answer, but invites people to contact him if they have suggestions.

Using Many Worlds of Compute Power with Quantum

Ahhhh. Quantum computing. James Birnie of ThoughtWorks gave a very interesting talk. But, the reality is that it is still a very difficult topic. Qubits have any state until you observe them, then they are either 0 or 1. I like how IBM Q's quantum computer can be used online and that the example given during the presentation is that of Schrodinger's cat, which is exactly what Qubits are. Having recently read Stephen Hawking's A Brief History of Time there were some things I could understand a bit better... Luckily, we all still seem to have plenty of time to learn more about it!

Very recently there was a meetup in The Netherlands where Jelmer Boter of the TU Delft gave a presentation on how qubits work. Sadly, the presentation is only available in Dutch...

Should the CTO be Coding?

The short answer of course is that it depends... Joshua Hoffman has been the CTO in numerous companies, mostly at a startup to small company size. According to Joshua, stuff a typical startup CTO should do is:

  • Recruiting
  • Coaching and Mentoring
  • Help define career paths
  • Help define team structure
  • Influence the engineering culture
  • Maintain a vision of the future

I'll highlight the one on helping to define career paths.

In general lots of companies don't provide enough ways to grow in a technical role. Especially in The Netherlands, where compared to e.g. Germany craftsmanship is valued far less, going into a management role is often the only way to really further your career. When Joshua worked at Red Hat, going into management was seen as "taking the lobotomy". Something that one would only do if somehow the brain wasn't right.

To counter this need for going into management. Joshua had a few slides in which he defined "engineer levels". The moment a software developer did the things on those levels in a successful way, they'd be promoted to that level. The goals in these engineering levels would go from being able to work on a problem alone to things like public speaking at conferences. Of course, what set of levels would fit your company would be different from another company. Which is why it's an important aspect the CTO should take a look at.

As for the CTO coding thing... Sure, if the items listed above are set up nicely, then sometimes the CTO will find time to code and should code. Maintaining a technical vision of the future will become hard otherwise. But, the CTO shouldn't forget that his main role is that of CTO. So if e.g. recruitment is going less great than before, then they should step in and work on it!

The slides are available here.