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.

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 artifacts, it could be the newest piece of JavaScript framework wonderfulness from another team or a proof-of-concept sketch you now have to make production-ready.

If you ever find yourself Indiana-Jonesing it through this kind of code what strategies and techniques can you use to stay ahead of the boulders and out of the clutches of the Nazis?

Having inherited more than my fair share of nightmare code bases through my career, many measured in millions of lines of code, I 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, cleaner state for the future.

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

Talking about general principles of getting code under control - using approval tests, building an adhoc testing framework inline - and then using tiny automated refactorings to make small changes to code to improve understanding and clear the way for getting code testable. Language agnostic.