I asked my students how they felt about having AI teacher avatars and they had a lot of negative things to say. The one thing that stood out the most to me was "it's disrespectful".
When I was a dev working with my business-oriented business partner, I had to get used to sitting in meetings where we promised the client the world having no idea if I could accomplish it or not.
Made a lot more money than I could have on my own.
"Ray, when someone asks you if you're a god, you say 'YES'!!"
They did this to me when I was a technical director of a mid-sized engineering consultancy (aka, a sweat shop). I learned it on the fly when they had me go to a client meeting. They showed the slide deck of all of our credentials, and I was astonished that the sales engineer took the slide I sent them and increased all my years of experience by 25%. I asked them about it later, and they said don't worry about it, everybody does it.
It's unethical and it's wrong and I won't participate in it. I stopped working there.
The "fake it 'till you make it" is prevalent in consultancies, because effectively all of them do it, and their clients know it, and if they don't do it they get pushed out of deals. I too started my career at one of such consultancies, and failed faking it once or twice until I managed to "make it" (that is, getting close enough to my peers so the client tolerated me). It felt dishonest, but was invaluable for a fresh programmer without any formal experience, at all.
IMO sweatshops are a necessary part of the ecosystem, but only until you grow out of them.
This is often the advice given by senior folks and I think it is somewhat similar to say that you have to "lie a bit on your CV". Still, I always wonder what would I do if I make these big promises to clients/bosses/management and I fail to deliver. Wouldn't that be worse than having said "no, I won't be able to make it in time" from the beginning?
For context, I'm early in my career (3 YOE) and I don't deal with management that much yet (I'm still shielded by my tech lead and PM), so I'm always looking for advice on how to navigate these things. I really can't just say "YES, YES, YES" when I know *very well* that something won't be possible.
One hedge I always used to make was, "I think we have all the information we need for now. We'll get you an estimate within 3 business days."
And then I'd sit down and bust my ass trying to find out if it was feasible or not. :)
If it wasn't, we could always come back with a lesser approach and people seemed to be happy with that. ("It turns out Android doesn't widely support [feature x] so we recommend [feature y] instead.")
Exactly this. I'm in a situation where I have to tell a customer that we won't be able to do the thing that I've spent a long time investigating.
My answer won't be "no, we can't do it." It'll be a form of "we have to use this alternate method to get to the goal, how does that affect your budget?"
Well said, and on the flip side the strongest signal that your management sucks is their absurd sense of entitlement and inability to handle "no" correctly. Their lack of curiosity and ambition will cause the business to miss out on so many opportunities.
A naive junior shouldn't stump them, but it really does happen all the time. If all they have to do is ask what it takes to flip it to a "yes", the same information is communicated. The only thing ever truly at stake was someone's ego.
While there are certainly people who are rich enough and spoiled enough that they have probably never been meaningfully refused anything in their lives, that produces terrible people, and absolutely everyone needs to learn how to accept being told "no" when "no" is the correct answer (or a reasonable one).
One trick I learned: If you have the type of manager who doesn't like "No", then say "Yes", but continually keep him in the loop as the project progresses to failure.
If you're up front honest, they'll think you're being lazy - even if you have good reasons.
If you say "Yes", and then fail for all those reasons while providing regular reports, the manager views you as "Someone who is willing to do things".
They often don't care about your actual success/failure rate, but instead use your attitude as a proxy for the actual success/failure rate.
Also, as the project is moving to failure, he'll usually intercept with "OK, how about we changed the requirements to ...?"
If you asked for that change in the beginning, the same rationale as the above applies.
Internally, it’s important to understand that every ask should have a business goal associated with it. The thing being asked for is rarely (never?) the only way to accomplish that goal.
Great engineers focus on the customer or business need and find/propose alternatives that are possible.
> and I think it is somewhat similar to say that you have to "lie a bit on your CV". [...] For context, I'm early in my career (3 YOE)
Please consider this input from my YOE battle scars:
1. Don't contradict your team while in a meeting with outsiders, but then you're obligated to follow up with your team offline, to try to mitigate any damage, and try to make sure it doesn't keep happening. For one example of why, I've seen one person consciously "mis-promise" things to customer, and when I talked with them offline about we couldn't be saying that, because it wasn't true, their response was "they won't remember". Narrator: "They did remember." And that's possibly why that person and a few others aren't very wealthy today.
2. Not everyone believes in "lie a bit on your CV" nor similar dishonesty. You'll probably meet colleagues, who you respect, who react to that with surprise and disappointment. You could also get fired for it, with cause. Especially if you're calling yourself an engineer, since determining and telling the truth is much of your job.
3. Though, on the other side of CV honesty, be careful about always using team-speak/think when in an interview context. Out of habit, you might naturally say "we" when talking about something you were instrumental in. But some people who think lots of people lie on their CV are going to hear that "we" as you generously including yourself in the accomplishments of others. I've started switching modes a little more for interviews, expressly claiming more credit, such as by saying unambiguously when I was the sole designer and implementer of something.
It took me years to notice that folks who confidently made stuff up or provided incorrect info in meetings were looked upon favorably. No one ever knew or cared that the thing the person said was incorrect. Just the confident way they said it.
Aside: start getting that exposure to management people now. You can book regular skip levels with your bosses boss and the PMs boss. Better than waiting until you get promoted and having to learn how to do it with a weight of expectation.
When everyone in a game is cheating, you will lose by playing fairly. And like other commenters have suggested - everyone expects similar behavior.
> For context, I'm early in my career (3 YOE) and I don't deal with management that much yet (I'm still shielded by my tech lead and PM), so I'm always looking for advice on how to navigate these things. I really can't just say "YES, YES, YES" when I know very well that something won't be possible.
It depends on a lot of things, like how big the company is, how critical the project, culture, management style, etc. - but you'd be surprised at what is actually possible that may sound impossible. I've had those "this is impossible" thoughts a lot early in my career and more often than not I was wrong. The few times I wasn't wrong, I made sure to highlight risks I saw at the outset, and when the risks materialized, point them out at the retrospective or whatever for CYA purposes.
The things you do want to avoid at all costs are death marches, impossible deadlines with consequences at the end of it, maintenance slogs which will tie you to a very annoying treadmill for your entire tenure - it's hard without experience to know where these things lie, but if all else fails, you can do what everyone else does, try the impossible thing, and either surprise yourself, or when it becomes clear it won't happen, toss it to some overly ambitious sucker (I don't condone this, I just have seen it happen far too often).
That's what I experienced early in my career, and then I independently discovered Rule 3: "Tell the truth to people who want to be lied to, and you'll go broke."
The key to surviving in such an environment is to let go of your ideas of the truth. The customer doesn't want to hear it, and doesn't want to know it. Deliver the lies that will make them happy and only those lies. The lies themselves are usually reasonably realistic; it's only when you combine them with your common-sense notions of truth that they become stressfully unrealistic. So give up your common sense and just deliver the lies the customer is asking for.
A less cynical way of putting this is to adopt the customer's frame of mind. The stress comes from the tension of your internal beliefs vs. the customer's internal beliefs; because they are coming from two different people, they are frequently incompatible. When you are working for a customer, you are working for a customer.
> The key to surviving in such an environment is to let go of your ideas of the truth. The customer doesn't want to hear it, and doesn't want to know it.
This is exactly it!
Like you might think "the promised features are not feasible." No, the features you will soon deliver are feasible, on account of you're about to go build them! If you fail, that is still very bad. But the point of rule 1 is you don't have to act like you signed up to deliver exactly X feature on exactly Y date. Instead you can think a little bit, and then you calmly set off on a process that should reasonably end up with the customer being happy. To many people this strategy feels like lying.
Yup, my breakdown was that I couldn't understand that the client doesn't actually care, they actually prefer to be lied to. Personally, I decided not to live in any system where either side is acting like this. Knowing the rules probably wouldn't have helped me, because I would've found the whole thing (and still do) disgusting and idiotic.
Not true at all. Even small, insular, just-a-few-hundred users PHPBB-style forums have to run Cloudflare or Anubis to try to stem DDoS-style scraping, and have a constant patrol of moderators to stop AI spam posts.
Not true. You can also make your code fast enough so your server doesn't get overloaded by three requests per second. Then you can just handle the requests.
No, fuck that. I'm not going to think twice about what I write just to avoid an AI checker, and I will delve into em dashes with gusto if that's what the writing calls for.
I'm not sacrificing the language simply to sound less like AI--that's absolutely a losing game.
And if anyone thinks my hand-crafted prose is AI-generated, they're free to look elsewhere. Right now AI detectors peg my pre-AI work as 30% AI-generated, and I'm certain that number will only increase as LLMs improve.
> I'm not going to think twice about what I write just to avoid an AI checker
It depends on your environment, I guess. If you're a student writing an essay or a researcher writing a paper, it's in your best interest to avoid sounding like an LLM, which means going out of your way to avoid certain idioms, even if it means letting go of things you liked to write.
I used to love a spaced en dash (the British English equivalent of the American unspaced em dash), but I wouldn't risk it now.
Many universal public systems (not all, see: Canada) effectively allow this through private plans and private providers that supplement the government benefits, often notably for speedier diagnostics and treatment.
reply