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.
Most bad management practices boil down to answers to the question, "how can you manage people you don't trust when they're doing work you don't understand?" Of course if you've reached that point, the grevious mistakes have already been made.
It’s depressing to think about the whole industry operating like this. Other than being very flexible on where you work and moving soon as the BS train picks up steam - any other tips to survive?
As someone that has spent years in consultancies and agencies, this one stings a lot.
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.
I worked for a company that would do this exactly, with an additional variable. The sales folks' bonuses were based on the original estimate, not any overruns. So they'd promise the customer a certain feature set then, write up the minimum feasible estimate, collect their bonuses, then blame engineering for the extra cost, feature creep, etc... when it was all by design.
I worked with a non-technical manager (banking background, somehow wormed his way into managing development) who never asked devs what they thought a task would take. I finally convinced him that this could not possibly work. I sat with him the first time he asked a dev how long the current task would take. The dev said "4 weeks". This guy said "I think it should take 2, so that is what I am putting in the schedule". Mind you, this guy had never written a line of code and had NO basis for his "thought" on the task length.
Another trick management plays is they will ask you for super rough estimates. And tell you that whatever estimate you give doesn't mean anything.
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.
It took me like four years working in a consulting agency to finally realize that I should refuse to give any estimates when I couldn't be pretty close to certain of the accuracy.
Equally bad, ask inexperienced developers to come up with schedule estimates, then insist that they be held accountable to those laughably inaccurate estimates.
We have a new trick too, every task in the backlog is estimated as 1 day worth of work. Most of the times those tasks take 3-4 days tops,
Even when we say otherwise, they still force the 1 day story rule...
[The common definition of estimate is] "the most optimistic prediction that has a non-zero probability of coming true." ... Accepting this definition leads irrevocably toward a method called what's-the-earliest-date-by-which-you-can't-prove-you-won't-be-finished estimating.
-- Tom DeMarco
---- as quoted in the book, "Software Estimation" by Steve McConnell.
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.
I have a feeling I know why he hired you instead of writing it himself...
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 :)
This mindset of "you don't need tests, just don't write bugs" sounds extremely naive and amateurish at first but having worked at many different kinds of large and small tech companies around the world for over a decade, I now think that there is actually real wisdom behind that mindset and I've met some very talented engineers who share that thinking to various extents.
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.
If you are out of the loop because you didn't work on a project for half a year or even are completely new to a project, this approach seems pretty impossible for myself. At least with the dynamics I had at the job described above (which included lots of project rotation among devs). I'm sure there are fitting settings where this approach might work, though.
It's strange to see these two points mentioned. One of the great programmers I worked with always used mostly two character variable names and rarely produced bugs. His title was Chief Scientist.
Ah yes. There is a strong correlation between the amount of code you write and the number of bugs you produce. Typing fewer characters means writing "less" code code thus fewer bugs. But a larger factor is that the shorter and more cryptic you write variables names, the less you will be asked to keep writing code, thus you will produce fewer bugs. To produce the fewest number of bugs, write less code.
"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.
This right here. I remember one night, after 9 hours at work, I was gonna log back in to make some additional commits.
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.
> There's always more work to do. If they don't like me, they can fire me.
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.
Startups are typically awful for this because the business is the founder's baby and they can't understand why other people aren't willing to sacrifice as much as they are.
I've felt it first hand and in the exit interview the founder didn't even understand I wasn't in it for the stock options are they're vested after 3 years and no way he paid me enough to actually buy in.
Wow! Sorry about that. This must have hurt a lot. It's funny how sometimes it's all about appearances,
- Leaving slack on
- Taking your laptop home with you even if you don't work
- Randomly send message on the week-end.
I've not done it, but I've seen people do this
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.
It has taken me a long time to realize that at least half of the prose I write, when writing a scientific paper, will be thrown away. Trouble is, until the full document takes shape, I never know which half.
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.
Haha exactly, most of that comment looked like a glowing praise of that manager honestly! A rising tide should lift all boats - would be nice if GP posted whether the team also got any credits and rewards for being the LITERAL definition of Innovative Risk Takers!
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.
Im sure this has happened, but It isn't my experience. Oftentimes companies want to make their employees happy bc they know it helps retention and hiring, and they want to be happy themselves. Culture is important and mentioning it isn't some cynical scam.
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 startup the founders may not currently be making a lot of money but they have a ton of equity that they hope will be worth a lot.
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.
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.
We have SAFe at our place for about a year now. I'd say there's a fair chance it will take over large enterprises fairly quickly. It's so process and management heavy that the people in charge will love it, and at the same time it claims to be agile so it's easier to push it down the throats of devs.
That's not just BS, it's straight up illegal in most jurisdictions (certainly California) if you'd be an employee rather than a contractor, as worker protections tend to include not only minimum pay but also timely pay requirements.
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.
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.
- 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:
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.
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.
If you were your manager, making your case. What would you say: Would you, in writing, enquire to know at what date you might expect to be relieved of your former duties? Who is provided for knowledge transfer?
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?
Good for you. You don't necessarily have to leave. Once you have some experience you can find another prospect and then deliver an ultimatum. You want dev work full time or you will quit. And mention that you already have another job lined up.
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.
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
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.
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.
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".