She emphasized that she was looking for diversity, because, as she said, "the type of people on the other side of the table from us are different than they used to be, and they don't want to be dealing with a bunch of 65-year-old white guys. So those aren't the type of people we're looking for." That's pretty much a direct quote.

I was at a small company before I went to grad school. The company began working with a guy in his sixties who'd been laid off for a while and couldn't find work, even though he had a ton of experience. We brought him in on a contract basis, and his role gradually expanded as it became clear that he had both excellent technical knowledge and great people skills. He became a mentor to me and helped me out a ton. He's objectively better at our profession than I am in multiple dimensions, but right now I could find a new job ten times more easily than he could.

I'd like to start a business in 3 or 4 years, and I'm seriously considering going out of my way to target people like him. It'll be my competitive advantage.

It doesn't matter how skilled a person is, or how much experience they have, in Silicon Valley you have a better chance of getting hired as a 20-something serial dog molester than a 50-year-old experienced tech.

And filtering out older people, while illegal, is so very easy to do to 99% of applicants by simply by looking at the year they got their undergrad degree.

Context matters a lot - such quotes are usually said in reference to a company's leadership team, and there's quite a bit of truth to them. When you look at the list of CEOs/Senior-Executives/Board-members at Fortune 500 companies, it's overwhelmingly middle-aged/old white men. I would consider that just as problematic as the age-discrimination that the article was referring to.

> assumed the speaker meant... I am guessing you are not an old person being subject to ageism...

> Context matters a lot

Yes it does, the context in which the statement is made, the person who made it and the context in which the statement is receive. Asking us to only consider on side of the communication ,and making excuse because in certain context the statement is not offensive doesn't seem fair to me.

> such quotes are usually said in reference to a company's leadership team, and there's quite a bit of truth to them

There is truth in any stereotype, that's why they exist. The usual issue is that they are alienating and non inclusive to some people.

> it's overwhelmingly middle-aged/old white men

And the prisons in America are filled with poeple who look like me, should i be okay with generalization on me about that. One thing that it seems that most leftist like me forget is that most CEOs are white , but most white are not CEOs...

> I would consider that just as problematic as the age-discrimination that the article was referring to.

Yes and the first step is adopt an inclusive language, and not make excuse we wouldn't accept on any other protected classes. The fight for diversity is won we get everybody on board. When we start to have a hierarchy of protected classes, some classes where it's kind of okay to discriminate against because X,Y,Z reasons then it starts to look like the exact opposite of what we are trying to achieve

And i guess the most interesting thing is the amount the mental gymnastic we have to do to find this statement okay, instead of just taking the most plausible explanation... It simply reflect the latent ageism in our industry, and the fact that it is still okay to be ageist so long as it's directed at white men...

If someone could demonstrate convincingly that executive roles are being awarded out in a purely meritocratic manner, then demographic-imbalances might be excusable. But let's be honest - executive roles at mega-corps are almost always handed out on the basis of personal relationships and perceptions. I strongly suspect that in a purely meritocratic system, we would see far more diversity in the executive ranks.

It's also curious to see the extent to which many commenters are willing to accept the premise that old/white/men are being discriminated against in some roles, but not the premise that other demographics are being discriminated against in other roles. Is the evidence for the former really all that stronger than the evidence for the latter?

These things swing to extremes, but harm will come to some. There are still good candidates out there with mortgages, families, etc.

I'm self-employed now and don't expect to ever put myself into someone else's employ (that's my tip to everyone else in the 40+ camp... entrepreneurialism isn't a groovy lifestyle choice, it's the offensive measure to secure your future --- business startup and continuity risks notwithstanding), but the "we need diversity" bell is now mine to ring. That said, I used to dream of creating a startup, building a team, growing a business --- now the dream is zero employees. It's me and my (life) partner, and we won't take on employees if we can help it.

Is that problematic?

Tax system already penalizes those who are producing wealth in order to subsidize those who are consuming it.

I dont think most Libertarians want 0 government, but I believe most government is best served locally where people can actually have influence and oversight.

[0]https://twitter.com/ThomasSowell/status/943248573222850560

[1]https://en.wikipedia.org/wiki/Thomas_Sowell

Using your logic (only related to this portion of your post, because as you stated money, does in fact, beget money), one should not work hard for one's progeny to have an inheritance? Should estate law just be modified and have all assets of a dead person go to the state?

Inheritance is deeply ingrained in most cultures that I know of (so, western first-world cultures), but it had never made sense to me. Inheritance is pure unfairness.

And people far more versed in the economic arcanes than I am have the same opinion: see Karl Marx

Why not? Why should a dead person continue to exert their influence in the form of cash after they're done personally contributing to society? Why does someone deserve the fruits of their parents' labor? Do we also judge children by the sins of their father? If someone's money is transferrable, why not blame or shame?

I think your sin analogy isn't an apples to apples comparison nor does it make sense in this context. However I'll play devil's advocate.

If your father was a felon / committed "sins" then most people in society are going to be skeptical about how you might turn out. It's an unfortunate truth. Not to say you will be a felon but based on the environment you were raised in you have a statistically higher likelihood of becoming a felon / deviant. So yes, you will be judged by the sins of your father whether you like it or not. That's why people leave their home towns for to start new lives or change their names. I'm not saying its right but that's the reality.

Not to defend the quote, but I wonder how else would you characterize “non-diversity” in this context? Specifically, if their current workforce composition is indeed “bunch of 60 something old white males” then how else would you express your desire to be diverse without referring to the current reality?

In fact it would actually make them significantly more diverse if they were to hire some 65yo white males.

She should not have said "65-year old", as that is blatant age discrimination. And she should not have brought in the terms "white guy", as it is racist stereotyping. It seems like that recruiter is really out of touch with what promoting diversity in the workplace is about.

However, despite this, you cannot deny that the majority of people working in the tech sector are white or asian and male. That's just a fact. I feel like you are demonizing diversification efforts in the work place just because of one experience you had.

That old white guy you worked with will not have a problem getting a job in the future, eventually, unless he has some sort of character flaw that renders him absolutely unemployable. Hell, he already has a job right now, though on contract basis. Even just getting your foot in the door is much harder if he was not white and male. You just proved so yourself by saying you would have a job lined up for him and people of his demographic. You are acting like old white men are the victims here. They are victims, but only because of their age. Now you know what discrimination looks and feels like. This is why diversification is important. It's simply a protection measure to help ensure equality and fairness.

> She should not have said "65-year old", as that is blatant age discrimination. And she should not have brought in the terms "white guy", as it is racist stereotyping. It seems like that recruiter is really out of touch with what promoting diversity in the workplace is about.

I am glad we can agree on this

> That recruiter you were speaking of probably meant that they were looking to hire a diverse set of people, as opposed to primarily just 65-year old white guys (which she probably believes to be the majority demographic that you'll see in a stuffy corporate environment).

I am not sure what warrant this generous interpretation. All we have to go with is a a "Derogatory" sentence from someone not in the group (young vs old). She is supposed to be train to speak publicly on behalf of a big company. She is supposed to understand diversity a litle deeper than the average joe. I am not sure what she meant, but to me the "way" she spoke speaks also volume on our industry ageism. I don't think we would have heard this about either hispanics/blacks or women.

> However, despite this, you cannot deny that the majority of people working in the tech sector are white or asian and male. That's just a fact. I feel like you are demonizing diversification efforts in the work place just because of one experience you had.

OP is not denying anything, he did not even mentioned diversity efforts or anything of that sort. The article was about ageism, and his comment was related a story where is people supposed to be trained to look for diversity make "bad" comments on old people. He probably feels concern about it because he can see him self in the old guy in a couple of year, or simply the proximity with the guy in his story make him feel some sympathy for him.

"Straw Maning" "look at this old white guy suffering" into "you are denying the struggle of of all this other people" is bizarre and from my perspective show a lack of empathy. Then going on a lecture on diversity is not helping.

> I feel like you are demonizing diversification efforts in the work place just because of one experience you had.

He is not, he is showing a deficiency in our inclusiveness.

> That old white guy you worked with will not have a problem getting a job in the future, eventually, unless he has some sort of character flaw that renders him absolutely unemployable.

Doesn't this article prove otherwise ? You saying this is essentially denying ageism.

> Hell, he already has a job right now, though on contract basis.

Discrimination is more nuance than getting or not getting a job. It's about being pass for certain possition, it's about having to work harder for the same reward, or working the same for less reward. It's about like in this case someone having the capacities to be a fully employ but having to settle for contract work.

> You are acting like old white men are the victims here. They are victims, but only because of their age.

I am not sure the point of this is on a thread on ageism. there is so many thing wrong with this statement..

> I feel like you are demonizing diversification efforts in the work place just because of one experience you had.

Since we are sharing feelings. I feel like you trivializing other people experiences and trying to create a hierarchy of protected classes. We don't go around telling cancer patient about the pains of poverty or vice versa. We don't go around telling white women complaining about sexual harassment about black men being killed by the police or vice versa. We don't feel the need to compare and judge and contrast those experiences. We just accept them as the general suckiness and unfairness of life, offer help when we can, sympathy when we can't;

When we do so, we are alienating people without good reasons. People will naturally fell more empathy toward certain groups either by identification or by just shared experience, and that's okay. We don't need to lecture them just because they aren't focusing on the group we want to focus on. Ageism is a problem, if you don't feel strongly about it that's okay, but please stop telling people who do , that they should be focusing on something else...

Count me if you can. No, not to give me a job but to be your partner. I would guess that there are some really smart older people who are under utilized because of all perceived drawback of age( often by not very smart people). But smart people are rare - there are immensely valuable whatever their age may be.

Somehow, I don't think this one is going to get pursued ...

They are huge :)

It's possible that the report is true, but that the author doesn't want the consequences of unambiguous identification.

I must travel in lowly circles.

Like, cashflow at 50 with 3 kids is important.

Yeah, you've saved for retirement at ~65ish, but you have 2 kids in college with one on the way up, plus a mortgage, plus just regular life stuff. That's not an unreasonable scenario at all.

Like, do you live in a first world nation? Honestly, the paradigm changes a lot in the 3rd world and your confusion would be more appropriate in Chad or something.

(In Chad, average age of first birth is 18, so you'd reasonably be a grand parent by 50, plus cost of living is very low)

If you have kids before your thirties, they will all be +25 when you are 55. They most likely finished college, they probably left the family home.

https://www.gao.gov/assets/680/670153.pdf

Edit: below, the table contents

               Households age 55-64 with        Households age 55-64
               no retirement savings            with retirement savings


  Percent of house-        41%                        59%
  holds age 55-64

  Median net worth        $21,000                   $337,000

  Median non-retirement    $1,000                    $25,000
  financial resources

  Median income           $26,000                    $86,000

  Home ownership rates     56%                        87%  

  Percent who own a home   22%                        27%
  that is paid off

  Percent with a           32%                        45%
  defined benefit plan

Then an additional 50% who have a home but still a mortgage to pay. The statistics don't say when mortgages will end, so we can't do any meaningful analysis on the majority.

There are more people on the low side, not WAY MORE contrary to your statement.

Which is to say there are some people who don't have their house paid off yet, but will have it paid off before they retire, and then live rent free (but with other bills and taxes). There are other people who will not have anything paid off.

That is the EXTREME minority of people over 50, at least in the US

>I admit that there is also another part of the population who is struggling and desperate for work at any price.

I would not say they are "desperate for work at any price." but most people over 50 need a fair wage for work, and by fair wage I mean a wage comparable to younger people as well

My dad was in fact laid off at 50. Everybody knew he was very careful to save a lot of money, so they always said "but you must have enough money saved away to retire by now". His response was always "yes, but I don't have enough money to get to retirement". In the 15 years between 50 and 65 his money is expected to double twice which makes a big difference to his retirement income. If he had started drawing at 50 would have much less money to work with. He needed a job to pay bills.

That is an assumption that may be invalid. Everybody is in their own private situation. Your assumption will be true for many but not for all. Many older folks may not need a top salary anymore and will take an average income for the pleasure of working with other fine people and doing interesting things. At some point in your life the career ladder will be less important than quality of life.

So, the only way that is even in the realm of possibility is if the kid was making $30K and the greybeard was making $300K. That's another benefit of greybeards: you get more bang for the buck simply because of the way salaries scale vs. performance that comes with good experience.

More like 50% more or at most twice as much.

This notion that experienced developers, as a whole in the industry, are making x times more than junior developers is nonsense. Utter nonsense spoken by people who have no idea of what they're talking about. It's true you can find outliers for that kind of thing, and I'm willing to bet they are specialty cases.

Early in my career I would get huge jumps in pay when I proved myself at a project. Almost fifteen years into this career and I don't get those huge jumps in pay anymore after a successful project. Not because I'm not deserving of the praise, but I'm already paid well to deliver based on my experience. A junior succeeds and gets a raise; a senior succeeds and moves on to the next project.

Could I get one of these mythical 300k jobs? I know I can. I'm willing to bet I could snag a 500k job if I pushed myself. But that would require sacrifices I'm not willing to make, give up hobbies that I enjoy, and live in a city I really don't care for. A city that would eat up the extra income anyway.

I'm more than happy with my current job that pays well and I get to mentor juniors every day, which I enjoy.

I'm drawing the same salary as I drew twenty years ago. (Never mind adjustment for inflation. It's the same actual number of dollars.)

I have a clear enough understanding of my trade that I'm willing to buy my own tools when they save me time (keyboards, monitors, development tool licenses, VM service fees, etc).

This all works for me. My kids are out of college without debt. I've got some money stashed in 401(k). I wouldn't mind retiring, but my small-company employer can't afford to hire somebody younger and they've asked me to stick around.

All other roles for different ages I've ever seen has been based on experience and not age, and at the companies I've been that experience is only about 30-50% higher at the worst.

I have heard that companies like recent grads because they are (1) more malleable and (2) can be paid less. But neither of those reasons seem to me strong enough. I'm talking completely about the company's own interests.

Let's address the first reason: malleability. A recent grad presumably will adopt the company's culture faster, complain less, and in general pick up things sooner. Well, the hardest, meanest coworkers I've ever had were late twenties, early thirties. I've worked with people in their sixties, and they're sweet people. Even the grumpy old sysadmin had only a thin layer of spikes. After just a few days I could see through most of it, and he was 10 times more helpful than my other sysadmins. Not only was he softer (at least deep down) but he was smarter, having done it for decades. Even when he met a new problem, his keenly developed taste made him more likely to choose something that would be more maintainable long term.

Now let's address the second reason: salary. I am 10 times better than I was when I started. I know, because I still work with some of my code from back then, and I desperately want to rewrite it all. How much more does a senior developer make than a new hire? 50% more? Seems worth it to me. 100% more? 200% more? Still maybe worth it. And if some old fella can't get work at all, maybe he would settle for something between 50% and 100% more. I mean, why not at least make an offer?

It just don't make no sense. Other fields reward grayhairs. You see some sixty-year-old painter or architect or carpenter, you think he's probably pretty good. You see some straight-out-of-college twenty-something in . . . any other field, you think, "I sure hope he knows what he's doing."

Well, iOS11 needs to ship on its annual schedule, non-negotiable. And the SVP will really complain if I ask for more money this quarter. So, cheap it is.

If a bridge falls down, it's really obvious and people die. If billions of computers become vulnerable to malicious actors and a few hundred or thousand people suffer dramatic personal damages, well that's a nice and quiet problem which will be quickly forgotten in the 24-hour news cycle.

This. I do development coaching and training. I’m totally burned out because my job doesn’t matter. These companies don’t care. They hire me to “increase code quality” but that ends up being a lie. They just use me to get their teams to crank out shit faster, and I do mean “shit”. They don’t care if the systems blow up a few times a year or once a week. Banks, oil companies, airlines, all of them. They loose millions because of it too, still it doesn’t matter. No one (in leadership) gives a fuck. “Just make this quarter’s goal” is all that matters.

Fucking equifax for crying out loud, NO CONSEQUENCES. If this isn’t ironic enough do some googling on why Equifax is named such. tl;dr This isn’t their first rodeo. They once fucked up so big they had to change their name.

Sucking at software only has consequences in a few industries, usually ones where the product is software, the product is discretionary, and the customer is fickle. Even then it usually sucks.

These same companies are audit conscious (about money), they’re crazy about regulatory compliance, and workplace harassment. Why? These things have real consequences.

The sooner some company gets fined one year’s profit or an exec goes to jail the sooner this shit will actually matter to them.

Your method is refactored to be super-fast and have no branches? Nobody cares.

Elegant, re-usable architecture? Nobody cares.

You've optimized an inner loop in assembly and increased speed by 30%? Nobody cares.

Made it to zero compiler warnings? Nobody cares.

No known crashers left in the bug tracker? Nobody cares.

Fixed that bug that's been in the code for two years? Nobody cares.

Patched a security hole that could allow a crazy bad attack? Nobody cares.

The vast majority of software shops out there care only that something--anything--ships as fast as remotely possible, and as long as it does not kill the customer, it's a success. Nobody in leadership gives a single fuck about anything else. There are a few places where this is not true, and good software people tend to collect there, but it's true for the vast majority of places where you will work. The sooner you accept this, the less likely you'll burn out.

Software should really only be measured by the value it provides. If a terribly buggy piece of poorly written code still saves hundreds of man hours a week, it's a win. (Unit tests be damned)

If that big ball of mud that's using 20 year old technology still prints a billion dollars a year - that's a win. (Microservices be damned)

If some slapdash jquery-and-duct-tape web app still solves a specific problem I have, that's a win. (React SPAs be damned)

Does crappy software flourish while beautiful software dies? Sometimes. But usually code hygiene, security, bug counts and crashes are not what makes or breaks the success of a piece of software. Developers often think their work is the most important, when in actuality it is usually not. Sometimes you really just are a cog in the machine.

This mentality is the reason why sometimes -- but not always! -- my phone won't play music in my car until I restart the _car_.

This mentality is why game development companies get away with charging full price for unfinished, bug-ridden games with crippled features and missing content.

This mentality is the reason why I couldn't see my credit card in the list of my accounts on my credit union's online banking site for several days.

This mentality is why Experian and Equifax don't report the same credit score for me.

This mentality is why I feel ashamed every time a receptionist apologizes for the wait, because they "have been having problems with the system."

Most importantly, this mentality is why I have to worry about whether someone will steal my identity because people keep writing shitty code on top of shitty code and my personal information keeps getting leaked.

When I'm so disgusted by my own profession, no wonder I ended up burned out.

We want everything fast! Nobody is willing to put in the work and get the reward after a longer period of time... No! We want results now! We don't want to wait for the food to be properly cooked, we want it now, so we go for fast food. We don't want to put in 1 year of work to learn something new so we can feel that we achieved something, we want it now, so we play a game where we can 'win' in 30 minutes. We don't want to build a relationship and eventually end up being intimate, we want it now, so we go for 'one night stands'.

Then you ask yourself... is it weird that the economic system works the same? That the software industry works the same? :/

> We don't want to wait for the food to be properly cooked, we want it now, so we go for fast food.

We go for fast food because it saves time. When I opt to order in instead of going out for lunch, or grab a burger from McDonald's en route, I do that because eating is mostly instrumental. I don't want to eat at that point, I have to, and the sooner I can fill myself up, the sooner I can get back to doing the things I actually care about.

Fast food, and food delivery services, allow people to choose to spend more time on other things, when those other things are more important to them. The same people will enjoy a finely cooked meal on a different occasion, when they prioritize it.

> We don't want to put in 1 year of work to learn something new so we can feel that we achieved something, we want it now, so we play a game where we can 'win' in 30 minutes.

Spending a year on learning something to just get a quick feeling of achievement is a very stupid way to go about it. Videogames are better for that. Learning is better for getting long-term feelings of achievement, and to actually gain knowledge/skills that you can use for something. And again, it's not something new - our generation wastes time on videogames, previous generations wasted time playing soccer, cards, darts, and doing tons of other quick-reward activities.

> We don't want to build a relationship and eventually end up being intimate, we want it now, so we go for 'one night stands'.

One-night stands exist for as long as humans are humans. Nothing fundamental changed, only the hookup methods evolved with population density and available communication tools.

--

> Then you ask yourself... is it weird that the economic system works the same? That the software industry works the same?

Nah, they don't work the same. In them, the actors are not driven internally, they're driven externally. People write shitty software, or sell shitty products, not because of their need for instant gratification, but because of market pressures. A fast hack sold by your marketing team can be a difference between you getting $100M contract versus not getting it, or getting your product on the market first versus a week after your competitor. Market economy, because of all its efficiency, is what creates the culture of suck.

It's so obvious. But until you realllllly sit down and internalize it... then you can be at peace with the shitty service of Comcast, etc.

In other words: Don't hate the player, hate the game.

Ha ha, maybe this is why they don't want older engineers. They're wise, cynical, bitter, skeptical and not likely to suffer bullshit management.

You just have realize that most software buildings are tents, and there are a few buildings that you can use out there.

I don't know if the world is getting a shittier place. But it surely is getting less reliable.

It is, because everything is being optimized into literal minimum viable products. That's how competitive markets work - whatever aspect of your product or business you can cut out to save money and thus get ahead of your competitors, you will cut out, and then your competitors will cut it out too, in order not to get outcompeted by you. This race-to-the-bottom phenomenon is fundamental to how competition works, and the result is that products gradually lose quality.

It's the reason why your grandfather's washing machine probably works 'till this day, while you have to fix your new one every year, and will probably replace it in five years. "Building to last" is a good example of a quality that the market economy optimized out over time across pretty much all products in all sectors.

Adjusting the cost of each product with inflation, things really are built like they used to be. Your grandfathers washing machine both cost far more than a current model* (again, adjusted for inflation), and all of the poorly built old washing machines broke and no on sees/thinks about them anymore.

* I am having trouble finding a source on washing machines specifically, however I'm assuming they followed the same trends as most commodities tracked by BLS: https://data.bls.gov/cgi-bin/surveymost?ap

As questionable as citing Reddit is, this post rather well encompasses what I am trying to get at: https://www.reddit.com/r/Showerthoughts/comments/4kn8ku/the_...

The way I see the post you're replying to is either you learn to cope with these things or you'll burn out faster.

Since there's no accountability, if you want to do things the right way, you'll have to do it by yourself and be prepared to swim against the tide..

Most of those bugs and failures you listed are really inconsequential in their contexts.

Car won't play your phone's music? Use the radio. Game has bugs? Play another game until it's patched, or find inventive ways to use the bug. Can't see your CC? You can still charge on it and pay its balance. Experian and Equifax don't report same credit score? Your creditors aren't reporting to every credit bureau.

Ashamed that someone else's system doesn't work? I can't help you there. That's some deep psychological issue.

About 10 years ago I came to understand that mediocre runs the world. All these people, who are your bosses, who are getting raises and promotions, they're the B/C students from college. They don't care about perfect. They really only care about finishing what they're assigned and going on with their outside life.

If you want perfect, do it on your own time.

Yes, I expect that for most things we could find a context that could render them inconsequential.

> Car won't play your phone's music? Use the radio. Game has bugs? Play another game until it's patched, or find inventive ways to use the bug. Can't see your CC? You can still charge on it and pay its balance. Experian and Equifax don't report same credit score? Your creditors aren't reporting to every credit bureau.

Elevator doesn't work? Use the stairs. Public restroom is filthy? Hold your breath and don't touch anything. Lost a tooth on the right side of your mouth because of an incompetent endodontist? Chew on the left side.

I'm not being facetious here. I really do agree that almost anything is tolerable if we decide to. That last example is from personal experience: I have lost three teeth on the right side of my mouth and I have to chew on the left. Most of the time, I don't even think about it anymore. And it really isn't that big of a deal -- it doesn't have a very significant impact on the quality of my life.

> Ashamed that someone else's system doesn't work? I can't help you there. That's some deep psychological issue.

It could be. Like I commented elsewhere, I would expect a doctor to be ashamed of Andrew Wakefield, but maybe most of them aren't. And even if they are, it could be a deep psychological issue that I choose to compare the state of our industry to what Wakefield did in his.

But here's the thing: I know that we can do better. Not perfect, better. But we don't have to, because we lack accountability.

Sure, perfect is the enemy of the good. But complacency is the last refuge of the mediocre.

Personally I get angry in those situations... the larger the company, typically the more safeguard crap in place that's supposed to prevent those issues, the more pissed off I get. But that's just me. I get angry when I see evidence of poor/buggy quality in business software the more visible it is.

why would you feel ashamed for waiting a little longer?

that's an odd thing to be insecure about

The problem is when the "negative value" is externalized leading to false evaluations. "Oops, so sorry we leaked all your social security numbers. Our bad."

Because it's not really the value overall the software provides that's being talked about but the instantaneous, immediately visible payoff to a single consumer that software, the people or that consumables are getting judged by. If the software is going to result in trouble over time, if it's going to have security holes that will cost a lot over time, if it's going to commit you to garbage that's updated less and less frequently, etc. None of this calculated. Just as the health costs of sugary drinks don't get calculated, the social costs of poor education don't get calculated, etc.

Is it possible that the value assigned to keeping that information secret was, in the end, actually appropriate?

Ask someone who's had their identity stolen.

I’d hire you.

The vast majority of people making agregrious security errors know no better. You could argue that whoever hired them shares or shoulders the blame, but to suggest they’re not decent people is a stretch. Most I’m sure are. They’re also likely infosec idiots.

Now if you know something is terribly insecure, understand what’s involved in fixing it, and go out of your way not to, then yes ethics come into play. I see that the same as an engineer (in the true sense of the word) staying silent on an issue involving automobile brakes that could lead to casualties. The consequences are not 1:1 but the ethical question is in the category.

If your bugs can hurt people (financially, physically) I think you need to work a bit harder to make sure it doesn't sneak into your work. Whatever you believe helps there (unit tests, formal verification, ...); if you didn't do all you could do because you are not paid for it (your boss tells you to add features, don't waste time on things that didn't break yet for instance), what should you do? Seems like a real issue for professional coders as there are not so many options; not many companies will pay to prevent these kinds of things unless they had a big issue before already (and someone(s) got fired / sued for it already).

But as one HNer to another, I was really talking about your second case. To claim here that security can ever be discounted, as the person I was replying to implied, is pretty much inexcusable. Everyone here knows that security affects more than just your business, so no one here should be solely applying business logic to it.

But those bugs could easily lead to mistakes in the output.

Code quality matters and has tangible consequences in that niche, and it was awesome to work in that environment.

I haven't worked anywhere like that previously, and I think the key factors that brought code quality to the forefront were:

* Bugs cost sales

* Poor code caused friction for features a significant amount (reduced ROI)

* Small teams and an insanely tight customer relationship to those teams. The client needed to have a stakeholder in our team or as close to that as possible.

But most importantly it was just the company culture from top to bottom. The director cared, he made the project managers care, and we already cared because it's more fun to write good code.

We did take on a rushed project at one point, so there is a good comparison in that project. It shipped, but everyone was unhappy, some key people left and had to be re-hired for. It triggered a very transparent discussion roughly titled "let's figure out how to never do that again" and to that end they curated the clients more carefully, and put in some checks to see if projects are a good fit.

But I understand that is probably unique, and at previous jobs the "good enough to make money" mantra has worked out okay.

I think when your software ___domain is complex and rapid, it pays to have sound architecture. When it is simple, or slow to change, it doesn't matter quite as much.

Whoa now. The Toyota 'unintended acceleration' case showed us that it's fine to kill the customer. The court declared themselves incapable of penalizing even the most stupendously egregious example of criminal negligence we're likely to see (Of 90+ 'required' and 'suggested' practices in automotive industry firmware coding practices, they did 4 in the code in question. The developers didn't have a bug tracker or static analysis tools. Typical of all organizations, the software engineers had no real power to demand more time or testing, etc). They lost a civil wrongful death case and paid out $4 million, then settled with the plaintiffs out of court before the jury could award punitive damages. So killing is OK.

The issue is that, I think, software people need to stand up for themselves. They need to tell executives no, and refuse to pump out slapdash work. They need to take responsibility for the successes and failures of the company. The practical truth is that in most organizations, the software is the most valuable part of the entire business and the thing with the power to enable the company to excel or fall flat. We've been waiting for executives to recognize this since the 1980s and they still just see the software people as people who do typing.

After a 10-month search, NASA and NHTSA scientists found no electronic defect in Toyota vehicles. Driver error or pedal misapplication was found responsible for most of the incidents. The report ended stating, "Our conclusion is Toyota's problems were mechanical, not electrical."

https://en.wikipedia.org/wiki/2009%E2%80%9311_Toyota_vehicle...

Third advice. It's not enough to fix bug, everyone MUST know that you fixed that weird bug that customers were complaining about for years and noone could understand the cause.

The important word here is pretend. If the system is safety critical you'd think that quality matters. It doesn't. What matters is following the process laid out in ISO 26262 or whatever standard applies to your field. Whether or not that improves quality is not important (it does, but only a little). The important part is that you have reduced/no liability for accidents if you can prove that you did everything by the book.

Edit: It's all about documenting that those things have been done and signed off on, so keeping track of paperwork.

https://en.wikipedia.org/wiki/What_Do_You_Care_What_Other_Pe...

...where he talks about his role and questions regarding the Challenger shuttle disaster; I don't know if things have changed much since then at NASA, but I suspect they haven't, given Columbia and such.

After all, that is the point of those heavy processes: manage to product something fairly reliable despite the acknowledged presence of morons and shitty managers. The process does not try to eradicate those people, it works around them with some kind of redundancy.

Having been one of those 'concerned' people, I must admit it is exhausting. You know that if some work comes from this guy, or that company, it will be 90% shit and you have to explain them again and again what is wrong and how to fix it, or do it yourself when you are really fed up. So basically you do your job + the slackers' job. That is how the system works. As a system, the result is not too bad. As far as individuals are concerned, however...

If you have to remind people of it, it's as good as not existing in the first place.

> What can you do for me or have done for me recently?

Services provided so far in the past that need to be reminded are at best irrelevant and it can actually hurt you to bring them up.

I'm not saying that it is nice, only that humans behave individually and (even more collectively) according to this.

You might also carefully consider your company's culture when deciding how to split your efforts between new (user-visible) features, preventive maintenance, and bugs affecting end users (especially any VIP end users that have your managers' ears).

For example, a 'Hero' culture rewards last-minute, late night, death march efforts, whether to fix an urgent problem, or to add that one feature that is (supposedly) needed to land a specific high-value customer/sale.

I suggest reading the comments on this thread:

https://news.ycombinator.com/item?id=13859961

I learned this at my first software engineer (though we didn't call it such) job back when I was 18; closing in on 45 years of age, and I'm still here at it, and don't see that changing soon. I have thought about management, but I really don't have such experience, and I'm not a real people person anyhow - plus I like to code.

Another thing I have learned - at least here in the United States: Not only do they not care about quality, they usually don't have any loyalty to you as an employee. They'll let you go without any warning at all, and if you're lucky, you'll get some severance pay.

So save your money, build a savings account with FU cash in it (6 months to a year of salary - or more), and don't be afraid to drop an employer like a hot potato if things aren't working out, or a better offer is in the works.

And above all else, don't let your skills stagnate.

Do they care if a year down the road your TTM times increase tenfold?

  We know that the bad code slows us down. Why do we write it?
  Why do we write the code that slows us down? How much does it
  slow us down? It slows us down a lot. And every time we touch
  the modules we get slowed down again. Every time we touch bad 
  code it slows us down, what do we write this stuff what slows 
  us down?
  And the answer to that is: well we have to go fast.
  I'll let you to deal with the logical inconsistency there, my 
  message to you today is—you don't go fast by writing crap.

When nobody cares about you get the point sooner or later where you can't ship, they've probably launched a product but there's still a lot more to ship in future. Eventually they become so mired in technical debt that they care.

When they realize they've invested a hundred million dollars in something that now has no value? They care. (especially if it's a turd before it gets out the door)

When a start up comes along and eats their lunch because they aren't weighed down be legacy code? They care.

When they lose revenue because they can't keep customers happy? They care.

The problem is that the professionalism of software developers doesn't allow them to learn these lessons early and hard enough.

> They care.

> They care.

> They care.

I disagree. They will hire a consulting company to do a root cause analysis. The Ha'vad grads from McKinsey will swoop in, determine that the past doesn't matter, you need to get to black and to get to black, the St. Louis team needs to go, along with 20% of the following 7 teams....

No, they don't care. And never will.

Edit: Unless we elect people who take away legal protections in place to regulate safety critical software

Where?

It's over two decades since that was written. I remember reading it when it was first published. Does it look much like the future?

`Why? These things have real consequences.`

To a business they see software/engineers as a expense. The whole focus as a business is to provide a service that people are will to pay more than it costs to provide said service.

Everything else doesn't matter, what does matter for a business is $$$$$ and making sure business doesn't get sued because bill touched jill with his #####.

For what my words are worth, I do think you need to take a step back and view it from a Business person perspective and attempt to align your goals with theirs. Get out of your cube and go and meet CEO's and CIO and talk to them about their problems and what their goals are. Then see if you two can work together to achieve their goals and bring value to the table.

Even writing this I've could think of 10 or 20 different business discussions you could have.

Anecdotally, this is one of the first things I try to gauge at a prospective employer. "Are their development teams seen as cost centers, or profit centers?" If the company works with technology a lot and doesn't see technology as being particularly important to its bottom line, that's usually a bad sign.

Also, discussions with C-levels tend to be pretty one-dimensional. It doesn't matter how much their infrastructure is falling apart, they'll still stonewall with something along the lines of, "our goal this quarter is new user acquisition - how does this improve those numbers?"

And they won't accept, "users cannot sign up if everything is broken" as an answer.

Like I said before you're viewing it from the perspective of a developer but not from the perspective of a Business person.

Instead of saying `Users cannot sing up if everything is broken` you need to see it from a Business perspective, and communicate it to them in the language they understand.

For example, `From our quarterly earnings report we need to have 10,0000 new clients signed up by the end of the month to reach the goal. We have on average 2,000 sign-ups per day. On the 2nd, 3rd of last month two of the critical system's fell over, and this result in a estimated 4,000 failed client acquisitions. The estimate from our quarterly earnings each new customer bring's in a revenue of $300 net profit from each client for the quarter. As a result of the system crash our quarterly earnings will be down 1.2 Million.`

Your job is to communicate clearly in the language they understand how it will achieve their goals. You're not the only department/manager who is requiring resources from the Business. As I stated before you're there to serve the business to achieve their goals.

Let's put it this way: Netflix has one of the most robust microservice architectures I know of. I promise you will find zero mention of it anywhere on their customer-facing pages. Because that is not the problem that Netflix solves for their customer; they solve a media library and streaming problem.

The business is your customer. You need to understand their problems and how you're going to fix them. Everything else is an implementation detail.

I'm not. Our industry is full of academics who've been told "this is the right way to do it, everything else is stupid" for the entirety of their education. They're academics, trained by other academics, ignoring the broader reality of why we do these things at all.

Another way to think of it is as of user acquisition problem. You have to highlight the benefits in a way that is compelling to them. At the end of a day all progress/fiascos in a company comes down to consistent and effective communication.

You are devaluing yourself and you are devaluing all the developers who don't want to ruin their week end at work.

I had to break it down to one of them "Listen, we've seen that the site being faster gets us X% more conversions, if the site was down, or if the site was ugly X% of the time and cost us those conversions, you'd be breathing down my neck to fix it, why is this any different...?" reply after a few seconds of thought "You're right, but you'll never convince Leadership"

Thus fuelling the idea that this sort of thing will just be done as other work is happening with no time budgeted for it.

> I obviously didn't bring to the demonstration that I had volunteered the time, it suited my point to make it seem like it was something easy I could do as an aside

I understand the impulse, but in long term this leads to inflated estimates from management - and tech side has only themselves to blame. When we pretend things take shorter then they really do, dont be surprised when they learn to expect our lie to become truth.

Long term here can be as short as three months.

No, there isn't.

Google is showing one series of ads per page. The study showed that having more legitimate results per page decreased their revenues. Of course, it gives less room for ads and less page views.

The work you did probably is great and do I think its above your average developer. Somewhere in the the top 10%. Though how you conducted yourself in the face of management was down right petty/folly.

Yes you did the best job in the world. You improved the performance of the serves by % and it did make management of those server's easier. Though you need to think about what you've done in the eyes of management.

Firstly you've modified the server's without permission. You've run tests out-side of work hours that could of impacted the business bottom line. For all I know (its up for debate) but your senior managers had more pressing issues on the table, and having a young code money running around outside office hours is the LAST thing they want to hear.

`It's not a simple as you may think it is.`

Some of the things that come to mind, and honestly I would of pulled you into a office to explain yourself if you're on my team.

1) Did you document all the changes you've made to the server

2) Did you back-up or store any sensitive information off-site during out of office hours

3) Did you modify critical system files that could cause another dependent system to fail

4) What ETA/Service level agreements if any did you break when bringing down the server for maintenance?

5) Did we lose any Security Certification with you modifying the server or changing any of the certificates on the server?

We're software developer, and yes when we see problem's we want to fix it to our best of our ability. Though when you're in a Business there are many thing you may not be aware of. In this situation I would honestly say you're lucky to keep your job! I hope you take it into consideration next time you want to go out-side of your duties.

I don't want to come down harsh on you, but there are times when you see a bad situation and there is nothing you can do about it. You notify the people who're higher than you of the situation and the dangers. It's then up to them to make the decision. After they've made the decision that is it. If the server blows up during the weekend, and they want you to come in and fix it (even when its there fuckup) you just take your hourly rate and x10. So if your hourly rate is $50hr and the server blows up, then your new rate is going to be $500 per hour to come in during the weekend to fix the mess.

Many of the points you've raised are moot outside of large corporate environments and projects.

It is likely that the commenter has root access to all of the things you mention and touches them on a daily basis. It is likely that they are not inundated with all of the heavy process you're bringing up. It is likely that all of the security concerns you raise are not even part of their current business. Working outside of set business hours is likely not a concern; overtime is likely uncompensated anyway and there probably aren't considerable office security protocols (they probably have keys and an access code for the whole office).

The points you've raised do not apply to most small development teams.

The only "clandestine" part is that I added the split test, and did some work outside of the set of features that was scheduled.

We had no policies around SLA, developing off-site, security or restricting sensitive information (think potential FERPA/HIPPA violation) which are yet other "non-features" that I tried to get them to adopt.

I implemented this entirely above-board, with more precautions and consideration than were taken by other developers on that team for the day-to-day.

The engineer is trying to optimize/normalize his free time by acknowledging quality issues, the management is trying to optimize their income by sweeping them under the rug.

The engineer is ultimately liable for the problem. Quality is insured with his reputation and free time.

The business guys almost always leave at 4:00pm and their bonuses are based on a metric not related to quality.

Not everything is quantifiable like that. If I'm writing code and I take the time to make it 30% faster then it won't make a difference to our bottom line. If that's done everywhere then customers will like us more, be more likely to stay with us and be more likely to recommend us, but that can't be quantified in my day to day work.

It is already possible to more-or-less show how a code change (bug/fix, new feature, change in storage backend, etc.) directly affects your IAAS bill at the end of each month, and taking it a step further by tying in some instrumentation and formulas (of the sort often used to calculate the effectiveness of marketing funnels for optimization and A/B testing) to show the concomittant effect on revenue allows ROI to be calculated.

So, I am pretty sure that Finance-Oriented Programming is going to be a thing not so many years from now, tied into the whole toolchain, and very few - not developers nor their managers - seem prepared for that sea-change (some Operations folks are probably a bit better off in terms of mindset and processes).

It's not a matter of opinion, but what the term means. They are cost centers unless they are closing sales (or being billed for about 3x what they cost, which is still way less than sales people will generate, being closer to 10x+ cost).

Best thing any employee can do is find out how their company actually makes money and understand how they align. Unfortunately, the highest business expense is salaries and one of the most important things for most businesses is remaining runway. So there is huge pressure to keep salaries down, particularly in cost centres, which aren't directly extending runway. If it's a service business it can get worse, as the money is typically made on billable hours - creating a perverse incentive to have cheaper and less efficient people to bill out rather than a 10xer (outside a senior business facing role). As long as they are capable and not so bad that they lose the client, it's often more efficient to have cheaper mediocre people from a business point of view.

Remaining runway is a measure that only exist for companies in the red. For most business it doesn't even exist.

Edit: to be more clear the discussion usually goes like this:

- Me: “where are we on fixing this bug? it’s been two years and customers are still complaining”

- Engineering: “we can’t touch at this component it’s a mess but we are rewriting it, this bug will no longer exists and it’ll be so much powerful, just wait a few month”

We all know how it ends. And when business pressure comes because it failed to deliver it’s all “business is evil we need more time to do great software!”

What we really need is senior and experienced engineers IMHO

Jesus Christ listen to yourself. You don’t know anything about me or how I approach things with my clients.

I care about how code affects humans but business don’t have to be responsible for how they hurt people with it.

Implied in this statement is that the parent has a myopic perspective on the business world. Based on my read of his comment, I don't think that's fair - and moreover would question whether or not your perspective is as unique as you apparently think it is.

In other words, I think you're patting yourself on the back a little much for figuring out how to chew before swallowing.

Oh right.

Good luck even ATTEMPTING to arrange a meeting with a Fortune company's CEO. "Who from what department again?". Worse yet if it not even your company's CEO.

Maybe, if you are lucky, you can get to skip a level or too. Software engineers are usually very far removed from the top leadership.

I've friends at ReliaQuest and I know it is a good company, but I am frustrated that the leadership at Equifax thinks that security is a minor issue that they can outsource to a 3rd party. If a company deals with sensitive financial data, shouldn't security be a core competence?

But in my experience, this is not true AT ALL. More experienced people might work less hours, but will produce the actual end results much quicker - both in hours and in calendar time.

Especially when considering that less experienced devs will (on the average) cause more bugs and worse code structure - in the long run this causes a ton of extra work. In my opinion that is the main difference that easily makes someone a "10x" or a "100x" developer.

Of course, on the other hand over-engineering at an early phase of a project is very much a thing too - starting with microservices, using the latest framework or language, etc.

Microservices however unfortunately have become a fashionable cure-all that's applied indiscriminately to software projects of all sizes, ages and purposes. Hardly anyone seems to be asking anymore why they're actually using microservices. Everyone uses them because everyone else does.

Microservices always incur overhead both in terms of engineering and network latency as well as maintenance / administration. If you have more than 1 microservice you need infrastructure for orchestrating and monitoring these services.

For all that to be worth it you need to have pretty solid arguments for using microservices in the first place. For a new project I'd usually advise against using microservices right from the start. Doing so is often rooted in the same kind of fallacy that has people worry about Facebook-scale scalability before they even have their first user.

If you start having problems that can be solved with microservices then good for you! This means your software is successful and has grown so much in terms of features and responsibilities it's starting to become intractable with standard approaches.

This is precisely why Martin Fowler argues for starting with a monolith first: https://martinfowler.com/bliki/MonolithFirst.html

A traditional monolith gives you the opportunity to learn about the problem ___domain first without having to worry about implementation details such as microservices.

Makes perfect sense to me.

A lot of what he's arguing against is cargo cult programming, and I think it's fair for anyone to argue against that. If your only explanation for why you chose one architecture or design pattern over the others (especially if that option introduces a lot of additional drawbacks) is "because that's just what you do", you need to stop and objectively evaluate what you're doing.

There is a link on that page for the more generic dataflow based programing. I'd advise anybody to follow it and simply ignore its specializations until they master the generic one. I'd also say that any program should be designed from multiple points of view, so do not stop at dataflow.

That's my yardstick - if I see poor man's distributed transaction attempts happening across service boundaries I'll start to assume over-engineering / cargo culting. If I see services acting a nodes in an pipeline or a flowchart, preferably with multiple incoming lines, it smells better to me.

If you are doing microservices, I hope you have a good reason for doing so. Because there are significant problems with using microservices.

In the last five years or so, I've done contract work at several large corporations. In every single one, they didn't care about defects or code structure. They just wanted to ship an application in a very short period of time.

When I asked about the same thing you pointed out, the response was the same, "We don't care about defects once it's released, and we don't care what the code looks like. It needs to work well for our end users, nothing else. Besides, in 6 months, we're going to redesign and rebuild it anyways."

It just seems nobody cares about long term maintenance, and likewise, they don't care much about the code or the amount of defects that code is generating. Pretty maddening when you think about it. Nobody cares about quality anymore.

1) working great and well for the end user, for the function of the software

2) bugs and code structure

Code quality can be so bad that it matters. But beyond a basic level, it does not matter. Bad code that works beats great code that doesn't fulfill it's function every single time.

I once had this great lesson. I was brought into a team as a TL/Manager. We were making a product that was doing pretty well, in terms of attention it was getting and so on. 1 week in, I learn that about 70% of the code is tests, 30% is actual code that's used at runtime. 2 weeks in I learn that everybody's always working on the tests, never on the program (there's a reasonably good reason for this even). 3 weeks in I explore the program, and at some point I try to run it. Turns out the "main" function is broken. Because of crashes (plural) during variable initialization it never gets to the first line of the main function ... How long had these bugs existed (it wasn't just one), you ask ? Well, over 3 months. Doesn't happen in the (VERY extensive) test run.

Lessons learned in that project:

1) test driven development is a great place to start, and a VERY bad way to run projects once they're even 10% into their delivery schedule

2) even the best tests don't check everything

3) even the best tests don't guarantee that even the most basic simple parts of the program work. In fact, tests actually WORK AGAINST THIS.

4) the value of a system test (where the entire program runs, by actually going into main and doing what it's supposed to on a realistic example) is incredible. The criticism that TDD developers have is valid, that if it fails you won't know (necessarily) where it failed, but isn't that serious. Firstly, you'll usually have some idea of where it failed, and secondly, and this is the big one, you'll know it fails. FAR preferable to the other situation. They're also very hard to write. Tough. You need them, far more than you need unit tests on 5 line functions.

5) you are MUCH better off with a "hero" programmer (bad name, "loose cannon" would be more apt description) AND someone acting 90% anal about tests, and managing the inevitable conflict, than you are without the loose cannon. Managing that conflict will be a challenge though. And yes, that means that, to the utter dismay of the TDD developer, you'll have to tell him to let in code without, or with bad tests, from time to time.

I've made the mistake at one company of thinking that my job was to architect solid software that was sustainable for the long term.

What they really wanted was to have software that was "good enough" and had all of the checkbox features to be attractive to potential acquirers so the investors would stop breathing down their necks.

Jack Dorsey became a billionaire from those losses. The same is true for probably all other early investors. For an investment in Twitter to have done really badly, there was a "bear" period of about 2 years.

And before you say it, remember that even Google stock dropped 60%, Facebook's 70%. Twitter's drop actually looks pretty reasonable in comparison.

So firstly, I don't think twitter is bad, and secondly, I don't think people have given up on twitter, and thirdly, that seems pretty justified.

Wouldn't you ?

As an employee who has a job because the company exists? Yes

As a retail investor - I wouldn't be quite as happy.

Contrast that to the small staff that Instagram had before getting acquired. It's still run on a relatively small staff now.

It's about producing working code, not about how many hours my butt is in a seat...

My personal belief is that our industry tends towards less experienced workers because they put up with shit managers more and can be used to cover for their issues. It's anecodtal only, but I have never heard management decide that their deadlines we're improbable if not impossible when bugs get through. It's always just explained away with platitudes about code quality that suddenly dont matter when that requires more money or more time

I've worked at two places where my tech lead at least recognized that if scope or requirements changed then deadlines changed. Now I am at a place where agile is just a word thrown at any problem and now we have things like being asked to integrate third party tools that we don't receive until a week before the deadline. My team stayed till 2 am and was back in at 9am the next day and _literally no one_ saw a problem because it's "agile" and that's what you do when your agile

e: Actually I did Kanban too and that was OK, but that is a lot closer to the "no methodology" thing and anyway doesn't involve you making decisions like "oh, can't start working on that, because the sprint is almost over."