I had no excuse for not attending DDDNorth this year, as it was held at Leeds University, a relatively short drive from home. Not that I'd be looking for an excuse - these free events are always superbly organised and provide a valuable opportunity to see sessions from a wide range of speakers without having to take time off work. It's no wonder the tickets are always snapped up so quickly.

As a contractor, I also appreciate the opportunity that DDDNorth affords me to catch up with so many friends and colleagues that I've worked with over the years, and it was great to see so many familiar faces.

With five slots during the day each offering five concurrent sessions there were plenty of difficult choices to be made. In general, I tried to attend sessions offering information I didn't think I would be able to get from books, blogs or PluralSight - stories from the trenches and architectural concepts rather than deep dives on specific technologies.

The first session I attended was "So You Want To Be A Tech Lead - 10 Things You Need To Do To Succeed" by Joel Hammond-Turner (@rammesses). I was delighted to find that the eponymous ten things were not airy-fairy woolly soft-skill type things, but in fact consisted of ten topics backed by a whole bunch of concrete real-world actionable suggestions. These ranged from large architectural tasks (use NuGet obsessively for all internal dependencies, set up automated release management with Octopus, etc) to the little things that can make a difference (be willing to take your headphones off, read and share The Morning Brew, add photographs to Personas..)

Next I saw "Not Just Layers! What Can Pipelines and Events Do For You?", presented by DDD circuit regular Ian Cooper (@icooper). This was the most technical session that I saw, and required some serious concentration. Ian started his presentation with some slides that explained the theoretical background behind the architectural concepts he was introducing. These were beautiful and densely packed with information, and I plan to review them at my leisure! He then fired up Visual Studio and demonstrated some C# implementations of the patterns previously described. Kudos to Ian for creating a successful presentation on a fairly dry architectural topic - inevitably it could only scratch the surface but has whetted my appetite to venture beyond the typical layering approach when considering candidate software architectures.

As I hurtle inexorably towards my 40s, and noting the general absence of older coders in the workplace, I have been starting to wonder whether I need to identify alternative career paths away from the code face. So the following talk was of particular interest to me.

Ceri Shaw's (@cerishaw) talk "Join The Dark Side - Why Developers Should Consider Management" began by covering some of the negative managerial stereotypes that we techies tend to hold (yes, there was a Dilbert cartoon). She continued by looking at the traits needed to be an effective line manager or project manager within a technical team, identifying (as the session title suggests) that developers did in fact possess many of the requisite skills. Although I'm still not entirely convinced that a full-time management role is the right move for me personally, I can see how some aspect of mentoring or scrum mastering might not be entirely incompatible with my desire to retain a hands-on techie, and I will be seeking out some of the resources she mentioned to learn more.

There were a number of interesting short grok talks during lunchtime. I particularly enjoyed hearing Grant Crofton (@relentlessdev) describe his attempts to use functional programming to determine the most appropriate school for his son! That sounds like a slightly more practical means of developing skills in F# than my own efforts to use it solve some of the Project Euler problems.

"Burnout Is Real And It's Coming To Get You" was the title of Richard Dalton's (@richardadalton) talk, which I consider to be the highlight of the day. Richard took a potentially worrying subject and gave hope and advice for all of us who have at some time felt ourselves to be at some point along the burnout continuum.

I was particularly interested in the observation that it is precisely those of us who place a high value on our work (and are willing to give up a Saturday to attend a conference) who are likely to feel burned out and overly self-critical of our perceived inability to drive technical change or achieve as much as we would like.
The Agile movement, Richard suggested, was born as the result of an entire industry feeling burnt out and unable to get things done.
He cautioned us not to be jealous of or constantly compare ourselves to other developers, and to consider what aspects of life are poorer for those in our industry who are able to devote vast amounts of time to developing open source frameworks or writing popular blogs. I was also pleased to hear someone else mention the guilt that they feel when they choose to spend their hard-earned free time reading for pleasure instead of being glued to PluralSight or reading tech books. We do need to go easier on ourselves if we're in this for the long haul.

The issue of age naturally came up - Richard concluded that there is no discernable mental decline between a programmer aged 20 and the same aged 40, it's just that we have many more demands on our time around this age, leaving us with less contingency time to catch up on the less productive days. If we make it through this period in our lives without quitting the industry, it was suggested that things could actually be easier in our 50s as children become more self-sufficient and we once again have some time to spare.

In summary, it was a very reassuring talk, wrapped up with helpful advice on how to handle burnout - what works and what doesn't.

In recent years the projects that I have worked on have involved much web services work (both as a client and server), so I was interested to hear David Whitney's (@david_whitney) "Lessons Learned Running A Public API" talk, full of tips gathered developing the Rest API for Justgiving.com
There was a good mixture of hard technical advice (how to handle versioning, authentication, what data formats to support..) along with softer ideas of the supporting work required to create and maintain a successful public API (generated documentation, SDKs, not being a slave to external requirements or a single client, getting a product manager).

I was particularly struck by the openness of the approach recommended by David, which involved creating public Google groups to push support issues into the community, and making a public uptime page available. Lots of good tips from the trenches here. Once again, here was some real actionable advice from a session that we can take away and put into practice.

And that (after the customary prize draws and closing comments), was that. Thanks to Andrew Westgarth, Black Marble, the University of Leeds, and all the sponsors and speakers for once again staging a vital event. The development community in the North would be much poorer without this large multi-track multi-session event, and I look forward to attending again next year.