Today I’m struggling with context-switching as I’m hopping wildly between front-end development to visual design and icon alignment back to copywriting and then user research. It’s a lot to juggle and today is one of those days where I feel like I’m goofing everything up. Too many plates are spinning and I don’t have the focus or the nerve required to keep them all up in the air.
Whilst I have the UX clearly in my sights I drop the ball when it comes to the alignment of text, the color of things, the visual treatment. Basic, obvious, junior typesetting stuff. And when I switch back to code for the first time in a while I’m sort of lazy and I make obvious mistakes. I hack things together and hop around solving all sorts of random problems without digging into this one problem, making a PR for it, and then moving onto the next thing once it’s done.
The way I know I’m screwing things up a bit is when I go back to a design or some code an hour later and spot all these painfully obvious things. It’s like when I context-switch I lose the ability to see this new thing clearly and it takes a while for my senses to tune into this new problem space. It’s why I think I’m an extraordinarily slow designer, I get there eventually but damn I sure enough took the slowest route to get there.
Over the years there have been some great visual designers I’ve worked with who can’t see the UX problems, or they can’t see the underlying code insanity. It’s not really a matter of context switching for them because they never get to that place of doing this whole other thing well. They always struggle with things outside their wheelhouse and yet they don’t ever really see how bad they are at it.
This is why we have more than one person on a team, people to fill in the gaps of your knowledge and your skill set. If there’s a React wizard on the team then I shouldn’t have to worry about some new API—I’m hoping they’ll tell me about it. And by letting them handle those problems, or asking them for a review of things to double check I’m not being lazy, it instills this extra degree of trust on a team.
The real nightmare scenario is when teams are mismanaged and there are these enormous gaps in the skill sets of everyone combined. For example if someone is great at UI design but then no-one is there to represent the UX side of things, those problems will never be seen. If there’s no one on the team that cares about performance or animations then there will be an imbalance in the thing you build. It’ll be slow and clunky and will be sort of lifeless. It’s why I argue so strongly for dedicated front-end engineers on a team. It’s just too much work to manage for one person.
On this note, this is where school teaches us all the wrong ideas. It tells us that we’re all alone, every project is the sole achievement by one person. And the shocking thing about getting a job for the first time is realizing how you desperately need to depend on others. One person’s amazing stunts and talents don’t matter as much as the health and well-being of those distributed skill sets across the whole team.
But when you have that level of trust, those overlapping skills, and great management? Oh, what a joyous thing.
Behold! My newsletter—sent infrequently—about new things that I’m working on. Every so often it’ll contain notes about web design and publishing things that I’m interested in, too.