What are some B.S. tricks management pulls on naive developers?

Never believe a hiring manager who tells you they'll hire you at level X-1 and promote you to level X after some amount of time. Make sure you get hired at the level you deserve.

Never believe that money is the only thing you can negotiate at a company. Most benefits are negotiable; the only question is who is authorized to negotiate them. Vacation policies are often negotiable, if that's a thing you value.

"Don't talk about salary" (or other compensation) is a common unwritten policy. Note that it carefully isn't written down anywhere, it's just an unwritten expectation. That's because 1) it's illegal in many jurisdictions to prohibit discussing salary/compensation, and 2) it's often to the employees' benefit to discuss salary/compensation with each other, just not to the employer's benefit. (That doesn't mean you bring it up in unrelated conversations; it means it's completely reasonable to discuss and compare compensation when you're trying to figure out things like "am I being paid fairly" or "is this person I'm mentoring/advising being paid fairly".

This is what I observed in a couple of companies. The most amazing thing is that some developers think that all is fine, some even like it.

Set a deadline without asking the developers. Or ask them and ignore their estimates. Or ask them and ignore that they will know after some initial checks which will take two days ("nope, we must know the deadline now") - so it's basically just guessing.

Then the deadline is "set in stone". This means only that it's a good way to punish the developers. Then they are forced to work during weekends.

At the end they are punished with bad yearly reviews, decreased bonuses etc. Sometimes some are even fired.

Then the management just moves the deadline to another, equally stupid, term. Of course they will get the full bonus "you see, the developers are lazy, but we fired the worst one".

Then the cycle repeats. The most funny thing is when the deadline is for some internal stuff where the client is fully internal and really doesn't care if the product will be this month or the next one.

It's not always a trick; sometimes it's quite sincere. My first boss as a programmer hired me because he tried to write the app himself and discovered that there were more efficient uses of his talents. However he did learn some important lessons that he passed on to me:

1. instead of giving full word names to variables, it is more efficient to just name the first one `a`, and the second one `b`, and then on the second pass through the alphabet `a1`, third pass `a2`, etc. He couldn't understand why I didn't re-use his old code written with this scheme or why I didn't adopt it going forward.

2. It is far more efficient to simply not write the bugs, as opposed to wasting so much time debugging them.

Thanks for the education Frank, I did learn a lot from you.

"We believe in work/life balance" ...or the closely related... "We reward quality, not just last minute heroics.

Yeah, right. I'm at employer #12 right now (30+ years in the business) and this has never been true. I've been at startups and big companies, I've built products and services, I've been on the good side and the bad side of this, but it has never been true. Cases where people are rewarded for doing the right thing and avoiding crises are rare. Far more often the rewards go to the people who grind out tons of feature code regardless of quality, and/or to those who pull all-nighters to debug those avoidable problems after they've already bitten a user.

If you're the kind of developer who wants to do The Right Thing, and you want to be rewarded for it, find a company and/or manager who has demonstrably done that. Do as much of it as you can, but don't rely on it to drive raises/promotions. Make sure you also do enough of the "move fast" BS so that you don't get written off before people even think to look at quality or team contributions to decide between you and the person in the next cube.

I worked at a startup that would only hire SWEs who did a 3 month internship first. The startup would not disclose the post internship salary.

Of course, the post internship salary offers were significantly below market rates. Many would accept the offers anyways because they had invested time and energy into the company.

The lesson is to never enter into a contract without full knowledge of it's consequences and how it will play out.

If you can just work overtime, and hit this deadline, then things will let up, and we won't do this ever again. :D

It took me a few rounds to detect this trick. I had a boss who would pick up on clues from upper management on where they may be headed. He would come back to our team, and throw everyone at a problem. "This is a priority for management.", he'd tell us. We'd solve the problem. About half the time, the solution would die right there, because management never requested it.

What he was actually doing was trying to guess what upper management wanted before they requested it. This way, when the request did come through, he'd have the solution on the spot. It made him look great. It wasted about half our team's time. One thing it did do for us is give us more experience in solving new problems, but at the expense of getting our day-to-day work done on time.

But I did get to the point of not being so eager to jump on his "call to action" meetings unless I had outside verification that it was an actual call to action by management.

He ended up being the head guy in charge of IT.

Management's idea of who "top performers" are tends to get skewed towards sycophantic or dishonest people, vs. the type that quietly gets the work done and doesn't care much about credit. But multiple times I have heard assurances, not to worry, they know who is really getting things done, and they know who is BSing them. When they say this, they never do.

I like Patrick Lencioni's definition of politics on The Five Dysfunctions of a Team:

> Politics is when people choose their words and actions based on how they want others to react rather than based on what they really think.

To know what others think and desire requires empathy. To counter B.S you have to do 2 things. Get to know yourself to create a carapace based on values that protects you, and get to know others, so you know the true reason why they want something from you. When these don't match (or don't match the proclaimed company values), this is the definition of B.S

If your values, their values and the company values match, then we can hardly call it B.S - and don't forget changing values and raising from naiveté is part of growth. It's ok to feel today you "gotta give 110%" then later realize this doesn't align with your life moment.

Anything related to the "culture" of the workplace. The higher ups are raking in tons of money. That's it. That's why they are doing what they do. "Culture" is to keep the workers entertained while the execs scoop up all the cash.

Scrum, which is "Agile" repackaged in a way that's in favor of management at the expense of engineers and the work they're doing and, ultimately, the stakeholders.

Here, have some equity instead of cash. When the company succeeds, you'll be rich!

Being a programmer is first being a human and second being one who writes code. Everything is politics. Everything is marketing and influence and leverage. The quicker you realize this and build these strengths, the more successful you’ll be at engineering and all other endeavors in life.

Programmers are often surprised by this. “But I just want to write code” – that’s just a very tiny piece of the puzzle.

1. Refusal to accept that task estimates are subject to change.

2. Managing people purely for their outputs; not as individuals with lives, career goals, interests, strengths, weaknesses.

3. Insisting on process but not participating. E.g. scrums with no management present.

- Hold a review for the customer. Insist that the story be simple and completely positive, to the point of lying. Terminate with extreme prejudice all references to "challenges", "complexity", or "risk" on the review slides.

- Convince the engineers presenting the slides that you actually understand the challenges and complexities of the job. Make handshake agreements that none of this will be forgotten internally. Say "We just need a simple story to get through the review hoop."

- Six months later, forget that any handshake agreement took place or indeed that anyone objected to the simple, straightforward, fallacious story presented in the review. The slides, after all, are the only thing written down. Insist that the engineers never conveyed any challenges to you. Blame them for delays, overruns, and missing features.

My lesson learned: never, ever sign your name to a fictional budget, schedule, or risk summary.

I've rarely had any of that. Mainly I get pervasive bad management from poor but well-meaning managers.

Only thing I can think of is a long time ago being told if you hit this deadline here's £X thousand pound bonus for the team. We hit the deadline, they made me redundant next day and told me I wouldn't be getting my share because "you should have got it in writing"[0]

I took them to court and won eventually. Good fun.

[0] Which was a) true but b) plain nasty. Worth repeating at this point, the 3 laws of contracting:

1. Get it in writing

2. Get it in writing

3. Get it in writing

General employment tricks:

- Asking you your current pay. Not answering when you ask them their budget. A good answer is to discuss the other offers you have on the table.

- Getting private info by asking you to correct something false. "So you made 80,000" will get an answer better than "How much were you paid?"

- Repeatedly asking you the same question because they don't trust you and have read they'll "get the real answer" if they ask three times.

This is the wrong question.

If you feel like management and politics are making you not trust the company, you should find another job, especially in this environment with plentiful jobs. If we suffer some sort of recession in the next couple of years, we need to hunker down in a good company that takes care of their employees.

"I worked hard to get you this token raise."

"Work hard and the promotion come. Eventually."

"You'll be a paper millionaire at IPO time."

"This bug needs to be fixed before you go home."

Any time management uses the phrase 'other duties and responsibilities,' and anytime management is suddenly willing to implement an idea they previously fought against.

A few days after switching roles and organizations within the company from regular system admin work to my first real development job, my old boss realized they were completely unprepared to continue without me. Due to the overall importance of my former customer to the company as a whole I was horse traded among senior management back to my old organization and role on a part time basis under the 'other duties and responsibilities' clause of my employment contract.

Prior to switching roles I made the case that the company should back-fill my position due to overall workload, the likelihood for burnout among my old teammates, impact to customer, etc (the original intention was to drop the role via attrition). I knew that something was up when my old manager was all excited to tell me that the company took my suggestions seriously.

As for how I dealt with it - unfortunately I bent over and took it. I have a myriad of reasons as to why, but the most salient is I feel I need the development experience and don't think I'd be able to find job elsewhere just yet. This has definitely accelerated my overall plans to leave the company entirely, but in the meantime I'm trying to milk all the experience I can from my new role and am preparing to quit at the earliest possible moment.

The silver lining out of this is that my partner, family, and friends have all been incredibly supportive. Additionally the team lead on my new team understands the situation I'm in and is trying very hard to present me opportunities to grow and expand my skill set even though I intend to leave the company in the future.

"We don't have a training budget right now, for you anyway, but that will change next year."

I dont consider anything bs unless its about money or equivalent. I Dont say anything at first or something like 'I think about it'. Think about My response, and finally Ask on something around these lines: "So your suggestion is X? And it would, unfairly, cause me Y?"

You need to understand the underlying dynamics of the modern corporation.

Each one is structured differently, but they have general similarities. It takes some time and study, though. One of the best lenses I have found to view the corporation is 'The Gervais Principle'[0], now about 10 years young. Rao uses 'The Office' to illustrate the dynamics of the modern corporation.

Broadly speaking: Sociopaths, in their own best interests, knowingly promote over-performing Losers into Clueless middle-management, groom under-performing Losers into Sociopaths, and leave the average bare-minimum-effort Losers to fend for themselves.

One of the key lenses is the idea of 'talk' and how people in a corporation talk to each other. Specifically, the 'power talk' of how the sociopaths talk with each other, and 'the 'posture talk' of the clueless to the losers.

Your question is about 'posture talk', how to deal with it, and how to 'baby talk' to your Clueless managers. The answer is to pull a Ryan and turn into one of the Sociopaths, not one of the Clueless.

Though it is only one lens, and one that is ~10 years old now, the 'Gervais Principle' is a valuable resource and mental model for viewing the modern corporation and may help you in understanding the kinematics that underly what is going on with your managers.

[0] https://www.ribbonfarm.com/the-gervais-principle/

Unilaterally setting unreasonable deadlines in order get engineers to "work harder".

Two questions I always ask a team: Do programmers on the team interact with users of their software directly and what are the technical chops of the leadership in charge of engineering.

Technical chops: do they engage in the wider software engineering community, what projects have they worked on, do they publish papers, give presentations, do they have a body of work, etc.

If the answer to the first is no and the answer to the second is difficult to find out then I don't even need to work with the team for a while to know there is going to be dysfunction. It tells me that this is an ego-driven team, inexperienced and politics will play a huge part in getting work done.

If the answer to the first is yes and the answer to the second is still difficult to find there's going to be some bullshit. You will have a toehold to fight against it because you can get the data you need from your users.

The answer can be no on the first one and the leadership can come from a good history of delivering good work. There is a range of bullshit here. You can still have ego driven development with a lot of bullshit. If you can't talk to your customers it's hard to know whether your leadership is bullshitting or not. However if you have done your research on leadership and trust them then there can be minimal amounts of bullshit.

If the answer to the first is yes and the leadership has a strong background and is well known then go work on that team. This is going to be a great team with almost zero bullshit. This combination is extremely rare but wonderful when you encounter it.

How I deal with bullshit -- get a therapist if you can afford it, group sessions if you're strapped, or start a group with local people to vent and get support. Burnout happens when you can't escape an environment that puts a lot of stress on you and you feel like you cannot control it. You might need to deal with the bullshit because you need the job to support people who depend on you. You can't deal with burnout by believing in yourself. Get a support system.

Bullshit is everywhere. It's often not because you are smarter than everyone else and can see it. It is often because you can't see everything going on and nobody can read your mind either. Bullshit happens when well-meaning people with insecurities are trying to meet unrealistic expectations (whether self-inflicted or social doesn't seem to matter). The best way to not spread bullshit is to leave your ego at the door. Seek teams that minimize bullshit and don't put unrealistic expectations on people.

- working on project A - jumping into unplanned tasks because of an emergency in project B - PM whose managing both gets mad at you because project A is gonna delay

Making me feel guilty because I save our ass? Time to update my resume

Manager: When can you have this task done?

Employee: I'll shoot for .

Mgr: Why can't we do ?

This was common in my team meetings at my last company. The boss was an asshole in general. He would always reframe things to put tons of pressure on you to get things done in unreasonable timelines, but he insisted this was normal and the onus is now on you to explain why we can't get this done in a "normal" timeframe. In front of the rest of the team.

Needless to say, if you're shy (or too nice), you'll buckle and try to get it done, and work yourself too hard.

I've been ploy several times to the "Mr. Jorkins" effect: when you have several managers, an unpopular decision will be the brainchild of the manager you are not speak to at the time.

Anytime they say something like "Just do X now and we'll do Y in the future" where X is an idea you disagree with that will be a problem in the future, and Y is your proposed alternative to fix things now before they get out of hand.

Get ready to be fixing shit.

Boss asks 'When?', I say 'You can have it now or in 3 days when it works'. Boss decides NOW to hit his deadline. Not allowed to book any more time to it. Slagged of un-mercifully in testing. Thanks Boss. £50Bn business is run this way.

"I myself personally can't stand politics get in the way of work!" rather suggestive that they're thinking about it...a lot.

"why don't you be the team leader, but let's not tell anyone..."

Hmmm

1. You need to reskill! Future is about x y or z technology

2. You have already learnt x technology? We can move you of your current project manger can release you.

3. Sighs reskilling isn't working as per our expectation

In my company they sometimes change “estimates” to “commitments”.

flattering