Value and opportunity are chaotic processes in effort and time.
All we can do is to try to maintain the levels of workload such that we have clarity of mind to seize opportunities when they reveal themselves. Honest and balanced colleagues help there, but that is ultimately a missions for yourself only.
which is why one should not self-sacrifice. It garners no reward for one. Secondly, if the boss doesn't realize how much of an enabler you are, then it's time to start looking for a new job before the layoffs even starts as a thought in the boss' head.
They eventually acquire enough experience to be able to produce something that sort-of works around the 3rd attempt.
But thanks to how good they are at communicating, are considered by management to be good engineers.
While doing a working project at the 1st try, without using this week's new framework and so on isn't as valued.
Unfortunately, this can cut the other way as well where you can have someone incompetent override competence or not even involved people further down which is common during large layoffs
This is in fact known in management literature: assign your best people to the least important project. That way the second best can grow to become the best, while the best are always free to help out if your fourth most important project has issues - it isn't a big deal if your least important project doesn't get done on time and if they manage to finish it so much the better. (your best are also free should sales discover a short window where a quick feature can bring in a large sale - though this is obviously easy to abuse)
Also, can you describe the problem? It sounds interesting.
The UI had options to check some categories and exclude others, this was mapped to sql with a nested query IN (…) and not in (…). I noticed that there were less than 64 categories and always will be so I figured pack the category membership into a 64bit ints and use bitwise operations. The UI query generation would map to use bitmasks instead. They didn’t even let me implement it, just agreed that it would work and took it from there. I think they were quite embarrassed by it. It ended up being 10K faster.
If they were ready to have you on for 6 months, You'd still probably be one of the most honest contractors if you stretched that out to a week, or even month. It's a shame honestly isn't always rewarded proportionately to suggesting an entire rework of their infrastructure.
Don't waste your time and clients money on pretending to do work that you don't. Its ethically wrong (maybe even criminal) and it sounds like you would be bored to death wasting your talent.
Don't blame the company for not wasting its money either. It did pay for the whole day and gave you good recommendations.
You could do fixed price. Or split the difference (on both sides of the estimate), which provides good incentives for both parties.
The hardest part of getting into contracting was the guilt of feeling "I'm charging too much for a simple fix!". If the fix was so simple and the client didn't find it in those six months then maybe your assumption that the fix was simple and obvious was incorrect. Regardless, your fix provided value, and you should be compensated for the value that you provided, not just the number of hours worked.
These bosses tend to be competent ICs who became team leads, they are best positioned to judge the ICs they manage because they themselves are masters at the craft.
"learn how to be better at self promotion"
Do you have another solution to this issue?
1.) Create a spreadsheet with all of the features of your group's/company's products(s) listed in rows.
2.) Create a column for every team member in the group and highlight the lead developers for each feature.
3.) Then ask each team member to add a checkmark in their column for every feature for which they would be willing to be on hook for 24x7 triage pager duty.
Over the long term - the most valuable contributor(s) on the team will be the one(s) with the most checkmarks next to the features they led development on (i.e. they write understandable code and document well) combined with the most checkmarked rows in their column (i.e. they proactively seek to understand other peoples codebases).
What if the table in fact shows which people are best at dodging the hard work
Combined with showing who has the most friends in the office (giving checkmarks to features built by one's friends)
This is kinda a well known phenomena in medicine[0]. Same with lawyers. I'm just reminded of this scene from Silicon Valley[1]. It's messed up and why everyone needs to be very careful with metrics and remember that metrics are only guides, not targets.
[0] https://www.theguardian.com/society/2016/jan/29/doctors-avoi...
In general though even if some developers are gravitating to only projects that are simple/trivial, those wouldn't necessarily be differentiators because such projects would have checkmarks by other developers as well.
Also it can help to have the Product Management team rank the features in terms of strategic importance and criticality to the functioning of the company.
I'd say the biggest benefit of such a spreadsheet is to provide visibility to leadership about the bus factor of the team. Too often the critical projects are really only maintained by a few team members. There's no incentive for new team members to learn the "legacy" projects versus creating their own pet projec. Then the inevitable RIF or transition happens and the lack of long term support becomes an issue.
However, often leads just need something in order to know what you are doing, especially managers that don't really closely work together with their team. It can help to just mention it to your lead. Because it is easy to see what you done, but not how you have helped somebody. Just mention it in whatever recurrent meeting you have. And if helping out takes more time, I'd say it is only fair to have whoever is responsible for delivery involved in prioritization, because then it is at the detriment of whatever you are working on, which might be more important.
Often, it takes less than 15-30 minutes to help somebody get unstuck. I wouldn't enjoy working at a place where people would refuse to help me with something like that, or I would be so pressed to achieve things that I can't spare 30 minutes out of my day to help someone out.
Doing this effectively requires tact. Try to mostly bring up your silent efforts casually, and be judicious about how often and in what situation you mention it. If it gets interpreted as an "I told you so," an excuse, self-importance, etc, then it will probably do more harm than good in terms of your standing with others.
Might be helpful to some degree. But won't save you if your organization's culture simply doesn't value your work or more generally doesn't care about proactive, methodical improvements that have no flash or immediate payoff.
In the context of one's effort valuation it seem to be a very bad advice. Unfortunately.
So in small teams where visibility is clear those things are obvious.
It's in larger orgs where you want to climb the ladder that you get bonus points for the problems fixed but not those you prevented.
At a big company you should be able to turn that into a number - 'this kind of issue was costing us $X/quarter, and thanks to my work, it is now costing us $(X-N)/quarter, in line with my estimates.'
It's performance season so I've been giving a lot of thought to how you quantify and attribute impact especially for folks in lower-visibility roles.
Not every company is going to see it this way but that's kind of a truism. Not every company sees any one kind of impact the same way, and you have to think about that relative to your career goals. I think aligning with your manager at the start, quantifying your impact and showing your results is going to get you the recognition you deserve at any company worth working at.
The intelligent, optimistic and genuinely good, helpful people who don't learn this (or refuse to compromise their good nature) end up burning out, getting performance managed or with PTSD
Some people don't want to give up the job at High Status High Pay Corp. That's the trade-off they are choosing. (Not every HSHP Corp. has to be a bad place to work, however.)
Well thought and expressed. Thanks.
> numerous daily examples of people just trying to do the right thing
And most people reading HN can do that.
That's such good advice.
On the same note, it's so discouraging when someone who is not/neither takes over, those people leave (one way or another), and you have to start the search again.
Or when someone is intelligent enough you don't figure out they're not honest until it's too late. <shiver>
Anyone who's been around the block a time or two will accumulate those experiences. I hope I've not been jaded by mine.
> Work is with honest, intelligent people
Yes.
Very true, and it may not even be malicious on their end, just avoidance and their brain rationalizing/minimizing without them realizing it.
This is good advice that’s well intentioned, but (sorry), it can be interpreted as elitist, and in a way that’s detrimental to the reader.
I am no way suggesting that this is the intention or belief of the parent, but while I’ve got more miles on my odometer than I’d prefer, they’ve informed me that “reasonable” is better than “intelligent.”
My god how I’ve found that working with reasonable people is so much healthier, more productive and rewarding than working with the unreasonable* intelligent folks.
*I fully grant to my current and former colleagues, friends and associates that I have been irredeemably unreasonable any number of times. Consider this a small thanks :).
Being reasonable is part of being intelligent. Surrounding yourself with intelligent people doesn't necessarily mean "surround yourself with the highest IQ individuals you can find." (not saying you're saying that explicitly, just that i think you're just using a definition of intelligence that's narrower than the parent) Working well with others, understanding when one has made mistakes and being able to admit to it, understanding both the known unknowns and the unknown unknowns of a problem...these are a better mark of intelligence than a mensa membership.
Not in the slightest, those two are quite separate.
I happen to believe that reasonableness is part of being intelligent, by the following criteria:
1. when you are reasonable you do not make unreasonable demands that will just be troublesome and cause workflow issues because in the end they are unachievable.
2. a reasonable person will be able to determine what other people are capable of in given situations, and be able to structure things in such a way that other people can perform to best meet expectations.
3. the root of reasonable is reason, a reasonable person can be reasoned with because they possess the quality of reason, in most of the history of philosophy if you do not possess the ability to reason you are an idiot.
Moreover, being able to admit mistakes (specific thing mentioned by parent) is oftentimes detrimental for you. People who do not admit them are typically rewarded, people who easily admit them punished. So, what you are looking at is "ethics even if it does not benefits me".
Being reasonable, is being someone with a strong genuine value for collaboration. They actively advocate for and work with others to optimize situations taking everyone's needs into account. Encourage give and take, constructive debates, and appreciate feedback. Etc.
An intelligent person can be all those things. Or none of them - but manifest them enough that, with some spin, they seem reasonable, while actually optimizing the environment primarily for their own long term benefit.
Very intelligent unreasonable people are disasters to work with.
> it can be interpreted as elitist
If "intelligent" is taken as 'naturally superior intelligence', then I can see what you mean (and I think that idea is a egomaniacal delusion). What I mean is people who choose to act intelligently; that's quite democratic.
It’s life goals to be smart, kind, and down to earth. It really comes from a LOT of experience though.
There's nothing wrong with elitism as long as it leads to initiation rather than gatekeeping.
> My god how I’ve found that working with reasonable people is so much healthier.
Could not agree more. Most people can be trained well to do any job required of them. What cannot be trained, and certainly at the behest of the employer is interpersonal skills.
The one situation where I would prefer someone who is intelligent at the expense of being personable is if I intended to hire 2-3 absolute weapons to be the core of a startup.
I think that those can be trained as well. The fact is that just acknowledging the issue requires a level of self-awareness that not everyone has, and training THAT as well requires being aware of it. External input and help from a specialist or a dear friend can get the ball rolling.
I really wish this were true, but especially in programming I don’t think this is the case.
I’ve spent years as a programming teacher. Some of my students have been among the most wonderful, enthusiastic, hard working students you can find. And yet, despite both of us working hard for a year or more, some never develop any talent whatsoever for programming. Statements like “everyone can code” can easily turn into a rod for their backs. - “Therefore if I’m not succeeding like many of the other students, it must be because I’m not trying hard enough, or there’s something wrong with me”. I don’t think this is anyone’s fault. Perpetuating the lie that all our brains have an equal capacity to program is a terribly cruel injustice. Some students would be much better served by finding another career that they can excel at. The faster they figure this out, the better.
Programming isn’t for everyone. It’s hard. Not everyone has the same capacity for it. I believe accepting that is an act of kindness.
I should have made my prior assumptions clear. The "most people" I'm referring to are CS graduates or people with IT diplomas and the percentage among those who are trainable to a capacity of competence in most companies are roughly 70%.
> Perpetuating the lie that all our brains have an equal capacity to program is a terribly cruel injustice. Some students would be much better served by finding another career that they can excel at.
When I was still a uni student I used to be a CS tutor in a help desk setting and I especially remember one guy who used to come in a lot. He had a really great attitude despite being humbled by the fundamentals. He used to repeat to me: "Sometimes you have to ask for help when you need it." After that semester I didn't see him again. I also remember a particularly annoying guy who used to come in and waste my time and the other tutor's by bringing in a problem and then solving it himself within seconds of sitting down just so he could talk about how he solved it and how much he knew. The world is not a fair place.
Yep. Those two stories are in some amount of conflict. I agree that anyone who has passed a decent hiring bar can be trained to some baseline level of competence. But the difference in capacity between that baseline level and someone brilliant can be huge. And it matters. This is the difference between something being an ongoing issue for the team for months, and it just quietly never seeming like it was ever a problem in the first place. As you say, it’s totally unfair.
People known for being purely highly intelligent people often think they know it all and are often a net drain.
Both honesty/reasonableness and intelligence are required. A family memebr is tearing her hair out about having to work with some assistants who are honest, well-intentioned, and pleasant, but who are just mentally incapable of keeping things straight — they literally screw things up and make more disorganization than they fix (fortunately, better help is supposedly on the way).
Overall, in hiring and working with people, most of the time, a warm body is definitely NOT better than nobody.
I'll let you know when I find this communist utopia.
If you start micro-optimizing - especially on other people, whose behaviour you can rarely change. It may leave you with lots of frustration and completely missing the grand picture.
I've personally been fortunate to have been able to form a network of a bunch of different well-connected folks so I can always choose who I get to work with in the event that companies shut down or get acquired or such and such. I feel the value of such a network does not get touted often enough.
Finally, I accepted the solution was long-term. I made a long-term plan - to do what I really loved - and focused my attention on that, and slowly built up the resources, skills, etc. for that plan. One wonderful side effect was that the dead-end part diminished in my mind; sure, I still had to do it, it still sucked and there were some awful days, but it would pass. I didn't matter so much; those people didn't matter; it was like one of those movies where the kid knows that someday they will leave the depressing, dead-end town they are stuck in today.
I hope that helps a little in your situation! Good luck!
Not too many of them around, are there? You can have either honesty or intelligence but not both.
And great engineers are consistently good at this type of passive, keeping the lights on work, but it does not reflect on their quantifiable work, so orgs do not include this in performance reviews. It is up to your manager to recognize this and advocate for you.
Especially with many organizations focused on data or metrics for performance reviews or promotions being able to say you fixed an outage that was costing $X million per hour comes across much better than a vague counterfactual notion that your high code quality prevented Y such outages in the first place.
Up until that point I knew my value but I don’t think anyone else quite got it.
If your solutions tend to be more stable from the get-go, it will get noticed at most places. There are always going to be that odd company where that's not true, but in my experience, simply doing higher quality work gets appreciated.
Your value will emerge with time.
Just keep calm and carry on.
Good and bad times will do their usual sinusoidal dance but your slope will be pointing up if you zoom out.
There will be unfair promotions outside of your team, reductions or freezes in yours (companies have tendency to throw people at problems = inflate dysfunctional parts; if you have well performing team - they won’t let you grow short term; just wait it out, they will eventually).
The psychology of workplace is quite subtle and almost backward. There's a motto "squeaky wheel gets the grease" .. to the point I'm thinking of trying some games. Like designers who produce crappy options and one good to toy with higher ups thinking they decide. There are some ideas in that vein so you flip the relationship and benefit from it instead of bleeding.
If you are an IC, you play it up with the right people. Those right people fight for you instead of the other way around. When the “we need to cut the fat” talks come around, suddenly you are not on the chopping block. But that also assumes the people fighting for you are not on the chopping block.
Soft skills across the industry is highly under valued. Knowing when to pick a fight or hold your tongue is also important (ie, reading the room).
I hate it but you got to do what you got to do to get that cheddar
You can phrase it as "I help teams deliver on time by making sure they don't get stuck." Or "I increase a team's velocity by preventing mistakes that stop work."
It's how you sell yourself and then, how you tell the story of what happened. Being able to tell a compelling story is important.
It is easy enough to 'measure', a good lead would value how you benefit the team and enhance your co-workers productivity and seek to understand this part of your contribution. He or she could just ask your peers, it is not science.
If this does not apply to your situation at all, then leave because no amount of evidence will ever force your superiors to accept it, it will only antagonize them. You do need to make your case sometimes, but the level of proof should not be that high, you need some trust in order to function as an org even if it is exploited sometimes.
Having a boss that loves to sell his team's work to his boss also works wonders.
In the end people ended up simply inflating the value of stories.
In my previous team I had to argue with a person that 2 story points to add translation keys were ridiculous.
To which the EM argued that 2 was okay because he also needed to write few accompanying tests.
I have nightmares thinking about this stuff. It was literally quicker to add the translation keys and that pointless test than to even discuss and vote the story and debate the points..
And large companies will probably never learn, because at some critical mass it becomes less important to ship than it does to tell people how cool the product you want to ship is. Devs don't get paid for shipping outside of a short surge of stocks (which they proceed to not be able to take advantadge of because potential insider trading). Heck, some industries just let you go after you ship.
If you don’t have such a manager, perhaps find them. Or become them.
However it is clear that noone is improving and that the process IS me.
What I've been trying to do is make sure that my scope and role is fully clarified, and any "extra" activity that I perform is documented and flagged. Anything that becomes a "common" activity implies a missing part of the process - be it a role that is missing, or a skillset that is lacking.
Before you start thinking that it is pretentious or self serving, it's perhaps the opposite - you owe it to the process and the team/business/organisation to make them see what you're putting in, else they fail to find the gap.
It's not paid off yet, but hopefully it will yield results within the next 6 months.
One piece of advice, I found myself this person once - it’s the road to burn out city to be the critical path answer to everyone on the team’s challenges. You sound like someone who is very generous with your time and support. In my experience once people have found a critical path there is no point at which they “stop.” This isn’t because they’re trying to hurt you, they’ve just found the answer so to them it doesn’t seem wrong.
It will take even more of your time, but you ought to consider practicing giving less answers and asking more questions of those who seek your help to try to help them unpack the issues themselves. It will feel more tiring at first, but you’ll gradually help the others learn and also create a small bit of friction that will encourage them to try their own solution or two before seeking you.
Management asks are separate/ they can actually reward you with compensation and promotions for this extra work. But the team asking for help won’t stop when you get more comp unless you start teaching that you’re not the answer.
Well, a problem that hasn't happened yet is a risk, right? So you can apply risk assessment math to it:
Value = Estimated risk of the problem occurring * Cost if it happens
Good leaders. Or, worse: Consultants. That is, it takes either an outsider or a self-critical leader to affect change? Those doing the planning are always optimistic [0] about their decisions, processes, evaluations, and progress. https://en.wikipedia.org/wiki/Planning_fallacy
[0] not always bad: https://en.wikipedia.org/wiki/Hiding_hand_principle
The opposite is the lemons market. It is why getting some wet building work done that is actually waterproof is a fucking dark art. Even the pros hiring pros get fucked because the “is waterproof” part is invisible.
Agree with your point, solving problems gets you points, avoiding them doesn't. My cynical view of the headline is, that a lot of people do get credit for solving problems that never really existed, simply either fabricating (intentionally or not) easy to solve problems or vastly overblowing problems they just happen to have a "solution" for.
If ypu successfully fight a fire, you are a hero, if you prevent fires it is just normal and nothing special.
Assuming you are doing other things make sure that is visible.
Also why did your colleague wait 3 months to ask you for help? A couple days would be OK, a month would be crazy. You should poll them and not wait for an interrupt.
A Sr eng who spends 6 months coaching a junior engineer has much lower value/hour.
A mature organization respects the process that prevents getting stuck for 3 months. But… they may be more stable and less nimble. Boring orgs don’t like heroes.
Think that it is the management's fault if they misjudge you. They have the chance to judge you correctly, yet they misjudge you. Their fault entirely.
The above seems to be how the top billing agencies on Upwork function, with fewer staff you can grift more people because the hours being billed aren't honest, and so you can have more clients and reach the "top" earnings position faster and more easily; with the same practices existing at least on one of the two prior platforms before oDesk and Elance merged.
Of course it doesn’t change anything about the people that work there, but the people at the top now clearly have a better idea of how it works than the last ones :P
What you do though is, you leave a very obscure edge case unhandled, make note of it, then just don't tell anyone. Invariably someone will hit it exactly one day before you're scheduled to go live. Then just apply the fix (make sure to procrastinate long enough to simulate working on it) and voila! The longest I've seen an edge case go unfixed in this manner has been three years.
Though truth be told I'm not smart enough to add bugs on purpose, I just sometimes notice I've failed to address an edge case and ... leave it. If it turns out to be important - I can fix it when the fix's value is maximum. Half my day is spent fixing others' unhandled edge cases, so it's nice to have one tucked away for a rainy day that you know you can fix easily.
Is the problem the incentive itself, eg. if they didn't reward fixed bugs would you write better (even just better communicated) code?
However, I’ve also had managers who pushed back against nice-to-have cleanups as the product matured (especially close to a release). They had cause as the product became overly complex, where issues were tedious to root cause and fix.
I tended to queue up a lot of improvements and then unleash them at the beginning of a release cycle.
Later QA would find a problem in the previous release but couldn’t reproduce in the later one… because I had already fixed it.
I didn’t introduce bugs intentionally, and the fixes were visible as we had to backport them for point releases, etc.
Moral points don’t pay my mortgage.
The company that makes it also has a generator they use when they're contracted to make more code in their awful language. It's bad, the code has to be manually cleaned up and sometimes is delivered broken. Then they get the money on the support contract to fix their problems. (It's not their only product/service, but it's key to many of their services, a way of hooking customers.)
Their generator did not using the looping constructs, and several of their "senior" engineers actively discouraged it because "You can't be sure a loop will do what you want it to do." (Wish that weren't an actual quote.)
From my limited experience with "proprietary bullshit languages that only exist to hook customers", there's ways to mess up how loops work in the language. So maybe those senior engineers actually know what they're talking about.
I've seen "languages" that treat variables differently based on whether they have uppercase letters and underscores. Before I saw this in action, I believed the seniors telling me to "never use uppercase letters ever" were insane...
Or. Dev hacks a fix up, sends to prod. Sees another bug and fixes immediately. No loss in revenue/customers/favorite vanity metric/whatever. Dev creates ticket to refactor/fix code properly and adds to next sprint. PM removes from next sprint to get capacity for further resume driven management projects. Issue crops up again due to hack. Original dev is now able to do ticket originally removed from sprint.
I have seen that this is one of the most efficient ways to advance your career especially in larger consultancy companies with hundreds or thousands of different customers.
Spend Q1 each crashing your respective project; spend Q2 as a fixer undoing that damage using his knowledge of his own work.
You’re both cutting edge and a proven fixer!
Tuco is a wanted man, Blondie brings him in and gets the reward money. Then just as Tuco is about to hang, Blondie shoots the rope and they both escape to another state ... where Tuco is also a wanted man.
Never point to the possible issues at the code reviews, retirement refinements etc.
Let your junior colleagues fail on a schedule within the margin of error on your planning, but keep a close enough eye on them so you know how to bail it out if they can’t pull it together with a little extra time/guidance.
Okay — still give good code reviews, but if you let them face-plant a little on design, etc, then they get experience. And you don’t look dumb when it turns out they were right. But you do look like a hero when they’re struggling to get across the line, and you whisk in to fix it.
In reality that I live, there is never enough time, if you have 3-4 team mates pumping features out, it is already impossible to prevent every problem and review every piece of code.
I don't have to be cynical about it, it just happens that issues will crop up over time and I am there to fix them and there is never enough time to prevent them up-front, because if you will try then you will never deliver anything. Ship fast and break things is maybe too far - but still shipping something beats not shipping ideal state.
Those 100 users took performance to a crawl but we never seen it earlier because it was never used that way in that capacity.
Frequently I end up having to do one more PR to get the tool to correct the exact problem the team experienced, so in practical terms is much less of a 'witholding' and more of a 'burning in' situation. But the final product does end up getting written in hours instead of days so while I don't get the credit I feel entitled to for foresight, I get mis-attributed with being able to solve difficult problems quickly.
Which is kinda true. I hate being caught flat footed so I'm always squirreling away fragments of a Plan C.
https://en.wikipedia.org/wiki/Time_bomb_(software)
Usually only works if you're the only dev, unless you get creative with counters like the original devs that made some nice cash fixing it all for y2k
(officially: don't do this)
I'm dumbfounded about all this, you spend years learning and reading books about the craft but the only topic which will matter is how you can con the game ?.. weird.
Much happier when I can fix something quickly because I have some tools or logic in the codebase already that lets me do something quickly by being covered with sanity checks so I can zip along without driving us off a cliff.
He's one of my favorite pranksters. But needless to say, the football team was not very good.
This only works in time limited sports though. Most real world situations are not time limited like that and so the advice doesn't apply.
This does work ok for long distance competitive running, since the factors at play are time and metabolic rate and is missing the strategy present in team based ball sports like football, soccer, basketball, etc.
I usually write my best code to show others it's possible to write good code and ship on time, with exceptions of course (and I usually document in code why its half assed)
By the end of the day he would plug back something and come out the "servers room" saying he fixed that and get everybody's praise. Even got him two raises in the span of 18 months.
That's how crazy it is.
I know a variation of this sort of story, where a good sysadmin/DevOps team was halved and then the problems started. The company didn't have those issues exactly because they had a good surplus of eyes to handle everything.
They realized only later the mistake.
Neither does it imply that it never happened.
They shared a story.
That being I highly believe that stuff like this has and is happening right now.
I've worked in consultancy enough to know that many job's securities revolve around solving specific issues, and if the issues don't exist job security gets lower.
The ones who are honest and actually disagree are banished and their lives are made difficult. They are called all sorts of names the most important being "not a team player".
If your boss is male, let shit fail. You'll get hero points for responding to incidents.
A female boss will quickly suspect incompetence if things keep breaking (i.e. see how far half-assed DIY home repairs get you with your wife before she loses patience with you). Your hero points will come from mitigation.
This paradox comes up a lot in security. IME in this particular field the gender stuff is less relevant since everyone is paranoid. But when we run stuff up to C-levels, it's only the female execs and lawyers that really stop to consider possible issues-- the men just dismiss everything until it happens.