1 of 25

Random lessons from

A CAREER AS SOFTWARE ENGINEER

React Advanced, 21/10/22

2 of 25

#remain

#leave

3 of 25

About me

Mendix

michel.codes

4 of 25

Dev » Sr » Manager » CxO
Dev » Sr
Dev » Sr » TechLead / Architect

https://nl.wikipedia.org/wiki/Bestand:IKBrunelChains.jpg

5 of 25

PART 1

CODE WILL BE IMPERFECT

6 of 25

7 of 25

Code is perishable

https://en.wikipedia.org/wiki/Hyperloop#/media/File:Hyperloop_all_cutaway.png

https://hackaday.com/wp-content/uploads/2020/07/atmospheric-railway-featured.jpg

The first lesson I needed to learn is that code is a by-product. Some waste in order to achieve a mean.

We all like to take pride in our work. To hone the craft. But sometimes that can get in our way.

Take for example Brunel, he basically invented the processor of the hyper loop. A train that would run on vacuum. It worked, but wasn’t efficiently enough due to the challenges of making a good vacuum system. And after half a year he parted with the idea again.

As programmers we often find it hard to part from code we have written and have put loads of effort in. But in can hold us, or our companies back. Sometimes an imperfect of the shell third party solution is just better from a costs / benefits perspective. We have to learn to be unattached to our code.

As a positive example, a while ago I was asked to look into an existing project, and make sure it got reused across different departments, rather than just the department that initially developed it. So I studied the library, ran some tests and sat with the original authors. And in the end decided that the best thing to do was to rewrite the core of it. To make it faster, and to make the behaviour more semantically correct.

And I was a bit hesitant to propose this, after all these were people not in my team, I was fresh on the project, and about to basically propose to redo a large part of what they had done. So I showed some numbers from my experiments and humbly proposed to rewrite a large part of it. I have definitely worked with programmers in the past that would take offence in that

To my surprise, and to my relief, however, the engineers on this project were totally fine with the changes I proposed, and it resulted in a really fruitful collaboration. But I realised this only was possible because they weren’t too attached to the code they wrote. They rather focused on shipping the best product possible.

https://en.wikipedia.org/wiki/Hyperloop#/media/File:Hyperloop_all_cutaway.png

https://hackaday.com/wp-content/uploads/2020/07/atmospheric-railway-featured.jpg

8 of 25

Code is perishable

Make concessions on solutions, �not relationships
Love code a bit,�and others as yourself

https://www.britannica.com/topic/Christ-the-Redeemer

9 of 25

Testing

Tests are not a separate story
Tests are (effort) x (risk)
Tests will become cheaper as you write more
Expect tests from peers

https://commons.wikimedia.org/wiki/File:Thames_tunnel_shield.png

10 of 25

Debugging

11 of 25

Debugging - log points

12 of 25

Debugging - setter / getter + debugger

13 of 25

Debugging - let it go

https://tenor.com/view/let-it-go-elsa-disney-disney-princess-queen-gif-3597315

14 of 25

WHEN THE CODE IS PERFECT, �ONE HAD TOO MUCH TIME

15 of 25

PART 2�KNOWLEDGE WILL BE INCOMPLETE

16 of 25

Great Western Railway

https://nl.wikipedia.org/wiki/Bestand:IKBrunelChains.jpg

17 of 25

Becoming a tech lead…

Spotting opportunities
Establish a North Star
Measure

https://isleofdogslife.wordpress.com/2014/04/03/the-launch-of-the-ss-great-eastern-1858/

18 of 25

What changes

19 of 25

What changes

Work on problems you don’t and won't fully understand
See an opportunity, have others seize them

20 of 25

Infrastructural projects are a catch-22

“If the technology was mature, �I’d use it.”
“If you’d use it, �the technology would be mature.”
Take the ugly short cuts

https://collection.sciencemuseumgroup.org.uk/objects/co419617/the-great-western-railway-new-terminus-at-paddington-print-engraving

21 of 25

Infrastructural projects are a catch-22

22 of 25

It’s all about the things you don’t do

Problems you don’t solve �(but others you focus on)
Solutions you don’t build �(but OSS library)
Abstractions you don’t build �(but copy paste)

23 of 25

Senior: Code will be imperfect
Tech Lead: Knowledge will be incomplete

24 of 25

–Isambard Kingdom Brunel

“I am opposed to the laying down of rules or conditions to be observed in the construction of bridges lest the progress of improvement tomorrow might be embarrassed or shackled by recording or registering as law the prejudices or errors of today.”

25 of 25

Questions?

https://nl.wikipedia.org/wiki/Bestand:IKBrunelChains.jpg