> Just hire devs who are great coders, great communicators, stubborn enough to push back against upper management, good hearted enough to sacrificed their own KPIs to focus on the success of their project, and masochistic enough to stick it out at an obviously poorly run project.

This is a pretty close description of the positions I find myself in as a dev and I don't think this combination of qualities makes me more hirable.

100% the same and I agree. getting fired and being worried that my next decision will get me fired has caused me all kinds of anxiety issues.

I recently decided that given my personality I'm not well suited to working as an employee for an employer and have gone solo. I don't want to feel like a victim to bad management or that my future and personal worth are tied to a single company as good/bad as they may be. I want my efforts properly remunerated, I want my reputation to speak for itself.

So while these traits may make you less hirable as an office worker, they may make you more hirable as an expensive contractor.

I feel the same way. I jumped ship once but didn't have enough savings to ride it out. Getting independent work without a track record was extremely difficult.

Looking back, I think most people going solo start as contractors and also diligently save at least a half year living expenses before hand.

I've begun saving but it's slow going and I'm getting impatient. I greatly enjoy the feeling of making my own destiny and having employees to care for, the idea doesn't scare me as much as it seems to bother most people.

In a position of leadership it's possible to build your own little utopia. It was a great feeling to build a bubble in a world that's usually shit, where a lucky few actually enjoyed their work and each other's company. Alas that opportunity has passed and it's nigh impossible to go from the job title developer to manager without climbing a ladder for years and brown-nosing.

Anyways, how do you recommend getting started? Like most career devs my company has me locked down with contracts so the usual advice of starting a side business isn't possible.

^^^ I reached exactly the same epiphany, if you can call it that, about 3 years ago now. It might change someday but I can't be an employee any more. I just can't. I can't tolerate the idea of having so much of my time sucked up on something that offers so relatively little in the way of return. And I cannot cede my future to management any more; I have to own responsibility for it because, honestly, there's only so much future left for me (or for any of us).

Also makes you a target for layoff rounds. The yes men are always safe. You should have your finances sorted out if you plan to stick to your principles.

It probably won't, because most of that isn't predictable (by the interviewer) at interview time. It could make you more valuable in your current job, though.

invaluable, but they won't kick me more money. I asked.

Find another employer. Then negotiate from strength.

Then, not invaluable. :-/

They fired my whole team except for me. They would rather have fired me too, I'm sure.

I get what you're saying though.

I wrote two mails yesterday which basically "push back against upper management", for a very good reason. At least that's what I think. Now I'm totally terrified about what will happen tomorrow. I have 4 kids and almost no money in the bank.

Don't 'push back'. That is the wrong terminology, and it's inherently confrontational.

Explain to your managers the range of outcomes and give them the power to make the decision with the best information you can provide them.

i.e. 'if we skip this bit, then quality will likely suffer, with these kinds of expected outcomes'.

Don't be dramatic or emotional, just try to give the best information you can.

Also have sympathy for them - money does not grow on trees - and basically balancing quality vs. time-to-market is a constant and difficult challenge.

This way - if they decided to 'rush' it - they know what the likely outcomes will be and the inherent outcomes.

If they are making the decision then the responsibility falls on them to the extent that you have provided them with thoughtful and realistic assessment.

Pretty much this. Sometimes pushing back is needed, but way more often "negotiation" is needed. It is unreasonable to expect managers to magically see into the development details, you have to explain, made plans transparent etc etc. When you do that you often (not always) find that requirements are negotiable and not equally important, e.g. it is possible to meet the deadline without sacrificing code quality. Oftentimes the compromise is possible - you wont get two week straight of refactoring, but they are ok with using 20% of development time for cleanups.

I have seen developers "push back for the right thing" in a way that basically amounted to angry emotional outburst over things manager did not understood. The dude thought he is pushing for the right thing, but everyone else thought he does not listen to their needs, refuses to follow the company vision of the product replacing it by his own. (They wanted simplest possible functionality and fast, he was constantly adding own requirements to "make it better". When the same person pushes for yet another refactoring, management does not trust him.)

The other thing to understand is that some experienced lead remembers teams that were given time, no deadlines and all the good stuff and then produced mess anyway, procrastinated and took long time to do it. I have seen that happen and I have also seen that ended in long wars over petty differences in style and opinions. Sometimes the mess is result of people doing something knew and thus bad decisions along the way. Code review alone wont solve that, because the reviewer may be the one forcing mistake on others.

You need to communicate in the way that will ensure the manager that he or she is not in the above situation.

There should be no need for 'wars' or even 'negotiation'.

It's the managers decision - not the developers, really.

The devs can lay out what can be done, and describe what the results will be if various paths are chosen.

'Skip the tests' - you get quality issues, but better schedule.

'Write perfect code' - you get quality, but it could take to long.

The old saying: 'fast' 'quality' or 'cheap' -> pick 2.

If your team is having problems because of bike-shedding over details, or messed up code - this is altogether another issue and needs to be addressed differently.

I think you're laying out what is absolutely the best approach.

If you're an employee it's sometimes hard to separate the company's interests from your own, so I sometimes do a mental exercise I call "playing consultant" - where it's purely my job to "consult".

I try to honestly describe the options, give my best recommendation and then whatever they choose is on them.

As long as you're tactful and willing to cede your argument if they don't come to see your side, there shouldn't be any reason to be terrified. If you act diplomatically and still have crazy bosses, might be good to find a different job if you can, or just not care and get your paycheck.

Unfortunately it is not that simple. Sometimes pushing back on the management is an indication of misalignment of priorities. It may not happen right away, but it can definitely limit your tenure.

I have been on both sides of this.

Surely not if you raise a point one time to get a sense of the waters. If the management doesn't like to hear opinions from subordinates, you could pick up that vibe and stop pushing back. It might require greater social and political tact than should be necessary, but no more than needed in normal life situations.

Granted, social IQ is on a scale just like analytical analytical IQ. It would be nice for engineers if we could be blunt and to the point in our communications and let rationality win, but people aren't like that.

I'm just arguing the other end of this, because I've sometimes seen engineers be abrasive while "technically correct", and then have it cause problems for them. Being pleasant in interactions is an important skill, and I feel like sometimes it gets disregarded.

Again,sometimes even with tact and diplomacy, your bosses can still be unreasonable, and that sucks.

In some companies this is respected more than people who just obey. I would potentially promote you and I know big corp execs who would too but could be that it is more common here.

The irony is that some of those qualities are probably more likely to get you fired rather than valued.

"It is difficult to get a man to understand something, when his salary depends upon his not understanding it!"

- Upton Sinclair

I've experienced this firsthand. Pushing for better development tooling and fixing problems instead of pushing features gets you a pink slip. Part of the reason I run my own shop now.

It turns out the people most involved in estimating don't like it when you say that most estimates don't deliver any value.

And this is in a climate where developers can often pick and choose their jobs. Imagine if code was more commodified?

"stubborn enough to push back against upper management"

Every conversation I've ever had with management about rewriting/refactoring has been fruitless. Now if I think it's necessary I just bake it into feature/bugfixing. The work takes ~20% longer which just means that features and bug-fixes take 20% longer to deliver.

That doesn't really get pushback, whereas asking for an extra week to do some cleanup work certainly does.