While I was browsing social media, I came across a tweet that said, “You’re too junior [in software development] if you’re using the mouse.” My initial reaction was just an eye-roll. But then, I realized that there’s more to talk about. 

Keyboard and Mouse are tools, just like VSCode, Vim, Emacs, Rails, Ruby, JavaScript, you name them. They are essential because they help us to get things done faster and more reliably. 
I see many developers spending significant amounts of time debating the right choice (why emacs is better than vim, JavaScript is trash, you name it).
I’m not here to weigh in on any of these specific discussions and arguments instead of getting the discussion on a higher level.

As software developers, we spend time talking about how we feel using this particular language, framework, or tool. We can get stuff done so much faster in Vim than Sublime Text, using tabs instead of spaces, etc.

But what if you would make the choice based on the optimal end result for your customer? Imagine you’d choose Rails over Sinatra or vice versa because you could ship six months earlier than planned. Or you could add offline support to your web application without breaking a sweat, and your customers’ productivity would go through the roof.

How does that feel?

Getting there means to look at your tooling from a different point of view. Do you understand how a particular tool fits into your company infrastructure and workflows? 
For instance, I’ve seen Developers choosing something very sophisticated but hard to learn and use. Why? Because it might express their intellectual prowess, thinking that this makes them more senior. In reality, it’s not the case.

What makes you more senior is team-enablement. Instead of having everyone else put in the effort to get to your level, you put in the effort to help your teammates level up. 

How does that look like? 

For instance, your company uses a build system that’s currently challenging to use with time-intensive maintenance. 
Everybody comes to you if they are struggling with getting builds to work. Every one of these support requests takes away your and your teammate’s time to deliver value. 

If this accumulates too much time spent on maintenance, let’s find a way to reduce this again. You could write additional documentation that explains steps better, or, if that doesn’t cut it, lead efforts internally to replace this system with something more user-friendly. 
Whatever you do, and the more senior you become, the more it is your responsibility to get roadblocks out of the way for others so they can deliver value to your customers and users. 
Once you deliver your product to the end-user, they won’t know, nor would they care how much effort you put into it. Sophisticated terminal setups and cutting-edge technologies don’t matter. They need to know that it works on their devices, that they can do what they’re good at reliably with your software.