mark (he/him) is a software engineer, photographer, runner, and other things too sometimes.
You don't have to be curious, but it sure is nice
In the software biz you don't have to be curious, but it sure is nice. It's important to understand the systems and constraints that we work in. There's often a lot of moving parts, and having a mental model of those moving parts when you're building is critical. How do you do it?
Sure, you might sit down and read all the documentation, all the manuals, all at once. If you're very academic, this might work for you. I dropped out of community college not once, but twice. The academic style does not work for me. If you're working in an existing system you might not read the documentation at all. You may just absorb information from existing examples in a code base. Perhaps there is no documentation.
But another way is to be curious.
Let's say you're working in a framework - maybe Django or Laravel or Rails. The beauty of a framework is that you don't need to know how it works. It offers you nice abstractions so you don't need to worry about how to route an HTTP request or how to serialize a database model to JSON. That's great for getting moving quickly. However as a system grows, it sometimes outgrows the framework unless you've very dilligently worked to that framework's principles and constraints in which case... very impressive work, maybe this post isn't for you.
You will need to begin making choices about that system's design and that is when the real power comes from not just understanding how to use your tools, but how and why your tools work.
So be curious. Review code from engineers more senior than you. Review code from engineers less senior than you. Ask questions and understand why they are doing something the way they are. What's that function do? What's the difference between a set and list? Read GitHub issues on packages that you use. Right click a framework class/function and Go to Definition. Toss yourself into unfamiliar waters, you will float eventually.
The best part about being curious is that learning becomes a game. You pull on a thread wondering what it will lead to. Keep pulling the thread. It's okay to not understand every single thing you come across. Read it anyway. It will eventually connect to something else you read later and you'll have a nice "A-ha!" moment.
When curiosity wanes, the job becomes rote and boring. If this happens, maybe you're burnt out. I think this happens to a lot of software engineers who work full time jobs but then also explore tech often in their free time. It's okay to switch gears and go for a walk or bike ride or something. The curiosity will come back.
You don't have to be curious, but it sure is nice.