I think, as a whole, software developers are an incurious breed.

I’m not speaking about the kinds of people who buy loads of reference books, go to conferences, or read articles and articles on software development. Or even the kinds of people who learn a programming language over a long weekend. Those are good things to do, and I don’t think there’s a shortage of software developers who engage in those activities.

I’m mostly talking about the mindset of a software developer within the workplace.

I’ve found that very few developers know much about their company’s codebases outside of what they directly work on. There’s a pervading thought: “If I didn’t write it, it’s not my responsibility.”

Though I’m not sure I can place the blame squarely on software developers, as perhaps these behaviors are encouraged by the companies that actually build these kinds of cultures.

In any case, here are some things I’ve found that can help counteract the kind of mindset I see so often.

1. Read other people’s tickets.
2. Read other people’s code.

That’s it.

Assuming this is all public knowledge within the company anyway, there’s no reason you shouldn’t do these things.

Read Other People’s Tickets

Consider the different ceremonies of Scrum.

• Daily standup
• Backlog grooming
• Sprint planning
• Sprint retrospective

I’m not saying Scrum is all that great (it isn’t), but it’s how many teams develop software, so it’s useful as a touchstone to begin to talk about why reading other people’s tickets helps you thrive in these kinds of processes.

When you’re reading other people’s tickets, you begin to know what everyone else is doing. It lets you see what they’re writing to the ticket owner and what the ticket owner is writing back. If you’re asked to pick up the ticket because a team member is on vacation, you already know and have context on what’s going on, rather than having to read the ticket from the beginning.

Not only that, but you know the shape of the sprint in more intimate detail. Ceremonies like daily standups only provide you with a cursory overview of what’s currently going on. I also find that very few people pay attention to standups in any meaningful way, so taking the time to read other people’s tickets reduces the need for standups.

Consider also the backlog grooming and sprint planning ceremonies. Many times the first time a person sees a ticket is during these meetings, so a lot of time is wasted reading and trying to understand what a ticket is trying to say. If you’ve already read the tickets beforehand, you know what it says and can spend the meeting evaluating each ticket on its merits rather than thinking on your feet.

Read Other People’s Code

I would say that reading other people’s code is far more important, however.

The first time a developer reads someone else’s code is often when they’re developing a feature or fixing a bug in an unfamiliar system. What happens often is that they try to make as little change to the code as possible so as to leave as minimal a footprint.

This is understandable, because they don’t have a firm understanding of all of the systems at play. It’s difficult to make changes to something when you don’t know what you’re changing.

There are practices like code reviews and pair programming that try to solve this problem. But by the time you get to a code review, you’re already too late. Such things are mostly a rubber stamp ceremony anyway.

Pair programming is better, but it’s a practice that puts the onus on others rather than on yourself. However, it can work well as a supplement to what I’m suggesting here.

Instead, you need to have started much earlier and read other people’s code from the moment you started working at the company.

Not only that, but you need to read every commit that goes into the master branch and perhaps even whatever stray branches are out there. If there’s something you don’t understand, you need to go and bug the developer who wrote that piece of code and start asking questions.

This helps you gain an understanding of the application as a whole. You begin to understand the domains of other people.

But not only that, you can also begin to understand other people’s coding styles, the kinds of patterns they are wont to use, their design sensibilities, et cetera. You can learn a lot just by reading code.

Conclusion

This kind of curiosity is difficult to cultivate. Much of the reason this is the case is that companies have very little reason to want to develop this kind of curiosity in their own software developers.

In addition, these kinds of things may rub people the wrong way. People like to maintain the borders of their own little fiefdoms or silos, and asking questions about other people’s tickets or code begins to feel invasive.

Still, without the knowledge and understanding of the entire application, it’s very difficult to do anything of import. Better to go outside your own comfort zone and shake things up.