forests and trees
Day 10 of 30. Working from home today, in my apartment near Amager Fælled, which is part of this massive park chain that runs 20-ish km down to the quaint fishing village of Dragør. There are forests and trees and lakes, and as I type this I'm reflecting on how often our technical terminology in computing draws inspiration from the real world. A tree is a specific type of data structure, where everything branches off of a root; a forest is a collection of trees; a lake is a system for pooling raw data across an organisation; and so on.
We do it too with digital design, to the extent where we have a special term for it: skeuomorphism. Save icons that look like floppy disks. Journals in game interfaces, designed to look like heavily-earmarked books. For every article claiming skeuomorphism is dead, you'll probably still find another 10 examples in the wild. (And floppy disks, much to my surprise, are still being sold - roughly 1000 per day as of writing.)
For those familiar with English idioms, there's another place we talk about forests and trees, a saying: "I can't see the forest for the trees". It means to be lost in the details, unable to perceive or understand the whole. We all know this state of mind, either in ourselves or in others around us. Not being able to let that one task go. Having too much on your plate, and no time to think about what's actually important. Chasing down too fine a level of detail up front.
When people ask me what being a software engineer is like, or how to get into the field, those sorts of questions, I have a few answers at the ready. It's essential to develop a good debugging mindset. Learn by doing, especially at the beginning; the ability to plan larger projects comes after a lot of doing. Get feedback early and often. Go to meetups or hack nights or conferences, ask several people this same question - it's a big field, software touches just about everything, and it might take some time to find what you enjoy.
And: you have to see the forest and the trees.
I have days where I'll spend an hour (or two) debugging a complex issue, then zoom out into planning our next few weeks to months of engineering work, then zoom back in and help unblock a teammate by getting clearer specs in place. In and out. Fine and broad. If I don't understand the broad plan, I can't see where best to help and unblock. If I'm not involved in the details, at least a bit, I can't flag key risks to our plans.
It's why, as a lead engineer, I try to ensure that I'm spending 30-40% of my time coding with the team, each and every week. It's why I'm always curious what my colleagues in product and design are up to. It's why I keep a steady lookout for things we can borrow from other teams, or help them with. It's why I make sure to have 1:1s with engineers, even though I'm not a manager (yet).
All of this serves a common purpose: gathering information, at various levels of detail, to see both the forest (the product as a whole, dependencies within the organisation, technical and strategic risks) and the trees (technical details, code reviews, individual tasks, looming blockers, team morale / mood).
If you only ever engage at the strategic level, your strategy quickly becomes unmoored from reality. If you're always shoulder-deep in the details, you can't see which details matter. Learn to see both. Learn to use both to inform the other.