I was honored when Dave Rael invited me onto his Developer On Fire show.

This show has interviewed so many of the world’s most amazing developers: Robert Martin, Scott Allen, Chad Fowler, Scott Hanselman just to mention a few of the recent examples, it’s a real privilege for me to have my name appearing anywhere on that list.

Please listen to it here:

Episode 128 – Kevin O’Shaughnessy – Dedicated to Learning

Another such show guest, Troy Hunt, wrote an article that I found a lot of value in recently on speaker anti-patterns. I found the introductory section especially revealing:

I realised that many of the talks demonstrated common speaking anti-patterns that I see all over the world in different talks. What’s more, at one time or another I have demonstrated every single one of them myself in my own talks. I know this because I watch them all again (at least once) and tear them apart.

Practice makes perfect, but only if we are honest with ourselves and continually look for areas of improvement.

So with this in mind I am presented a self-critique of my first podcast show along with additional and extended explanations. This is one of my longer articles, but if you are interesting in hearing about experiences and advice, why not multi-task by reading this at the same time? Even if you don’t want to listen to the podcast, I believe it will be well worth your time.

2 mins: Kevin the person:

Absurdly, the very simple “tell us about yourself” question was by FAR the hardest one for me, hence my almost non-answer to this. I was pretty honest, but if I was off-air, my most natural reaction would be to ask “what would you like to know?”. In the My Life For The Code podcast, I spoke about my job here, which I think was a little bit better.

3 mins: GPS and mobile:

When I was interviewing for my current job, I was a little worried that low price apps for GPS enabled mobile phones would disrupt the market for GPS devices installed in vehicles. I since learned that customers want to track their vehicles, not their driver’s phones. There is no way to tell which vehicle, if any, a mobile phone is in, so the only professional solution is to install a GPS device in the vehicle.

However mobile devices are very important for web browsing, and customer deserve a great browsing experience on their phones as well as their tablets, laptops and desktops.

4 min: Outlier Developer and Simple Programmer

Nothing to add to my answer except go check out those sites sometime.

Something that was edited out of the podcast (as it wasn’t a question, or at least not something I replied to) was Dave Rael saying that I was associated with Cory House. I take that as a big compliment because he has very high standards in quality and has consistently delivered high quality work since I first heard of him almost two and a half years ago.

Cory has achieved much more in his career than I have, but we are both fans of people like Robert Martin, Rob Conery, Steve McConnell and Jeff Atwood, we rarely waste time on things like watching the news, and appreciate that being a professional developer involves a whole lot more than just writing good code. I do feel that working with him has helped me to improve as a blogger – I still have some way to go, but I feel like I am making progress each year.

I found another interesting developer Cory today: Cory “Scalable” Nelson, from Chicago. If you are interested in coding at a fairly low level, he has some good stuff over at int64.org

5 mins: Pluralsight:

Pluralsight has helped me in my career and it can help you in your career too.

Here are links to my learning path reviews:

Security Learning Paths
C# Deep Dive Learning Path
JavaScript
HTML5
Programming in HTML5 with JavaScript and CSS (Microsoft Exam 70-480)
C# End to End
CSS
Front End Web Development

For advice on which courses the general (technical but non tech specific) developer should watch see my Top 10. The most important course I’ve seen since I made that list is Professionalism for Developers by the next developer on fire guest Nate Taylor.

For anyone considering doing a similar Pluralsight challenge, I recommend first doing one learning path, on the topic that you are most enthusiastic about, and then making an assessment on how many more learning paths you would like to do.

Until the challenge is completed I’m not in any position to look back and assess the full benefits, but it has definitely been useful for improving on my existing core competencies so far. There are a number of newer courses that look excellent but I no longer have time to watch. There are a number of things that need to be sacrificed in order to achieve this challenge.

8 mins: Value:

Relationship between wealth and happiness:

I find this topic fascinating.

For a humorous look at this topic see Benjamin Wallace’s TED Talk: The price of happiness. It is difficult not to be just a tiny bit jealous of someone who gets paid to try out all of the most expensive luxuries in life, including the finest wines, food and cars.

One of the most indulgent moments in my life was when I was a guest on Christmas day a few years ago. I was lucky enough to share a bottle of vintage Chateau La Fillette.

It tasted excellent. I then shared a bottle of £25 wine (very expensive by my standards but much less so) and this was also excellent. I could not say that one was twice as good as the other, much less 25 times so.

Another Christmas I preferred a £6 Chianti over a Barolo; some might call that “uncultured” but it is far better to have your own individual preferences and tastes than to pay through the nose in order to follow the preferences of “experts”. The huge price differences have more to do with exclusivity and bragging rights than anything else, which is why blind taste tests regularly produce different results to sighted tests.

Scientists have found that cheaper and inferior wines in expensive glasses taste better than top end wines served in plastic glasses, and we can’t even tell a white from a red. I’ve found good outside weather is a bigger taste factor than anything else. In the heat of the Spanish Sun with a good view, a beautiful drinking experience for two can be had for less than 4 euros.

It is not just the product itself, all aspects of the experience are crucial to the quality of the user experience. There are also lessons that we can learn from this in software engineering.

I also have more to say on this topic at the end of this post.

11 mins: What lights me up about technology?

There’s plenty to be excited about.

11 mins: Getting started with programming

Studying Haskell in my final year made me appreciate the functional paradigm quite a bit more than Standard ML ever did, but it wasn’t used very much in the real world in those days and I couldn’t imagine how much it would grow in popularity. I was mainly interested in C++ and loved OpenGL.

13 mins: Interest in and use of the C# programming language

When asked about C#, I realize where I’m going mid sentence and back up a bit. The merits of one language over another is something of a religious topic which could be discussed until the cows come home.

The best point that I can make, as it is a fact rather than merely opinion, is C# is also Jon Skeet’s favourite language. And I could give you more than 39,000 reasons why he knows a a thing or two about programming!

One disadvantage of C# that I often come across is its verbosity: I often see that it takes about twice as many lines of code to produce a equivalent solution to simple problems that are written in other languages. Functional languages tend to be much more terse. Adding support for LINQ was one of the biggest improvements in the history of the C# language.

It was interested to hear Dave Fancher make the connection between the teachings of Robert Martin’s Clean Code and Functional Programming.

Most of Uncle Bob’s career has been spent with C++ and Java, but his teachings promote a much more constrained form of Object Oriented Programming that is indeed a lot closer to Functional Programming. Bob wrote a beginner’s guide to Functional Programming in 2013 and gave a talk on Functional Programming at NDC 2014.

The ancient teachings of Object Oriented Programming being super powerful by enabling massive reuse with long inheritance chains are something that lead to massive technical debt, and was followed by a backlash, such as the following parody:

“The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.” ~ Joe Armstrong

JavaScripters can read more about this from Eric Elliott. Many times when I come out of the land of JavaScript back into C#, I feel like I’m being straight-jacketed. All I want is a single function but I’m forced to deal with extra the overhead of creating a new class and thinking of a good class name when the function name already says it.

However when I hear developers hype up ES 2015 features such as promises and generators as the most cutting edge awesome sauce of all time, I can’t help wondering where they’ve been for the last 10 years because these features have existed in some other languages for as long as that.

As I have a recently renewed interest in mathematics, it follows quite naturally that I am also re-looking at some of the benefits that functional programming can bring.

14 mins: Failure

At the end of my answer, I point out that developers should never rely on anyone else to do their testing for them. This is by no means any sort of slight on testers or consultants.

Imagine software development as a game of soccer (or any other team sport about scoring at each end). The best developers are like midfielders. They can read the game and understand when they need to attack (ship software), and when they need to track back and defend (by doing additional testing work).

The Quality Assurance Tester is like the goal keeper: they would not be needed at all if the outfield defense was perfect, but in the real world there are times when they will be needed to make a good save.

A very naïve, yet commonly held belief is if you write good unit tests they will catch all of your bugs. The best definition of a bug that I’ve heard is a difference between human intention and computer interpretation. Unit tests won’t tell you whether you have a good architecture, and are only good for a small subset of security issues.

Unit tests are a good start, but they’re just that.

19 mins: Is failing cheap a failure or a success?

I was quite vague in my story on almost breaking the law. To avoid giving the false impression that I worked for some sort of unscrupulous company, I’ll explain a little: a company I worked for had an information sharing agreement with another company that provided us with leads. We hadn’t built the software to share this data and the other company demanded that we honor the legal agreement.

Because of this there was pressure to get something done and shipped super fast (Pluralsight subscribers watch this clip for a highly dramatic and poignant story told by the next guest developer on fire guest, Nate Taylor).

Fortunately our team had the sense and the courage to ask questions about the requirements such as: If a lead gives out personal details to another company which is then referred to us, and then both the lead and their spouse give out their personal details to us, what does the Data Protection Act say about also giving the spouses details back to the referring company?

This was my first experience of working on a project that never saw the light of day, so I was downbeat. However, it was definitely a success. Many development teams (not to mention project managers and business analysts) would have missed any observation of that legal issue.

Being a software developer is about much more than just writing code, and being a professional is about much more than just turning up every day and doing exactly what you are told to do.

This example is just one way that you can save a company from a lot of trouble without writing a single line.

I have been going through the developer on fire episodes, beginning with episode 0. I have the ISTJ personality type, and perhaps that explains why I feel a need to go through things from the beginning all the way to the end, even when that involves a much larger commitment of time.

I am exactly the same with books, films and training videos: I hate the feeling of things being left half done.

This has the disadvantage of myself finding that I am quickly committing to more very time consuming things. So I look for ways to reduce the time involved. In the case of podcasts such as Developer on Fire, I use Impulse Media Player and listen at about 150% speed. I can also speed read books, but I find that I enjoy them much more when I read them at a slower pace.

When Dave interviewed me I was up to the end of episode 28. Many of the guests resonated with me, especially Jimmy Bogard talking about code simplicity, Jeremy Clark‘s message about the meeting needs of the users, Dave Fancher on the importance of good communication, and almost everything that Mark Seemann said. I was initially surprised that Mark Seemann studied Economics at University, but then I remembered that Economics is about 75% Mathematics.

As I am writing this,  I am listening to the DHH episode, and 36 minutes in he talks about race driving:

I can have a very direct feedback loop about whether or not I am improving, that’s what I really love

This is exactly how I feel about success as a mindset – the pursuit of continuous improvement. Race driving is also one of those rare occasions when the feedback you get is objective: its not just somebody’s opinion, you are either getting faster or you’re not. It then get’s even more similar to my points about success:

Some of the best races I’ve had are when we’ve finished last. Some of the worst races I’ve are when we finished first! The overall performance of the car is not nearly as important to me as, did I do the best that I possibly could?

100% agree! Don’t let anyone else label you by their perspective of success. This isn’t saying that you shouldn’t take criticism. Learning to taking criticism well and actively listening to feedback are very important skills. But sometimes the deck is stacked in our favor and other times it is stacked against us. There is luck in business just luck their is luck in poker.

Have you made the best of the circumstances handed out to you? Could you have done better? What could you have done differently? I believe these are questions to ask yourself regularly.

I would love to hear your opinions on this too because I am interested to know whether this is a popular opinion or whether it is an odd one. Certainly some people are more interested in competing with others.

“Comparison is the thief of joy.” —Theodore Roosevelt

25 mins: Speaking

If you have thought about speaking but been too scared to do, just do it. Feel the fear and then do it anyway.

26 mins: How do you stay current with what you need to know?

These are the main points I make:

• The most important resource is your colleagues
• If you use a video training site, make the most of it
• Read books (I once read that the average developer reads less than one book a year. If this is true then being better than average is easy)
• Go to developer meetups in your local area. Most are free and full of talented minds.
• Consider creating your own blog. I find it helps me structure my thoughts as well as preserve them.
• Read the source code of talented developers, slowly, asking yourself why they took the decisions that they made?
• Use Twitter for getting the developer news earlier, and follow people working in a wide range of areas.
• Avoid trying to learn everything. Pick one or two topics to learn at a time and work your way through gradually.

Although I recommend against trying to learn everything, since I recorded the show, I listened to the developer on fire Scott Wlaschin episode, which gave me the idea of doing the new blog post “The Case for F#” featuring Scott Wlaschin, Mark Seemann, Dave Fancher, Alena Hall, Kit Eason, Mike Hadlow and Ashic Mahtab.

I am delighted with their excellent responses and strongly encourage you to read it (after you’ve read the rest of this of course!)

I think it was Tim Ferris who said most people overestimate what they can do in a year and underestimate what they can do in 10 years. You’re probably doing many of these things already, but if you’re just getting started you can go from doing nothing to doing a bit of all these things in under a year, so imagine what you can do in 10 years (and then understand that you are underestimating).

I say more on the blogging and developer meetups in Reach Out and Grow with Professional Networking

29 mins: Book Recommendations:

Again I was surprised to hear DHH recommend a book on Stoicism. I recommended The Obstacle Is The Way and still do, but the reviews for Guide to the Good Life look pretty good and I might need to read that as well.

There are many more books that have both nothing and everything to do with software development. If Stoicism doesn’t appeal to you, try one of these are 3 examples:

The Power of Habit by Charles Duhigg
Four Hour Work Week by Tim Ferriss
How to Win Friends and Influence People by Dale Carnegie

When it comes to psychology, you don’t need to be in the profession to know the most important lessons. A book that is certainly not written by a psychologist but taught me plenty is Bravo Two Zero by ex-SAS soldier Andy McNab. He suffered horrendous brutal torture, but afterwards he said he was glad that it happened. It took me some time to figure out that this was normal.

I normally prefer books made out of dead trees, but if it a book on an emerging technology, I’ll go electronic. Finding there’s a 2nd edition out before the ink on the first edition has dried isn’t fun, but downloading an update to an e-book is a nicer experience, especially if it’s free.

I would also like to recommend a thought-provoking film: Adam Curtis Bitter Lake, available to watch for free on BBC iPlayer. Although on the face of it, it is a story about Afghanistan, the film is really about the severe and unpredictable side effects of over simplifying a problem. This has strong implications for the decisions we make in all aspects of our lives, including software development.

31 mins: Most excited about

Again there’s plenty to be excited about right now.

32 mins: Greatest Sources of Pain

Dave Rael has shown time and time again to be highly creative: taking ideas from completely different domains and drawing connections between them. I don’t think I would ever have seen a connection between modern day challenges with JavaScript and the teachings of Gandhi, but I think that’s something that we can all draw inspiration from.

Also on the DHH episode, connecting Agile and Stoicism, I never saw that either but now he’s said that I can see the connection. There is definitely a big overlap between Agile, Lean and Stoicism.

Tim Ferris’s advice “let the small bad things happen” is something that I regularly bare in mind.

Being Introverted Sensing, I used to dwell on mistakes and demand perfection from myself. Ironically, dwelling on mistakes is one of the biggest mistakes of all.

Review what happened, understand what could you have done differently, and move on. Focus your thinking in the present. Focus on the here and now.

I try to spend about 90% of my time thinking in the present, 7% thinking about the future and 3% thinking about the past.

33 mins: What do you geek out about other than software that really lights you up?

For brevity I say Mathematics and Psychology. Most of my interests outside of Software Development are actually non geeky, and my greatest passion is travelling.

 

It’s a big beautiful world, and exploring it is a whole lot of fun, and a healthy thing to do both mentally and physically.

However I have an interest in all of the sciences. All science is the quest for knowledge and truth, and it is important to give that work due credit. There are many parallels between traditional science and computer science.

Mathematics is the most fundamental of all the sciences. You can watch the first episode of The Story of Maths on vimeo. And Finding Moonshine is also worth a read.

Some knowledge of psychology is important for running a successful business, because businesses only survive if customers want to buy your products. If you can’t understand your customers needs and desires then you can’t offer them what they want.

Before the show I asked Dave Real which personality type he was, and it turned out that it is known as “The Debater” which is very apt for a podcast host.

Many guests of the show have a strong connection with music. I believe that this is to do with a connection between music and mathematics. I would argue that both music and computer science are forms of applied mathematics.

“Music is the pleasure the human mind experiences from counting without being aware that it is counting” – Gottfried Leibniz

36 mins: Progressive Web Apps

You can learn more about this from Google.

Tips for Value

37 mins: Tip #1 – Perspective: Never as Good or Bad as you think you are.

Again I am surprised just now that DHH’s first tip is also on perspective. It has taken me many years to appreciate how important perception really is.

DHH advises restating the problem. I think this is similar advice to Robert Martin’s advice on saying when something can’t be done, but a much more positive way of looking at it. Users (and managers) rarely if ever want to hear what you cannot do for them. They want to hear what you can do for them. Sometimes how you sell it is just as important as what you are selling.

Einstein’s theories on Relativity are another reminder that experiences vary dramatically according to the observer. Neither our eyes nor our brains see everything as it is.

In fact about half of the functions in the brain relate to sight, but it will never see the full spectrum. It will never see X-Rays, or Infra-red, unless we use machinery to convert them into our natural range.

It is the same with all our other senses and reasoning. We only ever perceive a part of what is happening, and can make what we want of that.

One of the best experiences is what I call the re-experience: those very rare occasions when you try exactly the same product again, but get a completely different experience from it.

The first such experience was about 6 or 7 years ago when, just for the hell of it, I decided to listen to OK Computer again. At that point it was probably 10 years since I’d first heard it and dismissed it as boring and miserable.

Recently I watched The Last Emperor again after 5 or so years. First time I saw that I found it really boring. Long periods of time watching some spoiled child running around a big palace. When I re-experienced it, I could not believe how much more there was to it.

It is less a story of an Emperor than it is the story of a prisoner, like the film the Shawshank Redemption. (While on the subject of prisoners, watch the story of Bassell Khartabil).

Puyi was a prisoner for his whole life, even at the height of his power. Near the end of the film the governer says to him:

You are responsible for what you do! All your life you thought you were better than everyone else. Now you think you’re the worst of all!

This is what I mean by never being as good or as bad as you think you are. We make a lot of decisions that we think are right at the time. Many of those decisions in fact are the right ones, but sooner or later we will fall short.

“Success is a lousy teacher. It teaches us that we can’t lose.” – Bill Gates

Some of our decisions will inevitably turn out to be bad ones. Especially in modern day software development, where everybody, regardless of “experience”, needs to start again, taking on the role of the beginner anew with every new technology.

No one can make only perfect decisions and almost no one makes only bad decisions.

38 mins: Tip #2 – Action and risk taking:

The Pendulum of Success: the left hand side represents risk of failure and the right hand side represents the magnitude of success. You cannot achieve success if you cannot lose. The higher the risk of failure the greater the magnitude of potential success.

At this same point DHH advises getting out of the office to be more productive. I recommended this in my Simple Programmer creativity series, and recently I asked several top developers about the relationship between creativity and productivity. Here’s what Jon Skeet said:

I think I’d argue that in many cases, creativity is productivity – if I can find an elegant solution to a design problem that’s been stumping me for days, that’s a productive day.

I absolutely believe that there are occasions when it is important to get stuff done super fast – especially at startups that tend to have a very short financial runway. Whether or not they reach take off speed in time will depend on the external, not the internal, quality of the product.

It’s just that in many businesses, companies get obsessed with metrics and miss the point that with say 10% more time spent on a better design months ago, those extra 14 user stories would never have needed to be raised in the first place. Metrics are never quite the same as quality. You can easily define any metric but you can’t fetch a bucket of quality.

(I once saw a normally mild mannered and very good colleague get miffed when it was reported to him that one of his classes had excessive class coupling. It was a factory class! Metrics can be useful, but if you are planning on implementing a quality improvement program based on code metrics, make sure that you understand what the number do NOT tell you, as well as what they do tell you.)

The point on creativity also emphasizes the importance of restating the problem and reminds me of Mark Seemann’s advice on making the problem disappear instead of trying to solve it as-is.

For further details on the Pendulum of Success, see #5 on my Top 10 for Jay McFarland’s course.

40 mins: Tip #3 – Spirit/Life/Appreciation:

Again I see parallel’s between my response and DHH’s here. Living your life well is the most vital thing. Many of the points that Robert Martin makes on professionalism in The Clean Coder also come to mind here as well.

If you remember how utterly, incredibly, and mystifyingly lucky you are to be alive, it has many benefits:

It makes you more conscious of how you treat others.

It makes you more focused on the present.

It reminds you to make your life count for something.

It is an example of positive thinking, and positive thinking can add as much 7 years to your life expectancy. And those not just your extra years but all of your years will be better lived years.

I also mention the lottery.  A scientific study in 1978 found that lottery winners are no happier than accident victims after one year. So don’t get sucked into the trap of thinking a bit more money will make you happy.

Most of the things that you dream of don’t require a lot of money to experience. You just need to courage to make them happen. You might not be able to own everything you want, but you can usually get the experience for an affordable price, or often for free.

I often find the iceberg metaphor helpful: what we see in life is just the tip, but there is far more below the surface.

In this case of existence itself, the iceberg is infinitely big, and represents all of the different people that would have been born if things had been only the slightest bit different.

This is all part of what I call Big Thinking: thinking within the context of the big concepts.

It won’t be long before we are history, but until then we have all have an opportunity to make history.

When working with complex problems there are times when the small details can make a huge difference.

But a very common mistake is wasting time on small details unrelated to any problem that you are involved in, or worse still, become involved in an issue because of a small detail.

For example, suppose someone says something mean to you. The Little Thinker pays great attention to this minutiae, wasting their time and energies on it and becoming emotionally negative over it.

The very best big thinkers are able to subconsciously discard it as unimportant and irrelevant before the conscious mind needs to be distracted at all. This is essential because the bigger issues require full focus and concentration. Great minds discuss ideas…

This is not being aloof or disinterested in others. It’s about separating the important from the shallow, and focusing on building the best life for yourself and those that matter to you.

It has been shown over and over that comparing yourself to others very rarely results in making you happier. Instead find a purpose for your life and measure yourself against your progress towards that purpose.

Final Words

The writing of this article became a serendipitous adventure for me. For one thing, I wasn’t expecting DHH to anywhere appear in it, let alone feature so prominently. I was also going to give my performance an overall grade, but my opinion here matters far less than yours.

I am just glad that I gave it a go, and plan to get involved with more podcasts in the future.

The idea that “all the world’s a stage” was already well known when Shakespeare immortalized it in As You Like It:

All the world’s a stage,
And all the men and women merely players

Very true, except in the real world there are no such things as dress rehearsals. Would you like to play a bit part, or be one of the main characters? The choice is entirely yours: you can be whoever you want to be.

Thank you for reading and please also take a couple of minutes to learn the story of one of our fellow Software Engineers and innovators, Bassel.

This article was written in memory of David Robert O’Shaughnessy