Software Engineering: A Learning Curve that Never Straightens

Published: 10 October 2019

Author: Richard Thomas

Working in tech is a lesson in dealing with moving targets. But if there’s one area in the business where that paradigm hits hardest, it’s in software engineering. Not only are the goals constantly shifting and the customer requirements constantly evolving, but the tools, methodologies and development environment beneath you are also on the move. That’s actually not too bad – as engineers we like playing with new things – but we get two challenges out of this. How do we discover and learn about new things? and how do we then introduce those new things to the business in such a way that we don’t destabilise processes and don’t follow false trails?

Of course, at a higher level, even “how we learn” and the tools to assist that learning, keep changing. So, we’re still finding better ways to answer these questions, but I’m going to set out our current thinking on the first question here – how do we keep our team learning, in the widest possible sense?

Let’s start with the recognition that there’s a difference – a big one – between Software Development and Software Engineering. We’d see the difference like this : Development is the production of software components that work, and Engineering is the ability to develop within a large-scale project, working in a team to create something that’s large, complex, but manageable and scalable, and adding value to that team in terms of ideas and communication. Engineering is Development PLUS:

  • proper testing
  • integration
  • architecture
  • concepts like loose-coupling and services
  • teamwork
  • a deep understanding of WHY we do things in a certain way, rather than simply doing those things efficiently and on time.

Software Engineering is what we want to be doing at Highlight.

When we talk about helping the people in our team learn and maintain skills, we’re talking about it in the wider, Engineering sense:

  1. Technologies : Languages, Javascript frameworks, Database architectures, Tools, etc; and
  2. Practices : how to create, manage and deploy large and complex software products, which goes right from the best way to manage a hierarchy of C# objects, to DevOps-style rapid deployment.

Let’s look at this in more detail, but be careful not to put too narrow a definition on ‘learning’:

First, we want our team to actively learn, about pretty much anything – ideally related to their jobs but tangential or orthogonal is OK. Continuous learning - even if not directly related to the work we’re involved in at the moment - can help prepare us for future problems, plant seeds for new ideas and ensure skills don’t stagnate.

We have a ‘free book’ program that lets you expense any vaguely-relevant book (soft- or hard-copy) that you want. We provide a full Pluralsight subscription for each team member, and we encourage people to go to conferences or meet-ups where good stuff is being covered. To be a bit more thought-provoking, Friday lunchtimes we have a ‘lunch-and-learn’ session showing a selected video on software techniques, technology, or engineering practices. We often get people from other teams sitting in, proving I guess that we’re substantially a technology company (or that people have discovered the free doughnuts and muffins that get handed around, but that’s a cynical view).

Learning should cover these topics

Learning goes wider than that, though. We try hard to encourage conversations within and between teams. We want people to share knowledge – be willing to show someone how to solve a problem, or just discuss it with them, but also being willing to accept that someone else’s idea might be better than yours. This is surprisingly important: we’ve had team members join from companies with very different cultures where having your idea critiqued is seen as a bad thing, and people resist it. It takes a while for them to loosen up and realise that this is one way you learn, and a key one. Working with other smart people is a valuable thing.

Learning at the Engineering level also means seeing and understanding how your code is used, and the impact it has. We don’t want Engineering to be a black box within the business, and we want to involve engineers from other teams like Product Development and Operations / Service Delivery. You’ll regularly see our engineers discussing how a new feature might work with Products, for example – providing input at a design meeting, or sitting with a UX designer who’s planning a new screen layout.

We’ve settled into a pretty good and methodical approach to Scrum, and this includes refinement meetings where a mix of teams go through what’s coming down the development pipeline. This gets our engineering team properly involved in the product process, rather than just having requirements thrown at them – good for the company and good for the team. Improved integration with our Operations team has led to roughly quadrupling the rate at which we deploy new releases of our service (we could go faster, but our customers like a regular, predictable heartbeat of updates). This has involved our engineers in the establishment of continuous integration, test automation, and other processes that mean our recent full shift into Azure became just another part of the long-term learning curve.

Finally, I should say we’re also experimenting with the infamous “Hack Day” concept. Possibly because our regular development work is so interesting (tongue in cheek there, did you notice), while we’ve floated this idea a few times, it hasn’t been embraced wildly. Our team know that if they fancy taking time to experiment with something new they could just ask – we’re happy to fund the purchase of tools, software and kit to help – and thus far, this has been more of an “on-demand” phenomenon than a regular thing. But we’ll be trying some other formats in the very near future so watch this space.

That’s it for now – how does this compare with your environment? And how do you like to learn? let us know.

Share this article: