Derek Graham

Information & Communications Technology

sketchnoting mob programming pair programming visual thinking extreme programming xp tdd agile Test-Driven Development

Newcastle upon Tyne, England, United Kingdom

Derek Graham

Principal Developer, Sage UK

I'm a Principal Software Developer working for a very popular business software company in the North East of England.

I co-organize NE Bytes, a monthly .Net community get-together and Agile North East, both hosted in Newcastle city centre.

I am an Extreme Programmer, an Infrequent Sketchnoter, a Collector of Programming Languages, a Speaker, a Mob Programmer, a Test-Driven Developer and Struggling Agilista. I am also a STEM ambassador, microbit hacker and project lead for the "Makers & Creators" events at Campus North with Tech for Life UK.

My main areas of interest are in using agile methods to help improve what we ship, test-driven development, unit testing, continuous and deliberate learning, visual thinking, design and, of course, code.

Current sessions

No SOLID evidence

The SOLID principles are something that everyone agrees are a good thing and are definitely doing but few people can tell you what they are. In this session I want to explore the detail of the five principles, why they aren't what you think they are, and what you can do instead to improve the code you write.

Hopefully not too ranty, targetted at newer developers who are sold SOLID as a thing to aspire to but don't have the experience to know what's wrong with it.

Let's build a PowerShell module in C#

PowerShell is a wonderfully useful language for lots of tasks and has a huge library of modules to do just about anything you could want to integrate with your software. PowerShell is built on .Net so if there's something special you want to do or you want to integrate with one of your own libraries, you can use C# to write a PowerShell module. In this session, we'll live code a simple c# module from scratch, implementing some of the features that make PowerShell really useful.

For intermediate or advanced devs with some understanding of c# not necessarily with much exposure to PowerShell.

Sketchnoting for developers

As developers the one thing we can count on is that we can never stop learning. Retaining, processing and making sense of new information are all parts of what we do every day. Sketchnoting is a set of techniques you can use to support and improve your visual thinking, communication and learning. You can even use it to get more benefit from the other sessions you attend at DDD North!

In this session, I will show you how sketchnoting works, how to get started, tips and tricks to save you time and why sketchnoting is so much better than F#. I'll also cover how it can be applied beyond conferences and talks to UX/UI design, team collaboration, agile methods and your personal development.

The Elements of Style

There are always plenty of new programming languages and frameworks to learn but changing your working style in software development can sometimes have a bigger impact on you and your team's success. Under pressure to deliver, we often find ourselves pulled back to individual contribution as the correct way to do development. There are better ways of arranging ourselves to lower stress and achieve better productivity as a team and I want to explore a couple of those here. I also want to introduce you to strong-style pairing as the smallest, easiest way of improving your (and your team's) development life.

Throw Me the Idol

Finding yourself in a situation where you need to make sense of, and maybe maintain, someone else's code is often said to be like gardening or, in extreme cases, archaeology. The code needn't been an old legacy system filled with ancient secrets and artefacts, it could be the newest piece of JavaScript framework wondrousness from another team or a proof-of-concept idea you now have to make production-ready.

If you have ever found yourself Indiana-Jonesing it through this kind of codebase, or expect to anytime in your career, what strategies and techniques can you use to stay ahead of the boulders and out of the clutches of the Nazis?

I have inherited more than my fair share of nightmare codebases through my career, many measured in millions of lines of code, and will share my insights for coping with impenetrable programs, how to gain confidence in the code before making changes and strategies for refactoring into a better state for the future.

Unless things go terribly wrong, none of this should involve any snakes.