I make around that. I think a big part of why I've been moderately successful is that I always look for opportunity in places other people often don't and I put people first. I don't consider my job to be writing code - I believe that what I do for a living is help people solve problems in ways that will make their jobs and lives easier and make our business more efficient. Code is just the way I happen to be able to execute on that. My primary focus is on the people who use the stuff I write - what do they need? what do they want? what problems are they trying to solve? what are their paint points? what dynamics are at play that are causing problems to arise? I try to think very deeply about why people are having problems and look for the best solution I can to solve the problem, especially in ways that don't involve code! A concrete example - a customer from the business came to me and said "could you add feature X." I spent time talking to understand why the feature was wanted. I then did an investigation asking everyone else I could find who has some relation to the problem that my customer thought X would solve. It turned out that the problem my customer wanted to solve was created by an inefficiency in the design of an internal workflow process. I reached out to the managers and stakeholders for that process, pointed out its unintended negative consequences for other people, and proposed a modification to the process that solved everyone's problems - and I didn't write a single line of code. I think that focus on the people and what they need has been why I've been consistently promoted ahead of people who are more deeply technical or passionate purely about tech than me. I almost treat my core technical skill - coding - as a last resort; my primary concern is helping people solve complex problems, something developers can be good at.

Another thing to be cognizant of is adding value at every step. One of the few hard and fast rules I have is "if its doesn't add value in the moment it doesn't go in the app." I never build anything that papers over a process problem, or people issue, or a workflow deficiency. I never make anything that someone has to do just because they are told they have to do it. Anything I develop has to benefit the person using the app in the moment, or otherwise they'll work around it. "Life finds a way" and all that. People wont do things simply because they're told - even at work. And places that try to paper over workflow and process problems with code end up with a swamp of terrible process and terrible software trying to enforce those processes and everyone ends up doing the wrong thing, or working around stuff, or gaming the system. I take all of that into account. I don't believe I can engineer people's behavior - so, instead I insist that everything I build be useful in the moment, so people are incentivized to do the right thing. Over a 15 year career I'll tell you that I've never found a situation where this approach couldn't be implemented. People always tell me that sometimes you have to make crap software that just fills some process need - but I've always found a better solution. I've always worked to look for the root of the problem and address that. I believe that this approach has been why I do OK in this field even though I don't work overtime, code on my off time, or keep up with the kids.