I'm a technolgist at TodayTix, the posts below are about work, but probably don't reflect my employers opinions. If you want to connect about work related topics, then this is probably the best place to do it. Work related tweets @workoworko
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.
Government believes too many students are racking up debts studying “soft” 3-year university courses in arts and social sciences, and is looking to funnel more 18 year olds towards technical training that is cheaper and will pay a faster economic dividend.
It probably was “soft” compared to some degrees, but I learnt an awful lot of “soft” skills that have proved way more important than the technical skills that I learned on the job.
The idea that one person, your manager, is going to be the oracle on your career is a bit optimistic. Mentees all round!
If you're an engineering lead business and you make vendor and toolset choices that don't take account of the impact on the team it's not likely to go so well.
Great deep dive into image optimisation - and a reminder that really delivering on web performance often takes expertise and diligence that's hard to deliver at scale.
Feels like every few months I end up sharing this link. Email has been around for 40 years and it's still catching us out.
Some thoughts on technical leadership and coding.
The other day someone in the team asked me if I still write code. Which got me thinking about how, especially in agency land, senior technologists often don’t. Faced with the growing need for Technical management and client facing technologists, many larger digital agency environments have a fork in the road where people can pursue a less hands on route.
Over the years I’ve worked with lots of senior folks who continue to be practitioners. People from an engineering background who are still, at least some of the time working with software. This isn’t unusual in other fields - nobody expects the top brain surgeons to do all the operations, but they are expected to do some. The same is true for lawyers and in agency land often true for strategists and UX / design folks.
That’s not to say that management and leadership aren’t skills in themselves, skills that require practice and a significant time commitment. As an engineer the way you scale and produce a better output is (or at least should be) by having a team. The team is your unit of awesome.
There’s code, and then there’s code. On the projects I’m involved in the amount of real technical output I contribute varies significantly. Often the things I’m doing are prototypes, setting a direction - more like someone doing a sketch that communicate an approach or a style. It’s not about being ‘the best developer’, firstly because defining best is difficult (fastest, fewest bugs, most code, least code, best collaborator etc..) and also because that’s probably not your role on the project.
Sometimes it’s just about chipping in with a bug fix, picking up a few tickets and helping when the deadline is looming and JIRA is looking a bit unpleasant. It’s fairly unlikely that I’m going to be picking up lots of dev work across any of my client work, but it is an aspect of how I go about solving problems in my day-to-day work.
That’s not to say it’s easy to stay on top of the ever changing technology landscape, but for me it’s not a binary choice between management and coding. They are part of the dynamic of technical leadership, and it’s important that you make time to develop your skills in both areas.
2017-11-15 14:47:11 GMT permalink
Recently I’ve been doing lots of work with voice interfaces. Globally AKQA has been working with clients on VI since it started to go mainstream, and in the UK we’ve helped Jamie Oliver and Arsenal get onto the Amazon Echo platform.
VI is also a lens to use when looking at system or service and figuring out what an MVP really is. By it’s nature VI is a paired back user experience - so if you have an experience that works well for voice users then you probably have a good idea of your core use cases.
From a technology perspective it also starts to place some new demands on engineers. It forces technical teams to think differently about infrastructure, code and server less at scale. The separation between code and infrastructure can get messy when working with AWS Lambda (and similar services), so it’s extra important to focus on code and build pipelines for anything but the most trivial use cases.
Developing for voice also highlights something I think is increasingly important for engineers - the ability to bring service design thinking into software / sprint planning. There’s an increasing overlap between writing software that doesn’t have dead ends and handles exceptions well, and managing the user through options and occasions frustrations of voice interfaces.
Test automation, unit and integration tests are even more important than usual (though I’m not sure how much more important you can make these kind of tests!). Manual testing of voice services is slow (you can’t really speed it up), so you need to have good test coverage to have high confidence in your software and for the team to be able to work at a decent velocity.
It’s also important for everyone on the team to spend time using voice services and to understand the emerging design patterns and expectations of regular users. In the early days of television it was apparently common to meet people who appeared on TV shows but refused to own a television set. The same approach won’t work if you’re developing VI. Using an Echo or Google home on a regular basis is the only real way to understand the possibilities and frustrations of voice interfaces.
2017-05-17 14:25:25 GMT permalink