Curiosity is a grossly underrated mindset. You may see it in some company values documents, or a leader may espouse the importance of curiosity, but it can seem like lip service. You may feel it is generally discouraged in our day-to-day work. We're urged to simply execute projects to keep them on schedule (ironically, the definition of projects is to work through the unknown, so isn't curiosity helpful?). We face inertia when introducing new technology choices as 'the team doesn't know it, so it'll slow us down' (an important consideration but shouldn't always be the top priority). We admire the inquisitiveness of youth, yet we don't generally hire for it or nurture it as we grow. Curiosity has served me well in my career, and I feel it is a vital characteristic of the best engineers I've worked with.
Why is curiosity important?
Wait, why should we care? We're not all working in a startup or academia. We're not pondering philosophers; we're trying to build things!
Curiosity enables us to scale. We cannot know or remember everything needed to build something or review someone else's design. But we can sense when to ask questions because something seems odd and doesn't fit our mental model. This triggers us to find answers to solve problems as best as possible by researching similar work from others, improving our mental model or challenging the original problem definition.
Let's talk more concretely:
In code, it means asking how we can refactor our code to improve extensibility and maintainability. Perhaps there are libraries we could leverage or produce. Are we teaching junior engineers the right way to think?
In system designs, why are interfaces designed the way they are? Will this design force us to make changes across multiple services, and is this valid or did we get our service boundaries wrong? Are there unnecessary technical constraints such as technology choices that are making our lives harder?
When reviewing requirements, are they indeed requirements or a solution design? Legal and policy requirements are typically more malleable than those presented to engineers, and understanding the underlying principles can lead to better solutions for users and a cleaner system.
How to be curious
Being curious takes practice, especially after it has been beaten out of us when working for many years. I like to think about finding opportunities to ask questions, and luckily, we have plenty of places in an engineer's day-to-day work to do so:
When designing systems, ask whether there are similar solutions around the organisation. Do this, especially after breaking down a system design into logically reusable components. While you should be working on a unique business problem (why should two teams solve the same problem and duplicate work?), we're likely coming across solved computer science problems.
Be prepared to throw away some of your design and work. Finding similar solutions around the company may take time, at which point you may have invested a lot of effort. Then, when you discover duplication, it is tempting to salvage your work by trying to justify why your problem is unique instead of biting the bullet and seeking to consolidate for the greater good. This is commonly labelled as "sunk cost fallacy".
When you get requirements for the first time, especially when they look like solutions ('we need to build XYZ feature'). Ideally, as a senior engineer, you're developing requirements alongside product and cross-functional partners to avoid premature solutions. If requirements don't fit into your mental model or an existing systems model, it's time to challenge either requirements or models.
Trust your sense of code smell in code reviews, e.g., mass code changes copied/pasted or naked integers being passed around. When you're not always in the code, it can be daunting to ask seemingly basic questions lest you risk looking like an out-of-touch engineer. Also, because other people have approved a PR, it doesn't mean you need to (maybe they were focused on other things or ran out of curiosity). Pointing out fundamental problems can serve as learning opportunities for you and your code submitter.
Are you repeating yourself in code? We're constantly manipulating monetary amounts; should there be a type? Why am I doing boilerplate work? Churning out lots of code makes it feel like you're busy, but are you adding value or simply bumping up lines of code metrics?
Frustrations are excellent sources of inspiration for process, design, or infrastructure improvements. If you don't have time to solve them now, note them for later investigation.
When and when not to be persistent with curiosity
As I mentioned at the start, it can be hard to be curious. We may be explicitly or implicitly told to stop; maybe your boss tells you, or people simply stop engaging with your questions.
The best way to gauge when to stop is to understand the value of your questions. What user or company value does solving this frustration unlock? If you come up with a solution, how much effort is it, and would it reasonably turn into a project and reality? Understanding ROI is your first priority, and hopefully, you can get to it before goodwill runs out.
It isn't uncommon to continue investigating behind the scenes or perhaps with a Skunkworks team of like-minded individuals when you deem the ROI high, but others don't (yet). It is incredibly satisfying to pull out a solution to a complex and urgent problem ('Look what I prepared earlier') that would otherwise be punted or cause massive technical debt. Find time and motivating deadlines to help push these 'secret' projects along; regularly scheduled hackathons are great targets.
Beyond working on solutions themselves, developing the sales pitch is also important. Others may not share your framing of the problem; otherwise, they would have already solved it. Be prepared to explain the root cause, size of problems, and potential returns when solving them. You also likely need to overcome inertia when presenting your answer to the long-running problem; people may, unfortunately, look at it suspiciously ('If it was so easy, why didn't we already do it'), so be prepared with as many answers as possible. You may need to accelerate follow-up investigations once your work is out in the wild to exploit any hype you generate.
Maintaining curiosity levels
It's hard to be curious all the time. My levels wax and wane over time based on my interests and energy levels. I find I can generally maintain my curiosity levels by:
Trying to keep energy levels up. Take breaks between intense periods of work.
Working on projects that interest me. Have honest conversations with your manager about this.
Expanding my interests. It is not only about what interests me right now, but what can help my team or org grow.This growth opens up more opportunities in future that may be interesting to you (scale problems, the next set of features, different types of users, working with different organisations).
Remember your ABCs: always be curious
If you made it this far, hopefully, you found this post resonating and picked up a few tips. With time pressure and inertia all around us, it can feel like our curiosity is unrecognised, and it can be tempting to just go with the flow. Remind yourself to find the time to be curious; eventually, you will be rewarded.
"Curiosity enables us to scale" -- really interesting take on the value of curiosity that I'd never considered!