How to be a better Software Developer - Five Insights

I attended the Voxxed Days Zurich 2017 Developer conference and it was a refreshing change of scenery. There were more than 400 attendees, and 36 globally known speakers.

Out of all the impressions from the conference there were five insights which really stuck, and I'd like to share them with you. They mostly originate from Martin Thompson in his very entertaining keynote:

1. Why are we so bad at estimating time to completion for software?

Martin Thompson referenced data collected in the 60's and 70's during the creation of the first FORTRAN compilers and noted that, as the team went on to their third iteration, their estimate got better and better. The first one was off by a factor of two, the third one by 15%.

In other words, the more you do a certain task, the better you get at estimating the time it will take to do it. Martin then made my brain go 'ping' when he said.

'The reason we get it wrong so often is that, most of the time, we're doing something for the first time'.

That was so refreshing. I thought 'Yes, but I've never really admitted it to myself'

Chart from the 1960's showing the delta between estimation and reality for three generations of FORTRAN compilers. The lessons still hold fifty years later.

2. What should we learn?

I was expecting something like 'SpringBoot 4.2' or something of the likes, but Martin went on to mention the basics which are valuable to learn in Computer Science, whatever the technology used:

• Algorithms & Data Structures
• Design Fundamentals
• Programming Paradigms
• Decomposition & Abstraction
• Mathematics

3. What could go wrong? The question you should always ask yourself whilst coding.

Martin Thompson also lauded Margaret Hamilton, the extraordinary programmer who coded the Apollo landing computers. She constantly challenged her colleagues with the question 'what could go wrong'

I must confess that I often concentrate on the happy path and 'things going wrong' is sometimes a last-minute realisation. Constantly thinking 'what could go wrong' and devising error handling processes right from the start helps you make stable code. It's so much more of a hassle when adding this as an afterthought, especially in cases where you are taking many sequential actions that depend on the previous action.

4. Your short-term memory is the worst enemy of code readability

This was a surprising insight. Your short-term memory contains all sorts of mapping information which is not immediately obvious. Think proper variable naming. Even if we have made a bad naming choice for a variable, say, we don't notice it because the mapping between the variable and what it contains is still fresh in your short-term memory.

The solution:

have a look at the code you wrote yesterday and see if you still understand it.

Most often, you'll notice some areas that are not obvious, but were obvious yesterday. This applies, incidentally, also to e-mails. In fact it's such an universal finding that there's a german expression 'eine Nacht drüber schlafen' - first sleep a night before continuing - which enjoins you to do exactly the same. It never occurred to me that what is actually happening is that your short-term memory gets purged, and you can see your text, or your code, with an 'empty' short-term memory, and such see it a lot more like other people will.

5. Functional Programming is coming and you should learn it sooner than later

One of the recurring themes during the conference was functional programming. In the past functional programming was relocated to esoteric, high-brow corners of IT but it's becoming more and more ubiquitous. A form of functional programming has been introduced into Java 8 and, of course, Javascript is a functional language - one of the really wonderful parts of the language. I always regret that those cool bits are sometimes completely hidden over by frameworks who try and reinvent Javascript as some sort of object-oriented class-driven stuff, which, you know, it isn't.

Start learning functional programming concepts

I can recommend LISP or Scheme as a way to break you teeth on functional programming. It's very strange at first because in LISP, the most natural ways to write things is with recursive functions, and there are surprisingly elegant ways to solve problems that way.

JavaSlang as a helper library for functional Programming.

From what I understood from Grzegorz Piwowarek, JavaSlang helps you by providing collections better suited for functional programming.

Gang of Four Design Patterns become trivial with functional programming

One of the most intellectually challenging premises, masterfully live-coded(!) by Mario Fusco, was that

most Design Patterns laid out by the Gang of Four, in particular the behavioural ones, are in fact workarounds for the missing abstraction of higher order functions.

Everything became trivial in his hands. 

Mario Fusco live-coding lambdas and obliterating the Gang of Four's Design Patterns.

Many thanks to the organisers of Voxxed Days Zürich!

You can get more insights into this conference by following their Twitter account @VoxxedZurich and follow the event hashtag #vdz17.

Have you made the jump to functional programming? How do you make exact software estimations? Please share below in the comments!

I am Andrew Magerman, a senior software developer with a passion for software quality. Have a look at my website www.magerman.com and contact me if you need support or have a question!

#NeverStopLearning #SoftwareDevelopment #Zurich #VoxxedZurich