10 amazing secrets university never taught you about how to become a truly professional software developer

09 Dec 2016 10 amazing secrets university never taught you about how to become a truly professional software developer

Last week I was very lucky to be able to attend the YOW! 2016 Conference in Melbourne. I had never attended a major conference aimed purely at software developers before and when I arrived early on the first day I wasn’t quite sure if I had the right building. Thankfully within 30 seconds of walking in the door I spotted a man wearing a fedora and I knew I had come to the right place!

The conference overall was an extremely well run affair. The speakers were all very good and many were either from high profile companies such as Facebook and Uber or were outright living legends of the industry such as Robert ‘Uncle Bob’ Martin. There were three talks to choose from during each time slot and they covered a wide range of topics. The hardest bit was choosing which talk sounded most interesting and I suffered from severe ‘Fear of Missing Out’ syndrome when making my selections.

I would highly recommend attending to anyone who is looking to gain a better sense of what’s going on in the software industry. Setting aside two whole days to listen to presentations, talk to other developers and generally ruminate about the craft of developing software is a great way to take a step back from the daily grind and spend some time looking at the forest instead of the trees. I picked up a number of things that I’ll be able to take back and directly apply in my day-to-day development.

I’ve summarised one of my favourite talks below:

The Scribe’s Oath – Uncle Bob

Ok, so the title of this blog was clickbait. There are only actually 9 ‘secrets’, and they’re not even really secrets because Uncle Bob told them to all of us at the conference – and I’m going to tell them to you now. However, it is true that you don’t generally learn these things at university, and it’s also true that you need to know and apply them in order to be able to call yourself a professional software developer, the emphasis there being on the word ‘professional’.

Bob’s main thesis is that as software developers, we are like modern day scribes. We have a skill which takes many years to learn and master. It isn’t possessed by the majority of the population and yet it is required in order to be productive in almost every modern day pursuit.

The rest of society is coming to realise just how important we are. The industry has grown exponentially since Alan Turing created the first series of instructions recognisable as a computer program in 1946 until today where there are around 20 million developers worldwide [citation wilfully withheld].  Programmers such as John Romero (co-creator of Doom) can be seen as heroes where as others, such as the creators of the infamous Volkswagen emissions test cheating software, can be seen as villains.

As the influence and pervasiveness of software grows, so does the risk of some catastrophic event being caused by faulty software. Such an event would be terrible, but what would make things worse is if, as a result, rules and regulations were imposed on us by people who don’t actually understand software. Instead, Bob argues, we should start self-regulating now, preferably before some terrible software calamity occurs. We should develop a list of standards and impose them upon ourselves, so that when the time comes, we can show that we are already acting as professionals and don’t require additional regulation. This same approach has worked for other professions, such as the medical profession, and should work for us as well.

As it stands, most of us have incredible freedom to be creative, experiment and build software in the way which we think makes the most sense. We should do everything we can to retain this freedom, whilst also acknowledging the increasing dependency that society has upon the software that we build.

Bob has proposed a list of nine assertions as a starting point. Most of these things you will probably either know already, or consider to be common sense. I personally still found value in being reminded of them, and taking some time to think about them in terms of my current team and project.

1. I will not produce harmful code
2. The code I produce will always be my best work and I will not knowingly release code that is defective in behaviour or structure
3. I will provide, with each release, a quick and repeatable sure proof that every element of the code works as expected
4. I will make frequent small releases that do not impede progress
5. I will fearlessly and relentlessly improve the code at every opportunity, and will not make it worse
6. I will keep productivity high and will do nothing to decrease productivity
7. I will continuously ensure that others can cover for me and I can cover for them
8. I will produce estimates that are honest in both magnitude and precision and I will not knowingly make promises that I can not meet
9. I will never stop learning and improving my craft

I think this is a great starting point and it’s really quite hard to disagree with any of them. To make you feel a bit better, I will freely admit that I have broken almost every one of these principles at some point in my career and I’m sure you have too (yes, even the ‘harmful code’ one, if you include the code I wrote and installed on a friend’s computer during university to randomly open the CD drive every time he typed ‘ls’ #programmerhumour).

Having said that I would like to think that, now that I’ve learned most of these lessons the hard way, I never knowingly break them. Furthermore, if I do realise I have transgressed, then I attempt to correct as quickly as possible. See rule number 9.

I should note that if Bob is coming to give this talk at a place near you and you have the opportunity to go, then it will still absolutely be worth your while to go along and hear him in person. He’s an entertaining speaker and explores each of these principles and what it means in a lot more detail.

After his talk I was able to meet him and he was kind enough to sign my copy of Clean Code. He struck me as a very down to earth and humble person. This is now the nerdiest thing I own.

 Other titbits and summary

Aside from Bob’s talk, there were a number of others which I thoroughly enjoyed, covering all of the expected topics: containers, microservices, data science, Bitcoin, typed JavaScript, security, agile practices, evolutionary architecture and more.

Of particular note was Dr. Brian Little’s ‘Personalities at Work’ talk. Dr. Little is non-technical but is an internationally acclaimed scholar and speaker in the field of personality and motivational psychology. He’s also done a TED Talk. He was an incredibly entertaining speaker and he had the entire audience laughing regular intervals.

He briefly explained the Big 5 personality traits and then zoomed in on the one that it is often assumed to be totally lacking by anyone in our industry: extroversion. He explained the mechanics of extroversion and what it means for introverts and extroverts trying to work together. Part of being a good software developer is being able to contribute towards a healthy team culture, in which every member of the team is able to bring their best. In order to do that, it helps immensely to be able to understand your team mates!

Overall YOW! was a thoroughly worthwhile experience and I’m looking forward to YOW! 2017 already!