In your experience, how can you smell the B.S from a mile away?
How do you deal with it?
Thank you
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".
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.
A slightly different scenario I see all the time, even today, is when a company takes on a fixed-cost job to build something. We come up with a basic MVP feature set, run it through the standard MoSCoW process, and then estimate how long each feature will take.
We end up with a final figure, and it's over budget. We strip things out, and it's still over budget. Rather than cut out features the client wants, estimates are cut down to fit the budget, or planning time is stripped out and we're expected to go straight into a build.
Funny enough, these projects always run over, and we always end up missing a ton of stuff the client wanted, because in the process of being lean we forgot to do any kind of documentation of changes, or to explicitly get in writing what the feature is supposed to do.
Things like these make me sometimes think that the whole business world is just a bunch of people lying to each other. Very depressing.
So you play safe and give them a super rough estimates and a lot of buffer.
And now all of sudden you are invited to meeting to explain your super rough estimates. You remind them that it is just a super rough estimate. They ignore that.
Now if you are weak, they will get you to cut your estimate. If you are strong they will ignore your rough estimate.
So they create a deadline based on your estimate. You remind them that it is just a rough estimate and deadline seems unfair. They tell you just do your best, deadline is not a super strict deadline.
Of course, project scope is bigger and there is scope creep. You are unlikely to make deadline.
All of sudden you are being asked why is project going to miss deadline. They tell you you did estimation, you need to meet this deadline. Work extra hours.
You try to remind them that you were asked for a super rough estimate but you are ignored.
Also your teammates hate you because they think you promised the deadline and now they have to work over weekend to cleanup your mess.
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.
Also contributing my part: a boss declining unit tests because they cost money. In the meantime, he's wondering how crucial bugs appear again and again and urges us to be more careful. It's always a relieve to leave those places :)
Debugging trains you to think about code. I think most of my programming skill comes from my open source project work where I didn't write tests initially. Now I can simulate code in my mind without having a computer in front of me. This is a really useful skill - You need to be under some kind of mental stress to learn this kind of skill.
When you don't have tests to rely on, your mind is forced to hold on to more details about different interralated parts of the code and over time, this mental stress trains you to hold a massive amount of detail in your mind and this helps you to write much better code. Also, being forced to hold a lot of code in your mind gives you a strong incentive to design clean simple architectures.
Writing bug-free code is not difficult for me now. Even on very complex distributed projects. I do write tests for my open source projects now but I do it at the end after everything is working. The purpose of tests for me now is just to lock down the code to prevent regressions. For some complex projects, I do TDD but I focus more on high level integration tests.
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.
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.
I even cancelled a night out with some friends, because "I really have to make this deadline"
Then it hit me, if as a competent developer I can't hit the deadline, it's because management added some extra work on top of our usual capacity, hoping we'll do whatever it takes to make it.
There's always more work to do. If they don't like me, they can fire me.
Nobody on their death bed said: I wish I spent more time at the office.
I was at a job were I figured this out. Management was a mess, scope was so fluid to be essentially non-existent, and it was always the devs fault. So I said "screw it", I work 40 hours and collect a pay check, and that will be the extent of this relationship.
Sure enough, about 8 months later I am let go out of the blue for "lack of productivity" and "failing to be a team player". The example cited? When we were asked to stay after hours to help the company move offices.
Unless its your company, the relationship should always be about the money. I am giving a skill for X amount of time. In return I an receiving $Y. Anything more or anything less either needs to be put in writing, or is effectively an unnecessary gift. Perhaps it may be one you want to give, but ultimately unnecessary. And anytime the company asks for more X without giving more Y, they are taking advantage of you.
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.
If someone can predict and deliver what a customer wants, before they want it, with a 50% hit rate, that is excellent.
What appears to be troublesome in the narrative is, "It made him look great." It would be far more encouraging to see, "It made our team look great!" I get the sense that perhaps this boss wasn't sharing success, both credit and reward, with the 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.
The challenge for new employees is to get a picture of the parts of culture they aren't advertising. The way the company evaluates employees, pursues transparency, treats people fairly, respects boundaries, Cares about customers, cares about quality, communicates internally, etc. are the parts of culture that matter, but they're hard to determine from the website
In a large company, most people _aren't_ making the big bucks and don't do it to make a fortune. They do it to make a living.
The "culture" of a place, especially at a bootstrapped startup where the higher ups _aren't_ raking in the big bucks is a huge draw to someone where money is not the main reason for taking a job.
For me, I'm paid well (probably 60th percentile for my location/position) but the flexibility I get from my employer which cultivates a nice culture and work-life balance is worth the cut in pay.
That said, if by culture you mean ping-pong tables, free beer and massages. I'm right with you.
In a large organization the people at the top are making an enormous amount of money.
My experience is that “culture” is for the people who won’t be getting rich from the company at some point.
I should add I don’t consider flexible work hours “culture”, that’s a real, concrete benefit. I’m talking about the organized fun and structured loyalty attempts management puts in place.
Came across a ton of those when first starting out.
Like, dude, am I supposed to live on the streets of San Francisco or Los Angeles just to work for some no-name startup? lol
Programmers are often surprised by this. “But I just want to write code” – that’s just a very tiny piece of the puzzle.
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.
PMs should probably be present during sprint planning for Scrum, but any level of management above PM really shouldn't be there.
I worked at this one place where, as much as I dislike Scrum, we had a pretty good pace going without upper management ever getting involved. Then the manager of our department(not an engineering manager) decided to show up to all our meetings because, shit, why not, and it completely cramped our style. They also began to dictate that we do things in a specific way even though our productivity was fine before. Fortunately, like most non-engineers, they lost interest after a month and almost never showed up again.
Granted, I have found at most of my jobs that management is absent when it usually counts. At one place we had a "demo day" as part of our Scrum process, but relevant parties in management almost never showed up. They would even claim they would show up but always came up with an excuse at the last minute. It wrecked everyone's confidence in them because a manager can't claim to say things like "product is key" and then fail to show up to product demos every single time. Yet demo was something our management wanted us to have.
That’s pretty common. Retrospectives are also only for devs, not for management.
- 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.
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
Edit: useful lesson though.
- 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.
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.
"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."
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.
Point is, having another role and being in the same company, you may reasonably expect some "support" for your old role. If you take this as failure of management, you can make demands from strength (of course in a diplomatic and understanding way).
At any time, dev work may make you miss deadlines, and where's that replacement?
Gets certified, no raise.
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.
This is the Old Men's Club, currently undergoing demolishment.
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.
Making me feel guilty because I save our ass? Time to update my resume
Employee: I'll shoot for <day>.
Mgr: Why can't we do <day-2>?
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.
Get ready to be fixing shit.
"why don't you be the team leader, but let's not tell anyone..."
Hmmm
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