When i was directly managing developers (now I manage dev managers), I always loved it when someone would talk about their expectations and targets. As a manager, there are usually many areas or topics that could be going in a better direction. and someone who is more engaged because they want to earn a higher salary in exchange for taking responsibility in some area of the team is a huge asset. If someone wants to earn a higher salary in exchange for taking more direct accountability for our outcomes (which can be in an IC or lead capacity), there's usually plenty of opportunity in the typical team, if the manager can structure it right with the various stakeholders and budget authorities. Just wanted to say, don't hesitate to start the conversation with your manager. I know some probably don't handle it well but some do. What I'd recommend is, a conversation based on the question "what would I need to be bringing to this team to hit salary level X". if the manager doesn't come up with an answer to that, well you probably should be looking elsewhere. but it might be the shortest path to what you want especially if you like your current environment.

I agree with you, but that’s only part of the story.

There are two ways to make more money in software development. Either take on more responsibility and be a force multiplier or gain skills/experience where the demand outstrips the supply.

During the first part of your career. Gaining experience to make more money without taking more responsibility is pretty easy. After that, you really do have to take on more responsibility or go into consultancy.

you're right. also, there's a type of responsibility i'm hinting at here that's less formal, more like: "this person can handle tasks of complexity X and is willing to do what it takes to create a quality solution", that is the nuts and bolts to my mind of a successful and high functioning team.

That’s what happened to me. I left a job as the dev lead at a medium size company with a small development department to work at a small software company where so specifically negotiated not to be a team lead. I told my now manager that I could be a lot more effective working across teams as needed as an IC and just demonstrating and mentoring the team leads who I felt were much more qualified than I was to be a team lead. They knew the software stack and they were all much stronger on the front end than so was. They all needed help with infrastructure and process.

I make more now and have more influence using relationship and expert power than I ever did with the role power I had before - the three levers of power in an organization.

Do all dev managers that report to you -- initiate conversations with you about how to increase their salary?

didn't see this until just now - no, not all.

The problem with finding a new job, as a programmer, is that you'll have to read and become familiar with a new codebase. Most programmers I know love coding, but hate reading other people's code.

“Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. ...[Therefore,] making it easy to read makes it easier to write.”

― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

https://www.goodreads.com/quotes/835238-indeed-the-ratio-of-...

It certainly is true if you keep changing jobs all the time. :)

OK - so its quite clear then - you need to decide between getting a raise and staying in your comfort zone.

Even within the same organization - a raise would typically entail that you take on new or more responsibilities.

That’s… interesting. Stephen King advice for aspiring writers is to read a lot. I’s say same goes for developers. Even if you read a lousy code you can at least anslyse what makes it lousy and how can it be improved. Reading good code will reinforce the understanding what good code is and might give some ideas for the future. Hating reading other’s code is a sign if the still novice programmer. Imho, of course.

Reading code I perceive as "lousy" and sometimes stepping through it with a debugger has often been a great learning experience for me. Sometimes I even realize that I'm wrong, and "lousy" design decisions were actually chosen to solve some tricky problem. More often it was just written in a hurry, or written before more modern libraries were available, but reading it still helps me improve my brain's "pattern-matching engine" for next time I see something similar.

To expand on that, I really like this quote by William Faulkner, and I think it really extends nicely to coding as well:

“Read, read, read. Read everything -- trash, classics, good and bad, and see how they do it. Just like a carpenter who works as an apprentice and studies the master. Read! You'll absorb it. Then write. If it's good, you'll find out. If it's not, throw it out of the window.”

What area of software development are we talking about?

That a person functioning as a software engineer expects:

a) Not to need to read or understand other persons code

b) Not to need to learn how new codebases work

Sounds completely unprofessional and misguided based on my experience.

Especially if someone is looking for a raise. At least where I've work, the more senior engineers (i.e. the ones who have demonstrated that they should get higher pay) are the ones who are constantly evaluating new ideas and new architectures, reviewing other peoples code (in open-source, these people are committers, not just contributors), collaborating with other projects that integrate with ours, etc.

I get the point about everything being 100% new at a new job being more uncomfortable than the incremental newness you should constantly be experiencing. But still - if you do have a hard time justifying a raise, remember that you're asking the company to bet more money on your. Bet on yourself first, step outside your comfort zone a little, and try lead in a way you haven't much before.

It does and it is.

But the fact is that it's just much much easier to convert ideas to code than code to ideas. It's also much easier to convert ideas to English than English to ideas, so better documentation probably helps, but it still sucks. (E.g. consider reading any sizable IEEE standard. It's all there, carefully described, but it's still a lot of work to understand.)

So yeah, many people prefer writing code to reading code, me including.

And BTW this is one thing that my university didn't quite get right. They focused a whole lot on writing code, but not as much on reading. The latter of course proved to be much much more important in my daily job.

/diversion

Not being exposed to big unfamiliar codebases may be comfortable, but dealing with unfamiliar code is a skill you will most probably eventually need, as few jobs are eternal, and not practicing for years will make for a painful landing.

Is this a problem, or fundamental part of development at all but the newest of companies?

I wish I had done that. I would wait until the job sucked before looking for another. I foolishly thought loyalty in IT is rewarded. In some companies maybe, I just never found one. New guy would get the cool new projects. I would vote you up twice if I could.

As an addendum, I recommend you interview anyway. In this strong economy there is no risk. In a weak economy they might toss you since they know you are looking..

My finding has been the same. I got a match once. I would have been better off leaving to some place more promising. Early on in your career your current employer is almost invariably a dead end.

Advancement happens, but it's the exception not the rule. Strong organizational growth is a driver of the exceptions.

I seem to remember an article (or I did the math) that shows that it's financially best to pursue a new job in the tech industry every 2.5 years.

It's enough time to get value from meeting new peers and make valuable contributions that they will remember but not short enough that they will view you as someone who's continually job shopping.

About every 2.5 to three years sound about right. But that only works up to a certain point.

When does it stop working?

I've been jumping ship every 2-3 years, for the past 15 years, and it's been working out well for me.

As an individual contributor, there is a maximum amount companies are going to pay you based on the local market. A company in Dallas for instance isn’t going to pay you $200K as a software developer more than likely.

This is a good answer. Jumping ship frequently works very well until you hit the plateau for your local market. I don’t have the data in front of me but my job changes early in my career netted me raises of sometimes 50% but each subsequent one increased less on a percentage basis. My last job change was +0%. There is definitely an invisible ceiling in effect.