anthony galvin

25 years ago this week I started working at what was then known as a 'web agency'. I started off as the 'work experience' kid - I suppose today I would have been an intern.

Quickly that became a part-time and then a full time job. The dot com boom was still in full swing. I didn't know a lot, but I bought a book on building websites from the computer section of Foyles on Charing Cross road. The 'internet' section didn't even fill a whole shelf. So much about technology and building websites has changed since 1999.

But amazingly many of the fundamentals I started to learn about on that first day (between making cups of tea), remain true today.

1/ Good design makes complex things appear simple. But simple is unbelievably difficult to achieve

2/ Thinking about the end user as a real person really helps - the best way to achieve this is to talk to some of your users regularly

3/ Readable code beats 'clever code' 99% of the time - leave comments. The next person will thank you (that next person is often your future self)

4/ Technology is like cricket, an individual sport wrapped in a team game. A lot of working with tech is an individual endeavour, but it's a team game. You need to operate well as an individual contributor and be an excellent collaborator to succeed

5/ It always takes longer than you think (Hofstadter's Law is real), and you often don't control the deadline - try and have a version that's ready to ship even if it's not quite right

6/ Fast web pages with good semantic markup are good pages - 25 years on having a H1 on the page is still a good thing! Web frameworks are amazing, but good markup wins every time

Productivity advice famously doesn't work. A persons tips are almost certainly only applicable to them - we are unique individuals, perhaps with only a love of searching the internet for productivity tips in common. So with that caveat I'm sharing an approach that's been working for me. Your mileage will vary as the internet often says.

Like lots of people in engineering lead roles I have a lot plates to spin. I have 3 main tools I use to make sure I'm dropping the right things - an infinite bullet list of notes and links (in Workflowy), my calendar (colour coded, but more on that later) and a Miro dashboard, which I spend a little bit of time updating on a Monday morning.

The dashboard is pretty simple, but it helps me ensure that I'm spending my time on the right things and also communicate to my team what I'm focussing on this week.

Driving (up to 50% of my time) - initiatives where I'm a key contributor, or I'm directly accountable

Supporting (20%) - important but I'm playing a supporting role

Monitoring (5%) - I need to know what's happening but I'm not a contributor

Directs (at least 20% of my time) - my direct reports

Coaching (~5%) - people I'm keeping an eye on (maybe skip reports) or am supporting in some way

The colour coding is the key, because I then use that in my calendar and notes to visually link everything together. If I glance at my calendar and there's two much green, then it means I'm not spending my time on the right things. It's not a hard and fast rule, but a heuristic that helps me keep things on track.

There's a template available in Miroverse if you want to give it a try.

When I started off in web development, back in the last century, everyone was a generalist. And generally people didn't really know what they were doing. Which was fine, we made it up as we went along, learning little bits along the way. For most engineers working with the web, the problems weren't that complicated. Tying to get your blink tag to render on various versions of IE and Netscape Navigator. Infuriating for sure. But in the grand scheme of things not that complex.

Fast forward 25 years or so and complexity abounds. Or it can do. Especially for bigger organisations working with bigger teams on (hopefully) bigger problems. In the front-end world new frameworks have supercharged the user experience of many web based products and services. With the added complexity and learning curve that a power tool demands. App development, for a while the home of the 'native' developer also has a plethora of cross-platform and alternative authoring options. These promise (though don't often deliver) a simplified development environment. Away from the front end, contributors to languages such as Grails, Python, GoLang and node.js add more and more features. Promising better, more powerful tools, with an ever improving developer experience (I said promise).

So where does this leave engineering teams and hiring managers. In a medium sized tech company nobody can know the entire architecture and tech stack. At least not with any mastery beyond some boxes on an investor presentation. It takes a team to deliver and in most organisations lots of different skills.

When hiring engineers, I always enjoy learning about how they solve problems that I don't see everyday. I meet a lot of candidates. It's fascinating how peple deploy so many different tools and technologies in such a variety of combinations. Sometimes people describe themselves as "full stack engineers" - which isn't a phrase I love. Full stack invariably means some back-end and some front-end engineering experience. But it doesn't mean the entire stack. No one person at TodayTix Group is able to deliver with mastery across every part of our architecture. We don't expect any one person to do so.

But we still hire full stack engineers. Teams taking on a problem need to be able to solve that problem regardless of the technology or tool that it touches. Which is why we have cross-functional teams with a mix of skills, experience and perspectives. Good engineering practices and process can go a long way regardless of the technology in play. The best full stack engineers (or multi-stack engineers for want of a better label) can bring multiple points of view. Arguably good engineers are generalists. However, complex problems often need someone to focus on a specific area, and in tech companies that specialism can get very, very specific. Which can be good for the organisation and very rewarding for individuals, at least for a while.

When I say a while, I have a specific example in mind. When I joined TodayTix Group I inherited a migration project. The goal was to integrate an acquired business. Moving off a legacy main-frame system that was decades old. Many of the project team had been maintaining this system for decades as well. They were true specialists. Day to day work for the team was a combination of being a care worker, therapist and engineer. But their decades of deep specialism hadn't equipped them or the company for the future. This wasn't the fault of the team. A failure of leadership had stymied technology strategy. A failure of people management and career coaching. Aligned with diverging company and individual priorities. The longer the business stuck with the mainframe the less incentive it had to develop the engineers supporting the system.

In a career as an engineer it makes sense to focus on the challenge at hand, to specialise in technology and tools that benefit you and your team. The path to being an experienced engineer is to build experience. Learning a new framework isn't experience. Solving some real customer or business challenges with it is experience.

But focussing on a single tool without taking the time to check-in on wider developments in your industry and chosen field is limiting. Ideally your manager should be taking some time to help you get this kind of perspective. But that's not always the case - especially if you're not a full time employee, work for yourself or work in a smaller organisation (and unfortunately in some bigger companies too!). If that's the case it's important to find other ways to do this. To have someone who you can chat to about career development, technology changes and what that means for you.

The goal for more experienced engineers is to be a general specialist. Someone with a variety of experience in different technologies, with knowledge of one or two technologies that are current. Like gardening career development is easier if you do it a little and often - not go on a training course once every 10 years.