Tue, Jul 2, 2019
Read in 24 minutes
This is a blog post containing my summary of all the talks and recordings from the Lead Developer conference held in London in 2019.
I recently attended the Lead Developer conference in rainy London. Despite the weather, the conference was great — well organised, inclusive, brilliant people, interesting and professional presentations, and a grand venue (Barbican). In this blog I will present my summary of all the conference talks. But firstly, well done to Meri Williams (organiser and host) and White October Events for orchestrating such an outstanding conference! You can follow The Lead Developer on twitter to keep up to date with other events that might be taking place near you. The highlights video can be found here.
Processing all the content from 2 days worth of talks can be a bit overwhelming. Therefore, I decided to write this summary not only for personal use but also for anyone else who may find it useful or who simply wants a quick reference to some of the content for the conference.
This summary consists of all 2 days and 27 talks, numbered accordingly. For each talk I structure the content as follows:
Before I start, I just want to say thanks to my company Simplesurance for providing me with the opportunity to attend this event — especially since I required a visa to get there! We are hiring in Berlin so check out our open positions and in particular, I am currently looking for a frontend engineer for my team.
Lara’s talk set the stage for other speakers to come. The quality of the talk was very high and the topic was one which many could relate to. 4 out of the Tuckman’s 5 stages of team development formed the basis of the talk, namely: forming, storming, norming, and performing. During the storming phase, fear or doubt can lead Amygdala hijacking where the brain tells the prefrontal cortex to go on standby, leading to lack of concentration and focus in the team and tasks at hand.
Lara discusses how to take care of your team during this stage by identifying the level that each person in the team requires for their 6 basic needs (BICEPS) to be met. The 6 basic needs (BICEPS) are:
Providing feedback is also discussed and Lara presents a feedback equation which entails:
**Books: **None — but Asim is thinking of writing one ;)
José’s presentation was about how we can achieve high performance when teams and goals are constantly changing. He presented 5 engagement points to achieve this, namely:
Last year when he attended the Lead Developer conference he set a goal to present at this year’s one, which he did by using the techniques he spoke about in his talk — well done!
OKRs (Objectives and Key Results) is a framework for defining and tracking objectives and their outcomes. Whitney got the audience’s attention with her talk on OKRs. This was because she was promoting it even though in recent times OKRs have received a bad reputation. Whitney provides 3 bold tips to follow when starting with OKRs, namely:
Overall, Whitney promotes a bottom-up approach with OKRs since this leads to innovation.
What I liked about Ronald’s talk is that he provided a lot of scientific evidence to back up his question: What does it mean to build AI software? This is because AI, by definition, is a science. A lot of companies say “we want AI”, but what does it really mean? Ronald explains that it’s about building software which delegates decision-making to machines.
The talk is scoped around the context of data-driven AI vs model-driven AI, which you can read more about here — data-driven AI discovers the model based on data collected whereas model-driven AI attempts to capture knowledge through explicit representation and rules.
Ronald spoke about the components of a SMART framework, namely:
Using agent-based theory, Ronald discusses the different types of agents:
According to Ronal, we should stop asking the questions “Is this software real AI?” because it’s impossible to answer. I highly recommend watching this talk if you want to, plan on building, or being involved in any AI software development.
“People come first” — this is the main point of Rebecca’s talk and is a key prerequisite for enabling teams to self-organise. Rebecca provides a couple of tips for managers to help achieve self-organising teams, namely:
Self-organising teams are great and can provide a lot of drive and innovation.
Heidi’s talk highlighted that if you make it rewarding to do the right thing, people will do the right thing more often. She compared this to training dogs :) As simple as it might sound, there is a lot behind this. The following suggestions were made, to change the behaviour of someone:
Understanding what motivates someone requires understanding what makes someone feel rewarded. This can be different for every person. What makes you feel rewarded?
Angie spoke about the challenges of testing AI software and highlighted the importance of testing AI software. Testing scenarios where machine learning determines some outcome (e.g. Clothing likes and dislikes, Netflix recommendations, and ad recommendations) is challenging because there is no exact predictable outcome to test against. Nevertheless, as machines make more decisions for us, it becomes even more important that this software is tested.
Angie concludes that there is a need for thoughtful and critical tests and the future is here and we should test it!
Steve is a member of The Royal National Lifeboat Institution (RNLI). In his talk, he compared several similarities between building a team for a critical mission at the RNLI to building any other team that needs to respond to critical situations.
The main point is to extend the training to run exercises which simulate real word critical situations. This helps foster a team where each person knows they can rely on the other team members, especially when in a critical situation. Doing this can build teams that have:
Check out Dave Snowden’s Cynefin Framework for more details of this. In summary, Steve says that we should all build “crews”.
Melinda compared developing developers to video game design. She shared 10 lessons with us:
To sum it all up, as managers, developers are our users so we need to provide good user experience, according to Melinda.
Most of us what to have diverse teams, especially since it can help foster creativity and innovation. If you don’t believe that, have a look at all the academic papers on this topic. However, according to Bethan, managers like to hire people like them. Therefore, management needs to be diverse if you want to have diverse teams.
Bethan provides some tips on how to adjust your interview process to attract a more diverse range of applicants:
Brian spoke about how they set up virtual teams of volunteers to handle on-call situations. Some of the suggestions were:
Most importantly, humans > computers — look after them.
This was a first-time talk for Kate and I must say, she did a really good job — sounded like a seasoned pro! The main topic of the talk was about how to help developers develop quicker by providing time at work for developers to do “non-work-related” software development. In Kate’s case, this was 10% and the time could be used so that developers can develop themselves and learn in a way that works best for them. For some, this could be side-projects, open source projects, preparing for meetups or talks, or simply doing courses.
However, getting this approved in a company or getting it started requires some action:
Providing the opportunity for developers to grow has positive outcomes for developers such as intrinsic motivation, autonomy, and satisfaction. Think about how you could do this at your company.
Apparently, Nickolas has told great stories at previous conferences and this was no exception. Nickolas told us the story of the Eiffel Tower and how Gustav Eiffel navigated the political scene in France at the time to be awarded the project to build this famous landmark. I won’t go into the story — you can read about that here (it’s a Wikipedia link) or watch Nickolas’ recording.
Apart from Nicholas’ telling of the story, what I liked is how he applied the lessons learned from Gustav Eiffel’s political dealings to the working environment we find ourselves in. Every organisation is political and we should not be afraid of taking part in these politics because it could lead to something great. One way is to change your perception of certain “politically orientated” words, such as:
I highly recommend watching this talk for its entertainment but also its educational value.
Pat kicked off day two with a talk about different technical leadership flavours. Every leader has their own style and you need to invest in finding your own flavour. The talk was divided into 3 main sections, namely:
What is technical leadership?
Where do people demonstrate technical leadership?
How do people demonstrate technical leadership?
What is your technical leadership flavour?
As a side note to the conenctor leadership flavour: this reminded me of some social network analysis centrality measures which are used to identify influential people in a network graph. One of the most interesting ones is the betweeness centrality which identifies the amount of influence a person (node) has over the flow of information in a graph. This could be useful to identify the right people to connect with or to connect others with, which is useful for the connector leader. I wrote my masters thesis on along the lines of social network analysis, relating to a trust model and here are some articles of mine if you want to go down that rabbit hole.
Dora filled in for one of the speakers who couldn’t make it. Her talk was about inclusion and here are a couple of the points she mentioned about improving inclusion:
This is an important talk for those interested in improving inclusion at their company.
This was Jonathan’s first tech talk and he did a good job telling us how to deal with BAU (Business As Usual) tasks, which are tasks that are required to keep everything running as usual (e.g. maintenance tasks). He defined 3 actions to help with BAU:
Jonathan also recommended hiring a “tech support engineer”. This is someone who would basically automate themselves out of this position and transition into a new role. For example, this could be a good opportunity for a beginner and it would help unblock the team.
Ola gave a great talk on how the hiring process can be adapted to make it more effective and inclusive. Here are some points which she made:
I’m sure some of these points could be useful or at least worth trying out in your hiring process.
Miriam gave a talk on the state of mobile development in 2019. This topic was of interest to me, having done development in this area in recent years. The main question was: is it better to do native development or cross-platform development of mobile applications. As always, the answer was “it depends”.
Native mobile development involves the development of Android apps using Java or Kotlin and iOS apps using Objective-C or Swift. The is little to no code sharing between these apps but they are often considered to be more performant.
Cross-Platform mobile development involves the development of both Android and iOS apps with a single framework. This allows one, for the most part, to have a single implementation of the app which is then compiled for iOS and Android. These are not hybrid apps, which are normally web apps running in the web view component of a native Android or iOS app. In contrast, cross-platform apps render to native app components and the main thing that differentiates them is where this rendering takes place.
Several cross-platform frameworks are:
So, it depends on the feature. Understanding the feature will help you select the best approach, which could even be a combination of native and cross-platform development.
My personal experience is with React Native and at Simplesurance, using ReactJS and React Native we were able to share a lot of code between 3 platforms, namely web, iOS, and Android for our digital insurance broker app in Germany called Schutzklick-Makler. How we achieved that is explained in my react-shared boilerplate project. (Sorry for hijacking this summary — I couldn’t resist :D)
P.S. Miriam made brilliant summary notes of talks in real-time which have been very helpful for me while writing this blog. You can check them out on her twitter feed. Thanks a lot for that Miriam!
Franklin gave a good talk about how to create a security culture in the team. He specifically focused on infrastructure teams but agrees that security is everyone’s job. Here are some notes about how to go about building a security culture:
I managed to get my hands on the security edition of the Increment magazine which Franklin brought with from his company — Stripe. I recommend checking it out.
“RSA encrypted traffic is safe now but NOT in the future!”. This is the outcome of James’ talk and a scary but realistic one it is. James talked about the progress being made in quantum computing and how it can be used together with Shor’s algorithm to crack public key cryptography (e.g. RSA).
I will avoid all the details here but basically, on a large enough quantum computer, Shor’s algorithm can run in polynomial time to find an integer’s prime factors. Prime factorization is the fundamental idea of RSA encryption which therefore implies that it can be cracked by Shor’s algorithm. The key constraint at the moment is that you need a quantum computer with a sufficient number of qubits that could operate without succumbing to quantum noise and other quantum-decoherence phenomena [wiki-reference]. Check out Jame’s recording for more information about this.
Julia talked about her experience in navigating the world of frontend frameworks and compared this to Neopians — those who play Neopets. I had no idea what Neopets are and it seems like this was after my time (feeling old) but I got the sense that quite a few people in the audience could relate. I don’t want to go into detail about Neopets here but in short, it’s a platform where you can look after a neopet and buy almost anything for them in a virtual world.
Selecting a frontend framework can be daunting but Julia provides some points on how to achieve this:
Here is a list of frontend criteria used by Julia:
Given the situation, it’s not always easy to assign a person to each framework to try and identify which one to use but nevertheless, the criteria and tips provided by Julia can be very helpful in the process of identifying which framework to use in your own projects.
This was Jonathan’s first talk and he wrote about his experience here if you are interested — well done btw! In this talk, he discussed the complex topic of providing software estimations. Ideally, he’d push for #NoEstimates but this is not really possible as estimates are at least required to some extent, to ensure realistic planning for software projects. Instead, Jonathan mentions that trust is important in giving estimations are here are 5 points that can facilitate trust:
Check out the recording of his talk for more details. One last important point to keep in mind — estimates are very important because they can impact peoples lives. Wrong estimations can lead to people working extra hard to achieve something which of course comes at the sacrifice of something else in their lives. Have respect for the time and well-being of others.
Paula has a largely remote based team and during this talk, she discussed approaches which she took to try and include everyone and improve communication and collaboration among the team. It was triggered by a company-wide survey which indicated that her team did not feel well-aligned. To try and change this, Paula tried a couple of approaches, namely:
For the most part, these approaches worked. However, there are a few were a few things which didn’t work:
In summary, Paula encourages regular team health checks to identify the health of the team even if things seem fine — silence is not golden, it’s deadly.
Joanna gave us some insight into the state of health care equipment and even in the leading hospitals, the equipment is still not as advanced as it should be. In her project at Google Deep Mind Health Stream, she had to scale up the team as the project grew and there are several lessons learned from that experience:
These are valuable tips for handling the rapid growth of the team and her talk is well worth watching.
Neha gave a great talk on facilitation techniques. Having attended several workshops I noticed that I have seen a lot of these techniques in action and this talk provided a good summary for anyone who has to facilitate a workshop. On a high-level, here are some of Neha’s techniques for facilitation:
There were just too many good points to mention them all here so check out her recording if you want to find out about all the techniques in detail.
Sal and Clare lit up the stage for the final talk of the conference. They spoke about how they developed a time-machine for a 25-hour hackathon and won! The best part is that they were the team that focused the most on their well-being during the hackathon compared to others. They took time off to sleep, eat well, and stretch regularly and in the end proved that it’s not required to sacrifice your well-being to achieve great work — actually it’s encouraged not to. This might seem obvious but a lot of us don’t put enough emphasis on our well-being and overwork in order to achieve goals — either set by us or our employer.
Sal and Clare went on to motivate how important sleep is and how we are all different in this regard. To support this difference, companies should find a balance of providing flexible working hours but also create a highly structured environment to facilitate collaboration. Check out the recording for more info about Neurodiversity and the Spoon theory.
That sums up my summary! As you can see, there is a lot of content and I hope that you found something useful among all of it. All the speakers did a great job to prepare thoroughly for their talks and a lot of knowledge was shared — thanks to them!
Here are some other blogs about this conference which I came across, that might be of interest:
If you have any comments or corrections for the things which I have posted please feel free to leave them in the comments or contact me directly on Twitter.