My Developer Productivity Talk at .NET Oxford

UPDATE: Since doing this lightning talk, I have also done an extended hour-long version at a couple of the DDD conferences. The full blog post about the hour-long version of the talk can be found here. That includes everything that is in this post, plus a lot more. So probably worth reading that one instead of this!

In November, we had another lightning talk event at .NET Oxford, where I did a talk on Developer Productivity. I summarised the talk, in my blog post about the night, but promised that I'd do a full blog post about my talk - so here it is!

It was only a 20 minutes talk, so I didn't have a huge amount of time. It was broken in to the following three sections ...

• The Power of Compound Learning
• Snippets and Note Taking
• Tools and Automation

Intro

It always surprises me that if you take a room full of developers, the deviation between each developer's productivity level is huge. And I mean, seriously huge! A task that might take one developer half an hour, might take another developer an entire day. And the quality of the solution will also be wildly different.

A lot of it is of course down to experience, but it isn't as closely tied to the number of years the developer has been developing for as you might think...

You might have a "20 year" developer who has been working for the same company throughout, the same technologies - hasn't the foggiest about the latest technologies - no idea about design patterns and best practicies. No idea about writing maintainable, testable code. Never written a unit test in their life.

And you might have a "2 year" developer, who actively studies every day - reads blog posts and books, listens to podcasts, watches Pluralsight, has side projects, dabbles with other technologies and programming languages.

The two year developer is probably going to be a better and more experienced developer. I'd certainly rather hire a developer with this mindset.

Now imagine the twenty year developer had had the same mind-set as the two year developer! Activity studying every day throughout those twenty years! Imagine the difference!

The Power of Compound Learning

I touched on this in my blog post about National Coding Week (see the 3rd question) "What advice would you give others wanting to get into coding?" So rather than repeating myself, I'm just going to quote my answer from that blog post ...

My biggest piece of advice would be to never stop learning! And also to actually embrace learning, as it's something that as a developer, you'll be ongoing doing a lot of. If you embrace it; actively study daily - read books, watch Pluralsight, listen to podcasts, read blog posts - then you'll very quickly put yourself ahead of the average developer.

I don't know the official term for it, but I think of it as incremental learning, where learning a little bit every day, over a long period of time, becomes huge. You could also think of it as compound learning because in the same way as with compound interest, where you earn interest on your interest, on your interest, on your interest - you also get the same concept with learning. The more you learn, the more underlying knowledge you have to build upon. So basically, the more you learn, the faster you learn, so the more you learn, so the faster you learn! This is a very powerful concept to appreciate and take advantage of.

You also learn and retain more by being motivated - so it's important to make sure you enjoy what you're doing and never get stuck in a rut. There are so many great technologies to play with - even if this is a side project or getting involved in an open source project - make sure you play and have fun with different technologies and programming languages. There's a lot of very cool stuff going on - especially nowadays.

Snippets and Note Taking

As developers, we repeat ourselves a lot! More than we realise. And I don't mean as an industry - I mean individual developers repeat themselves a lot. How many times have you Googled the same problem multiple times; spent half an hour searching for the same Stackoverflow answer more than once; written code that does the same thing, more than once. It's a tremendous waste of time.

This might sound really obvious, but it's surprising by how many developers I've seen who don't have a centralised place to put their code snippets.

I personally use Workflowy for this. You can read a blog post I wrote about this here. But the tool you use isn't the point. The point is that you have a centralised place you can quickly store snippets and notes. It could be Workflowy, Evernote, OneNote, GitHub, even text files in Dropbox. It's the concept that matters, not the tooling.

There are a few points I'd recommend though when choosing a tool...

• Make your snippets and notes sharable. And I don't mean sharable with other people - I mean between your home PC and work PC - and anywhere where you'd need to access them.
• They should be easily searchable and well structured. As this gets bigger, you still want to be able to very quickly find what you're looking for.
• Centralised. Most IDEs have some form of snippet extension. The problem this this is, you're limited to using them just in that IDE. I have lots of things in mine - code snippets, command line snippets / reference, step by step instructions on how to stuff, build script references, regedit hacks, etc, etc.
• Private / Personal (see below)

I want to expand on the final "private / personal" bullet point. Your snippets / notes should be personal. Now, one might argue that you should share it, let others contribute. The problem with this is that everyone's minds work differently. One person will write and structure their notes completely differently than the next. So if multiple people are contributing, then you need to have some form of moderation and standards as it gets bigger. It also raises the barrier to entry. One of the hardest things about this is consistently contributing. Everything you do, ask yourself if it could be of use to your future self. If so, spend a couple of minutes adding it to your snippet repository. If multiple people are contributing, then you're even less likely to contribute as frequently.

Now, after saying that - please bare in mind that I'm talking about non-project specific snippets and notes. It's not company or project specific. However, if you work in a team, then it's very important to have a internal development documentation. Ideally a wiki of some form. I've worked with quite a few teams that don't take time to document properly, and it's not good. Documentation is very important. If a key developer gets knocked down by a bus - the company shouldn't be screwed! However, this is not what I'm talking about in this talk. I'm talking about your own personal snippets and notes which you can take with you from company to company, as well as side projects.

Obviously, the true benefit to this is when you start using your snippets and notes. I've had tasks before which have taken me an entire day to do the first time I've done it. And once in my snippet repository - I've done the same task next time in a fraction of the time. It's a massive time saving.

Tools and Automation

The final section of my talk, discussed tools and automation. As developers, everything we do revolves around tooling. From small tools like the clipboard, to massive tools like Visual Studio. We've all heard of both the clipboard, and Visual Studio. But there's plenty of other tools that can help us be more productive that are less common. Also, there's plenty of functionality even in those tools we already use that we probably don't use. Think of all the functionality in Visual Studio that you don't use, or don't even know exists. And even speaking of the clipboard - most people put up with a single-entry clipboard - copy something, and you lose your previous entry! Using a simple tool like Ditto can transform the way you use the Clipboard, and be a big productivity boost.

LINQPad

One example of a tool that I find a lot of .NET developers don't use, which every .NET developer should be using - is LINQPad. I've written quite a few blog posts on this, and also did a 20 minute lightning talk at .NET Oxford dedicated to this.

This is a fantastic tool with so many different use-cases. Rather than me detailing what it does in this post - I'd recommend checking out both their website, and my list of tips and tricks blog posts about it.

In the talk, I demoed LINQPad briefly, but obviously didn't have enough time to cover it fully like I did in my previous lightning talk.

Resharper

Resharper is a Visual Studio extension which literally saves me hours each week. I should point out that Jetbrains are a prize-draw sponsor of .NET Oxford - but my reason for talking about and praising Resharper are completely unrelated. I genuinely find it that useful.

I demoed a bit of functionality of Resharper, wanting to focus on areas where I think developers who already use R#, perhaps don't know about. Some examples which spring to mind are Incoming Calls, the Stack Trace Explorer, pulling members up and down into base/derived classes, changing signatures, etc. I also showed the standard functionality for members who weren't Resharper users already.

The CLI

I didn't spend too much time on this one, as Stuart Leeks was doing a lightning talk on PowerShell at the event. I did want to demonstrate the fantastic tool ConEmu though. As I feel that the stock command line in Windows might well put a lot of potentially CLI users off using the command line.

I mentioned earlier about the power of tools. Well, if you're not a command line user, then you're missing a large percentage of tooling that can make you more productive. Obviously there are GUI tools - but you should have both the GUI and CLI tools in your toolbox - otherwise you're limiting yourself from the get-go.

For more about the CLI - you can read my recently blog post about Getting more from the Windows Command Line.

Todo Lists

I also briefly discussed todo lists. I recently wrote a blog post: Todo lists: The right way, which I'd definitely recommend reading. However, that post focuses on non-based-project tasks. I also recommend using todo lists for project-based tasks too. Break what you're working on into smaller actionable chunks, then work from that list. And as you think of things whilst you're working, just quickly add them to your list, so you don't forget them. I find that working from a list like this, minimises procrastination and also stops you from forgetting the smaller details.

I'd also recommend every time you stop working - eg. for the night, or when you stop for lunch - write a couple of sentences reminding yourself where you're up to. This means that when you start the next day - you're starting hitting the ground running.

Conclusion

This was just a 20 minute talk - so quite a lot of content to attempt to cram in. I managed most of it - but I didn't get chance to demo as much of R# as I'd have liked. I did cover most of the things I wanted, so not too bad!

Since doing this talk, I've also started trying the Pomodoro Technique, and have seen a big difference! So perhaps in my next productivity talk, I'll discuss this too. I definitely have a blog post in the pipeline about this!

I'd love to hear your thoughts about the different tips and tricks you've found along the way to make you more productive as a developer.

Please retweet if you enjoyed this post ...

Blogged: "My Developer Productivity Talk at .NET Oxford" https://t.co/ZjYDag1lHC @dotnetoxford #Productivity #publicspeaking #softwaredevelopment

— Dan Clarke (@dracan) December 28, 2017