91–100 of 272 posts
How about y'all stop complaining about everything
Would you please stop posting like this, read the guidelines, and then comment civilly and substantively? https://news.ycombinator.com/newsguidelines.html
Earlier quoted context omitted.
> One of the issues is using the word "engineer" for any of the brogrammer types In Canada the term 'engineer' is regulated at the provincial level, and a person can be prosecuted for labeling themselves as an engineer if they are not registered and licensed with their province's engineering association. For example in Ontario in order to join Professional Engineers Ontario and call yourself an engineer you must meet…
Ethics exams are the stupidest kinds of exam. If you have no ethics, you'd have no problem and cheating to pass.
They care about having a legal lever to manipulate so that there is proof that you should have known better.
Earlier quoted context omitted.
I don't think it's ageism if one person is selected based on being willing to work more for less money. That's just a labor market. There's an argument to be made that 20-somethings shouldn't work more than 40 hours a week or should require higher pay. Or that employers should place more value on the work of more experienced developers. Or both. But I don't think experienced developers should be exempt from keeping w…
> I don't think it's ageism if one person is selected based on being willing to work more for less money. That's just a labor market. All sorts of discrimination exists still because "perfectly rational" arguments like yours ignore underlying reasons. For example: it's the same justification racists used for intelligence tests for voting not too long ago.
But trying to address perceived ageism doesn't solve the problem. Being aware of contributing factors and correcting for them on an individual level does.
First, ageism is not just a SV phenomenon. For example, see the very young White House aides in Clinton, Bush, & Obama administrations.[1] Second, the tech companies that have a reputation for favoring 20-somethings will still hire older workers for certain positions. - Even though Mark Zuckerberg said, "younger people are just smarter" , he hired an "old" person like Sheryl Sandberg to be COO at age ~38. - Bill Gate…
The experience bar to have Guido van Rossum's image is also pretty high too. ;) But how many Guido van Rossum's can a company afford to hire; how many do they need to hire?
I think the problem is that for the lesser jobs the minimum viable candidate is chosen because there's a relatively low perceived cost for choosing the wrong cog. Even Google, with their "Better to skip 99 good candidates than hire one bad one" mantra won't be impacted in any appreciable fashion by a less-skilled hire.
In fact, any candidate with greater than the minimal viable skills (i.e. someone in the industry for 10+ years) is usually seen as being too qualified (thus, too expensive) for the role being filled. Why hire an architect to move gravel? They'll just be unhappy with the job, and immediately seek to leave the role they were hired for.
At least, that's the perception.
Earlier quoted context omitted.
I wish this was true in India. In India, we love to parade around saying respect our elders. But when it comes to Indian IT companies, it literally is a pyramid. I used to and still wonder where does all the 10+ year experienced guys go. In almost every team I have been, its predominantly freshers. In India, once you have 8+ years, I have heard the number of calls one get from recruiters is far less. And if you are n…
Maybe they have too many people ?
Earlier quoted context omitted.
This mythology leads directly to horribly created software that will either ensure many terrible security breaches in the future or the continued proliferation of "magic" throughout a product. One of the issues is using the word "engineer" for any of the brogrammer types. an engineer in any other proper engineering discipline does not become worthless with age, their experience actually counts for something. Somehow…
> One of the issues is using the word "engineer" for any of the brogrammer types In Canada the term 'engineer' is regulated at the provincial level, and a person can be prosecuted for labeling themselves as an engineer if they are not registered and licensed with their province's engineering association. For example in Ontario in order to join Professional Engineers Ontario and call yourself an engineer you must meet…
Found it: https://en.wikipedia.org/wiki/Iron_Ring
I think it is a mistake to think that ageism only describes a preference for young over old. The exact opposite has been/is the case for many industries in many countries. Ageism is bad, regardless of age.
I wouldn't want a college graduate to be the one architecting the infrastructure for our company's golden goose.
Earlier quoted context omitted.
I don't think it's ageism if one person is selected based on being willing to work more for less money. That's just a labor market. There's an argument to be made that 20-somethings shouldn't work more than 40 hours a week or should require higher pay. Or that employers should place more value on the work of more experienced developers. Or both. But I don't think experienced developers should be exempt from keeping w…
It's predjudice if you pre-judge how much people are willing to work or how much money they want based on their demographics.
If you are avoiding older candidates because of presumptions about them in terms of work ethic or compensation expectations, you are wrong. If you are advertising below-market salaries and expecting >40 hr work weeks and only attract younger people, there is nothing wrong with that.
Older candidates are not entitled to employment in the positions they want at the rates they want. They need to compete in the labor market with the rest of us.
Earlier quoted context omitted.
That's not ageism; that's a gentle form of hazing, and to be found in almost any profession or trade. An extreme example is what medical students go through in the early years of their study; a mild example is how, when I worked nominally as a cashier in a grocery store as a high school kid, the more experienced folks ran me from pillar to post for my first couple weeks' worth of shifts, doing everything from stockin…
Nah, as the older engineer, I can say with conviction that it is simply taking advantage of younger colleagues. Older engineer is using his connections, status in group or friendship with decision makers to avoid uncomfortable shift. There is no other point. Occasions to find out whether you work hard tend to arise naturally, without putting all weekends on younger colleagues. Also, while mentoring is important part…
Part of learning your craft is learning how not to get owned, too.
> In the nineteen-twenties, an engineer’s “half life of knowledge”—the time it took for half of his expertise to become obsolete—was thirty-five years. In the nineteen-sixties, it was a decade. Now it’s five years at most, and, for a software engineer, less than three. This sort of mythology is NOT helping. An experienced Software Engineer has valuable skills that do not age at all. Yes there are new languages and fr…
Also draws a poor comparison between e.g. a 20-years-experience coder who was writing C++ until a year ago and someone fresh out of college whose been writing node.js nonstop in the three years since getting their degree. There may be one you have more fun playing ping pong with, but (and I say this as a youngster myself) the professional choice is the one where the value for dollar is best and the code is something…
That's very true, but might not necessarily favor either of your two examples. The choice between "20yr C++ veteran and 3yr node coder" is not always obvious or clear-cut, and the quality differential does not, in my experience, clearly favor either side based on that information alone.
I've seen people who left school and coded like crazy for a few years on flaky and fad-oriented stacks--because that was where they could get employed in a hurry with zero experience and a lot of debt. I've seen those people emerge from those environments with an incredibly solid understanding of software design principles and how to do things professionally while balancing time/money/legacy/human/etc. concerns. They learned those lessons not by refining their craft over 20 years of working on an old stack, but in just over 2 years of working on a stack where every day they had to ask their "rockstar" colleagues questions like "Why is this simple thing so hard to do? Why do you keep writing the same kind of bug over and over? What alternatives exist to these tools/strategies?" and not getting good answers. These folks didn't code much outside of work, but they did read about other tools/practices in their free time. By the time they left, they learned excellent techniques (and professionalism) out of acute, concentrated discomfort at what they were made to work on, even while everyone else was taking shots of the piss and calling it brandy.
(And yes, I've seen people in that same situation internalize the cancer and become "X. It's the future!" zombies.)
And I've seen 20+ year veterans who were extremely proficient in a very few (one or two) methodologies, who tried to apply those methodologies to everything--even use cases where it didn't make sense, confused their colleagues, and directly induced bugs ("Making a chat app prototype/mockup for management next week? JavaScript doesn't have CORBA support? Let's write low-level TCP code in Node so we can emulate CORBA using a library I'll write for you. Thrift is too new, I don't care if it's already supported; WebSockets are the 'wrong model'; you need a proper brokered architecture for this . . . proof of concept . . . wait, why is my TCP reading code corrupting data because of off-by-one errors in my read loop?").
I've seen very senior programmers whose "breadth" of tools understanding consisted of re-implementing very specific design patterns from e.g. Java or C in a dozen languages, rather than learning to use the tool that was correct for the job.
I've seen extremely experienced people whose expert understanding of a few things concealed intense insecurity about their knowledge in other areas, and who defensively tried to fit many square pegs in round holes--anything from "we need to use this email collaboration tool I'm super good at that everyone (happily using $other_solution already) has never heard of", to crazy implementations of object/factory patterns in functional languages, to bizarre architecture review and management practices. These people were all competent, and very experienced. They were also scared--not of learning new things, but of being inferior in any single way to their colleagues, even after decades coding. That's a shame, since those folks had the most to teach others, if they'd taken time to have a sense of perspective and/or face their fears.
(And yes, I've seen people with that experience be refined into amazing teachers and stellar coders over the years--people who could get deep understanding of a totally unfamiliar tool in a week, be teaching others to use it in two, and be teaching others when not to use it in three.)
TL;DR the choice is not that simple. But I haven't seen a clear correlation either way between time-spent-in-industry alone and professionalism or output quality. Every industry has old deadweight and young cocky rockstar-wannabes.