The ABC of Software Engineering (Always Be Curious)

I’m not comfortable with things I don’t understand. I cringe at comments like “I don’t know why this fixes [my problem] but…” I’ve seen that in code comments, commit messages, and PR descriptions. To me these are red flags, but also opportunities to learn and grow.

Copying and pasting code from some stack overflow solution is a slippery slope. We all do it. We’ll find a page that answers our question and copy/paste the code into our app. That’s fine. What I occasionally take issue with is engineers willfully passing up the opportunity to understand why the code works; why it solves their problem. This is a signal that indicates the quality and potential of an engineer. Are they curious?

That doesn’t mean you need to become an expert in everything you work with. I’m certainly not. Each time we encounter a new concept, framework, or system we begin to develop a mental model for how that thing works. This model is informed by our experiences with it and thus only as complete (or accurate) as we have needed it to be up to any given point. When we experience something that doesn’t fit the model, that’s when we should embrace curiosity to refine our understanding and go deeper.

This applies to engineers at all levels. Junior engineers may encounter more of these opportunities for a while, but technology constantly evolves. Our knowledge must evolve with it regardless of seniority. We must be perpetually curious to remain successful in our field. Seldom have I regretted digging in to better understand something. It’s time well spent.