Pling!

Portrait photograph of Chris Northwood

I'm Chris Northwood - often found online using the handle laser, or some variation of this. I also hold the radio callsign 2E0NTW, however I've been dormant for some time. I'm hoping to get back into radiosport soon, though.

I post on Twitter as @cnorthwood.

I currently work for the as a Senior Web Developer.

I've completed an MSc in Computer Science with Speech and Language Processing at The University of Sheffield, gaining a distinction. I also have gained a 2:1 for my undergraduate degree in BEng Computer Science at the University of York.

I've worked on multiple award-winning projects, including The Guardian's Student Media Award for Best Website whilst the technical lead on Nouse.co.uk, the UCISA Award for Excellence whilst lead developer on Mobile Oxford, as well as personally winning the Greg Dyke Award for Outstanding Achievement.

How I structure JavaScript

Published on

I'm not a big fan of JavaScript frameworks. Most of them seem to assume that all your logic is written in JS, and they don't leave much in the way of support for progressive enhancement, and with variable results for accessible websites.

It's important to make a sidenote about progressive enhancement at this point, it's not just about users which have disabled JavaScript, or who use old browsers, but if you're aiming at really supporting mobile users, mobile connections really do vary in speed and quality, and if you go through a tunnel half way through loading a page, the core content of your webpage should still be usable. Progressive enhancement is still important!

So I write my JavaScript following a few simple principles. First, I think about it in terms of components. This is made much easier in that most of the web sites I work on are very much document based, rather than very rich web apps (although I have seen document-based content delivered using web app frameworks). The HTML delivered to the end users encapsulates as much content as possible, and then my JS modules are designed around the concept of enhancing certain parts of the page.

An example component of this might be responsive images. By default our users get served a small image which means mobile devices get a small initial payload, and everyone gets at least an image. We can then enhance this image by picking a more appropriate size from our image resizing service in a progressive manner for users with more capable machines. Given how big a proportion of our content images are this gives us significant savings without unnecessarily losing quality on larger screens.

A typical JS module has three key methods:

This structure makes unit testing straight forward (there is some debate about whether the constructor should also init, but I don't like constructors with side effects on the DOM...), and also a fairly straight forward way of using these modules in different contexts.

The document then being delivered then has a controller (for lack of a better word), which performs selections (using querySelector) and the initiates the various modules. We use Require.JS as a module mechanism to encapsulate these classes which works well for us.

The final type of JavaScript we have on a page is often the completely transparent modules that track state that some other modules use to determine their state (e.g., a stats module that might track when you interact with a component. In this case, we use events to communicate between modules, so a stats module just listens to events that a state tracker might fire, and a UI module can also listen to that event and update its state accordingly.

It's not perfect, but it's pretty lightweight, and it's also quite fast. Combined with the cuts the mustard technique, I've found that we can write pretty much pure JS (without even JQuery!) using modern techniques that work cross browser. It's easy for new team members to get up-to-speed with (it's just JavaScript) and it fits with the progressive enhancement model well.

Someone needs to really disrupt TV

Published on

A few things have happened this week which have inspired me to write this blog post. The first is that earlier this week I attended a BBC North Women in Technology event. The theme of this event was "Our Friends in the North" with a panel discussion about Manchester's place in technology world (an interesting discussion focussing on Manchester's heritage, including the birthplace of intercity rail travel, the industrial revolution, the post-war home of Alan Turing and the first stored-program computer, and the "Madchester" scene), including a lot of focus on why Manchester is currently punching below it's weight.

The other main interesting thing was attending a conference in New York (plus a couple of days added on as tourist time). Whilst there, I used Google Now extensively. Google Now is, I believe, the single most impressive innovation in recent years. For a long time, computers, and more recently, smartphones, have relied on the 'app' metaphor. That is, a lot of disjoint user experiences to solve individual tasks (or, more often than not, a muddle of tasks in one UX distinct from an overall UX). Google Now smashes that, and I think Google could take it a long way. Upon my return to Manchester, I discovered that Google had finally incorporated Manchester's public transport data into Google Maps/Google Now, making Google Now actually a usable experience in Manchester.

A lot of people who know me know I've been interested in public transport for a long time. This started when I worked for OUCS on Mobile Oxford, and is something I've played with on and off for the years since I left - taking a small part in the open rail data community and participating in betas with organisations like Traveline and TfGM. However, all the use cases I envisioned developing with my 'manchester.io' project are now satisfied with Google Now, and to a lesser extent, sites like RealTimeTrains and Open Train Times. There's little more I can add to that sphere now, I failed to deliver and lost any advantage I might have had. (The fact that all of these things are proprietary do worry me, however). The only interesting innovation remaining in this space is one of little interest to me, but frequently espoused by my friend Josh, and can be summarised as "Uber for buses" (i.e., there's been lots of innovation around the open data of public transport, but not of public transport itself - where are the startups aiming to disrupt First and Stagecoach?).

But there is an idea that's been burning in my head in recent months, although I've no idea what to do with it.

Television is changing. It's hard to even define what TV is any more. Freeview is, sure. But is iPlayer? Even with the VOD bits? Is YouTube? Is Usenet/the torrenting sites? In my head I see TV as relating to broadcast and simulcast, and things like iPlayer and YouTube as VOD - a distinct thing from TV. This distinction will become irrelevant in the future however - why should a user care about this? The interesting question is who's innovating here? In the UK, the big players seem to be putting their bets on IPTV, but with things otherwise continuing as they are. Which is boring. There's YouView, but I don't think it's anywhere near as ambitious enough. With the newer startups - Netflix/Lovefilm - they seem to be staying in the VOD world, although with content that would have previously been originally TV, rather than a proper merge. I don't believe replacing TV with VOD is the future - VOD loses some of the benefits of TV (TV as a medium is fantastic for content discovery in a way VOD isn't at, as well as for live events), and the BBC have set themselves an interesting challenge with moving BBC Three to be online only using iPlayer, but I remain far from convinced this is a challenge the BBC as an organisation can truly meet.

(At this point I should add a disclaimer that this blog post is a personal one only, and my views are definitely my own, and should not be considered representative of the BBC at all)

For the BBC to survive, iPlayer needs to die. Or at least, it needs to evolve into just the standard way people consume BBC content, with no differentiation between online and broadcast content - a seamless experience that's not limited to just one platform, it needs to play nicely with ITV, Sky, Channel 4, Netflix, YouTube... YouView is not this future. The barriers to entry are still too high, and it's still too tied to the traditional world. When I can get channels like Geek & Sundry on my set top box, with equivalent prominence to channels like Pick TV, etc, then we know we'll have made it. And I think that world will be amazing. (Just think, with this, and an object-based broadcasting world, how that 10 foot display becomes more than just a way to watch video - imagine the rich experiences that can be delivered...)

The closest so far I've seen to a genuine next generation TV device is the Chromecast. It's better than a typical set-top box in many, many ways, and I'm interested to see where Google go with it, but the prospect of a Google-owned future also scares me. We need competition in this world, and we also need open standards. Television as it is now succeeds because of open standards. Can you imagine needing separate devices to watch BBC and ITV? Microsoft are dominant in the business desktop space, Apple cross the boundary between consumer desktops and tablet/mobiles well (although I believe consumer desktops are due to die for all but the enthusiast - tablets satisfy the needs of most consumers), Google are currently the most interesting player in mobile because of Google Now and Android (sorry Apple, but a new look & feel for a phone doesn't excite me), but TV is wide open. Microsoft's play with the Xbox is very interesting, but it remains to be seen how they scale from providing home entertainment to gamers, to providing home entertainment for everyone else, but it seems that everyone else has just taken the app metaphor and applied it to television (look at the modern smart TV offering, as well as devices such as the Apple TV and Roku). Even the BBC's own play - Red Button (and the Connected variant, as well as various smart apps) are still this. I think a true convergence will feel more like Google Now, than the current approach.

This is actually an area I'm quite passionate about, and where I see a gap. I've no idea what the answers are, but I know what I'm asking now - what replaces the EPG? I'd love to work to discover the answer to this, but I can't do it by myself, I don't have the individual skills. I'd need a team (one where the team is greater than the sum of it's parts) to discover this. If I were to do a startup, it'd be to answer this question. Although I've got no idea who'd fund it - it's a risky strategy, but if we get the answer right, it could be extraordinary. Imagine what an Android-like ecosystem would look like for TVs - open platforms, high quality linking (actions, etc). I suspect the current organisational structure of the BBC doesn't give ideas like this much of a room (don't get me wrong! We get genuine space to innovate, but that space is within the confines of our current deliverables and vision, and R&D seem to be focused on longer term ideas), which is a shame.

If a startup were to happen, Manchester is the most natural place for it, though. The area has a strong heritage, and is very strong in user experience (although most of that is applied to e-commerce), and it's also the home for a large chunk of the BBC's technological staff (approximately 40% of Future Media staff, as well as the R&D North lab), and the BBC is an organisation with a reputation for developing large leaps in TV technology. Although in it's current politically neutered state (can't possibly do anything which might actually impact the markup disproportionately, due to the way we're funded!) I fear it won't be able to bring about that change in of itself - ask yourself, would the current BBC be allowed to deliver something like the Chromecast? However, this change does need to be delivered on open standards if it's ever going to become the new TV. People won't stand for having a Now TV box for some things, a YouView box for others, a Chromecast for Netflix... Everything needs to interoperate (and the easiest way to do this is for DRM to die, rather than exist and continue to make it difficult to enter this field and cripple innovation, restricting it to the big player).

Now who's with me? And does anyone know how I can go about achieving this?

What sucks about front-end development

Published on

Front-end development still sucks, and it's not only because of cross-browser compatibility, it's also because of the tools we're using. There are 3 areas that consistently cause problems for me, and there's no way I'm the only one.

Non-semantic HTML

(tl;dr - table designs are bad, so why are we re-implementing them with non-semantic class names? We should use our CSS frameworks to have only abstract classes that we make concrete by extending them with semantic class names. Also, progressive enhancement isn't dead and still has value.)

As I'm redeveloping Manchester.IO I've decided to use a responsive grid (specifically Gumby), mainly because it makes life easier, and secondly because it's best practice and will probably result in a better looking site. That's fine, but why does every single Sass/Less framework suggest first in the documentation that you should write your HTML like this?

<div class="row">
    <div class="col-4">I'm some content!</div>
    <div class="col-4">I'm some more content!</div>
    <div class="col-4">I'm the last content on the line!</div>
</div>

Did we not learn that table designs are bad because they heavily couple the design of your page to the meaning of the document? Yet we're doing exactly the same here! I'm hoping that I don't need to repeat the lessons as to why separation between style and content is important (and also, between behaviour, which is the JavaScript part of our front-end design world).

This has real, negative consequences for our apps - they become harder to make accessible and harder to maintain due to the heavy couplings between these layers. And they are layers, there's no particular reason why some HTML by itself should not be able to represent meaning without a MVC JavaScript framework underlying it. The problem is that we've sacrificed client experience (unless our clients are using modern, fast devices on high-speed Internet connections) in order for fancy technologies, and in fact our same high-quality modern user experiences can be delivered using traditional progressive enhancement techniques, rather than the more brittle rich web apps that have become the standard in modern web development. (I recently upgraded from a Samsung Galaxy S2 to a Nexus 5, webapp performance on mobile phones is a real problem unless you're using the latest and greatest).

What I would like to see is a Sass framework that only provides mixins, and no concrete classes themselves (apart from maybe some reset and base typography rules). You'd extend the abstract ones with your semantic class definitions (maybe every section is a row, etc, whatever makes sense for your desired outcome). But ultimately, you should be able to take a reasonably defined HTML document and then style it how you want without making anything but minor changes to the HTML. At the very least that'd avoid situations like this one:

Chrome Web Developer Panel - 1167 (95%) of rules not used by the current page

That's over 200k of unused CSS being downloaded in my case, just because I decided to use Gumby.

JavaScript library management

(tl;dr - managing JavaScript dependencies still sucks, and Bower has fundamental flaws that limits it's utility)

What's the best way we've got of managing vendored assets right now? Until recently, it was downloading zips and copying them into our project, but yay for Bower! Except Bower suffers from a fundamental flaw, in that it conflates the unbuilt source of a front-end library with the built version. Sure, frontend components are generally interpreted rather than compiled, but we often still want to do some post-processing to it (thankfully the Bower devs have already acknowledged that this is a big problem, but as far as I can tell there's no immediate plan to fix it.

Bower's other big problem over putting packages in a vendor directory is the lack of first-class support for AMDs. AMDs are the single biggest improvement to JavaScript in quite a long time and take the pain out of front-end development considerably. There's an extension that'll output a require config for my vendored packages (yay, yet another tool I need to run somewhere in my build pipeline), but it's still not as easy as just dropping the minified files in a directory called 'vendor' and adding a path to your require config. And dependency management tools should make life easier, not harder.

(As an aside about Python - I do most of my non-work web dev in Python nowadays, but Python's setuptools doesn't even pretend to know about any other languages, some sort of post-install hook would be nice, so it could run, e.g., Bundler, to install Compass/Sass, etc.)

Media Queries

(tl;dr - screen sizes don't necessarily imply a device class directly, but that's what we use it for)

Media queries are being used for things they were never intended to be. Just because a device has a small viewport doesn't necessarily mean that it's a phone, but that's the inference we make (as we've got no other detail in which to make that determination, short of doing user agent sniffing), so we make our touch areas bigger because we assume it's a touch screen device, and all sorts of other things, but it's all just a guess. For example, what happens if the device is currently running over a mobile data network? Maybe we don't want to fetch retina images to save on data allowances, perhaps we've got a device that's controlled using a 5-point remote rather than a pointer and want to lay out our user interface differently.

I consider myself to be a "full-stack" developer, rather than just a front-end specialist, so maybe I only feel these issues because I'm comparing it directly to other parts of the software stack rather than considering the front-end in isolation, but front-end development still feels very immature and like the wild west, rather than the engineering discipline we're striving to be. We need to make it better.

Introducing Manchester Tech Nights

Published on

I've now made this actually be a thing - please see Manchester Tech Nights #1

There's something that's bugged me about events in Manchester's tech scene for a while. There are a lot of great specialist events, and a lot of networking events, but there appears to be little in between, ones that cross knowledge sharing with networking, other than the now-defunct Social Media Cafe, the Northern Digitals BLAB Talks, and ThoughtWorks' Manchester Geek Nights. However, BLAB Talks are geared more towards the creative side of the industry, rather than the technical side and Manchester Geek Nights speakers appear to be limited to ThoughtWorks.

The specialist events are great, but there's just so many of them, that it's impossible to attend even just the ones that are interesting to you, and the networking events tend to be heavily geared around alcohol and drinking, which in itself is problematic and can be exclusionary.

When I lived in Oxford there was a great event I attended frequently, Oxford Geek Nights, which basically has a format that fills a gap that I think Manchester now has, so I'd like to start running a monthly series of nights in this format, and hopefully some other people think this is a good idea too.

What?

I'm going to call it Manchester Tech Nights, and I basically want to use the format of Oxford Geek Nights - 1 or 2 keynote speakers followed by a series of unconference-style lightning talks, followed by relaxed chatting and drinks if you'd like.

The talks would come from anyone who feels they've got something interesting for Manchester's tech community:

When?

Monthly feels right, and having a look in the important places (Lanyrd, the MadLab/TechHub calendars), the last Thursday of the month seems to be pretty clear, so if I said 28th November 2013, 7.30pm for the first one, would that suit?

Where?

This is the hard question. Basically, I'm looking for somewhere which is:

Now, in my naivety, I'd hope venues like this would be available for free, but if they're not, then we'll need sponsors.

What Next?

Well, I'm hoping to draw on community experience for venue suggestions and then organise somewhere, and I'm going to need some speakers, so if you're interested in giving a 20-30 minute talk please let me know at chris@pling.org.uk, in the comments below or @cnorthwood on Twitter.

Oh, and some attendees too. If you're interested in attending, please let me know on Lanyrd!

The perfect backlog

Published on

In the perfect backlog, the product owners elicit requirements from the users and stakeholders using a whole array of techniques, and then they write it up in the form of a user story and put it on the backlog. They don’t determine the best way to solve the problem in the story, but they then go and determine how important it is in priority order and continue consulting with the stakeholders and users to gather more requirements.

Once the story starts to appear on the horizon of the backlog, the business analysts, UX designers and developers have a think about the ways they can solve the need presented. Sometimes the solution is self-evident (perhaps an author wants to see what their article looks like before publishing it – sounds like we need some sort of preview mechanism!), but often it’s not, and the “obvious” solution might actually miss out on a more innovative, better idea (maybe instead of preview we should make the authoring environment look and feel like the published environment). So the business analyst might go and bang the requirements around a bit to make sure the user story is the right one, and then go and find out exactly how we’ll know when we’ve solved the presented problem (the acceptance criteria). The UX designers and business analysts develop some interaction processes and solutions in the context of the whole system, maybe following user centric design and the developers go and check how realistic it would be to build the proposed solution.

These potential solutions are presented to the product owner who decides the one they like the most (hopefully based on the knowledge of the users and stakeholders, but sometimes it might just be the one that has the most whizz-bang features).

Then the business analysts, the UX designers, the developers and the testers get together in a 3 amigos session and turn the acceptance criteria into scenarios which satisfy those criteria in line with the proposed processes and user experience, and everything now meets the ‘definition of ready’ to come into a sprint. Maybe this ‘getting ready’ process is tracked in a sprint, or maybe you have people in your scrum team who spend some time outside the sprint in order to get things ready, but now we’ve hopefully got a solution to a story that can be delivered (to your definition of done) in one sprint.

But getting that perfect backlog is never that simple. Coming up with solutions to problems is fun – sometimes the users think they really know what they want (time to break out the 5 Whys if so, because maybe they don’t want a faster horse), and sometimes the product owner thinks they know the answer (but they should stick to what they’re good at, and leave the solutions to come from the people who do what they’re good at, that’s what they’re there for after all). So it takes discipline.

Scrum suffers from seeing everyone in the team (except the product owner and ScrumMaster) as equal. In reality they’re not. Sometimes they’re specialists, other times they’re “T-shaped” specialising generalists (my favourite type of team to work in), and very rarely is everyone a generalist. But everyone is creative, and you should use the skills they do have to your advantage. Your scrum team are not cogs which churn out software, they’re a team to come up with solutions to problems. Trust really makes an effective team, so trust the team to deliver effective solutions to problems and stop product owners over-working.

Scrum lives and dies by the backlog, and a poor backlog (especially one which is poorly managed) can turn many projects into wagile death marches. Have a look at your backlog – does it consist of problems to be solved, or solutions to be built? If it’s the latter, then in my opinion, you’re doing it wrong.

I don't use alarm clocks

Published on

Like I imagine a lot of the working population, I hate alarm clocks. Unlike a lot of the working population, I don’t use one.

When I tell most people this, they recoil in horror. How can I not use an alarm clock? Aren’t I always late for work? Well it turns out that if you trust your body, then you’ll normally wake up at a natural point in the sleep cycle. How many of you wake up just before your alarm clock goes off, only to turn over, get another 5 minutes sleep, then get interrupted in the middle of a sleep cycle and wake up feeling more tired?

I am lucky enough to work in a “creative” profession, where the hours I work aren’t (very) important, but the quality of my output is, so I officially work a “flexitime” system, and I realise this isn’t for everyone, but maybe I’m getting old and I love waking up relaxed from a good night’s sleep. Trust your body clock, without the safety net of the alarm clock, you won’t turn over and fall back to sleep and you’ll wake up feeling happier. Give it a try, and maybe you’ll wake up feeling better too.

Age 26 - The Retrospective

Published on

As people who know me quite well will know, I’ve spent quite a bit of the last year or so of my life going through a period of introspection – a retrospective, if you like (although I’ve not quite got 3 columns of what’s gone well, what’s gone not so well and what I need to improve!). This week I realised that I’m actually at the happiest I’ve been in quite a long time – it was my birthday, I got offered a permanent job (and a promotion) at work and am well on my way towards my weight loss goal amongst other things! I thought it was a time to reflect again, write something and reflect on where I am so far – so here we are!

At the end of 2011 I left a pretty serious long-term relationship and it turned out that the grass wasn’t really that much greener on the other side after all. So after the resulting low, I started trying to figure out how to pick myself back up and I put together a life plan – a set of objectives and actions (and then put them on Trello – it’s satisfying to move things to the Done column).

Now, one of my good friends Ian:http://cubicgarden.com/, who’s been described as a Wikipedia of dating, has helped me with this process, and although the purpose of my retrospection wasn’t really around dating (although that was a part of it – I wanted to figure out exactly what I wanted), a lot of advice around dating is actually just self-help, particularly around self-confidence. A lot of the things that are covered in dating advice books and those communities, is around an area called “inner game” – that basically boils down to self-confidence. A lot of the other bits of advice from those kind of communities are to be taken which a pinch of salt (to say the least, it can be full-on misogyny at times), but GirlOnTheNet says it better than I ever could, in that a lot of the advice from the pick up community is basically just self-confidence, and then going and talking to women).

Ian and I have different views on some aspects of dating, and although his advice has forced me to push boundaries, I’m not trying to emulate his approach exactly, as we’ve got different personalities and experiences (which is fine – there’s not one single approach to dating which works for everyone), but I have been on more dates, of which the majority have been good dates, and I’ve managed to figure out what I’m looking for as well – which is definitely something that I struggled with a year ago, and not knowing that left my paralysed at times.

I now have my own home, which I’ve made into a good reflection of me and my personality, I’ve started dressing better, but again into a way that’s a good reflection of my personality, I’ve started rowing, which has immensely boosted my level of happiness in my physical self, and I’ve now got a network of good, local, friends around me – which is something I’d found difficult to have for a while, largely as a result of moving city on average every 12 months for the past 5 years. I’m really happy with my job, and that’s been the strong foundation which all my other confidences has grown from. There are still aspects I want to work on – I’m still overweight, I drink too much and get too loud when I’m drunk, and there are still quite a few areas of my life I wish I had more confidence about – but from where I was 12 months ago, I feel a large difference, and I just wanted to capture that.

What I learnt from Startup Weekend Manchester

Published on

This weekend I attended Startup Weekend Manchester, hosted at the soon-to-be-opened TechHub Manchester space. The idea I pitched was probably quite an ambitious one, and different to most of the other ones there in that it was aimed as a service to be delivered to a very niche selection of business, rather than a mass-market product. Regardless I got a few bits of interest and managed to form a small team to develop the business plan with Ian Horst, David Haikney and Josh R and the weekend got underway.

We put together what I thought was a sound pitch (BBC Fusion training kicking in there) and I think we delivered it well, but ultimately the idea didn’t get much traction from the judges and we didn’t finish in the winning 3, which was disappointing. I’m pretty damn passionate about the idea and have absolute dedication that the time is right now to disrupt the market so it was disappointing to not be able to share that passion.

However, this has given me a kick up the butt to really make some traction on the problem and start tackling some of the difficult problems I’ve been putting off for doing – I’ve now got a about half a notebook full of concepts, ideas, potential graph structures and high-level algorithms to tackle the problem… I also learnt a few things from the weekend – mainly that I need to get customer validation, and the way to do that is to get Molly 2.0 complete and mancunia.mobi running off the new stack, rather than just being timetable-driven as now (which is largely uninteresting). Lack of design ability and time continues to stymie me though. Once this is done I can put it in front of people and get their feedback, and then I also need to deliver proof that I’ve got the skill to build such a solution.

The other thing is something I’ve known for a while now, but this weekend has really highlighted for me – I need a co-founder who’s as passionate about disrupting the transport data industry as I am, and who has the skills I don’t have, specifically the people and business skills. And I still don’t know how to find such a co-founder in Manchester – most other people I know who are interested in the area of open data or transport data are technical, or already involved in startups of some kind. But maybe you’re reading this blog? Who knows, but it’s something I really need to drive forward on – network more, and meet more people… i.e., my weaknesses.

Do I have any criticisms about the weekend? Well, I was hoping to find a co-founder and actually get some traction on my idea from other people, and I got none of that. Startup Weekend wasn’t actually what I expected – specifically the rule about not being able to develop prototypes or do work in advance (other than coming up with a thought-out idea) hindered me a lot, and was surprising to me – it seemed that the competition aspect was focussed upon more than the “let’s start businesses” aspect. Non-mass-market products are hard to validate over a weekend, and the cynic in me asks if there’s much value in a business that can essentially be formed and build it’s product over a weekend (despite being billed as not a hackathon, the judges did praise teams which managed to get an MVP built over the course of the weekend) – this was probably our main failing, we were pitching a technically complex product with no demo to prove that we could deliver on it. My other main criticism was the lack of feedback we got after our final pitches – other than a handful of comments and praise for the winning 3, the other teams got almost zero feedback from the judges. I’m guessing our failure was down to the lack of validation we got for our idea from customers and a technically complex idea with no proof, but I could be wrong.

Do I regret going to Startup Weekend? Not one bit. It’s given me the motivation I need to actually make more progress on my own technical work. Will I be going to another one? Probably not.