Job applicants over 40 filtered out by employers - <AUTHOR> https://www.uu.se/en/media/news/article/?id=9014&typ=artikel <comment><USER2> I just turned 40. There is an unfortunate grain of truth, especially among start ups, but it would be a mistake to think the situation that dire.

I am constantly pestered by recruiters and companies to interview. I think one of the things that helps is that I trimmed my resume to omit material older than 5 years, removed unnecessary dates, and I make a point of drawing attention to studying for new industry certifications. It probably doesn't hurt that I stay physically fit, either. As cruel as it may be, if you're out of shape and look "frumpy" or "run down," that will count against you far, far worse than your age.

The key is to make the age factor irrelevant by not drawing unnecessary attention to it or by projecting a stereotypical "middle aged" image. We can argue all day about whether that's fair or not (it's not), but you have to do what you have to do.

<comment><USER3> > It probably doesn't hurt that I stay physically fit, either. As cruel as it > may be, if you're out of shape and look "frumpy" or "run down," that will > count against you far, far worse than your age.

I am still in my early 30's but this really resonated me. All my life I have been conditioned to think that character, experience and expertise is what matters.

But the reality is that people will form impressions of you by they first 5 seconds they meet you.

<comment><USER4> Once they get to know you and your work, looking frumpy or whatever becomes a much smaller factor in their opinion of you. But the first impression is often what determines whether they will get to know you or not.

</comment></comment></comment><comment><USER5> I might have 'lucked out', I'm 41. I under performed in my 20s (it was the 90s after all and the bubble burst just as I was gaining momentum in the market) and received my college degree at 30. I assume most people who see my resume consider me 8 - 10 years younger than I really am. Doesn't hurt that I hit the gym and haven't gone gray yet. I went the mobile route (iOS) and haven't had a pay cut in 8 years (currently 200k+ living in the mid-west). Not without its ups and downs, I tend to not get hired at start ups, maybe those 20 somethings smell something is up, but fortune 100s are quick to give me an offer letter.

With age comes maturity. It's allowed me to get along better with my co- workers (so many upper 20s, lower 30s tend to be a bit... hot headed) and I'm not afraid to negotiate. The older I've gotten, the more comfortable in my skin and in my skill set I've become.

If there's ageism I've yet to experience it and I've worked with people well in their 50s doing mobile. It comes down to who you're working for, what your skill set is, timing and, in my opinion, health. You've got to stay healthy and look healthy! Also, I tend to prune my resume, no one wants to see your experience 8+ years ago.

Or maybe it's all luck, ask me in five years what I think when Objc/Swift goes the way of PHP, I might be singing a different tune.

<comment><USER6> > currently 200k+ living in the mid-west

Is this an employee salary or contracting/consulting income?

<comment><USER7> I'm not sandoze, but the figure seems reasonable for folks with 20 years of experience. Most of my buddies make about that much (plus 25% to 50% bonus) in NYC. I make slightly less than that.

<comment><USER8> NYC is slightly more expensive than the mid-west.

I can say that I live in an area closer to the rural mid-west than NYC, and we consistently see 1-year contract rates for iOS developers in the low $200's, up to $280-300k if you have 8+ years of relevant domain experience (again 1-year contracts). If sandoze is consulting $200k is 100% reasonable. If they're a full-time employee, $200k is pretty high but definitely possible with their experience.

</comment></comment></comment></comment><comment><USER9> Harsh and an obvious problem for those over 40 and industry in general, but is this simply the natural result of companies optimizing for maximum productivity at the lowest possible cost to them?

Many 40+ year olds have families or other life obligations outside of work, and thus they may not be as willing to put in absurd hours that a young employee could be squeezed for. The older employee also might be more likely to take weekends off, and want to use vacation time.

Additionally, someone over 40 is supposed to be in or near their peak earning years, which lasts ten to twenty more years (or did historically anyway) so their expenditure is going to be significantly more than someone with a few years of experience.

I realize it's one of the lamest analogies possible, but for many companies, employees are quite literally a cog in a larger machine, and so they want the cheapest possible cog at a reasonable quality level that works the longest before breaking down (quitting, getting fired, burning out, etc).

To fight this, I'd bet those over 40 would have to aim to get into important management and executive positions, which are less likely to be swapped out for less experienced, less demanding, and cheaper labor.

<comment><USER10> > Many 40+ year olds have families or other life obligations outside of work

Why is this a (seemingly) common belief? It seems backwards to me. I had a lot more obligations outside of work in my 20's and 30's when my kids were young than after 40. I'm in my early 50's, and I have more free time now than ever.

<comment><USER11> I'm in my mid 20s and i don't know any friends my age with kids.

It's just not very common to want a family before 30.

<comment><USER12> Not sure why people downvoted you... "mean age of first time mother" is climbing and is nearly at 30 years old in most of the developed world now.

[http://time.com/4181151/first-time-moms-average- age/](http://time.com/4181151/first-time-moms-average-age/)

[http://www.statcan.gc.ca/pub/11-630-x/11-630-x2014002-eng.ht...](http://www.statcan.gc.ca/pub/11-630-x/11-630-x2014002-eng.htm)

[http://www.huffingtonpost.co.uk/2016/03/09/pregnancy- around-...](http://www.huffingtonpost.co.uk/2016/03/09/pregnancy-around-the- world-age-of-new-mums_n_9416064.html)

</comment></comment></comment></comment><comment><USER13> That's hilarious. In medicine, a 30-year-old MD is too young to make some more complicated operations alone. In IT a 30-year-old programmer is just too old to be hired.

The funniest interview I had was with some blonde girl in her twenties, who read through my CV and said: "Oh, you see. We cannot send your application to our client. You see, here I have hundred of applications from people at your age, who are managers in their thirties, and you are not. There is most probably something wrong with you." And it was a position for a programmer, not a manager.

And it was when I was in my early thirties, not forties.

Currently, I'm almost 40, and I seek only for remote work (family issues). I have been paid for programming for the last 14 years. I had different jobs like sysadmin, dba, programmer; using over 10 different languages.

And despite all that searching for work is really hard. Usually, it stops at the recruiter who is only interested in an answer to "how much do you want to get?". After that, there is no counter offer, no negotiation, nothing. Sometimes there is an answer like "you want too much, but don't negotiate at this recruitment step".

When I get to the technical part of the interview, I usually get some Yeti- Level programs to write. Yeti-Level, because you are not going to write anything like that in those time restrictions in that jobs. A good example is implementing a program which gets input from a file, in the input, there are domino tiles, and a function needs to match them and find the longest chain... all must be super optimized from the beginning. And you have 5-10 minutes to do everything, including reading the task description, examples and writing tests.

The funny fact is that this company is searching for candidates for months. The sad fact is that due to such strange recruitment process, good old experienced programmers will starve.

I really think that I did very bad choice with my career. There are so many other jobs where people are not removed because of age, and experience is really appreciated. In IT you just need to accept that companies want young inexperienced kids, who want to get little figures, but a game room is a must.

<comment><USER14> > I really think that I did very bad choice with my career.

Sadly, I have come to a similar conclusion: tech is a great way to earn money early (because the wages rise quickly), but the ceiling hits early and is quite hard to break through. Use those early years to save up money, then switch to something else.

<comment><USER15> My early years I was terribly paid. It's only recently (since I became freelancer, in fact) that I'm making decent money.

<comment><USER16> I worked with a freelancer once when he was brought in to help pick up the slack due to two people going on paternity leave, guy was being paid more per day than the two guys were getting in a week.

Contract work has interested me since then, but it looks like a real hard slog to get good income.

<comment><USER15> My first year I made € 8000 (though that was mostly due to trying to make my own product). I recommend building a buffer before you take the leap, though once I'd had my first big project, it's been fairly smooth sailing.

</comment></comment></comment></comment></comment><comment><USER17> I am 43 I know this is true. Even for people in their thirties.

This is why I decided to start my own company again after 4 1/2 years at Square which was probably the last time I ever would be working for someone else.

This way age becomes an asset rather than a liability.

<comment><USER18> I've often wondered whether this industry is similar to Hollywood with its ageism. Once you get in, there are often many roles available. But at some point, you need to start creating roles for yourself (if you can).

</comment></comment><comment><USER19> I don't understand why everyone bought the idea that we don't need unions anymore.

This is exactly the sort of thing they make better.

<comment><USER20> Citation required.

A union won't make a company hire you. Whatever power union has, it comes after signing on the dotted line, so that particular problem would not be solved by a union.

Unlike police or muni drivers or Detroit auto works, programmers are among the most frequent job changers.

Other than Hollywood unions (where main benefit, as far as I can tell, is ensuring that you don't get taken advantage of too much at the low end thanks to minimum wages etc.) is there any example of a union for a profession where you change your employer every 2-3 years?

<comment><USER21> _is there any example of a union for a profession where you change your employer every 2-3 years?_

I know a few construction workers who essentially work for the union. A contractor will get a job, and they'll contact the different unions and say they need people to get it done.

<comment><USER22> The unions in construction also provide continuous training for their members, and good training to boot. I've had real estate developers in NYC tell me they won't do foundation work with non-union labor because it's so important to get it right the first time.

<comment><USER23> Though the drawback is that union workers tend only to want to work with union workers. So you can't go with the union workers to do your foundation, and use a non-union contractor to do other work.

An employer I used to work for found this out the hard way when word got out that they had hired a non-union carpenter to do some custom cabinetry on an office build out (he was an expert craftsman who was not cheap, so it wasn't done for cost savings).

Suddenly it got very hard to find workers to finish the electrical and plumbing work.

<comment><USER24> _Though the drawback is that union workers tend only to want to work with union worker_

That is the whole point... a worker's only leverage is to withhold labour. As an individual that is insignificant but en masse...

</comment></comment></comment></comment></comment></comment><comment><USER25> Since it is not legal for employers to require you to give your age as part of an application, doesn't this simply encourage candidates to lie about their age? One way that age is given away on resumes is to look at work history or date of college graduation. In lieu of the current situation, is it not advisable to simply not give the date of graduation and only provide the previous 5-10 years of work experience on resume?

It isn't a perfect approach, but it makes it more difficult to discriminate since by the time you have a face-to-face interview with the employer you are already well along in the interview process.

<comment><USER26> It is difficult to hide your age. LinkedIn makes it impossible. If you want to be competitive, you need to share your accomplishments. If they are actual accomplishments, they are Gooogleable in a simple search anyhow. Hiding your age by leaving off dates says, "Hey! I'm old enough to hide my grad dates!" (which means you are now over 30) This culture is not helping itself. We all need to find the bravery to stand up against this at every age, because, I hate to break it, every person under 30 on this forum will be over 40 before they know it. I sure hope it finds them at the very tippy top of their career game. Our economy doesn't look great right now. Best of luck finding that chair before the hip-hop stops.

<comment><USER27> I am under 30 and do not list my graduation date.

<comment><USER26> you may want to start listing it and take advantage of the ageism in your favor while you can. :) I had a 28 year old friend who was getting botox a few years ago. I could not believe it; they looked so young to me. They told me I didn't understand how bad it had gotten in NYC. I thought they were nuts. Now I see why they were freaking out. This climate is so unhealthy. If we thought we had real problems with body image and eating disorders--- I fear the level and scope of mental illness this kind of youth-loss anxiety tech bro culture will deliver unto us as time passes and we do nothing. This plus body image plus some of the social issues that come these plus drugs plus work only social circles seems like a recipe for a kind of health crisis epidemic that---- we totally see this coming and are doing nothing about it. In fact, we are still convincing many of our own on this very forum that its even a problem even as Chinese workers are facing overworking themselves to death as a health crisis.

<comment><USER27> Thanks for the advice, and it may hold true in some markets but in my market I've been seeing ageism affect the young, too.

</comment></comment></comment></comment></comment><comment><USER28> > In the study, the researchers sent more than 6,000 fictitious job > applications to employers who had posted job ads for administrators, chefs, > cleaners, restaurant assistants, retail sales assistants, business sales > agents and truck drivers to then compile the employers' responses, such as > invitations to job interviews.

Not trying to be in denial, but all these jobs appear to be blue collar jobs (assuming "administrators" is office admins and not Sys Admins / Network Admins :) .

Any data on whether this happens in our Tech / I.T. Industry, where every other month, you read a story on severe shortage of skilled tech workers everywhere?

<comment><USER7> I have to concur with you. I've been hearing about this death at 40 thing for decades and I think it's a bit blown up, especially in IT field. There were a lot of folks warning about this even during the dot com bubble when there was very severe IT labor shortage.

In my 20 year IT career -- and I've worked mostly in tech/finance in the NYC area -- the only downturns I noticed were during the most extreme financial crisis, such as the dot com bubble (2001 -- I was at an internet startup) and the housing crash (2008 - I was at Merrill). Most of my buddies in my age group are doing quite well. Even those non-technical folks who used to complain about the age discrimination two decades when they were in their 20's, are now employed in semi-technical jobs.

Now, I'm pretty sure that the age discrimination is real in other industries, but it's still quite difficult to find qualified, experienced candidates in IT, regardless of age.

<comment><USER29> The finance industry is much nicer than the web industry, when it comes to aging.

</comment></comment></comment><comment><USER30> "You know what they do with engineers when they turn 40? They take them out back, and shoot them." \- Primer

<comment><USER31> This reminds me of the off topic question I always had about YC - "if it is an incubator for fungus - is it valuable?"

<comment><USER32> "And there was value in the thing, clearly, that they were certain of. But what is the application? In a matter of hours, they had given it into everything from mass transit to satellite launching, imagining devices the size of jumbo jets. Everything would be cheaper. It was practical, and they knew it. But above all that, beyond the positives, they knew that the easiest way to be exploited is to sell something they did not yet understand."

I've always been quite impressed by the writing in Primer. The dialogue is a massive departure from the clean world of Hollywood but it makes it feel far more frantic but also real.

</comment></comment></comment><comment><USER33> In government contracting, the jobs can be hit or miss. There's some really good ones and some stinkers. They usually pay based on experience. Jobs requiring 20+ years are of course more rare than ones requiring just a degree and no experience. A buddy of mine who's 60 decided he'd take an entry level Java job for a few years after being in a challenging senior architect role. The pay is less, but he loves it.

Part of the challenge of getting a new job after 40 is deciding whether it really matters whether you're making the same or more $$ in the next job or not. Many people are unwilling to take a pay cut when they have 20 years of experience, even though the job only requires 5.

</comment><comment><USER34> Time for some heavy stick and penalties, laws exist: [https://en.wikipedia.org/wiki/Employment_discrimination#Lega...](https://en.wikipedia.org/wiki/Employment_discrimination#Legal_protection)

Challenge is to prove it.

<comment><USER22> An employment lawyer chimed in on this in another thread. Apparently discrimination laws are generally only enforceable at the end of employment, but discrimination is much more prevalent at the beginning. It's much harder to prove that some didn't get hired for a prohibited reason than it is to prove they got fired for one.

</comment></comment><comment><USER35> Welp. Guess it's freelancing and minimum wage shift-work until I die, then.

<comment><USER36> Sometimes I really do wish I went into an industry where experience matters, such as law or medicine.

<comment><USER37> Someone needs to clean up the crap left by all these 20 somethings.

We have 3 developers all nearly or over 40 cleaning up the mess done by someone who appears to have been in his early 20's. The system works, but it could have been done with a fraction of the complexity.

</comment></comment></comment><comment><USER38> I left my former industry at 40 (now just over 3 years ago), bootcamp'd and got into dev and it was the best thing I ever did. I've been gainfully employed since the move and love my current job. I can't say it wasn't a lot of work, and yes I feel the competition of the young folks, but it is what it is.

<comment><USER39> Congratulations, and welcome!

</comment></comment><comment><USER40> How did they actually test this? Without details, there is no new information. As well, do we know that there are no confounding variables in these findings?

As a hypothetical employer I might think these roles are lesser roles, so if you are older I would wonder why you had not been able to secure a greater economic situation.

Second, as consumer facing roles, attractiveness is a benefit, with those over 40 having less of it. It is not discrimination on the basis of age, but attractiveness that would be the cause.

<comment><USER25> This is a tough one, because it's rooted in reason. The employer asks themselves "This guy is applying for an entry-level or junior role at a very senior age, why are they doing so? I must be on guard for potential problems because if this guy is still applying for these kinds of roles at this age there must be something wrong with him/her".

The worst part about this is that it's somewhat rooted in truth in a lot of cases - but it shouldn't be a preclusion to an interview at least. I try to view things as objectively as possible and give objective examinations to avoid this kind of bias.

With consumer-facing roles, I think that is an acceptable bias to have. After all, the courts have ruled that Hooters can discriminate on basis of gender for their consumer facing roles (not back end such as chefs though). For joe schmoe engineer that only writes code and rarely/never talks to the end user though there is no excuse.

<comment><USER41> I don't agree that most consumer-facing roles should be able to discriminate in such a way. Does it matter if your wal-mart cashier is older or younger in the same manner that it does at Hooters - or any other establishment that is based on looking at people?

I'd argue not. Hooters - and modeling agencies, nudie bars, and so on - actually have a business based on how their employees look. Stores, offices, and so on? The truth is that it doesn't matter. Unlike Hooters, they wouldn't lose a large base of their customers.

</comment></comment></comment><comment><USER39> I didn't have too much trouble last year at 41. Took a couple months to get any traction at all, but then suddenly got a few interviews and eventually some offers all in quick succession. Maybe I was lucky though. After reading this story I'm definitely more inclined to stick with the position I have rather than to try to go out on my own again.

Another talking point: the trend of waiting until late 30's to have kids greatly compounds this problem.

<comment><USER42> I've been actively searching the last few months and my resume is getting rejected on sight despite many years of experience doing exactly what the requirement states. I honestly don't know if it's agism, their expectation that I'll demand more salary or It's just written poorly.

<comment><USER43> When you're past entry level, you need to be getting jobs through your network not by cold-calling or submitting resumes in response to ads.

I've changed jobs three times since I was 40, but in all cases I knew people at my new employer who could sell me internally.

I don't think it's so much age as it is that employers don't want to take as much risk on an unknown person for more senior level positions.

<comment><USER42> It's how I got my last job. I haven't actually been hired off my resume in 10 years. Almost all of my network today do the crap I'm trying to get away from.

<comment><USER39> OP here. FWIW I got my leads entirely off of spamming my resume around. For the prior 15 years I'd done freelancing for local companies and had a few-year stint in a small company, so didn't have a network. I was in small-town Michigan so once freelancing dried up I knew moving was going to be a requirement. Thus I was able to spam the whole country. That probably helped my cause a bit.

I noticed you mentioned LinkedIn in another thread. FWIW I don't have an account and it didn't appear to hurt me.

</comment></comment></comment></comment></comment><comment><USER44> >A questionnaire study directed at a selection of employers shows that there are three characteristics that the employers consider to be important and are worried that employees over the age of 40 have begun to lose: the ability to learn new things, being adaptable and flexible and being driven and taking initiative.

Open question - is there any research on to what degree these three worries are true?

<comment><USER45> Not really an expert in this particular area, but the research I'm aware of kind of suggests if anything the opposite is true, depending on what you mean by "the ability to learn new things."

There's some cognitive decline, but it tends to start after 25 or so, and it's mostly associated with slowed speed per se rather than learning ability. There's also some controversy in that the declines might be associated with serious health conditions, that are associated with age, rather than age per se.

The other things you mention either stay the same or increase with age, which strikes people as kind of counter-intuitive, which speaks to stereotypes people have.

</comment></comment><comment><USER46> For founders who are fundraising, it's even more extreme.

Job applications generally don't and possibly can't ask about age, but it's a required field on applications for YC or other incubators.

<comment><USER47> That's extremely curious, if it's indeed the case, because older founders tend to succeed more often than their younger peers.

<comment><USER46> For a investor who funds many businesses, EV matters much more than hit rate. TBH, for an early investor, a success rate of over 20% is possibly a sign of being too risk-adverse.

</comment></comment></comment><comment><USER48> So, age discrimination is not tech specific, but unlike other industries, tech workers change jobs much more often and that creates the illusion that the problem is more tech industry related.

</comment><comment><USER49> With general increases in the age to receive a pension (increasing six months every two years in Australia), but challenges in finding employment, what bridging options are there? What's the landscape going to look like for 50 year olds if re-skilling after a lay-off doesn't always help?

</comment><comment><USER50> There's ONE thing that really amazes me. A lot of people around the world - not just in Europe or in US - keep speaking about talent crunch, STEM shortage, etc, as an emergency... so, if this research is not flawed, the real issue is that such talent is just ignored at 40?

<comment><USER51> They only say that to loosen immigration for cheap, visa-dependent developers.

<comment><USER26> Thank you for saying that. The Elephant was just sitting on everyone's face.

</comment></comment></comment><comment><USER52> It's very hard (if not impossible) to avoid being biased when reading resumes.

Personally I would strongly prefer that resume's I review were anonymized and all hints that might bias me were removed before any decisionmaker see's them or they are filtered. This could help more women and minorities get a foothold at that step in the process (I mean generally, not with me specifically).

However, while relatively simple censoring of resumes would remove some bias from review, such as race (can often be hinted at by the name or university attended), gender, etc, and it would prevent googling of the person's name, age is extremely hard to hide. You can see a person's job history, which is generally will tell you their age within +-5 years. One partial solution might be to only list job history for the previous 10 years and remove the year a degree was earned, but relative seniority at the beginning of that 10 year work history will still be a very effective proxy for determining age.

So, unfortunately I think we can't hide age in an effective way without removing critical information from a resume (removing everything else we can that can be removed _should be removed or hidden_ ), but I think it's interesting to speculate on why older workers will be filtered out. I suspect it is a belief (or intuition aka unconscious belief) that someone applying for junior or entry level positions when they are > 40yo is correlated with 'something being wrong', since if there is nothing wrong you would have expected them to have reached a point in their career that they no longer have to blindly submit resumes for these kinds of positions.

I wonder what would happen in a study like this if the resume's representing older hypothetical candidates included some kind of cover letter explaining the situation. For example, saying that they started out working at a bank for 15 years but they found a passion for cooking and that is why they only have 5 years of experience as a chef. My guess would be that not only would this undo the bias against them, but you would find a strong bias towards them (just a guess).

</comment><comment><USER53> My father, 60 y.o. engineere, in a few months retiree, asked me how to find a reliable freelance basic lvl jobs. The thing is, the country just passed a couple of recession periods, and the retirement program, the country is going to greet him with is around usd100/mo. What obviously is not enough to cover expenses. To find a local job at such age and at that economical situation us just not worth time and effort. And there are literally millions of such as him. I personally will probably not receive any pension at all (currently 32yo.).

</comment><comment><USER54> > In the study, the researchers sent more than 6,000 fictitious job > applications to employers

Might this be a clue?

Any job application which is in the reaches of an automated process must be a joke endpoint. How many other automated applications do they get selling employee skills, sex, penis enlargement pills, fast loans, malware and other trash.

Disclosing information should be the first "BS" smell for a job. I'm often well into getting work done before the person I'm working with figures out how old I am, where I live or other personal details. Granted, that's freelancing.

I live in the Philippines where the age requirements are actually advertised. And these ages seem pulled out of a hat. And I get the sense that people running the show at all levels couldn't tell their asses from a hole in the ground. It's a pleasant surprise to find someone who seems competent at convincing you that there's some purpose for them taking up a spot at that spot or role they are taking up in a serious time commitment out of their life.

Clearly the hiring process is just as broken as everything else. Why expect that hiring is going to be significantly more awesome than the rest of the system?

Don't interact with machines. Get to know real people. Show people what you can do. Preferably find people who tell you they could use your help rather than you telling them that you need a job. ;)

</comment><comment><USER55> Have a side project in an en vogue "cutting edge" framework or language, and they will care much less about how old you are.

</comment><comment><USER56> I am unable to reconcile these facts that life expectancy keeps rising and jobs opportunities keeps falling. Government across the world in low/mid or sometimes even high income countries are already running huge budget deficits. So they are not going cheap/free amenities to jobless masses when even people with jobs are finding things expensive.

</comment><comment><USER57> Is there (age) discrimination? Of course.

That said, there are qualifications and there's "fit." The more experience you have, the stronger the signal on what you might (or might not) enjoy.

For example, if you're 40+ and most your resume says startup, do you really expect a blue chip international to be interested in you? Do you really want them to be? Sure, maybe YOU really need a job. But history probably shows you'll leave as soon as you can land another startup opportunity.

Again, not doubt there's bias in the hiring process. But bias can have a purpose. And sometimes you have to live with the depth and breadth of your CV.

</comment><comment><USER58> This is why employment-based purposefulness of life is so dangerous -- I think it is nothing short of a tragedy that the way society is set up validates an utter hopelessness if you are not employed, this despite the fact that there may be structural factors arrayed against you. I've seen it almost chew up my father and I want to resolve that it'll never happen to me, but I know so long as structurally employment remains the default badge of worthiness in a capitalist society -- that it will come to pass for me as well.

</comment><comment><USER59> Whats the logic here? Are applicants >40 generally worse performers?

<comment><USER60> No one has mentioned that sometimes older people don't fit into the culture of the business.

<comment><USER17> So funny to be called older people when you are 43 and party with the best of them. Anyway.

This is why I decided to start my own company again after 4 1/2 years at Square.

This way age becomes an asset rather than a liability.

<comment><USER61> How do you recover? I'm only 33 and while I can still party with the best of them it takes it out of me. No more $1 drinks until midnight on Thursdays and being back at work at 8am.

<comment><USER17> I don't recover I just don't do it as often as I used to :) I have two kids how wake me up between 5-6 am.

</comment></comment></comment></comment></comment><comment><USER62> If only there were some kind of physically demanding test for employment, I would then punish all those youngsters by going to the front of the line.

</comment><comment><USER63> The market conjuncture is not skewed only one way. Right now, people whose career went under 10 years ago, are competing with people in their 20ies. IT industry has a disproportional portion of people in "senior" level positions.

Companies want to hire professionals in their prime, and look at anybody else as a second grade cadre.

</comment><comment><USER64> 31 here. Couldn't find work for 6 mo despite being well qualified for positions I applied for. My guess: too many applicants for the same position. Ended up going the freelancer route, couldn't be happier now. Sorry, I know this doesn't relate to age (I don't think) but just wanted to say that.

<comment><USER65> How do you put your freelance work on your resume?

Do you list projects, companies, time spans?

If you apply to a "regular" job, how are those references checked?

<comment><USER66> Good, long-term clients are worth their weight in gold. Both in terms of regular income, but also references: references for new clients or new employers.

</comment></comment></comment><comment><USER67> I am in my fifties with over 30 years programming experience and proficient in 20 languages yet one employer rejected my application because I didn't meet their requirements and they found a better fit.

I work fifteen hours a day, can't stop learning and trying new technologies to keep myself on top of the wave.

<comment><USER18> I have been in the business a while myself. It's a lot of work to stay current (and well-rounded). But, I've had relatively long stints in my career with one big industry change. I'm not sure that years of experience necessarily translates from one company to the next, although a proven track record of adaptability and flexibility is helpful. I've come to rely on networking for job opportunities. Having someone willing to vouch for a candidate made a difference when I was on the hiring side.

</comment></comment><comment><USER68> I'm more concerned personally with the fact that at nearly 40, I think I can actually notice getting dumber. :-/

</comment><comment><USER69> "Logan's Run". It's here.

<comment><USER70> Good movie, good ending.

</comment></comment><comment><USER71> I don't speak the language, so I'm unable to read the underlying report, but I hope this quote is out of context in the article: "There should be no doubt that the employers discriminate on the basis of age," when the study itself shows discrimination for very specific roles: administrators, chefs, cleaners, restaurant assistants, retail sales assistants, business sales agents and truck drivers.

</comment><comment><USER72> A few observations.

First off, companies like Cisco, Microsoft and Oracle, and even Google, are running entirely off of the centralized education system in the US. These are companies that got their software into curriculum and taught everyone their way of doing things, then engaged in shoving their software and a lot of labor into large organizations making a gargantuan mess that was glossed over with lots of "free overtime". Compare Cisco CLI to Juniper, or Microsoft to Debian, or MS SQL to Oracle; who's going in who's direction.

Why?

If you made the investment in understanding exclusively those companies products you went along the technological imperialism trip and now that you're on the other side, and you never spend time understanding the theory or building critical thinking skills, you're washed up. 20 years working on a massive oracle mainframe or with purely Cisco R&S becomes a liability, the reason being, you never tried to find a better way to do things or try to eliminate your job and replace it with something better.

There's an honesty in Meritocracy; The market has always valued the independent thinking, hard-working, incredibly knowledgeable IT staff with a tremendous depth of understanding of infrastructure, programming, politics, and equipment over what 95% of the IT market has become. 95% of the people I've worked with expect the solution to be in some arcane google search result or in a book; they don't expect to go on the journey of finding the answer. What they never develop is real creativity, a real understanding of the systems they work with, or a real understanding of the architecture, why things are done, or the process of how to build on themselves; to set a path for themselves and others that that eventually brings about a finished product.

The entire IT industry is maturing and getting older and as they do, older staff that haven't done this is viewed as a liability. I'll agree, there's all kinds of ways to try to hire gullible people who don't know their own self- worth. Fact is though, those kinds of companies are on a long-term death spiral of their own making. Every time a large corp outsources, I go look at the 10-k and I see a major cash flow problem of managements making. "The old cranky sysadmin way" is beginning to take at more and more companies and that will trickle into academia as time goes on as management begins to understand what technological imperialism means and what the results are; generally, a total mess.

It's a very controversial thing to say these things because it makes a lot of people who aren't that good, or who invested their time in the wrong things feel like they are doomed. Fact is, there's no set career path in IT like there is in other fields like Attorneys and Lawyers, Stock Brokers, Research scientists and Academia.

The trick I've discovered is to put in no more than 40hrs a week at work, and if overtime is needed, come home and practice, do architecture work, learn algorithms, make good notes, read programming and architecture and project management books. 40hrs a week is for work, 10-20hrs a week is for self- betterment. Then you come into work, and find ways to eliminate your job. A new approach that saves butt loads of time. Get your assignments done early, then either come up with a new project to work on, move on, or study. Within a few years of doing this, you will be a top-tier programmer\architect\systems admin, whatever you want to do.

And while I do feel for people who feel they've fallen behind due to having a family, the fact is from my perspective, the real issues with society are things like 21% of GDP being spent on a scummy healthcare industry, or high incomes of the top 1%, or lack of wage parity tariffs on imports from China. The baby boomers have really messed things up for us. The fact you can't go from a high paying IT job to a factory job or retail management position and still have enough money to put your family in a decent home with 3 hots and a cot and to put your kids through school and college is a failure of society in general, not the IT industry. Those issues need fixed and frankly, contribute a heck of a lot to our messed up society.

<comment><USER73> Good observations; some good points made here. We can expect things to become even more competitive in the future. If one does not feel that their years of experience are an asset in solving problems for others, then they should perhaps look back and adjust.

It is convenient to place blame for personal issues on some anonymous discriminatory entity (which may as well be real and not imaginary), but there must be things one can do to better themselves, especially in such high demand, unstoppable industry that we're in.

It is best to focus on finding ways to stay afloat (or even control your drift) than wail and sink.

</comment></comment><comment><USER74> At any age, just ship products that are quality and marketable. Have good routines and get things done. Stay well informed and educated. Your only useless when you decide you are useless, everything else is just noise. Averages and means are not necessarily definitive of what individual experience will be.

Technology and mobile/web/games are _still_ young industries, in all new industries they start/skew younger. Radio for instance was young at inception but is now older in terms of age, it takes a couple decades for people to decide it is worth pursuing or starting in.

Being a web developer has only been around for 20 years and being a mobile developer only a decade truly (smartphone era). People are going to skew younger here and more coders are 40-50 and younger. As time goes on this will change and skew older. Incidentally because it is a young industry, there is a large divide of people that grew up with the internet and ones before, same on mobile. I think that hangs over the age thing. Older people used to be bad at tech but most people in their 40s even grew up with it or used it very young. Many of my older coder friends started with commodore 64s, Apple IIs and had to find answers before Google, they are now mobile/game/app/web developers. Many of them are more knowledgeable than younger coders today may ever be because they were in the time when everything was being built and the layers were easier to see. There is tons of cruft for a young coder to navigate and once you get out of college (22-24) or masters (27-30) and work for 5-10 years and get your head around this skill, they call you too old, it is a bit cruel but goes back to the young industry bit.

On the brightside, our industry is also unique, we can break out on our own and still compete enough to provide a living. In other industries and lines of work, the costs to startup are immense and risky, bootstrapping is easier in technology. Either in freelance or software as a service or starting something, there is always an option if you keep coding/building/shipping/solutions. Programming is a meta skill like business and marketing that allows you to literally go into almost any industry.

Most people in tech around their late 30s or 40s want to start their own thing and that is a benefit. Young developers may be too uncomfortable doing that because of their confidence and experience. Even lawyers and doctors, if they don't start their own practice, put up with the same push around that everyone else does as they age and get experience. What you need to do is find your own vehicle around this time so you can navigate the waters with a little more command.

Just ship and build things, don't get caught up in the averages. There is a lack of coders still that can deliver from start to live, in fact this situation appears to be getting worse. Provide that and you will always be marketable.

Side note: if you are over 40, I'd suggest paying for your own individual independent insurance. I feel health insurance is another pressure on older engineers in startups at least. I have seen at least two guys get run out based on health conditions and age. Once health insurance is separated from the job, ageism is less intense at these types of places.

</comment><comment><USER75> I will be 40 next year. Humans are expendable; we have to make our own worth. If we don't do that, we end up like I am right now: a year from 40, homeless, broke, in a lot of debt, out of work, failed startup, facing a felony on false accusation.

Life is challenging for me now, and this article directly applies to me. Oh, and there's that thing about being a white male and suicide. Now imagine being a kind of intimidating looking type in a very non white anti trump area.

Tribalism is real. Had I stuck with my tribe early on I'd be more secure. My demise is probable at this time.

I am solid in my desire to self terminate yet lack the ability to overcome fear of death. I stay alive but it's closer than ever. It's almost a humane thing to let me go. I wouldn't wish my brain on anyone.

Good luck all.

<comment><USER76> [Deleted] - upon re-reading the parent, I feel I've misjudged the volatility of the situation. Sorry.

<comment><USER77> These are the wrong ideas to express to one who indicates an interest in self- termination.

I wish I could double down vote you.</comment></comment></comment>


A CS Research Topic Generator or How To pick A Worthy Topic In 10 Seconds - <AUTHOR> http://www.cs.purdue.edu/homes/dec/essay.topic.generator.html <comment><USER2> Reminds me the "Automatic CS paper generator"

<http://pdos.csail.mit.edu/scigen/>

</comment><comment><USER3> A friend wrote something similar for computer architecture and microarchitecture papers. It's eerie how many papers sound a lot like these lately..

<http://www.eecs.berkeley.edu/~waterman/bs.html>

</comment><comment><USER4> I just note that the link below, a subdivision name generator, submitted (by someone else!) a few days ago, got killed after being quickly upvoted to the front page. I can't find the HN link -- maybe it no longer exists -- but commenters suggested the page wouldn't even have been noteworthy in 1998, etc. I thought the tiny app was brilliant recognition of a formulaic part of our linguistic world.

<http://adrian.gimp.org/cgi-bin/sub.cgi>

<comment><USER5> Yes but this one is from Dr. Comer a well known computer science professor. <http://www.cs.purdue.edu/homes/dec/>

</comment></comment><comment><USER6> Reminds me of Dack's Bullshit generator for Resume's - <http://dack.com/web/bullshit.html>

</comment><comment><USER7> I suppose this is the academic equivalent of <http://classnamer.com/>.

</comment><comment><USER8> You can have some fun building your own generators with "polygen", an EBNF- based generator written in OCaml.

</comment><comment><USER9> A few years ago this could have been useful for me. I am always late to find the good stuff.

</comment><comment><USER10> I love it.

<comment><USER11> It's the "literature review" that kills.

<comment><USER12> It's the literature review and six drafts of the paper only to find your advisor thinks your topic is no good. That kills.</comment></comment></comment>


Soylent: What Happened When I Stopped Eating for 2 Weeks - <AUTHOR> http://fourhourworkweek.com/2013/08/20/soylent/ <comment><USER2> "Though I drank tons of water during Soylent, according to the instructions, those missing 4 lbs of water weight indicate I may have been less hydrated when I came in the second time."

More likely: you carried a lot less liver and muscle glycogen by the end (a typical result of low carb intake), and glycogen binds a lot of water.

When I first keto dieted, I lost _13 pounds_ in the first 2.5 days, probably almost all water, much of that probably from shedding glycogen.</comment>


Is Meebo Worth Half a Slide? - <AUTHOR> http://www.techcrunch.com/2008/03/18/is-meebo-worth-half-a-slide/ <comment><USER2> I've been using Meebo a lot less since gmail integrated AIM chat.</comment>


Neal Stephenson's Kickstarter Game Is Dead - <AUTHOR> http://kotaku.com/neal-stephensons-kickstarter-game-is-dead-1636526717

<comment><USER2> I'm sad about the game, but at the same time happy that he'll have more time to write now.</comment>


Things You Should Never Do, Part I (2000) - <AUTHOR> http://www.joelonsoftware.com/articles/fog0000000069.html <comment><USER3> If you absolutely must rewrite, consider isolating and replacing components piecemeal rather than scrapping the whole thing and starting over. You don't eat the whole cost at once, you can keep moving forward with new features if needed, and you get more modular architecture to boot.

It's called the Strangler Pattern. [http://www.martinfowler.com/bliki/StranglerApplication.html](http://www.martinfowler.com/bliki/StranglerApplication.html)

<comment><USER4> The problem with that seems to be that you're tying yourself to the old application in one way or another (e.g. old interfaces, old architecture, old programming paradigms).

<comment><USER5> Not at all. It is perfectly possible to go from a big freaking desktop app (BFDA) and rewrite it, piecemeal, to be a single page web app.

The way you do that is that you first, piece by piece, split the BFDA into multiple layers, then you make it client-server, split the data-storage into its own server, split the gui of, split the business logic of. Then you rewrite the parts that request stuff for the client into using JSON and rest, then all you have to do is to port the (hopefully) tiny amount of gui interface the user needs to Javascript and the entire app still works.

Is it easy? No. Does it waste some work? Yes.

</comment></comment></comment><comment><USER6> This article, when I originally read it 5 years ago, was hugely influential to me. It completely convinced me of the superiority of refactoring existing systems to an ideal over rewriting. It doesn't take anywhere near as much time to fix cruft as it is to create a system from scratch and try to avoid your own cruft. But it's scary and it's an unknown. But if you approach it with courage, it falls quite easily.

EDIT: refactoring large systems has also convinced me of the superiority of statically typed programming languages for large projects. When I break code, I want it to break as hard as possible. I want to see absolutely everywhere function XYZ is called, and one way to do that is to rename XYZ to XYZ___ and see where all of the compiler errors show up.

<comment><USER7> The article and Fowler's Refactoring book had a similar effect on me as well. Your point about statically typed programming languages is one that I've been feeling the brunt of, though I'm not convinced yet.

I've been 100% python for the last few years, after a career mostly in Java and I definitely miss the sweeping refactoring abilities and hard-breaks during those kinds of refactorings. It does lend courage for sure. I'm just SO MUCH MORE productive in python for most of what I do that I'm not willing to throw out the baby with the bathwater yet. Instead I've been trying to focus on leveling up test coverage, and experimenting with Rope for refactorings ( [http://rope.sourceforge.net/](http://rope.sourceforge.net/) ). I'm also slowly learning patterns for coding to make refactorings easier moving forward.. choosing code and data structures that are more easily affect-able later, or even things as simple as naming things for grep-ability.

<comment><USER8> Modern statically typed languages (cough cough not Java cough) generally have static type inference, which removes a lot of redundancy from the code. Being able to do

val object = MyObject(someOtherObject(12, "hello")) // Scala

instead of:

MyObject object = new MyObject(new someOtherObject(12, "hello")); // Java

saves a lot of time and it just looks nicer. All the while retaining the advantages that static, strong typing have (great potential for refactoring, a lot of errors can't happen at all). Of course, there are some things that will still take up more space than they do in Python or Ruby but it's a great improvement. Languages like Rust, Scala or C# also have a good variety of functional programming tools that can make your life a lot easier.

<comment><USER9> Interestingly, this (narrow) case _is_ supported by C++ (auto) now.

Even C, kind of:

#define AUTO_TYPE(X,Y) __typeof(Y) X = Y

... though I'm not sure I'd recommend it.

Type inference in full generality can give you a bunch more, as I just went into over here: [https://news.ycombinator.com/item?id=6327327](https://news.ycombinator.com/item?id=6327327)

</comment></comment></comment></comment><comment><USER10> This is the most overrated and overquoted piece of (bad) software engineering advice ever. Sure, it's harder to read unfamiliar code than write new code, because your understand the reasoning behind the new code. That's exactly why rewrites often make much more sense than labor-intensive incremental changes.

I've had many real-life situations where I successfully chain-deleted thousands of lines of legacy code and replaced it with some sub-100-line method that simply worked. All that without understanding how legacy code works. You're wondering what's the secret here? Instead of trying to deduce the undocumented logic behind legacy code I gathered current requirements and implemented them in the simplest way possible.

In most cases the results were dramatically more readable, because I used build-in language capabilities and standard libraries whereas old code spectacularly failed to do so. Also, I didn't have to worry about requirements that were no longer relevant.

<comment><USER11> >>I've had many real-life situations where I successfully chain-deleted thousands of lines of legacy code and replaced it with some sub-100-line method that simply worked. All that without understanding how legacy code works. You're wondering what's the secret here? Instead of trying to deduce the undocumented logic behind legacy code I gathered current requirements and implemented them in the simplest way possible.

Except one of the main reasons legacy code tends to be so long is that it deals with tens/hundreds of small edge-cases or bugs that your "sub-100-line method" simply cannot account for. So what you are doing when you re-write the legacy code without even understanding what it does is regressing the product by several years in terms of maturity and stability. Your new code will face the same problems the legacy code did, except it will break. And then you will have to start adding to it...

Now, it is absolutely possible that those edge-cases and bugs that the legacy code dealt with are no longer an issue: maybe they were added back in Windows XP days, and your users no longer use Windows XP, or something. In that case, yes, go ahead and rewrite it. But you need to think about and understand what it does first, and why.

<comment><USER12> Exactly, It comes across as really arrogant to replace thousands of lines like that without even looking at them. Maybe those old timers first iteration only had 100 lines too.

<comment><USER13> I've done massive refactorings in the past as the parent is suggesting. But before I do it, I try to figure out whether the code is hard to read because the developer was bad, or because a good developer was forced to add support for hundreds of edge cases over the years.

If I notice at a cursory glance that I can replace more than a few ridiculously convoluted chunks of code with something simpler and be sure that I broke no edge case for those chunks, I just assume that the previous developer was simply incompetent and rewrite the whole thing to meet the original requirements. (And perhaps down the line a developer better than I will do the same with my code!)

</comment></comment></comment></comment><comment><USER14> We have plenty of empirical evidence that you can rewrite from scratch - <USER2> competing product in the marketplace is essentially a 'rewrite from scratch' from the perspective of all the other products. Almost very start up poster on here is 'rewriting' an app in that sense.

If you can't 'rewrite from scratch' (i.e. write a new app) you probably don't have very good programmers (they are only comfortable bandaiding and throwing a few routines in existing code), or, perhaps, management is tying their hands someway. So, I don't buy into the horror stories. Well, I buy that they exist, just not that they should drive my decisions.

Of course, you should expect the cost of your new app to be about the same as entering the business cold. It's particularly difficult to meet every requirement/feature/bug of the old system. Orgs get fossilized around features. If you were to download and install a new IDE you'd expect it to have different features from the old one. You will miss some of the old features, but presumably the new features more than make up for it (otherwise why would you switch). Yet, when we upgrade apps, it's "remove nothing at any cost". It doesn't necessarily make a lot of sense. It can take enormous effort to re-implement some broken feature as opposed to just offering a new way to do things.

None of that is to say I blithely throw code away. I did, once, amidst a bunch of hue and cry of 'oh no', but it was the correct decision because the old system was hacked together by 'weekend programmer' (my boss at the time who was very smart but learned programming from a book). I turned it into a modular, decoupled system, and most of those parts got reused over and over in different parts of our vertical. If you have a plan, and the old code doesn't, it can pay off.

There's more to be said, but this is a wall of text already. Every day I work in the refactor mode, even while mostly adding new features. Its an extremely powerful idiom. But I also have my eye on code that really needs to go to the big bit bucket in the sky. No one understands it, every fix introduces new bugs, and what it is trying to do is very well served by existing open source code, or code be written from scratch.

<comment><USER15> Note the article is from 2000. Joel mostly talks about big and mature desktop software (big as in Microsoft Excel). Average startup's code is small, narrowly focused, has a (relatively) short lifespan, so it can be rewritten from scratch by 1 or 2 people.

If you've ever worked with legacy systems older than 10 years, you'd notice that they become a victim of their own "success". You can't throw away features added over years, because a lot of users depend on it, and if you tried to rewrite it, you'd have to rewrite bug-to-bug.

I worked on such systems, and I did try rewriting, and gave up because of sheer volume of work and the knowledge of institutional lore that was required to do it. On the other hand I'm currently embarking on our startup's "rewrite" and things are much much easier, because the feature set is small and I can freely throw away stuff that didn't work.

See also, [http://en.wikipedia.org/wiki/Gall's_law](http://en.wikipedia.org/wiki/Gall's_law)

<comment><USER16> It isn't just that people depend on the features, you frequently lose track of which features were created for who, and for what reason. Sometimes it's just easier to keep things in motion, rather than start over and wait for someone to scream. (A case can be made for both)

<comment><USER14> Right. I do not argue that rewrite is always the right thing to do; indeed, I argue that very most often it is the wrong thing.

But, answer me this. How many companies have imploded because their software was not maintainable? That's the other half of this article (Joel only wrote half an article, I contend). You can no longer make competitive bids for work because your impossible to understand. It takes months for the simplest change. Your customers leave in droves because your code is endlessly buggy, and you are pouring money into the drain of bug fixes that just introduce new bugs. Or, it is just a long drawn battle, as your profit margins slowly erode away as each new feature becomes incrementally more expensive to implement, until you are at negative return.

I say again; we have massive empirical evidence that total rewrites of very large infrastructure works. If you don't do it, your competitors will do it for you. And, of course, if you do it when there is no competitive need for it, you will be flushing money and/or your company down the drain.

(edited to fix some grammar and clarify a few poorly worded points)

<comment><USER16> I wish good data existed on this, but most would be confidential, and this is very hard to measure to begin with. Ultimately it's a judgment call. There isn't a black and white, but Joel is giving a Year 2000 plea that people at the time were tilting the wrong way.

</comment></comment></comment></comment></comment><comment><USER17> This is an interesting article because though the rewrite killed Netscape, the rewrite became Firefox, possibly the most popular browser in the world.

It became that way because developers were able to run laps round Microsoft (who clung to an old, bad codebase).

And because it was a redesign not just a rewrite, and the redesign redefined what browsers did.

Firefox, as we use it today is a rewrite of that rewrite, with god forbid far less features than the original!

I wonder, with a little more money behind Netscape, and without anti- competitive MS browser bundling, would Joel's piece look so correct in hindsight?

<comment><USER18> I remember using IE when they started bundling it with Windows and it was a FAR better experience with instant loading instead of waiting Netscape to load. Everyone likes to blame the bundling of IE as causing Netscape to fail, but in reality, the initial versions of IE just worked better. Netscape's engineers knew this, and probably realized they had to rewrite to compete with the speed of IE.

Interestingly enough, these days hardly anyone I know uses IE or Safari even though both are bundled with their respective operating systems. Most of these folks install Chrome because they are familiar with it and it doesn't impose any significant performance penalty.

Ideally, Netscape should have been optimizing their browser for speed all along. But since they were the only kid on the block for so long, they became numb to how slow things had gotten. It took IE coming in with a much better experience to shake them into action. Unfortunately, by then it was too late for Netscape as a business to recover.

<comment><USER19> For your information, The bulk of IE loading happened during Windows boot. The user just wasn't informed of it.

I don't know whether Netscape could have done the same and didn't, or whether it required some inside access to Windows.

<comment><USER17> In oldschool firefox, maybe in navigator too, pre-loading was implemented as a tray icon. The tray icon would load at startup, and could be used to launch the browser. It still felt overly heavy.

</comment></comment></comment></comment><comment><USER20> If I had superpowers that allowed me to delete one website from the in internet forever, it would be this article.

I find the "complete code rewrite" to be the most powerful programming technique I have in my repertoire.

In 2007 I wrote an application called FlightLogg.in. It was basically a clone of logshare.com that I wrote in my spare time with PHP. It was my first really 'big' project. You can see the code here: [https://github.com/priestc/old- flightloggin](https://github.com/priestc/old-flightloggin)

If you look around that codebase, you'll see nothing but spaghetti. I starting writing the app in late 2007, back when you could say I was a 'noob' (so noobish in fact, I didn't even use source control). At the time I thought I was writing the most awesome code ever. By the middle of 2008, that project had reached a state where it was pretty much 'done'. I then stopped working on that codebase, and moved on to other projects.

Then by late 2008, FlightLogg.in's traffic had kept growing, and there was a list of bugs and really cool features that I had thought up since I last touched the codebase a few months earlier. I set out to continue development on the PHP codebase. The problem was that in the past few months I've been away, I had become a better programmer, and the sight of that spaghetti code made me vomit.

It was less about the code being 'bad', and more about me not remembering how things worked. The small set of fetures and fixes I wanted to make would have taken me a few hours to do back when I was first working on this codebase. Since a few months time had passed, it was taking me much longer.

Eventually I decided to do a complete code rewrite. This was before I ever saw that Joel Spolsky article. The new codebase is here: [https://github.com/priestc/flightloggin2](https://github.com/priestc/flightloggin2) It took me roughtly the same amount of time to build the new codebase as it did the old codebase.

Ever since, each and every project I take on, I accept the reality of doing a complete code rewrite might come up. For my own personal projects, I do complete code rewrites all the time. On the other hand, at the various jobs I've had over the years, its a much different story. If I came into work today and brought up the idea of doing a complete code rewrite, I'd either get laughed out of the room, or even worse, threatened with being fired, thanks to this Joel Spolsky article. Thanks Joel.

<comment><USER21> Joel isn't talking about the kind of software that can be rewritten in a few days or weeks. He's talking about "large scale commercial applications" ...

If you have an app with a complex codebase that is making money in a pretty competitive space and you decide to stop everything and do a complete refactor (the blocking kind in which you can't do anything else while that is going on) then you find yourself in a situation where you can easily be surpassed by a competitor. Its probably a smarter move to do a more 'gradual' refactor.

<comment><USER20> Its not like I had to shut off the old site while I worked on the new codebase... The old codebase was running perfectly fine, up until I shut it off and replaced it with the new code.

<comment><USER22> There are plenty of projects where by the time you've finished your rewrite the product will have moved on so far that you'll have to rewrite some again. I seem to recall Facebook making several attempts to rewrite in a language other than php but the codebase just evolved too quickly.

<comment><USER23> You don't rewrite for features. You rewrite for better maintainability and productivity. After your rewrite you shouldn't have to rewrite it again. The balancing act is that a rewrite should improve your implementation velocity, so while it may be a setback, your velocity should be much higher than your competitors, so over time you would be able to surpass them and then gain a lead they cannot beat thanks to your higher productivity. As the technical debt grows, your productivity will get slower and slower, so you won't be able to keep up with your competitors anyways. That's the gamble.

Just because Facebook was written in PHP doesn't mean that the code was unmaintainable. I don't know if it was or not. The problem they had was that it was unscalable, and they didn't do nothing about it. They wrote a PHP to c compiler, and that's a monumental task. So they paid their technical debt in a different way that they decided was the most efficient way for them to deal with it. If the problem isn't scalability, and is maintainability, you may not have that luxury. Unmaintainable code's problem is inherently in its structure, and the only solution for that is refactorization or a rewrite. The code may be so unmaintainable that even refactorization isn't really possible. The best offense is a good defense. Deal with technical debt from the get go. Sure, write your MVP in a weekend just to test it, but rewrite it early for maintainability while it's still small and possible.

<comment><USER22> Fair points. I guess I was reacting more to the fact that the original example probably wasn't of the scale (single person) to use as an example. The Facebook case is definitely different in that they were building new features too fast to keep up with.

My project (single developer) is undergoing a big underlying change (switching from MongoDB to Postgresql) at the moment. I still need to keep development going on the live branch while I do this work. I'm doing it because I'm having maintainability issues with the data store that I've been putting off for a couple of months. It's as you say - make sure you refactor before you discover that refactoring is impossible. It's something I do regularly and my business partner has noticed that after a refactor of a component he gets other features faster so that's the only justification he needs.

</comment></comment></comment></comment></comment></comment><comment><USER24> If you read jwz's output, it's not that "Mozilla decided to rewrite it", it's more like "bunch of idiots who didn't know what they were doing took over and tried to rewrite things whilst ignoring all the sane advice".

</comment><comment><USER25> Great article that is still relevant today (sadly, I remember reading it when it first came out). If you really, really feel the need to rewrite from scratch, I recommend instead picking up a copy of "Working Effectively with Legacy Code" by Michael Feathers [1]. It will give you ways to improve those terrible code bases while not throwing out the existing code. Plus you'll still get that "new car smell" of working on your code.

[1] [http://www.amazon.com/Working-Effectively-Legacy-Michael- Fea...](http://www.amazon.com/Working-Effectively-Legacy-Michael- Feathers/dp/0131177052)

</comment><comment><USER26> Seems to me that a lot of what Joel was complaining about could be mitigated by some well-placed comments in the code. "This function is 2 pages long! Oh, this part does that, and THIS part does THAT. I see what's going on. This is all good."

This seems to be something people don't even bother to argue about any more. Everyone's given up! I don't do much myself, but no one I have worked with over the past 20 years has done ANY. Scary. I've only recently moved out of engineering to a "real" coding firm, but I'm still not seeing it.

I guess coders, in general, either think that everyone should immediately understand WHY code should be doing what it's doing, or be fired, or they think it's job security to not share these details.

<comment><USER27> That's sad to hear. Part of it is an ideology that code that needs commenting should simply be rewritten. But I've written many paragraph-long (or page- long) comments, especially at the class and module level. Where comments are really necessary is to give a big picture overview how all the parts come together. Or to explain the "why". My personal theory is that comments are like chess annotations. Sure you could just read the notation, but the comments show you what is unseen, like what would have happened in six moves if white had taken that pawn. . . .

<comment><USER28> This is a really insightful comment. I've struggled in the past with what the purpose of commenting is. I've written some programs where comments were the majority of the code, and it was actually more difficult to read than if I'd just left it unannotated. I've also written quick-and-dirty programs that gradually turned into behemoths, left them alone for six months, and then come back to them and felt like kicking myself for not putting comments in.

I just had a crazy idea for commenting, though - I'm imagining an IDE that is built for two monitors. The left monitor is your source code. The right monitor is your comments. You wouldn't put your comments in and around the code; you'd put them into this application that would be running on the right monitor. When you select a line of source code, the relevant comments pop up on the right side. They can be as complex as you want them to be. If your class needs five pages of comments, you can put five pages of comments and not have to worry that it's going to disrupt the source code. Then, when you select something else, that comment disappears and is replaced by the comments for that line. You could even have extra monitors (or sections of that comment monitor) showing multiple things - for example, you could have the function's comments along with the line-by-line comments.

Is this crazy, or more importantly, has this been done before? I think the first thing that someone will say is that it's too much effort, but it doesn't have to be used for everything. You don't need to make a five-page comment for your for-loop, but you might for your massive class that encapsulates ten objects and has forty-five functions that modify different things.

<comment><USER27> I've never heard of showing two different view styles of the same source code document in two separate windows/monitors, but it makes sense. Perhaps this could be done with literate programming, or LaTeX packages (where you use the same file either to build the documentation or install the package), or even Javadoc and its imitators, with an IDE that lets you collapse either the comments or the function bodies. Maybe Light Table could have something like this? But if your tooling had good support for it, like being able to click on a function in the code window and make the doc window bring up that function's info, that'd be pretty nice.

</comment></comment></comment></comment><comment><USER29> The rewrite meant Netscape 6 used Gecko, which brought us Firefox, which revived the browser wars, which brought us the WebKit browsers.

History is a twisted mess...

<comment><USER30> The real question is would Firefox on old Netscape 4/5 engine run the same and allow them to do what they did with Firefox? Or would they have eventually rewrote it into what Gecko is today?

<comment><USER31> I think Mariner (the codename for the cancelled project) was supposed to be developed in parallel with Gecko.

</comment></comment></comment><comment><USER32> One of the huge pitfalls in the writing from scratch situation is that often times the original application didn't have adequate requirements. So the team sets about building the new version without a comprehensive and detailed understanding of what the old version did. That alone can lead to huge timeline and cost overruns.

And if your organization didn't learn from its mistakes the first time around, it'll make many of the same mistakes the second time around, except this time they'll be concentrated in one monster release rather than a number of smaller releases. Especially if the original developers have left.

</comment><comment><USER33> _It is easier to write an incorrect program than understand a correct one._

\-- Alan J. Perlis, Epigram 7

</comment><comment><USER34> I picked up the Pragmatic Programmer some time ago and among the great lessons it had, the one that sticks with me every day at the code editor is: You spend far more time reading your code than you will writing it.

With that in mind, it makes it easy to write tests and more comprehensible variable names (still thinking and re-thinking how to best do documentation...was checking out github's Ruby guide and Tomdoc yesterday [http://tomdoc.org/](http://tomdoc.org/))

<comment><USER35> That looks like noise to me. There is almost four times more code dedicated to comments than useful code. If you write unit tests it would cover/explain all these cases. I don't see the point.

<comment><USER6> I agree. It would work a lot better of the function were called something like "stringRepeat" or "duplicateText" or something other than "multiplex", because that's really not what multiplexing means. Then, rename that one parameter from "count" to "repetitions" and the function is almost completely self- explanatory.

Not to mention, it probably doesn't deserve to exist at all. "text * count" is simple enough that it should probably be inlined.

<comment><USER35> Comments are generally superfluous, sometimes incorrect and often used to explain away bad code.

<comment><USER36> Depends on the comments. I had to go and fix someone else's scripts, with comments like:

#open files and read contents

#loop through list

No idea what was in the file, or why the contents were being read. What was the purpose of the loop.

Commenting on those things would have saved me a lot of time. (It took me a week to fix something that should have taken a day, if it had been coded better in the first place.)

(To put it into context, it was a previous workers code which interacted with the database I had written. When I changed some things in my code, her code stopped working. I didn't know how exactly her code worked, or the nature of the files that it was reading from the system, but I did know what working right would be. I am sure this is not an uncommon situation.)

</comment></comment></comment></comment></comment><comment><USER37> This is esp. true for dynamically typed languages.

An IDE helps a lot more deterministically for a static typed language like Java.

<comment><USER38> Say what you want about Java, its awful "kingdom of nouns" paradigm, its lack of nice functional features, etc., but it is a highly readable programming language.

<comment><USER39> I think all the boilerplate really does detract from the readability. Your eyes sort of glaze over and you can miss small departures from the boilerplate you expect to see.

<comment><USER40> Really? You have trouble with code like this?

        RegistrarInstallationsChoicesSubclass registrarInstallationsChoicesSubclass = millisDOMX509Grow.getRegistrarInstallationsChoicesSubclass();
        KeyedGSSPolygons keyedGSSPolygons = new KeyedGSSPolygons(incompatibleTransliterationNoPerfCombiningContention, iSO885915ConnectionlessAsyncDiagonal, dotDataetJDIMarshallingResourceszhObservablesDiagonal, native2asciizhDelegateEnvarLearned, insertStrategyRTFLearned);
        keyedGSSPolygons.addISO885915ConnectionlessAsyncDiagonal(iSO885915ConnectionlessAsyncDiagonal);
        AppendingGuiceJustificationMarshalling appendingGuiceJustificationMarshalling = instantiatorParenthesisForeachOutlineCounted.getAppendingGuiceJustificationMarshalling();
        AdaptiveReflogMerges adaptiveReflogMerges = new AdaptiveReflogMerges();
        adaptiveReflogMerges.addIishCoolbarTuple(iishCoolbarTuple);
        AppendingGuiceJustificationMarshalling appendingGuiceJustificationMarshalling = keyedGSSPolygons.getAppendingGuiceJustificationMarshalling();
        RanksPessimisticSeparableDialFirst ranksPessimisticSeparableDialFirst = new RanksPessimisticSeparableDialFirst(native2asciizhDelegateEnvarLearned, colorizeHmacComplexJanitorEnvar);
        ranksPessimisticSeparableDialFirst.removeIncompatibleTransliterationNoPerfCombiningContention(incompatibleTransliterationNoPerfCombiningContention);
        AdaptiveReflogMerges adaptiveReflogMerges = fixerAppletPerfEs.getAdaptiveReflogMerges();
        ReferencerBreakingViewersvAes256RenderingsGJ referencerBreakingViewersvAes256RenderingsGJ = new ReferencerBreakingViewersvAes256RenderingsGJ(membershipDriverConsistency, iishCoolbarTuple, sectorPartsGJForking, ranksPessimisticSeparableDialFirst);
        referencerBreakingViewersvAes256RenderingsGJ.addISO885915ConnectionlessAsyncDiagonal(iSO885915ConnectionlessAsyncDiagonal);
        DitherTWSDLGraphemeInserting ditherTWSDLGraphemeInserting = cnxnsCNTWSDL.getDitherTWSDLGraphemeInserting();
        Message12DL2ExposeReconcilablePerfEditionUnaligned message12DL2ExposeReconcilablePerfEditionUnaligned = new Message12DL2ExposeReconcilablePerfEditionUnaligned(dotDataetJDIMarshallingResourceszhObservablesDiagonal, sAXXMINamessvInconsistencyAnswerLoopingCommunicatorEdition, insertStrategyRTFLearned, dotDataetJDIMarshallingResourceszhObservablesDiagonal, nIDiffuseGraphemeINAes256Kind);

<comment><USER38> Lulz. This is why you don't do graphics programming in Java.

</comment></comment></comment></comment></comment><comment><USER41> This article shows how much progress we've made in languages and tools over 13 years. It's vastly more difficult to read large, c++ codebases with tons of memory allocation, pointer arithmetic, macros, and complex locking schemes than much of the Java/Ruby/other mainstream language code written today.

Also, it strikes me that this was written in an era where most large-scale systems were giant monolithic codebases sharing an address space, rather than distributed groups of services communicating over a network. Distributed systems are inherently easier to rewrite because a lot of the hard problems around abstraction, state, representation, etc. already have to have been solved by the architecture -- you can't exactly pass a naked void* over the wire.

</comment><comment><USER42> So he was wrong then? NS6/firefox seems to be doing alright today... Rewriting your OWN codebase from scratch certainly makes it get better with each iteration - as long as "from scratch" implies constantly referring to the old code.

<comment><USER43> In 2000 Netscape had 19.25% market share, it took 8 years to get back to that position with Firefox: [http://en.wikipedia.org/wiki/Usage_share_of_web_browsers#The...](http://en.wikipedia.org/wiki/Usage_share_of_web_browsers#TheCounter.com_.282000_to_2009.29)

</comment></comment><comment><USER44> This is from 2000. People need to stop posting old articles without putting a date in the title.

<comment><USER45> Relevance and recency are not always directly proportional.

</comment></comment><comment><USER23> The new historical perspective on this is very interesting. The code rewrite killed the company, but it gave birth to mozilla, which came back to topple IE from its throne and help bring through a new renaissance of browser development. If they hadn't rewritten their code how would have history changed? Would we be where we are today? How many years behind would that setback have put us? The release of Firefox was instrumental at disrupting and evolving the web. With a poor code base could they have done that as effectively as they did?

A company may be transient, and killed by choices that hurt them in the short run, but will support them in the long run. But good open source code is eternal. The quality speaks for itself. Their decision may have killed their company but it was astronomical for the web. From a higher level perspective, they did the right thing, and it shows that good code is so powerful, it can even outlive the company that made it.

<comment><USER46> On the other hand it was particularly for this stand-still of NS, why IE was on the throne. And this made HTML/JS effectively a proprietary standard, which brought web development eventually to a stand-still also.

When open standards enforcing browsers finally became available (and – saying this as a once ardent NS-follower* – what a buggy mess NS 6.0 was in the beginning!), it was essentially a political question, whether they would succeed or not (as they were incompatible to most of the existing web code base).

*) I used to code NS4.x-compatibility and open standards calls then, even, if I wasn't able to bill for these as clients were only interested in "does it work on IE, so it's fine".

</comment></comment><comment><USER47> I know I don't have the expertise to argue with Joel Spolsky about software engineering, and while I agree that rewriting from scratch is a huge strategic mistake, it is hardly the worst.

Have any of you ever worked for a large engineering firm with a sizable operating budget? There are many "strategic" errors that happen on the daily basis in those kind of shops that range from software stack choices to engineering process drowned in bureaucracy. Rewriting code is hardly the worst.

Also, don't assume that even though rewriting code is bad for business, it's bad overall.

You iterate, and learn from mistakes you made that were caused by the lack of experience at the time previous code was written.

You de-couple components during a rewrite and eliminate unnecessary features, drastically improving maintainability.

You make it easier for other programmers (and yourself) to read the code.

You can alter core platform pieces, make tech stack alterations, and eliminate reliance on legacy components during a rewrite.

The list goes on...

</comment><comment><USER48> At first sight, this statement seems odd. For sure, writing a text is more difficult than reading it, and programming is writing a text. But a different kind of text. A program is written to communicate ideas with a computer first, and with humans second, whereas an article or novel is written to communicate ideas with humans only. What if we would have a programming language that allowed us to write to communicate ideas to humans first and have the compiler/interpreter automate the communicating with the computer?

Or could it be that a non-trivial program is essentially more complex than an article or novel or any other regular text we encounter daily?

Or is reading a program similar to reading a text in an unknown language? Like trying to read some Roman text when you don't really know Latin, but you've access to a Latin-English dictionary and a good grasp of history and the context and topic of the Latin text?

<comment><USER49> Reading and writing themselves are the least difficult parts of reading and writing programs. The majority of writing a program is conceiving of a well- defined model--after that, all you are doing is typing. The majority of reading a program is attempting to reconstruct someone else's conception of a model into your own brain from the typed description. Reading just the text written for the computer answers all of the "what" (as if it didn't, the program would not run), but none of the "why" \-- and so makes reconstructing that model very difficult.

<comment><USER39> Yes and even after you have enough working knowledge to support or enhance the code you will still find yourself continuously suprised because your model is not a perfect understanding of the author's intended model, AND the code itself is not a perfect representation of that model to begin with.

</comment></comment></comment><comment><USER50> Code may not rust overtime but it does become harder to maintain and more importantly harder to find quality innovative people willing to work on it. I would guess that very few of the people making a pro argument for Joel Spolsky's article would be willing to support 1970's COBOL banking software for a living.

</comment><comment><USER51> It's not black and white. There are situations where investing in your old code base is throwing good money after bad and there are situations where the old code base can be better. You need to make educated decisions not blindly follow rules.

Refactoring can be a problem because you're always working towards some local minima. It's a little bit like the decision to renovate an old house vs. raze it and build a new one or buy an old car/boat and repair it.

There's a good discussion of various factors here: [http://programmers.stackexchange.com/questions/6268/when- is-...](http://programmers.stackexchange.com/questions/6268/when-is-a-big- rewrite-the-answer)

</comment><comment><USER52> There's a time and place for everything. Firefox and Mac OS X are examples of successful rewrites. I've had some positive experiences with re-writing certain things from scratch. Not to downplay the issues Joel raised back in 2000, but if a product is tied to a technology that's limiting its effectiveness, and better alternatives have become available, a next- generation implementation bears consideration. I think companies that fail to iterate and evolve this way will ultimately stagnate.

</comment><comment><USER53> I can't imagine how a codebase could be so horribly bad that it doesn't do even one thing right, and you have to throw it out wholesale. That is, assuming it was good enough to ship at some point.

I don't like to feel that I'm wasting my time doing rework, and vulnerable to getting in way too deep with no backup plan. I'd definitely want to rewrite in pieces without ever discarding the whole, even if eventually there might come a day when every single piece has been rewritten.

</comment><comment><USER54> You usually only hear the catastrophic failure anecdotes. Large, complex, yet successful rewrites I know about:

* The Windows kernel. From my understanding, Windows NT was a completely different kernel from Windows 95 and eventually replaced it in Windows XP.

* Coldfusion, I used to work with an ex-Adobe guy that told us the story how this was rewritten from scratch at one point. From C++ to Java

* I used to work on the SQL Server team at Microsoft. We completely rewrote the Reporting Services product between the 2005 and 2008 releases.

<comment><USER46> Windows NT was an incremental update to what would have been the next VAX-OS. (As for my humble knowledge.) See "Dave Cutler and Windows".

But another good example for a very successful rewrite would have been Adobe's ActionScript for Flash 5 (turning to an ECMA-script-like language).

</comment></comment><comment><USER55> I always deem readability the number one priority in writing working code. Readability is not just about understanding what the code in front of you is doing but also easiness to find where in code a particular business logic was implemented. Code written with readability as the top priority has the best chance of avoiding the need for a full re-write. And even if it needs to be re-written from scratch, it's so much easier with a readable codebase.

</comment><comment><USER56> How does this apply to a platform change? Say, going from an application written on 80's UNIX hardware that's still going strong today on a 9-year old Itanium system?

Start writing replacements for individual modules? The original programmers are set to retire in another 5 years and then it's going to get really, really ugly.

</comment><comment><USER57> April 06, 2000.

Any progress report on this?

<comment><USER58> This article has been posted around 3-4 times this year alone. Most people should already be well aware of the cost of a full rewrite due to all the horror stories. Yet, sometimes the best software has come from a full rewrite.

<comment><USER6> Unless the original system just did nothing of what it was supposed to do, a full rewrite being successful would be in spite of itself.

</comment></comment></comment><comment><USER59> (2000)

</comment><comment><USER31> An example is legacy color parsing. I personally figured out where legacy color parsing is in the Netscape classic source: [http://stackoverflow.com/questions/8318911/why-does-html- thi...](http://stackoverflow.com/questions/8318911/why-does-html-think- chucknorris-is-a-color/12630675#12630675)

It is so subtle even Netscape's own Gecko rewrite did not get it completely right the first time: [https://bugzilla.mozilla.org/show_bug.cgi?id=121738](https://bugzilla.mozilla.org/show_bug.cgi?id=121738)

</comment><comment><USER60> Does anyone have a good way to distinguish between -

A) Rewriting the codebase.

B) Fixing & modularizing the codebase - breaking it up into self-contained units/parts while improving, cleaning, and modernizing them?

Because if you throw away the edge-case of completely starting from scratch, B) can easily be seen as A) and vice versa.

Is there a thin line here?

(*I have a 200K line C#/.NET app that will be evolving and pivoting with it's next major version).</comment>


Google sees alleged child porn in man's email, alerts police - <AUTHOR> http://www.cnet.com/news/google-sees-alleged-child-porn-in-mans-email-alerts-police/ <comment><USER2> [https://news.ycombinator.com/item?id=8128951](https://news.ycombinator.com/item?id=8128951)

[https://news.ycombinator.com/item?id=8131407](https://news.ycombinator.com/item?id=8131407)

[https://news.ycombinator.com/item?id=8125039](https://news.ycombinator.com/item?id=8125039)

[https://news.ycombinator.com/item?id=8128687](https://news.ycombinator.com/item?id=8128687)</comment>


Gearing Up for the Cloud, AT&T Tells Its Workers: Adapt or Else - <AUTHOR> http://mobile.nytimes.com/2016/02/14/technology/gearing-up-for-the-cloud-att-tells-its-workers-adapt-or-else.html <comment><USER2> I honestly have no idea what their version of the cloud is.</comment>


Google releases 'My Location' for cellphones (w/ google maps) - <AUTHOR> http://venturebeat.com/2007/11/28/google-releases-killer-my-location-feature-for-cellphones/

<comment><USER2> It gave my location to within a few blocks. In a small town without a car, though, "a few blocks" is significant. Not obviously useful to me, yet.

</comment><comment><USER3> What's a good phone and plan that will give me unlimited internet access? I couldn't figure out how to add it to my tmobile plan.

<comment><USER3> wow, I checked verizon and tmobile and didn't find something like iphone unlimited internet access for a different handset. What am I doing wrong?

</comment></comment><comment><USER4> Wow, great. Now Google knows my e-mails, what pages I google for, and where I am.

</comment><comment><USER3> Is this software you install on your phone or do you just have to go to that URL?

<comment><USER5> It's software. Google Map Mobile, a java app in most cases. I just downloaded it but unfortunately the my location feature is unavailable om my phone.

</comment></comment><comment><USER3> Will it work on the iphone?

</comment><comment><USER6> Loopt, you guys need to react quickly.

<comment><USER7> Loopt supports a broad range of devices already, with greater accuracy:

<https://loopt.com/loopt/phones.aspx>

More are on the way :)

<comment><USER6> It its current form Loopt is a niche product because it requires GPS. The salient feature of "My Location" is that it doesn't require GPS - this is what make it a game changer.

<comment><USER8> Don't nearly all phones now sold in the US have GPS?

<comment><USER9> They all support GPS for the purposes of E911, but I don't think most of the phones that triangulate position from tower data support GPS for application developers or anything other than E911. <http://electronics.howstuffworks.com/gps-phone2.htm></comment></comment></comment></comment></comment>


Ask YC: How to choose the best Open Source license for your project? - <AUTHOR>

Hey guys, we're starting to go through the process of open sourcing our project.  Problem is, it's hard to figure out which license to go with. Has anyone here gone through the process before? What licenses do you prefer + why?  What works for commercial open source companies? <comment><USER2> I head an open source project that provides bilingual semantic analysis of Chinese (<http://www.adsotrans.com>). The commercial opportunities we get come from having the best and most flexible software in the market. (If anyone wants to launch a semantic search or advertising network in China, I'm your man). Being open source is irrelevant.

There have been three advantages to being open source in my experience: (1) it can help potential clients find you and simplifies the sales process since everyone is already crystal clear what you provide, (2) it can attract users to contribute things that aren't software, but that the software helps you generate (content, data), or (3) you want other people to contribute to the actual code base.

Neither #1 nor #3 are good enough reasons to go open source in my opinion if your goal is making money. The only advantage you'll have over a closed source company comes with #2 - in which case you aren't a software company at heart. All of these rules go out the window if you're working in a really, really niche area, but then your business is really consulting.

My advice would be that if you REALLY want to go open source for some reason, use a license that permits others to use and develop your software, but doesn't permit them to redistribute it. This will prevent others from forking the code commercially, but won't deter hobbyists and/or developers from using it to build systems themselves. Restrictions on redistribution also give you the freedom to change the license in the future when you figure out what you should be doing while protecting early adopters from having the rug pulled out from under them. At that point they can either continue developing the software themselves, or start paying for it.

<comment><USER3> If you can't redistribute it at all, it's not really Open Source. The GPL is the most restrictive license of those that meet the OS definition, more or less.

</comment></comment><comment><USER3> Depends on your goals.

It's not a bad question, but I wonder if someone hasn't written a definitive answer yet...?</comment>


Another Standing Desk? Yup with Launch Discount - <AUTHOR> http://www.smplstndrd.com/ <comment><USER2> Cool that you can do that with cardboard, but $120 is a bit steep.

I'm sure you could get the cost down with volume, but how low, really, can get you go?

Wouldn't it be better to have something that would sit on top of a desk (and was height adjustable)? That way I can keep my existing dest and easily pop up when I want to stand.

</comment><comment><USER3> For that price you can find a Jerker on Craig's List...

$120 + tax for cardboard? Nice profit margins if you can get it.

Jerker was only $129 new. I'm certain IKEA was paid to kill that desk off... It was too perfect.

[https://www.jerkersearcher.com/](https://www.jerkersearcher.com/)</comment>


Deep Dive into WeWork's User Base as Hundreds of Members Cancel - <AUTHOR> https://firstname.lastname@example.com/deep-dive-into-weworks-user-base-as-hundreds-of-members-cancel-6b17d3be1d8b#.d6u2shcy2 <comment><USER2> Where did you get this data?

<comment><AUTHOR> This is what we do at Thinknum -we build bots to index business data across websites for thousands of companies.

<comment><USER3> But Justin.... this is a privately held company. You yourself wrote "Until now, skeptics have relied on back-of-the-envelope math and gut level instinct". So how did you take a deep dive into all 69,280 members who have ever signed up for their co-working space?</comment></comment></comment>