Why the Tech Industry Needs to Deal With Its Ageism Problem - <AUTHOR> http://simplicity.laserfiche.com/content/why-tech-industry-needs-deal-its-ageism-problem <comment><USER2> This seems to come up a lot, and I agree that age discrimination is an issue. However, there are some obvious reasons for it outside of the the "we think older people are stupid" line. Younger people will often be willing to work more, for less pay, in more marginal conditions. (Witness the discussion a while back about whether ping pong tables and catered food was a perk or a red flag)

Young people have a greater percent of their experience on the most modern platforms and are unlikely to "write FORTRAN in any language" (JS, Ruby, etc).

We've also discussed how homogeneity is valuable to an early startup. Having everyone be culturally similar may allow faster pivoting and interpersonal comprehension.

Finally, tech startups today are largely focused on the "exit": it's not about building and maintaining a product in the long term. Older employees have the planning, analysis, and maintenance experience to establish a product vision for the next decade. But the startup founder (by and large) doesn't want to think of a product over a decade; it's all about MVP, pivots, and fast exits.

Not that any of that is bad, it just doesn't fit well with the average older employee.

I'll admit when hiring I have a little bit of the opposite bias. Very young employees can sometimes be too aggressive about "what is this legacy garbage? we should rewrite it all in RoR and JS". Hey man, we're still maintaining COBOL apps here, slow your roll. It's all about long term planning and maintenance for us.

<comment><USER3> You are talking rubbish.

> Younger people will often be willing to work more...

Younger people _have to_ work more, because they don't have enough experience to work efficiently, yet.

> Young people have a greater percent of their experience on the most modern > platforms

So, 1 year of "shiny new tech" > 1 year of "shiny new tech" \+ 20 years of other relevant experience? Riiiight.

> homogeneity is valuable to an early startup

Wow. Homogeneity is a killer for any team. The whole point of building a team is to find people who can work together, and become more than the sum of their parts. For that, you need people whose strengths cover for their team-mates' weaknesses... the very opposite of homogeneity.

OK, it's not all rubbish. I agree with this...

> Very young employees can sometimes be too aggressive about "what is this > legacy garbage? we should rewrite it all in RoR and JS

<comment><USER4> I don't think you're be fair at all. Young people don't work more because they suck, they work more for a variety of reasons including: they aren't yet jaded or burned out, they don't know how to pace themselves, they have fewer family obligations, they are more excitable.

Second, no one has 20 years of relevant experience. Maybe computer science fundamentals have stayed about the same, but it was 1993 20 years ago, and what we do now looks nothing like what those of us who were around then were doing. Further, all those years of experience could have, and often do, entrench very bad habits. I've seen some atrocious code from people switching from older workhorse languages to more modern ones, it's not pretty.

Finally, /the _data_ suggests/ homogeneity is valuable in early startups. You're not wrong about needing a team with different strengths, but you also need a team that really understands each other intuitively and agrees on fundamental values and principles. There's too much friction otherwise.

<comment><USER5> >no one has 20 years of relevant experience

I've been designing game APIs for 20+ years, actually. And that's what I'm doing now as a contractor.

I'm still working in C++ like I was in 1993 as well. I first learned C++ in 1989, so that's also 20+ years experience.

>all those years of experience could have, and often do, entrench very bad habits.

Working exclusively with languages like PHP, Ruby, and JavaScript can entrench some pretty atrocious habits as well. I would put my "started with assembly language and moved eventually to high level scripting languages" habits up against a "started with JavaScript" programmer's habits any day.

>Finally, the data suggests homogeneity is valuable in early startups.

What data? I think compatibility between developers is important. But I'm working on a project right now where the median developer age is about 25 (I'm more than twice as old as some team members), and I'm making crazy fast progress on my part of the project, keeping everyone happy. Beyond happy, really; no one expected me to get as far as I have this quickly. And yet I'm putting in 30 hours a week or so.

I think being awesome is valuable, on any project, startup or otherwise, and that "fundamental values and principles" is a red flag indicating "OK working tons of overtime", which is clearly not necessary if you have the awesome.

<comment><USER6> Just out of curiosity, as someone who has been using C++ a lot for two years rather than 20, do you use a lot of the new C++11 features? I started in 03 and can't think to go back to no smart pointers, move semantics, threading library, or > > template closing.

<comment><USER5> I've been using boost smart pointers since long before they became part of the C++11 standard. :)

I haven't been using most of the other C++11 features, primarily because they aren't on all the platforms I'm targeting (yet!). But I will. They look very tasty. :)

</comment></comment></comment></comment></comment></comment><comment><USER7> Personally, I think ageism in the industry is great. Let my competitors ignore the large pool of experienced engineers out there, and hire some young kid who is "cheaper". While he's fixing his design for the tenth time, I'll pay that expense old dinosaur to do something boring, like get it right the first time.

<comment><USER8> Last team I built, that was exactly how I hired. My team of 5, all 35+, could run circles around your typical team of 20. Only downside was it was sometimes hard to get them to try new things.

<comment><USER9> Why would I want to try something new when Perl and MySQL running on Solaris and Apache gets the job done so well? Just kidding :). As I get older, I do find it easier to rationalize using the older, mature thing over a newer, less tested thing.

</comment></comment></comment><comment><USER10> In issues like this, it's important to interpret statistics correctly. For instance, the article cites this:

>"Eight of the companies, the study said, had median employee age of 30 or younger." In comparison, the Times reported, the median age of the American worker was 42.3 years old.

Ageism is not the only explanation for this discrepancy. The software industry has _exploded_ in growth in the last twenty years. Most other industries have not seen the same rate of growth. When a labor pool for an industry is strained, it sends a signal to young people to pursue a career in that field. As a result, the labor pool is filled by proportionally more young people.

Eventually the growth of an industry will cease. Then less young people will pursue it as a career path, and the median age of laborers in that field will rise.

<comment><USER11> The growth appears to have leveled off in the early 1980s except for the momentary dotcom bubble more than a decade ago.

Google and the computinged wordpress blog claim the BLS reported 550K-ish programmers in the mid 80s and about 500K now. We're in a long term decline since 2005 and it looks like we might drop below 400K by the end of the decade, but for the last 30 years its more or less been around 500K.

To quote the computinged blog "Getting reliable data on programmer employment is surprisingly difficult."

Going into the field would have been a brilliant idea in 1975, but in 2013 its kind of like becoming a UAW autoworker, its more like when are you going to be downsized, not if.

</comment></comment><comment><USER12> I wonder if ageism is really that much of a problem. I'm 51 and still working as a software developer but all of my contemporaries have moved on from development to something else.

I've definitely experienced ageism but I suspect that it is rarely institutionalized. Instead I think that people like me are relatively rare. I have no real interest in management or another career--I like being a developer. That means when I show up for a job interview, I don't exactly fit in since it is likely that few of the candidates are my age or older. Sometimes I can overcome this and other times I'm not really given a chance.

I mostly work as a contractor so I have frequent job changes and I haven't found it to be that much of a problem. It is just another hurdle that has to be overcome. The group I'm working in now, I'm the oldest developer by at least 10 years.

<comment><USER5> Contracting is the way to go for the older crowd.

How else could I be making $125-$250/hour? No company is going to pay me $250k-$400k in salary, and if they did, they'd expect to own me 24/7.

This way I get to work part time, have lots of time with my kids, and when I _do_ work overtime, I get paid for the extra hours. So I know they aren't asking it lightly.

At least right now I've had _no_ trouble finding gigs. Work's been finding me, in fact. I have more options available than I can take. And between gigs, I can work on personal projects, one of which may turn into a real business someday. It's all good. :)

<comment><USER13> A number of big companies _do_ pay in the $250-400K range for experienced computer programmers with a solid track record, and give them reasonable hours.

<comment><USER5> I have heard hints of this, but I have a number of other...quirks...that prevent me from seeking this out. I like to be running my own business, for instance; my next product is being funded by my current gigs. Take a job as an employee and they expect you to stick around for a couple of years. I want my next three projects to be released in that time frame.

</comment></comment></comment></comment><comment><USER14> I'm 37. I'm willing to believe there is are two decent reasons for some apparent ageism. I think #2 here is probably in the not-safe-to-share-in- public category, but honest discussion requires embracing one of those every now and then, so here goes:

a) When supply of well trained programmers is increased, it happens with 22 year olds, who are graduating from college. There is a 30+ year lag on those folks becoming old programmers. To hire a 50 year old programmer, he would either have had to graduate back in 1985 when there were a lot fewer people studying programming, or else changed careers at some point. And a lot of people don't change careers. There simply aren't as many older programmers available because it's a new field as these things go.

b) I've wasted enough years on dead-end tech that I'm more cautious about what I spend my time on now. Things I have become an expert in that are now useless to me and probably not valued by an employer:

TCL, Oracle 8i and PL/SQL, Ada, Java 1.1/1.2, EJB, Java AWT & Swing, Struts, Delphi, Flex, Paradox, Access + VBScript, ASP.NET 1.0, ODBC/OLE/ADO.NET, Linq to SQL, Subversion/MKS Source Integrity/Rational Clearcase/Perforce, differences between bash/ksh/csh scripting, awk+sed, perl, prototype.

And those are just the dead-ends that I regret exploring, because I think I will never use them again and because I could have spent that time learning something more useful. I know the time wasn't completely wasted, but time spent on prototype would have been better spent on jquery, time spent on linq to sql would have been better spent on nhibernate, etc. Reflecting on that leads to a bit of analysis paralysis when looking at TodoMVC to pick which next framework to invest time and effort in - will this be another flash in the pan, is this nothing but Fire and Motion (1)? I expect many employers would probably benefit more from a team of people who lack that perspective, because they'll be giving up more of their evenings and weekends on things that might pan out. I still do that, but a bit less these days, and I wait a bit longer before I dive in. Some might value my caution, but they probably aren't starting a bootstrapped or VC backed change-the-world-through-web- programming moonshot business.

(1) [http://www.joelonsoftware.com/articles/fog0000000339.html](http://www.joelonsoftware.com/articles/fog0000000339.html)

</comment><comment><USER15> I'm replying to this one only because it is on the top; I am not singling the author out in any way.

This is all so foreign to me. I moved to SV 2 years ago, and I am 47. Y'all are in such a bubble. Every day the recruitment ads state 'change the world - join our social dog teeth brushing cloud service'. I'm only _very_ slightly joking, merely to avoid calling out the actual companies and services. You know what changes the world? Dialysis machines. Microprocessors. Crash avoidance systems. Artificial hearts. More efficient aircraft. Factory automation.

My point is that it takes experience and time to build something important and large. You can't 'move fast and break things' if you are writing an accounting package or code for a chemical reaction chamber. You don't 'pivot' into a new $1B investment in new microprocessor.

Sure, if you are starting up the social dog teeth cleaning service you probably don't need much more than a few 20 somethings willing to kludge together 10 different half baked components (full stack developers!), and there is no point to knocking that kind of environment - I'm sure it is very cost effective. But I see this kind of thinking and lack of planning leaking into other businesses and ideas. I look at job ads for very difficult undertakings using the SV buzzwords of the day - pivot, agile, and so on, and my neuron starts throbbing.

Moreover, I rather worry about all the people coming up in the bubble, thinking it is bedrock reality. I may be wrong, but I suspect the world's appetite for social X services is small. No, I don't suspect it, I know it. Things like microprocessors, thermostats, smart Tvs, graphics cards, dialysis machines, car entertainment systems, accounting packages, factory floor software, and so much more are the engines of our economy. And I see so many posters on HN that I would _never_ hire for a job that required engineering and planning. They don't have the skills, they aren't learning the skills, and when they are 30-35 all they will know how to do is 'program by magic' \- change things until it works. Ya, no, you can't work on my flight computer.

This is probably just personal, but there is a very sour taste in my mouth whenever I hear about 'pivots' and 'exits'. I get why they are important in some HN type companies. But our world is truly built on products that require forethought ('move fast, break things' \- new motto of Boeing? Not so much), planning, solid engineering, and great technical skill. I wonder why so many 20 somethings pour their talents in lives in something that will be discarded in a month when their myopic 'leader' goes chasing after the latest shiny thing to catch his eye (which is, IMO, the usual reason for a 'pivot'). I guess it pays well. I wish they were working on a better JIT, a lower wattage cpu, or what have you. I wonder at their job prospects when they are 35, have a family, don't have time to go back to school to learn calculus or what have you, and didn't 'hit' and make fuck you money. And I wish founders would actually do a market survey before launching the 5th dog teeth cleaning service in the same tiny geographic area. So many postmortems on here are truly head scratching. You didn't realize that this tiny pocket of under- served market, which is of keen and relevant interest to dozens of companies all around you, maybe, just maybe, has huge barriers to entry or scaling, and that every other company already explored it and wrote it off as unprofitable? Everyone but you is leaving money on the table? Hmmm.

Sorry, I am just having a 'wow, the silicon valley bubble sure is weird' moment. And I'm old, and cranky. Get off my lawn. But seriously, be very, very careful about taking the ideas and lessons from some tiny start up and trying to apply it to anything outside of that very odd, self-referential world.

<comment><USER16> As someone from a liberal arts background who is taking steps to change careers, it's comments like this that are making me want to go into computer engineering rather than computer science. It'll be harder, but as someone whose career suffered from the last recession I've become a bit more sensitive to bubbles and the growing size of the labor pool in CS. I fear that in the next decade being a programmer could become more akin to being a lawyer today.

I'm not trying to make an argument about whether what I say is true. I'm just expressing a few musings.

<comment><USER17> I do think web programming is going to be become commoditized in next 10 years or so. Don't get me wrong, the salaries will still be livable, but for the kind of websites the OP talks about, there's going to be more supply then demand.

That said, I do think there will always be a need for people who are willing to solve tough problems using methods and technologies that may not be cool, but are effective.

<comment><USER18> Great point.

If you're specializing in webdev, it _cannot_ hurt to look beyond and make contingency plans if this turns out to be true. You don't want to get laid off unexpectedly and find yourself technically lacking. What I mean by this: find a more specialized area and see if it's interesting. Could be mobile, machine learning, compilers, etc. Don't be scared of systems programming -- it may come back with a vengeance.

FWIW, webdev has smelled of commoditization and 'cheap' devs for a little bit to me, and it's scary. Everyone gets screwed by this; especially as you get older.

<comment><USER19> What kind of webdev are we talking about? Large backend services or a wordpress website? Or even the Ghost [1] blogging platform? By mobile, do you also include mobile web front ends then? Do you include Twitter & Facebook as part of that kind of commoditized developer?

I'm an iOS developer and have been looking into webdev to spread out a bit. Possibly something like clojure for a backend and node.js for quick simple services.

[1] [http://ghost.org/features/](http://ghost.org/features/)

<comment><USER18> Good question! I'm speaking mostly to the simple CRUD apps that startups often concern themselves with. Complex backend services will be fine. My heuristic is this: if a framework is giving you huge productivity advantages, there's nothing stopping someone from figuring out how to GUI-ify/sugarcoat the parts you write as a good disciple of this week's True Framework. After all, that's what VB did: made it easy for non-devs to make a Windows GUI with a little bit of code. It will happen to webdev, and it will happen to iOS (usepropeller.com).

How do you counter this? Easy: specialize in something requiring hard-fought knowledge. It could be great chops in UX, or deep domain knowledge. But I use the word hard-fought intentionally: this is know-how that is not easily digestable from a blog post.

Industry may require you to be skilled in certain frameworks, but it's not the same at all as having strong, general programming skills you can apply everywhere. Personally, I'm looking to Clojure for the infinite meta- programmability, and resulting brain-refactoring that ensues.

It's about a lifetime of education, and always challenging yourself. That's the real payoff. Industry will run in circles, convincing itself it is innovating, while ignoring a lot of cool stuff done in the past. Dig into it, learn, and write about it.

</comment></comment></comment></comment></comment></comment><comment><USER20> The problem isn't that young employees have qualities that make them more appealing. That's just the reality of the situation.

The problem is when a candidate who has better qualities gets passed over for a younger candidate based on prejudices based on the previous generalization.

Say you want a skilled programmer who is going to work for a certain wage and put in an amount of overtime, and you pitch it to a fresh college grad, and a 35 year old who just got downsized out of a job; when the interview concludes, it's obvious that they are both willing to take the wage you're offering, and the 35 year old is far more knowledgeable.

If you take the kid because you think the older guy might not be as willing as he claims to put in overtime, or because you think he might be too set in his ways, or because he might be too old to match the cultural fit... That's a problem.

People can hire young people because they're cheap. Especially startups, who maybe can't afford to pay for experience. Likewise, someone with a mortgage and kids might be less willing to look for a job with a risky business. So the average age might drop in those kinds of businesses and that's OK.

The problem is when you see the effect and invent the cause. "More young people are in successful startups, that means avoid old people if you want to be successful".

Instead it could be just "frugal startups are more likely to succeed, so don't spend too much on your labour" in which case given two candidates willing to take the same wage, the one with the better skills should win, regardless of age.

</comment><comment><USER21> While I agree with the sentiment, the statistics quoted don't support the author's thesis.

> The average age of a successful entrepreneur in high-growth industries such > as computers, health care, and aerospace is 40.

> Twice as many successful entrepreneurs are over 50 as under 25.

> The highest rate of entrepreneurship in America has shifted to the 55–64 age > group, with people over 55 almost twice as likely to found successful > companies than those between 20 and 34 – in fact, the 20-34 age bracket has > the lowest rate of entrepreneurial activity.

If ten times as many people over 50 than people under 25 try to start businesses, then the statistics strongly favor the under-25's. These statistics don't mean anything unless you know the number of people in each age group who start businesses.

> 75% have more than six years of industry experience and 50% have more than > 10 years when they create their startup.

What does this even mean? Years worked is not the same as having useful experience.

The article would be much stronger if it showed evidence that older workers were more productive, more likely to succeed at starting a business, or were in some other way undervalued by the current job market.

</comment><comment><USER22> Sadly enough, I've experienced this. At my last job, after requesting a pay rise my boss just said no and followed up with 'well you should think yourself lucky, your pay is pretty good for someone of your age.' I quit about 2 weeks afterwards.

</comment><comment><USER23> Unfortunately, the list of companies with the oldest workers -- IBM, Oracle, Dell, HP, among them -- would evoke eyerolls from most young hip tech workers today. What's Apple's median age?

Of all the big young tech companies, I would think that Google would be the one to benefit most from older, experienced employees (besides the group of all-stars it already has, such as Norvig)...Google's business encroaches on a lot of other domains, and domain knowledge is something that (usually) gets better with age. Perhaps in 5 to 10 years, there will be a bigger group of 40+ yr old professionals with enough tech experience/savvy to be more obvious assets to tech startups.

<comment><USER24> > I would think that Google would be the one to benefit most from older, > experienced employees (besides the group of all-stars it already has, such > as Norvig)

+1. Google and Microsoft do a great job in this regard. Not just hiring older workers but getting _new_ stuff built by people with massive amounts of experience.

\- Ken Thompson and Rob Pike (C/Unix fame) are bringing you Go.

\- Anders Hejlsberg (TurboPascal/Delphi) is bringing you TypeScript.

</comment></comment><comment><USER25> > _It seems the young engineers, growing up in an era of unlimited storage, > didn't know how to tackle the problem._

Starting off with some ageism and general cluelessness of your own doesn't help. If they wanted a "young engineer" to generically optimize data storage, I would be at least half-competent, and could give them the names of several engineers far younger than 77 who would be excellent at such work in general.

What neither I nor virtually any other engineer, young or old, would know, and what the engineer who helped build the thing would, is anything about the specific equipment and code in use on Voyager. This is specialized knowledge, just like a lot of the knowledge young 2013 NASA engineers have.

It is equally as beneficial to employ those engineers to modify the systems they built as it was to employ Lawrence Zottarelli to modify the system he built. Age is unrelated.

</comment><comment><USER26> I think this problem will take care of itself. It is a numbers game. Eventually all these twenty-somethings will be thirty-somethings; and with that they will need the long term work relationships needed for raising families and planning for pivot into the Golden Years. Statistically the vast majority of them will have to work for money and I very much doubt that people will just exit the game at 30. They will just have to adjust their expectations.

<comment><USER27> I have no doubt Zuckerberg will be changing his tune in the years to come.

"Young people are just smarter"

That has to be one of the most stupid things I've heard! :)

</comment></comment><comment><USER28> So, at last count of criticisms our industry is ageist, sexist, able-ist and racist. Did I miss anything?

<comment><USER29> If that's all you're taking away from these criticisms, then yes - you likely are.

</comment></comment><comment><USER30> I am surprised that so many of the comments seem to be ignoring the obvious: more experience generally means higher wage in the tech industry. It's a money issue.

I've personally worked with older programmers, and there has been little noticeable difference in capabilities (and often added benefits of organizational know-how). The issue is the pay.

Incidentally, it's the same reason why big companies are championing H1B visas by saying "there aren't enough US nationals to fill the roles" (even though the numbers don't bear the statement out): companies want to pay less for somewhat equivalent skills. Who wouldn't?

</comment><comment><USER31> I'm getting on the old side of the average, approaching 40. But in my experience I've never seen a startup founder tell me that I or anyone else was too old. Mainly because the industry really is a meritocracy and it's about what a person can do _now_ , usually. Fortunately for me most juniors don't know _all_ my tricks just yet.

I will say this though - I have to constantly step my game up to stay relevant. At 50 I will be expected to not only know programming very well, but the industry as a whole including analysis, planning, finances, management, etc.

<comment><USER32> > I have to constantly step my game up to stay relevant

This doesn't strike me as the case in other skilled professions. A successful middle aged CPA, MD, lawyer, or finance exec often has the option of more or less coasting on accumulated relationships and prestige.

This idea that a skilled software engineer must always be training up on his own dime and time is really kind of strange, in the bigger picture.

<comment><USER31> I never looked at it that way but one could draw analogies to things like new techniques in medicine. Such as a new robotic operating mechanism or new ways to treat people. On the other hand CPAs seem to have had their work set in stone since people used tables and numbers, I feel for those guys. Lawyers probably have so much research to do I doubt they ever really stop learning (albeit it's charged to the client) .

But learning is probably what keeps me from getting bored. I will say though, if I have to learn _another_ JS framework I'm going to === my eyes out.

</comment></comment></comment><comment><USER33> This is awful. What does the list of out-of-context statistics about entrepreneurship have to do with hiring tech workers? Who is the "Tech Industry" and how are "they" going to deal with an ageism problem defined by the article as simply statistically skewing young?

</comment><comment><USER34> The sweetest thing to see is an old master working alongside a young buck in tandem. You get the best of both worlds.

Anyone who is on either side of that equation is fooling themselves on the reality of engineering and team dynamics.

</comment><comment><USER35> It's not an ageism problem, it's a loyalty and perception problem. Old people by their nature cling to institutions of loyalty and start-ups are definitely not known for staying around for +3 years.

Furthermore start-ups also implicitly prefer "just good enough" in order to get your company up and flying enough to quickly accrue investor interest, whereas stability forms the bottom-line of our elder engineers -- and stable systems require far more time than some investors are comfortable with.

Even worse, there is the management aspect. Older people have very different management styles, and throwing caution to the wind is definitely not among their managerial toolset. If your company has older people in positions of power then it definitely scares vast swaths of people away -- from eager investors looking to turn a quick buck and energetic young engineers looking to for autonomy to work without anyone second-guessing their decisions.

Finally, the saying "old is gold" applies quite well, however that gold needs regular polish to remain shining.

<comment><USER11> "Old people by their nature cling to institutions of loyalty"

You're a little out of date. That applies to the gold watch retirement crowd from WWII and "Mad Men" era and all that. None of those guys are under 80. The kind of people who think "talking pictures" on celluloid is high tech.

We are talking about (former) kids who listened to Nirvana on CDs while Kurt Cobain was still alive, not listened to Gunsmoke on the vacuum tube radio during the great depression LOL.

<comment><USER27> THANK YOU. I was going to point this out. Waaay out of date :)

</comment></comment></comment><comment><USER36> The reality for older developer is that you are going to have to:

1) Move to management to continue advancing

2) Find one of the very few large to midsize companies that has a long-term developer career track comparable to their executive track

3) Start you own thing and exploit the fact that you are more productive than younger developers, and _control the purse strings_

Large and even mid-size and event ostensibly tech companies still, for the most part, view developers as an R&D cost center. They look at cheap development resources, either young kids or foreign, and think "For the price of 1 developer, I could have 10!"

Now they have 2^10 problems.

<comment><USER37> In nearly every profession there is a ceiling for the doers. There is a position in a senior/lead/architect role and a pay rate you hit within companies that you can't exceed besides some annual 1% raise.

Those who are still motivated to move up must go in to management or strike out on their own. Chances are if you have reached this point the trappings of your previous success has made the latter choice a risky undertaking.

</comment></comment><comment><USER38> In general I, at age 26, agree that experience gained with age can provide a strong benefit in terms of code organization, management, interpersonal relations, and many other factors. I think it's a gross misrepresentation, however, to say:

 _... Suzanne Dodd, had to coax another 77-year-old engineer, Lawrence Zottarelli, out of retirement to modify the old technology so it could store more data. It seems the young engineers, growing up in an era of unlimited storage, didn't know how to tackle the problem._

Last time I checked we still don't have unlimited storage... and Is this really because the young engineers didn't know how to tackle the problem, or because the code was poorly documented and written in a way that would be confusing to anyone who was not the original engineer? Programming styles have changed; people used to have to use their memory very efficiently and therefore had tricks to use it more efficiently that aren't as popular now (sacrificed for readability/maintainability), that doesn't mean that young people can't learn those tricks, just that they haven't had to.

</comment><comment><USER39> The funny thing about the efforts to increase diversity among developers is that it's just increasing the inputs of the ageism meat grinder we're all headed into. So everyone besides white males gets to have a harder time joining the profession, only to get chewed up and spat out like the rest of us. Lucky them. (OK, I admit that's actually not funny at all)

</comment><comment><USER40> Experience, skills with the newer technologies, "cultural fit" (in the true, organizational meaning of the concept): I see these as objective measures. They are important.

What cannot be overlooked though is the emotional aspect of interviewing. It leads to all sorts of biases, and in a subtle way drives racist and ageist hiring practices. I think that "comfort level" with the applicant is a particularly hazardous feeling as it can be confused with cultural fit. If not checked, hiring people within our comfort zone produces a homogenous work environment and an insular organization.

I often find myself thinking more clearly about candidates when I actively counter the "this person is not in my tribe" notion that I believe is behind "comfort level". After all, we are not a fraternity or sorority hiring to make friends.

It comes down to being professional and objective, and being mature enough to hire and work with people outside of our generation or culture.

</comment><comment><USER41> A low average age isn't an indicator of ageism by default. It would make sense that people of different ages would be interested in different types of employers. Consider the following job characteristics:

1\. Business travel is a plus to the young crowd and a minus to the older.

2\. Legacy technology is a plus to the older crowd and a minus to the younger.

3\. Large vs small teams. A younger group will have more generalists, and older group more specialists. A younger team will be small with minimal layers in the way. An older team will need a larger group to support the specialization gained over the years of experience.

Picture a large company that designs motherboards. No travel, established technology, large teams of specialists. Now envision a distributed team of <10 working on some new document classification web app on AWS. I'd wager that a completely different age group would be found in each circumstance. Not necessarily due to ageism.

</comment><comment><USER37> Some of my experience on hiring "older" engineers (I currently have over 10 years experience in software eng/dev):

1\. They have a family with responsibilities, sick kids, and dance recitals, etc.

The bad:

Leads to, less professional growth outside of work, more personal days, more sick days, more personal phone calls during work.

The good:

Once comfortable, they rarely leave the job unless forced out.

2\. They attempt to solve every problem with the same set of solutions. Few attempt to find new technologies or try different things.

The bad:

The implementation may not be the best one available that will set up the business for future success.

The good:

Solutions are generally predictable.

3\. Lack of motivation to prove themselves.

The bad:

The project deadlines are just met. They do just what's asked of them and not more.

The good:

Deadlines are met. They don't try to tackle mroe than they are capable of by expanding the problem domain.

<comment><USER27> 20+ years here.

While I'm sure there are some 40-something's that are like the above, I don't know of many - most people I work with are 35-45, are very hard working, innovative, highly motivated, always learning new things, and work a lot.

Lots of younger people I work with party a lot (and are hung over lots), distracted constantly, aren't at all loyal, are constantly distracted by the shiny new toys, and super arrogant

(and YES, I am purposely using a bad stereotype, just like a lot of the posts here are in the other direction. One thing experience has taught me is to NOT stereotype based on meaningless things like sex, race, or age - look at what someone can do - passion, drive creativity, intelligence, etc. If you base your decisions on foolish stereotypes, in either direction, you are just limiting yourself and your company)

</comment></comment><comment><USER42> I think many workplaces have an idealized picture of what kind of person is a programmer, manager and so forth.

I worked at one place where boomer IT staff were happy. One guy told me, "It's great, I just plan to coast a few more years to retirement."

Gen X and younger people were miserable at this place. One guy who was 27 was fed up with not being taken seriously so he (1) started an MBA program (which the employer had to support at least partially) and (2) deliberately gained weight, and (3) went to a hair salon and had them do a fancy tint job on his hair with aluminum foil and stuff so he'd get grey highlights.

</comment><comment><USER43> I know personally, I intend to create a company after I get experience from industry. I am a 21 year old college student, so that means ill be somewhere between 28-35 when I start a company. At which point I will probably higher younger for cheaper. Perhaps that is part of the reason those companies have such younger workers. Most Programmers either do consulting, start their own business, burnout, or change career paths by 30 based on the 20 or so I talked to.

I could be totally off, but from what I know and have seen this seems to be the trends.

</comment><comment><USER44> Throwaway account. I recently had an interview with a start up from the latest YC batch. First words out of the founder's mouth, after hello: "So, how old are you?"

For a moment, I was speechless.

Not sure if it was just social awkwardness and shyness that made our young founder jump to that question. But in what universe is that ever an appropriate question in a job interview?

(I'm in my early thirties.)

<comment><USER27> That founder should be very careful, if he doesn't want his company mired in a bunch of lawsuits: [http://jobsearch.about.com/od/interviewsnetworking/a/illegal...](http://jobsearch.about.com/od/interviewsnetworking/a/illegalinterv.htm)

(not suggestion people should just start suing, but this is up there with not wanting to hire someone because of the color of her skin).

</comment></comment><comment><USER45> The bigger concern is that a prospective employee must show a willingness to adapt and evolve from a technological aspect, as opposed to feeling that whatever they already know is "good enough"

An unwillingness to train does exist in the more seasoned veteran demographic; but it's just as bad when you get young developer that is a evangelical about their particular niche.

</comment><comment><USER27> A good read on age and genius: [http://www.wired.com/wired/archive/14.07/genius_pr.html](http://www.wired.com/wired/archive/14.07/genius_pr.html)

</comment><comment><USER46> Great closing line: "Avoid ageism. It isn't rocket science. Even when it is."

<comment><USER47> I'm not sure if you're being sarcastic, but I thought the closing line was terrible. It's a very complicated issue, and not something you can just say to avoid.

<comment><USER48> So you are suggesting that discrimination on skin color is complicated? That discrimination based on prospect is older the the person conducting the interview is not something you can just say avoid? That a woman wouldn't fit into your macho 'Brogrammer' culture? I'd go on but you seem to be a fan of very short sighted thinking.

Check that. I would like to suggest that wisdom from the prehistoric days of programming seems to fit best here: 'Use the right tool(individual) for the task' Nothing else is relevant. The only subject worthy of discussion in an interview is can they do the job. If the answer is yes then you can solve 'other' problems after they become a problem...

<comment><USER49> People have unconscious biases. Merely telling them to avoid those biases is unhelpful. Giving them ideas how to avoid those biases is more helpful.

"Have someone screening applications. That person also removes anything that identifies protected characteristics" is one tip. (In the UK those are age, disability, gender reassignment, marriage or civil union, pregnancy and maternity, race, religion, sex, and sexuality. In the US they are race, colour, religion, national origin, age, sex, sexuality, pregnancy, citizenship[1], familial status, disability, veteran status, and genetic information.)

</comment></comment></comment></comment><comment><USER50> Experience matters a lot in software development. For example, after many years as a software developer this is one of the valuable lessons I've learned:

Outside data is ALWAYS dirty.

There is no clean data. And part of the value of experience is knowing how to handle this. For example, assume I get a very large data set from a third party that is crucial to my project. Unfortunately, all the fields are strings. Years of experience have taught me the following ways to deal with this:

1) Implement a lot of logic and validation into the program itself or as a pre-process step. This is a lot of work, requires a lot of domain knowledge, you may still miss a few edge cases, it will force the deadline to be pushed back, and increase the budget. However, those are the disadvantages. The advantages are that this could become a competitive advantage. Maybe no one else knows or has tried to clean up this data before. Identifying and doing this work can lead to a whole new business. A classic example of this is GIS data. GIS data is very very dirty. Street, St, St., Highway, Hwy, Freeway, Fwy, all typical examples of how dirty the data is. Companies like Navteq are based on their ability to clean up GIS data. Apple's Map app was a disaster because Google is so good at and has years of experience cleaning up GIS data.

2) Push back on the third party to clean up their data. Doing this takes some finesse and social/business skills. You can't just say, the data is hard to handle. That sounds like whining and laziness. Your manager can't do anything to help you if that's all you have. Instead one tactic is to make a schema (this is what WSDL and XML Schemas were invented for) and tell the third party that their data must conform. Then it becomes their problem. They might push back, but now your manager has something to fight with. But if they agree to conform and the schema is bad, then it will become your fault (the third party will just say, hey it conforms to your schema so that's your problem). So you better make sure the schema is good (experience helps here). And it may require meetings with the third party's technical team to compromise or figure out what a good schema is (which requires social/business skills and experience).

3) Identifying these problems early. If these data issues are not considered or found early, they will lead to big issues later. This is why senior developers get their work done fast and go home early. They don't make mistakes like using floats for currency or assuming a string is always a certain format. Junior developers make those kinds of mistakes and spend 80 hour weeks fixing it in the code, rewriting unit tests, and running scripts against the database to carefully migrate the data. They may seem more "productive" but they created the work (like the broken windows fallacy).</comment>


Terminal Escape Sequences: What You See Is Not What You Get - <AUTHOR> https://ma.ttias.be/terminal-escape-sequences-the-new-xss-for-linux-sysadmins/ <comment><USER2> The HN guidelines ask the submitter use the original title, which in this case is "Terminal escape sequences – the new XSS for Linux sysadmins".

Among other things, preserving the name makes it easier for readers to identify duplicate postings. The same URL, with the original title, was submitted five times 12-13 days ago ( [https://hn.algolia.com/?query=Terminal%20escape%20sequences%...](https://hn.algolia.com/?query=Terminal%20escape%20sequences%20%E2%80%93%20the%20new%20XSS%20for%20Linux%20sysadmins&sort=byDate&dateRange=all&type=story&prefix=false&page=0) ). Only [https://news.ycombinator.com/item?id=10273336](https://news.ycombinator.com/item?id=10273336) has comments, and even then only two.

Which you knew because this is the _fourth_ time you submitted this URL.

I see that you have made many links to the ma.ttias.be domain, that many of them are duplicate posts, and that you are experimenting with URL tracking. This feels like you are abusing your ability to post to HN. At the very least, it's behavior that I strongly dislike, and don't want to see here.</comment>


An update on Redis and Lua - <AUTHOR> http://antirez.com/post/an-update-on-redis-and-lua.html <comment><USER2> > My solution was to convert null (multi) bulk types into false, and the other > way around, false returned from Ruby is turned as a null bulk reply.

should read:

> My solution was to convert null (multi) bulk types into false, and the other > way around, false returned from Lua is turned as a null bulk reply.

</comment><comment><USER3> This is an interesting turn for Redis.

In my mind, this is the lightweight, NoSQL analog to stored procedures.

<comment><USER4> I'm sure you simply meant to make this comparison based on the fact that both implementations execute scripted functions on the data store server. However, I think there is a very important distinction that warrants a clarification: Stored procedures are saved on the server and then referenced by name. Redis scripting requires that the code be transmitted in each request.

Antirez goes over this in his original post, here: <http://antirez.com/post/redis-and-scripting.html>

<comment><USER5> "Redis scripting requires that the code be transmitted in each request."

Only until antirez implements the EVALSHA command.

<comment><USER6> Implemented ;)

</comment></comment></comment></comment><comment><USER7> That's cool, but not nuts about JSON. They should include at least one space- efficient format, like messagepack (which is 100% compatible with JSON after encoding / decoding). Of course, this opens the floodgates...

Also, is zlib available?

<comment><USER8> In recent benchmarks, Node's JSON implementation is almost twice as fast as messagepack. I think I'd rather have the more universally used format anyway.

<comment><USER7> It's not about speed, but space efficiency, msgpack is significantly smaller. That's useful for a mostly in memory database. As far as speed that's negligible.

<comment><USER6> Hello, if you care about size, the best way is to just use Redis Hashes, that internally store fields and values into a binary very compact representation.</comment></comment></comment></comment>


Performance cost of Ruby ORM model instantiation  - <AUTHOR> http://merbist.com/2012/02/23/quick-dive-into-ruby-orm-object-initialization/ <comment><USER2> Thanks for posting my article. Quick update, someone did more benchmarks with different versions of Ruby and adding MongoMapper: <https://gist.github.com/1894055>

<comment><AUTHOR> Thanks for the update. I like seeing articles that cover tangible, measured detail. It's the kind of the stuff that's often overlooked in favor of gee- whiz syntactic sugar.

</comment></comment><comment><USER3> And in the same way: measure how long it takes to get an answer from your DB before you start worrying about these number.

<comment><USER4> It's been a long time, but I think your assumption is probably flawed.

DataMapper isn't faster by accident. This benchmark is trivial. Try loading up 1,000 objects with an actual query for each O/RM and benchmark that. Then try a single object 1,000 times.

Instantiation is neat, but "back in the day" my findings were that you often spent just as much time _if not more_ simply building the objects on the Ruby side as any reasonable database query you might be executing.

In fact the cost was so prohibitive it quickly became obvious that simple things in ASP Classic like selecting 2,000 rows and rendering them in a table on a web-page could in many situations be so slow as to be impractical in Ruby. Especially since the entire request is buffered (that's more or less still true today, the flushing available in Rails isn't nearly the equal of writing directly to a TCP socket).

Method dispatch kills.

The example of selecting a single object 1,000 times nicely illustrates this since it stresses the "front end" of your query-interface as opposed to the "back end" of materialization.

The price of admission in Ruby is _absurdly_ high. It doesn't take years to build an O/RM because it's easy. ;-)

<comment><USER3> > It's been a long time, but I think your assumption is probably flawed.

My assumption? My assumption was merely that you should measure it _before_ you start worrying about it. I'm not trying to say that isn't a problem (it might very well be), just that you should measure first.

> In fact the cost was so prohibitive it quickly became obvious that simple > things in ASP Classic like selecting 2,000 rows and rendering them in a > table on a web-page could in many situations be so slow as to be impractical > in Ruby.

I agree, rendering 2,000 rows isn't the the regular use-case for ActiveRecord. If you're attempting to do so, it would be silly to create objects for all of them. AR isn't "magic sauce"; it's a convenience library for making things easy to work with.

> Especially since the entire request is buffered (that's more or less still > true today, the flushing available in Rails isn't nearly the equal of > writing directly to a TCP socket).

Buffering is the only sane default if you want safety. If you don't buffer, and there's an error in the middle of the response, you've already sent a broken page with a 200 response (cacheable and everything).

<comment><USER4> > Buffering is the only sane default if you want safety.

 _A LOT_ of sites on the web survived for many years without it. And they felt more responsive because of it.

I think it's a fair trade-off to optimize for your user experience instead of the machines. Honestly, Google is not going to ding you for this, and as long as you've got an exception notifier going and are on top of it, there's no reason it should become a real problem for _most_ sites. Being able to make a choice per-request/action would be nice of course.

> My assumption was merely that you should measure it before you start > worrying about it.

I have. I wrote the original versions of DataMapper (which BTW, _was_ a DataMapper despite popular belief. The methods hanging off the models were just helpers to the Session originally but it lost it's way at some point).

I can tell you for a fact that it's slow. Sure, go ahead and measure it. I'm not saying that's _bad_. Just apply some judgement to the situation. Are you grabbing a lot of rows? Are you performing lots of individual selects? (Or using AR+include options where each include is effectively the same as another query?)

You can feel free to write slow code until it becomes a problem, or you can develop some good practices _up front_ , before ever needing to profile, to prevent much of that. Disregard for reasonable optimization and forming good habits based on generalized rules of thumb is just as evil as premature optimization. We're not talking about twiddling minutia here.

> it would be silly to create objects for all of them

Why?

Hibernate can do it. NHibernate can do it. LLBLGenPro could do it (probably the closest to Ruby's Sequel, but here it was a non-issue even with Models). Simpler AR style O/RM's like Wilson O/R Mapper could do it.

Given that AR doesn't really provide a decent DAL tool that I can recall, I'd say it's perfectly reasonable to expect that the "Full Stack" framework you're using covers the bases without nasty surprises. Especially if you've come from a background where millions of method-dispatch events imposes nanoseconds of overhead instead of milliseconds of overhead (Java and .NET at least).

I don't think it's at all "silly". I think it's a perfectly reasonable goal.

</comment></comment></comment></comment><comment><USER5> My experience has been that ORMs generally 'suck' outside the trivial CRUD use-cases, and it's usually faster and simpler just to write native queries again your database.

I've used hibernate, linq, active record and mongoose in real production applications, and pretty much every time the same sequence of events happen.

1) Wow, this ORM is so cool, I've saved so much time as I dont need to learn anything about the underlying DB.

2) New feature comes in that requires something other than CRUD. Oh how do I do this with the ORM. Either you extend it with plugins, or learn the ORM query language that's kinda like the native query language but worse.

3) Now we got some real data, why is it slow as hell? Oh, those 'cool' abstractions are creating n^2 queries, implicit joins, etc

4) Let's rip apart the ORM, and use a thin layer that just execute the native queries.

A few years back I worked on a quant finance application that had 100GBs of tick data in a oracle DB, and the only way to get reasonable performance AND abstraction was to write optimised stored procs for each feature in the end application, and have the middle tier just call them through a thin abstraction layer.

At our startup dump.ly, we started with using Mongoose with Mongo because it was so easy just to persist some JSON data. However very quickly we went thought the above loop, and are now 100% Redis, with a thin layer that executes native Redis commands. It just ended up being simpler and faster.

Takeaway is that in general ORMs are an anti-pattern. Every DB (noSQL or yesSQL) is a compromise between a set of features, performance, consistency, scalability etc. You need to understand these in detail and hence should not be abstracted away.

</comment><comment><USER6> Sequel looks pretty interesting. I've really fallen out of love with ActiveRecord ... mostly because it really only simplifies the most basic scenarios and as an abstraction it's so very "leaky" as Joel would say. I've begun work on an idea for an ORM that just simplifies the most tedious parts of writing SQL but requires no boilerplate classes and is light and speedy <https://github.com/iaindooley/PluSQL> (but it currently only supports MySql because it requires buffered query sets)

</comment><comment><USER7> "Never assume, always measure" - Never a truer word spoken!

<comment><USER8> Words to live by…

</comment></comment><comment><USER9> I worry that this sort of article could be misinterpreted easily, even with the disclaimer.

It's talking about optimizing something that takes less than 1% of the vast majority of an application's cycles. Which doesn't really mean anything... Be careful using this sort of benchmark to disproportionately affect decision making.

<comment><USER2> I hear you, but my point wasn't to show how to optimize AR but instead what's going on when you initialize a model. In other words it's more about software design and architecture decisions than performance.

<comment><USER9> "Performance cost of Ruby ORM model instantiation" may not have been the best title :)

<comment><USER2> Agreed, the post title is actually "Quick dive into Ruby ORM object initialization".

</comment></comment></comment></comment><comment><USER10> Thanks for the great post!!! It is really usefull</comment>


Dino Dai Zovi on Mac OS X Eploitation [pdf]  - <AUTHOR> http://nchovy.kr/uploads/3/301/D1T1%20-%20Dino%20Dai%20Zovi%20-%20Mac%20OS%20Xploitation.pdf <comment><USER2> I wonder why most of the real "hacking material" links I came across here on HN tend to be ignored -- earlier today (or late night if you are in the US) there was a post about a severe vulnerability discovered in Intel CPU and got no more than 6 points or so.

Has anyone else noticed it?

<comment><AUTHOR> Well, HN has changed over the past 6 months or so. Highly technical stuff doesn't rise up to front page as it used to. My suggestion is to monitor user submission feeds of people you like or share similar interests with. That way you will have a more customized experience and won't be disappointed by some of the front page stories.

But this is a superb presentation about how security in an OS works. I enjoyed it a lot.</comment></comment>


Samsung's 75-inch MicroLED 4K TV is a huge step into the future - <AUTHOR> https://www.theverge.com/2019/1/6/18168793/samsungs-75-inch-microled-4k-tv-pitcure-quality-ces-2019 <comment><USER2> Seems like the perfect panel to build my HAL-9000 desktop ;-)

My biggest problem with LED panels is that, the last time I participated in a round table, my back was close to the wall display and I am sure I got a Roentgen tan from the massive output of the LEDs.</comment>


Ask HN: What are your favorite JetBrains IDEs "lifehacks"? - <AUTHOR> I use IDEs from JetBrains (such as IntelliJ, or PyCharm) as my daily development tools, and even after 2 years of using it, I still occasionally find some "hidden" feature, or shortcut, that simplifies my life a little bit, such as custom tab-completing templates, or class diagram generator and so on...<p>So, what are your favorite lifehacks on JetBrains platform, that are not universally known? <comment><USER2> Do a search for something.

I used to double click on the found text, select and copy.

Now I just select the search result line and hit copy.

Much faster.</comment>


Startup Quote: Jim Collins, Author, Good to Great - <AUTHOR> http://startupquote.com/post/10195045526

<comment><AUTHOR> The essence of profound insight is simplicity.

\- Jim Collins

<http://startupquote.com/post/10195045526></comment>


Where are all the Women?  - <AUTHOR> http://venturefizz.com/blog/where-are-all-women

<comment><USER2> Some portion of this is culture, but some portion is definitely biology as well. Men, across different cultures, are consistently more prone to risk taking, and show higher variance in ability. (Interestingly women have higher average IQs than men in our culture, but men have higher variance and are a majority of people with _very_ high IQs.) There is an evolutionary rationale for this, but what is important is that this has been observed.

Therefore when you look at a high-risk activity that is very ability driven, such as startups, there is no surprise that men are over-represented. This is probably not all of it. But even in a perfect world, there would be a clear bias.

That said, there are many areas where women have a natural advantage over men. Many markets exist where the majority of likely consumers are women. (For random examples women are more likely to do shopping, organize weddings, and sustain stronger social networks.) Any startup that wishes to succeed in such an area would be well-advised to have a lot of female input. And a female co- founder could be a significant asset in such a situation.

</comment><comment><USER3> I'm far from being an expert on statistics (and related stuff), but I'm still a bit leery of the "Women Build Great Companies" section. Don't get me wrong, I'm not saying they don't or that I'm against having more women start companies or anything of the kind. It's just this: all of the author's claims in that section are backed by statistics. That makes me wonder, if there are "so few women entrepreneurs starting high potential, high growth companies", doesn't that make it likely that there's some statistical bias in favor of those companies?

My reasoning is like this: if you can get into the XYZ college either by being rich or exceptionally smart, wouldn't a statistical analysis tend to "show" that poor people are exceptionally smart?

<comment><USER4> It's like you're psychic or something, posting exactly what I was thinking while I was still composing my response :)

</comment></comment><comment><USER5> "women-owned businesses accounted for 21 percent of the entrepreneurs that sought angel-investment capital in 2009, but only 9.4 percent of those females were successful in their quest"

But what percentage of men who seek VC get funded?

<comment><USER6> This really ruins that entire statistic. It's comparing two completely unlike things. The first number is women vs. men, but the second number is not.

</comment></comment><comment><USER7> 3\. "They are more likely to reproduce and therefore more risk-averse."

Not a mention of this seems a little disingenuous.

</comment><comment><USER4> Ok, so we see that only 9% of women who apply for VC get it. Then we hear about how startups run by women do so much better than those run by men. Now, suppose the reason so few women get VC is because the male VCs are less disposed to give women money--and those who do get money are those who provided such a fantastic plan that it was a _clear_ winner. Since this essentially makes the entrance criteria harder, you'd expect that those few enterprises which make it through are going to do extremely well... something along the lines of all those uber-startups run by women.

I'm not saying women can't make good companies, I'm just saying that the implied bias on the part of male VCs would tend to select only the very best woman-founded startups. Level the playing field, and you'll probably get the same performance as men.

<comment><USER8> Important related question I don't see in the article: what percentage of men who apply for VC get it?

</comment></comment><comment><USER9> They have kids. White male is king of the jungle, get over it.

<comment><USER10> White male? Last I checked, Yellow made more money on average than all the other colors in the crayon box, kiddo.

Check your facts for stale stats.

</comment></comment><comment><USER11> They're in my basement...</comment>


Case Study: The IBM ProPrinter (1998) - <AUTHOR> http://www.computerweekly.com/feature/Case-Study-The-IBM-Proprinter

<comment><USER2> And a video of someone demonstrating this by putting a Proprinter back together:

[https://www.youtube.com/watch?v=spDYSKl3kmo](https://www.youtube.com/watch?v=spDYSKl3kmo)

<comment><USER3> That was a fascinating video. It starts a bit dry, so skip the first 2:30 if you're not so interested in the business speak.

</comment></comment><comment><USER4> This IBM no longer exists, physically or spiritually.

Physically speaking: near as I can tell, the printer plants in Armonk, NY and Charlotte, NC are long-shuttered. If anyone has evidence to the contrary, by all means, post it.

Spiritually: The low-end printer division was part of the 1991 divestments. It became part of Lexmark. As far as I know, Lexmark no longer manufactures anything in the US. They just slap their name on various imported OEM designs.

p.s. This case study was written in 1998 about events in the late 1980s. The Lexmark divestment had already occurred. The manufacturing capacity was probably already dead before the study was published.

<comment><USER5> The Charlotte facility doesn't make printers any more (I worked nearby at Wachovia/Wells Fargo CIC for a while).

A story I heard from an IBMer was that the robotic assembly systems weren't ready at time of product launch, so they were hand-assembled using temp workers. IBM thus discovered that designing for robotic assembly meant that humans had a much easier time of building the product. They did eventually install the robots to save on the labor cost, though.

I installed hundreds of those printers while on another contract. They were a little dated by then, but still a solid office printer. We only had to replace a few of them, and that was because of a lightning strike close by the customer's office. Very reliable.

I don't miss the massive Centronics parallel cables one bit - what a pain it was to route those things up from under people's desks.

</comment></comment><comment><USER6> > In order to reduce costs, plastic parts were incorporated into the > Proprinter design.

This article pushes the pros of these decisions and not the cons.

As a result of similar decisions, you end up with devices being throw away because the case had a single little plastic tab break.

As always, it is a tradeoff.

<comment><AUTHOR> The fact that they used plastic doesn't mean that the design was based on disposablity. You can still purchase ancient working ProPrinters on Ebay and there is still a long tail market for the [ribbons].

It was really HP that developed the throw away printer market with the Deskjet 600 series. The first generation Inkjets and second generation Deskjet 500's were designed according to the principles that made HP a respected brand for instruments and calculators.

[ribbons]: [https://www.google.com/search?client=ubuntu&channel=fs&q=ibm...](https://www.google.com/search?client=ubuntu&channel=fs&q=ibm+proprinter+II+ribbon&ie=utf-8&oe=utf-8#q=ibm+proprinter+II+ribbon&channel=fs&tbm=shop)

<comment><USER6> You combine two parts that can be replaced separately into one piece where if one piece of it breaks the entirety of it has to be replaced, you're shifting the repair<->dispose spectrum towards disposablity.

Reliability is orthogonal to repairability.

<comment><AUTHOR> I understand what you are saying. I believe that in terms of the life-cycle of any mechanical system, repairability and reliability asymptotically become synonyms. Combining two parts into one favors repair because the logistics of stocking parts is simplified and repairs are simpler.

Provided of course that the goal of combining the parts is benevolent, e.g. that the two parts tend to wear at about the same rate.

In terms of printers, the reliability issues aren't plastic parts. They are:

       sticky liquids running in an open loop system in
       and around opto-electrical controlled mechanisms.

       pretending ordinary users interacting with such
       a system is going to provide reliability.

       pretending that paper is dimensionally stable
       under changing humidity.

Early HP consumer inkjets were reliable because the cartridge was electronics, ink, and printhead. It was the only thing that could go bad other than paper handling.

<comment><USER6> Combining two parts into one part when one of them is much more complex than the other does not favor repair.

If it was combining two parts that tended to fail at about the same time together? Sure. But the provided example isn't one of those cases.

It favors replacement. Consider it taken to a logical extreme - every item is throwaway. That's not what most people would consider repairable, and yet, under your definition of repairability, it's the most repairable system there is (as anything can be "repaired" with one swap). So I disagree with your definition.

I disagree with your assertion that "in terms of the life-cycle of any mechanical system, repairability and reliability asymptotically become synonyms". My parent's current car is a whole lot more reliable than the clunker they used to had - but on the flip side it's a whole lot less repairable. In other words, it takes longer to break, but when it does it's a whole lot harder (and more expensive) to return to a working state.

And I agree regarding printer cartridges - the current system is insane. That being said, current printer cartridges are an example of the end result of the same sort of thinking that ends up replacing a separate spring with an integrated one.

<comment><AUTHOR> The [Ship of Theseus] is an ancient paradox. Compressing the time scale to a single instant just shows the flexibility of language and the overlap of our concepts. My clothes dryer is reliable in the sense that I can disassemble it and replace the heat coils and bearings and belts. When repairs are finished it is the same clothes dryer. If I had purchased a new white good unit, it would be a different dryer and if it could not be repaired it would be less reliable than which could.

Because by reliability we imply use. A Ferrari that is not driven does not thereby become reliable. It becomes a hanger queen.

[Ship of Theseus] [https://en.m.wikipedia.org/wiki/Ship_of_Theseus#Ancient_phil...](https://en.m.wikipedia.org/wiki/Ship_of_Theseus#Ancient_philosophy)

<comment><USER6> The distinction is:

If you take a printer, and replace part A, and a time later replace part B, and a time later replace part A again, you've thrown out three parts - 2 of A and 1 of B.

If you take a printer, and A is broken so you replace the printer, and a time later A is broken again, so you replace the printer again, you've thrown out two entire printers.

These are not the same.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> WIP = Work In Progress ... it's an accounting term and usually represents the amount of money that's held up longer than your fiscal month.

Great article though. I remember those printers well.</comment>


Democracy Earth's ICO token sale site - <AUTHOR> https://www.ico.democracy.earth/ <comment><USER2> The links at the bottom of your site for slack and github are not working. Will they be activated soon?</comment>


Ask HN: What does the employment future look like for Linux enthusiast? - <AUTHOR> <comment><USER2> Hang around HN a bit longer before asking questions and you will get more responses --I see your account has been active for 54 minutes LOL>

There will be plenty of linux jobs.

<comment><AUTHOR> It wasn't a matter of trying to get a linux job, but rather getting idea of the market in the future like the question suggest.

On the other hand, congratulations! This year has been 5 years, going on 6 since you've been here! Whoooo!!</comment></comment>


Netflix officially launches streaming only plan, bumps current plans up $1 - <AUTHOR> http://blog.netflix.com/2010/11/new-plan-for-watching-instantly-plus.html

<comment><USER2> Actually some plans get $8.00 increase.

[http://3.bp.blogspot.com/_2d54TOFKFPY/TOnyZck- c_I/AAAAAAAAAA...](http://3.bp.blogspot.com/_2d54TOFKFPY/TOnyZck- c_I/AAAAAAAAAA0/6bMFJtNibuE/s1600/pricegrid.jpg)</comment>


Ask HN: Do you have a project logbook? - <AUTHOR> When working on non-trivial tasks, I always keep a text document open to log my work (Word, SQL or Markdown depending on the context). I sometimes save the document when I'm done, but it invariably ends up in a project/client directory and seldom being read again.
I'm looking for a way of writing, archiving and searching my logs - a personal, taggable blog of what I did a specific day - so I can both go through my work chronologically ("What did I do that day or week?") or by project ("What did I do last time I worked on that project or for that client?"). It must necessarily be fast and very responsive, and embedding images by drag&drop or copy&paste would be great, but otherwise the needs are pretty basic.
What do you use to log your work, and how do you organize your logs? <comment><USER2> Workflowy ([https://workflowy.com/](https://workflowy.com/)) is my goto for keeping lists, planning, and tracking my work/project logs.

For work, I have a section structured as such: Work > {CLIENT} > {YEAR} > {MONTH} > {DAY, HOURS, SUMMARY}

e.g. A day's entry might look like:

8/13/2014, 6.75h, One-liner summary of the big ticket accomplishments today * 11 - 12,30, 1 - 6,15 * [x] #ASAP Task 1 description * [x] Task 2 description * [x] Task 3 description * [x] Meeting with @client @coworker1 * Notes from meeting... * More notes...

I track my hours worked in shorthand and format {DAY, HOURS, SUMMARY} because I dump and parse the data at the end of the month to generate my invoices.

SQL, Markdown, or code snippets is a little trickier, but you can hang multi- line text as a sub-node using SHIFT+ENTER. In general, Workflowy offers a ton of great keyboard shortcuts and pretty decent search capability. Media attachments would need to be as URLs AFAIK.

I've been using it for 2-3 years and if they ever decided to close shop, I would seriously try spinning up a similar service.

</comment><comment><USER3> I have a "log file" for each week, broken down by day where I keep track of my TODOs and check them off. I put little notes next to the todos that describe what exactly I did, but not in much detail. But I can easily go back to 12/05/2011 and see exactly what I did that day. I usually plan one week in advance, but I only put task details there once I actually figure them out.

"What did I do last time I worked on that project or for that client?" is more difficult. I'm a fan of using blossom.io + Slack (slack.com) for large projects or startups. Usually there is only one such project I am working on. If you have lots of different project then these tools may cause too much overhead...

</comment><comment><USER4> I'm using a desktop wiki : [http://zim-wiki.org/](http://zim-wiki.org/)

I use it in a messy way, but it's what i want : take a note quickly.

I create a page by day with the calendar and there is a full text search tool for when I need to find and old note I also like the task plugin : you put a todo mark in any page and you have an icon to regroup all the "todos". I put some keywords sometimes, to help to remember later or when i'm using the search tool.

There is a picture plugin, but it's just keeping a link to the real picture, so it's lost when you move it.

I know there is the same kind of tool for vim, but i didn't try it.

</comment><comment><USER5> I've just started playing around with Harvest (getharvest.com); it might be worth checking out if you're already using some kind of task-manager (because they integrate with tools like Asana). Makes it easy to see what you did, which projects it was for, and to bill the client accordingly.

</comment><comment><USER6> Wiki on a USB stick :D [https://www.dokuwiki.org/install:dokuwiki_on_a_stick](https://www.dokuwiki.org/install:dokuwiki_on_a_stick)

Get synkron, configure it to mirror your wiki to a harddisk as backup and you're set.

</comment><comment><USER7> At my job we have a JIRA server running. It is a big enterprise piece of software, but you can log stories and tasks pretty well. If it were up to me I would use something else, albeit I am not sure what that is.

</comment><comment><USER8> When I was on my own, I used Google Doc to keep track of daily logs in a loose way. I am getting a team so I switch to asana. It has been for 3-days I am fine with that.

</comment><comment><USER9> Workflowy works great but sometimes it gets tricky (depending on how you'd like to format things).

<comment><USER10> Weavi (weavi.com) would be a great choice to organize lots of things.</comment></comment>


Nikjju Mass SQL injection campaign (180k+ sites compromised) - <AUTHOR> http://blog.sucuri.net/2012/04/nikjju-mass-injection-campaign-150k-sites-compromised.html

<comment><USER2> Does using Noscript prevents the spreading of this?

<comment><AUTHOR> It prevents a user visiting those sites from getting compromised.

However, the spread if this is via SQL injection, so as long as those sites are insecure, it will keep going..</comment></comment>