I was bored so I did a Flickr Instant Search - <AUTHOR> http://instantimg.appspot.com/flickr

<comment><USER2> Do we really need every single one of these Instant Search copy cats to be posted to Hacker News? A few lines of JavaScript to submit a form for you after you type a few letters is not impressive at all.

<comment><USER3> Submit something awesome and I'll upvote your technical feats instead.

</comment></comment><comment><USER4> Want a job? ;)

</comment><comment><USER5> I did a few searches... land, cobra, corn... and really didn't get many results that matched those words. Is that just how people are tagging them w/in Flickr?

<comment><AUTHOR> The default order is date-posted-desc I should try other parameters like interestingness-desc, interestingness-asc, and relevance.

</comment></comment><comment><USER6> I don't think your search is working correctly. Google's 'instant' shows its prediction's results. Yours shows the results of the exact characters already entered. Yours only shows the prediction if you hit 'enter' and let it auto- complete.

<comment><AUTHOR> Yes you are right, I will try that

</comment></comment><comment><USER7> I can see that you're providing a prediction, and it was actually spot on accurate for my search term very early on ("golden retriever"). How do I actually have it use that term?

<comment><USER6> I tried that search and when I hit 'enter', it filled the rest in and did the search

</comment></comment><comment><USER8> The appeal of instant search is completely lost on something like this, where a bunch of heavy pictures have to be constantly reloaded.

<comment><USER9> It is fast on my fiber optic connection.

</comment></comment><comment><USER10> Errrm... I searched for "dog" and got pictures of women, then searched for "cat" and got pics of cars. Not sure whats up there!

</comment><comment><USER11> Can you send me an email? firstname.lastname@example.com Im trying to build an instant search for a big online retailer.

</comment><comment><USER12> Now working for me, no instant updates and pressing enter on search query does nothing. Firefox 3.6.9

<comment><AUTHOR> I just fixed it, I removed a console.log line that was breaking firefox. Enter will only apply the google suggest query on your search. Thank you

<comment><USER12> Works now. I see you limited the amount of search results. No pagination?

</comment></comment></comment><comment><USER13> You were bored? It shows.</comment>


Theranos faces congressional inquiry over faulty blood tests - <AUTHOR> https://techcrunch.com/2016/07/05/theranos-faces-congressional-inquiry-over-faulty-blood-tests/ <comment><USER2> But their still hiring!</comment>


Machine Learning Interships - <AUTHOR> https://blog.bigml.com/2018/02/23/kicking-off-the-bigml-internship-program/ <comment><USER2> I attended your ML Summer School, and this looks interesting, will definitely have a have a look!

Props for using Clojure, It's a beautiful and productive language. Just being curious, which ML libraries are you using?</comment>


NewLisp – puts fun back in Lisp - <AUTHOR> http://www.newlisp.org/ <comment><USER2> Some previous commentary

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

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

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

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

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

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

And Paul Graham [http://lambda-the- ultimate.org/node/257#comment-1889](http://lambda-the- ultimate.org/node/257#comment-1889)

</comment><comment><USER3> Source code?

<comment><AUTHOR> The source code is on sourceforge [1] with unofficial mirror on GitHub.

[1] [https://sourceforge.net/projects/newlisp/files/](https://sourceforge.net/projects/newlisp/files/)</comment></comment>


Interactive coin offerings (2017) - <AUTHOR> https://arxiv.org/abs/1908.04295 <comment><USER2> [2017] - It was only just now added to arxiv.

Here is an explanation in blog post form by Truebit (the primary authors company): [https://medium.com/truebit/an-intro-to-truebits- interactive-...](https://medium.com/truebit/an-intro-to-truebits-interactive- coin-offering-e6d1dae36090)

</comment><comment><USER3> [https://upload.wikimedia.org/wikipedia/commons/3/39/Ethereum...](https://upload.wikimedia.org/wikipedia/commons/3/39/Ethereum_Price_History.png)</comment>


Epic Demonstrates Unreal Engine 3 for the iPod Touch/iPhone 3GS - <AUTHOR> http://www.anandtech.com/gadgets/showdoc.aspx?i=3695

<comment><USER2> I need some kind of controller I can mount the iPhone to -- maybe better speakers, a d-pad, a couple buttons, extended battery pack.

I would pay for that (maybe you could even bundle some games with it!).

<comment><USER3> I would settle for being able to simply use a bluetooth keyboard - that would be sweet - just put on some headphones for audio. I do quite a bit of itouch gaming, and would love to be able to do that.

</comment></comment><comment><USER4> Maybe now they'll finally make a finished Linux port of the engine for all of those Linux-based smartphones.

<comment><USER5> We can but dream. Icculus was working on an Unreal 3 port to Linux (on the desktop), but appears to be on ice for whatever reason.

Latest news about UT3 on Linux: [http://www.phoronix.com/scan.php?page=news_item&px=NzI4N...](http://www.phoronix.com/scan.php?page=news_item&px=NzI4Ng)

</comment></comment><comment><USER6> So I take it the iPhone 3GS has programmable pipe-line graphics hardware? I was just talking with some folken over at gamedev.net about whether or not there were any handheld devices out right now that have shader support. That's really the only big deal here. Graphics engines like Unreal 3 are intended to be very, very efficient. You don't end up with a top-of-the-line 3D rendering engine by being wasteful of processing cycles, and that translates to handheld development universally. The change in rendering paradigm from fixed to programmable pipeline has been the biggest hurdle to getting the latest engines running on "less performant" hardware. After that, it's all content. It makes no sense to use Unreal v1 to push 100,000 triangles when Unreal v3 will push 100,000 triangles a lot faster.

<comment><USER7> iPhone 3GS has OpenGL ES 2.0 with shader support. OpenGL ES 1.1 was fixed- function and is what is currently on the iPhone/Touch. So when everyone moves to 3rd gen touch or 3GS then shaders will be in effect for the market.

<comment><USER6> Yeah, that was something that surprised me about the Motorola droid: it's only GLES 1.0, with _vague, incomplete_ support for 1.1. Fixed-function is an unfortunate conceit these days. Programmable pipeline is actually easier to teach to complete noobs.

<comment><USER7> It is really just a matter of the timing of the hardware. Mobile is about late nineties systems, when it breaks into the opengl es 2 support and 1GHz and 512MB RAM area then we will see the devices jump up to shader support.

Then you will also start to have flash and other software rendered stuff being fast enough. But battery technology needs to advance further as well.

Couple years out except for the cutting edge like the iPhone or the coming Google Phone (HTC) which has Android 2 which also has OGL ES 2. Android will also have the NDK (native) to compete with the native iPhone SDK to speed things up. It is just like coding for old hardware but with better software. So native, graphic tricks, hardware rendering, etc are all relevant again for a moment.

<comment><USER8> AFAIK android sdk 2 doesn't support opengl es2

<comment><USER7> Yeh they might not, but they need to. Android NDK 1.6 uses OpenGL 1.1 so you'd think with the iPhone 3GS being OpenGL ES 2.0 that the rumored Google Phone Nexus One would also be that and the next version of android would be as well. Guess we'll have to see. WebGL is based on OpenGL ES 2.o and Windows 7 mobile might even support it.

It is rumored to be so: [http://www.fastcompany.com/blog/kit- eaton/technomix/guts-goo...](http://www.fastcompany.com/blog/kit- eaton/technomix/guts-googles-nexus-one-smartphone-spill- net?partner=homepage_newsletter)

<comment><USER8> Yeah, completely agree, supporting the 2.0 standard is essential to remain on par with the iphone and not make android phones look like second class citizens. The wave of "handheld-console level" 3d games on iphone is coming soon, so if not in 2.1, it would be ok even if they slip it in one of the next minor releases. Just one thing bothers me, the introduction of gl2.0 will further segment the market...

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> Taking bets that the "other mobile platform" is the ZuneHD.</comment>


We Hire the Best, Just Like Everyone Else - <AUTHOR> http://blog.codinghorror.com/we-hire-the-best-just-like-everyone-else/ <comment><USER2> tl;dr: The only measure of on the job performance is on the job performance. The only thing that _matters_ to your company is also on the job performance. Why not focus on that?

It is utter voodoo.

I came up in the late 80s. Interviews were _maybe_ 2 hours long. You might be handed a piece of paper with a problem to aggregate some information distributed in a few different arrays and print them out. You know, write some for loops and a few logic statements.

Then you talked about the job. This is the job. Do you want to do it? What do you have to bring to us? Do you have a lot of experience and want to lead, or not a lot and want to learn - we'll adjust position and salary.

And you put a team together. Some were great, some were okay, some needed to be let go. In total, all sw people had a job.

Contrast that with today's voodoo, where proxies are weighed more than on the job performance (the only thing that matters).

In the end, you put a team together. Some are great, some are okay, some need to be let go. In total, all sw people have a job.

It's all exactly the same, except the absurdity of interviewing by proxies. It's simple logic - he average of everything is average. Why have we abandoned logic?

So many things matter more than remembering red-black trees from your midterm (I'm 49. I TA'ed a graduate level algorithms class back in the day, but I don't happen to remember it. That's what books are for). Like being able to run a project. Being able to write documentation. Being able to enter a room with a combative and upset client and keep the business. Being able to mentor your colleagues. Taking ownership. Leading by example. Ability to learn. So many things that are not even discussed in the current interview environment.

I've watched companies spin their wheels for months, rejecting perfectly good people, looking for that mythical person with exactly the right, esoteric combination of skills, who, for some unknown reason, wants to stall their career and get hired into a position where they learn nothing because they are expected to know everything already. People that are eager to learn? No, sorry, not rock-star material. All these prior successes mean nothing, no one could possibly learn a technology or new algorithm, right? And, more than once I've had people get downright snide about it. I'm sorry that you misread my resume, contacted me, and I didn't have that absurdly specific combination of skills. My fault, right?

Y'all have lost your minds. :) Which is okay, we're an eccentric bunch, but jeez, let's inject some reason and introspection into it. The faces are different, but the talent is no different than the 70s and 80s. There's zero evidence that any of these interview techniques are reliable. There's tons of evidence that interview techniques are horribly biased in many ways. Just stop.

<comment><USER3> Has it become more costly to fire bad hires since then? In my mind, a lot of the idiotic behavior in hiring is driven by the fact that it seems to be way more expensive to hire the wrong person than to hire nobody. The risk of litigation from firing someone seems real to a lot of places I've worked.

<comment><USER4> Usually it's fear of confrontation and laziness. If you're not discriminating against people, it's fine.

I've had a few folks that I've had to let go folks, including folks in .gov with union contracts and motivated defenders. It is doable.

End of the day, don't be a wuss. Setting up some hunger games "audition" is passive aggressive bs. If you're nervous, hire a contractor and get them on the payroll later. Or just hire the person, and give them a months severance. Problem solved.

<comment><USER5> That's what my current company did with me. Works really well. Some people are not okay with becoming a contractor first but sometimes that's the way things go.

</comment></comment></comment></comment><comment><USER6> Also: Give the "not-the-best" people a chance to develop.

The CEO of one of my past clients, a consulting company, always said: "You can teach everyone to be a great programmer". And he put his money where his mouth was: He hired people with no programming experience (even with no university education) and personally trained them for _several months_. Also, senior people in the company were encouraged to also help them and guid them.

He had to fire some of those people later, mostly because they were not a good fit for the company. But some of them became great programmers and software consultants.

"Hire only the best" is really only half of the battle. Give people an environment where learning is encouraged and failure is expected. And help them wherever you can. Most will learn and enjoy it.

<comment><USER7> "You can teach everyone to be a great programmer"

Flat out dead wrong. If you hire "anyone" and try to teach them to be a programmer then you will probably fire them.

This is the sort of attitude that leads companies to outsource their development overseas: "Our programmers are people hitting keys. We'll get overseas people to hit keys and overseas people hit keys for less money.", cause, you know, anyone can do it.

Programming is VERY hard and it takes a huge amount of motivation and hard work to become any good at it. Sure you can learn how to do simple stuff without any serious interest, but to be beyond ordinary it takes enormous work and time and research and Joe Schlepp off the street is simply not going to do that.

If you want to hire people and teach them then you need to look for these things: enthusiasm for computers and programming, demonstrated willingness to learn, energy and effort. You should value energy and effort more highly than anything. Those are the raw ingredients for trainees, and people with those ingredients are far from "anyone".

<comment><USER8> You know what the irony is? Us programmers thinking that "everyone can be a great programmer" is our preponderant liberal and very idealistic views showing.

And we keep going around and shout that and other people believe it. And in turn we are being taken advantage of with long hours, unfair compensation for our contributions and the worse of it all? Ageism in our industry is rampant.

I look at physicians, surgeons, accountants, lawyers and others with envy, because in those professions, the older you get, the more esteemed and valuable you are. We peak at 30.

<comment><USER9> Software engineers who "peak at 30" are not taking care of their careers. I'm over 50, haven't worked a full year anywhere in years. I contract or consult, and can usually find a new job lead in hours (or just deal with one of the many sitting in my inbox), and get hired in one (max two) interviews. And it's not because I'm a rocket surgeon. I know _lots_ of software people who are eminently employable in their 50s and 60s.

A critical problem that exaggerates the "ageism" is people who sit in the same corporation for 15-20 years, get laid off because companies change, and haven't refreshed their skills for many years. I saw my spouse go through this last year. She got laid off from the company where she'd worked in a variety of roles for 13 years. Her field toward the end was product management/ownership, and she liked it, but she didn't like Agile - she'd had bad experiences at her employer with careless engineers using "agile" as an excuse to have no process and no oversight. She had also spent many years developing deep domain experience in a narrow specialty (international e-commerce). She could find generic PM jobs easily enough, but they didn't exercise her domain experience and they didn't want to pay her what she'd been making just to be a generic PM. It took her six months to find a new job that uses her domain expertise (educating herself about Agile along the way).

For people less determined and hardworking than her, the problem can easily be much worse. If you've done nothing but Microfocus Cobol for the past 20 years and suddenly have to find a new job because you employer finally ditched that antique piece of crap, and you aren't interested in learning how to do something modern, you're in a world of hurt.

<comment><USER10> You're describing one of two routes people go.

Some people stay in a job for 15-20 years. They are a programmer for maybe 10 of those, but over time they grow into a niche, the company grows, and that becomes a job title.

Maybe they get called a project manager, or a product owner, head of QA or engineering or lead architect. Either way they aren't a programmer any more and they mostly manage something instead of doing - manage people, contracts, processes, customers...

And that's why programming has a pay ceiling - careerist programmers become something else, and footloose programmers become consultants and contractors and leave the regular pay figures.

The value of a good programmer probably becomes diminishing returns after a certain point. The best programmer in the world can't raise the sales of your web app past a point - if they do what it takes to do that they become something else, like a product manager. That point depends on the technical difficulty of the task and the size of the opportunity, but most code needs a good coder, not a great one, and beyond that it's all product fit, sales and luck.

I'm footloose too, and I'm noticing as I get older that the people interviewing me have often been in their job a long time. They bet on the company and became less flexible in the general labor market in return for better opportunities internally.

Honestly, when I work for them, I'm usually surprised how many normal things they don't know. Maybe they've never seen proper unit testing, or don't know what ITIL is, or think linux is still an immature product and you should stay safe with a microsoft stack.

But they know why the code is the way it is. They know what was tried in the past, and how it failed. And their boss has seen what they do in a crisis, which is much better than trusting someone unpredictable.

My suggestion to someone young, if you have the temperament, is to stay for up to a decade and grow into a new, higher value role. Then learn that until you know it well enough to get a job elsewhere and move before you stagnate.

</comment></comment></comment></comment></comment><comment><USER11> Look at the reasons startups failed. "Product didn't work" isn't even on the list. For most appcrap and webcrap, making it work isn't that hard any more.

There are exceptions, where making it work is the hard part. Theranos is poised to fail because they can't make their medical test technology work. Cruise (YC 14) will fail if their autonomous driving doesn't stop crashing. Space-X lives or dies depending on how often their rockets blow up. Those companies need "the best".

Go down the current YC list.[1] Who has a hard problem?

Hard:

\- 20n: A computational synthetic biology company

\- Industrial Microbes: Upgrade natural gas to chemicals using synthetic biology

\- Transcriptic: Access a fully automated cell and molecular biology laboratory, all from the comfort of your web browser

\- Raven Tech: We are building the next generation OS (website sucks; all giant images, no info.)

Not hard to implement:

\- Cleanly: Laundry & dry-cleaning delivered at the tap of a button

\- GiveMeTap: Each bottle purchased gives a person in Africa clean drinking water for 5 years

\- EquipmentShare: Rent high quality equipment at the lowest price, guaranteed

\- Meadow: Buy medical cannabis delivered from local dispensaries

\- Cinder: Notifications when food is done. All in a countertop electric grill.

If you're on the "not hard" list, you're probably better off hiring people who've done something similar but aren't superstars. Otherwise, you'll get overdesigned IT infrastructure, like Soylent. (Soylent does maybe two shopping cart transactions a minute, and boasts about how elaborate their systems are. They're bikeshedding. They're in the food business; IT is a support function.)

[1] [http://yclist.com/](http://yclist.com/)

</comment><comment><USER12> The article is a real gem. One part I particularly like:

>This level of strictness always made me uncomfortable. I'm not going to lie, it starts with my own selfishness. I'm pretty sure I wouldn't get hired at big, famous companies with legendarily difficult technical interview processes because, you know, they only hire the best. I don't think I am one of the best. More like cranky, tenacious, and outspoken, to the point that I wake up most days not even wanting to work with myself.

Jeff Atwood has the self-security to say something like this publicly. It's really small-applause worthy in my book, since people will look for anything, especially anything unrelated to leadership, to tear a leader down[1]

As an aside, I think the political cost to admitting faults ties in roughly with the "Great Man Fallacy"[2] We're looking for an Iron Man to believe in, but when Tony Stark can't actually write a program to hack into a government mainframe in two hours, we get disappointed.

It reminds me very strongly of when Zuckerberg tried, for fun, to solve an engineering problem after two years of being the CEO of Facebook. He had a lot of trouble writing basic code; the engineers watching him struggle, who all thought Zuckerberg was this amazing super-genius who could do anything, ended up condescending him.[3]

[1] I do believe that plenty of so-called "leaders" are not actually good leaders. Rather that those people who grow to learn to be leaders, should not be detracted on certain details that are tangential to their business.

[2] [https://en.wikipedia.org/wiki/Great_Man_theory](https://en.wikipedia.org/wiki/Great_Man_theory)

[3] There should be a specific term for "Gosh darn it, I may not have a billion dollars b-b-but at least I'm better at this thing in this particular way!"

<comment><USER13> That's kind of terrifying. Whenever my work takes me away (or largely away) from writing code for a few months, I worry that if I'm back on the job market... Not only is my code a bit rusty, but my list of JS frameworks has fallen behind too.

</comment></comment><comment><USER14> We used to ask "What makes this candidate weird?" during the decision meeting.

It wasn't always a deal breaker, but it was very important that the team would be different after hiring someone. We hired quite a few non-CS grads, whether they came via a boot camp or were just self taught.

We ended up with a ragged team of misfits and it was awesome. I've never worked on a team that was so effective at challenging assumptions and biases and shipping features faster than anyone else. I'm convinced it wasn't through Herculean efforts by individuals, rather the product of clear communication and trust within the team.

Ive tried to explain why this worked. One observation: Very rarely did someone make implicit assumptions. Such assumptions are often wrong, but they happen because individuals are similar enough that extrapolation a partial understanding into a full one implicitly happens. We assume that since we got from A to B on the same path that the path from B to C is likely the same. On a team of misfits, you have to clearly communicate the entire sequence of events because everyone is on an entirely different page to start with. The result is that the final product is 100% on target, whereas normally there are a few deviations as the result of implicit assumptions.

<comment><USER15> Sounds like your team kind of backed into an insight psychological research has identified and Google has attempted to apply. Something called "psychological safety".

"Psychological safety: Can we take risks on this team without feeling insecure or embarrassed?" \- from re:work

There's a great NYTimes article about it that looks at your hunch about the weirdness of the team members being the key to awesomeness. But Google ultimately realized that it wasn't so much about how different the backgrounds of the team members were, but was instead that that internal diversity could produce psychological safety.

[http://www.nytimes.com/2016/02/28/magazine/what-google- learn...](http://www.nytimes.com/2016/02/28/magazine/what-google-learned-from- its-quest-to-build-the-perfect-team.html?_r=0)

<comment><USER14> An anecdotal effect of said environment. We stopped doing person based scrum. We were able to get away from the "justify my personal usefulness on the team" status updates. And it was awesome.

</comment></comment></comment><comment><USER16> I work in the "boring" old insurance industry, based in the midwest. I love reading articles like these, and as I read them I get excited and say to myself "yea!" and "spot on!". But they seem to center around startups and Silicon Valley.

The truth is, when it comes to building, maintaining, and supporting internal, line of business apps, management isn't even pretending to look for high end talent. They want predictability, reliability, and someone who will "fit".

I wonder how many people out there fit my profile. That is, they get excited by reading blog posts like these from some of the thought leaders, and desperately want to apply the thinking to their own workplaces, but then feel like we aren't really the target audience.

<comment><USER17> Yep, me too, midwest huge insurance company. From what I've seen, there are very few people in mid to upper management that think developers are anything more than a cog in the machine (and only 1 who's ever stated that 'publicly') - I'm looking to leave after 11 years - I've given up on it changing.

<comment><USER18> As stated several times over the years, particularly on HN and by patio11 (edit: or was it Joel on Software? Perhaps both?), work for a profit center not a cost center. The internal software to run insurance companies is a cost center. It is in managements interest to reduce and keep costs down... that's detrimental to what you do. Working on a software product or Saas is a profit center. What you are making is to be sold. It's an asset. An asset management wants to make as valuable and profitable as possible so they are willing to invest in it. That works to your favor if you're developing that asset.

<comment><USER16> In addition to my previous comment, I'd like to hear people's thoughts on the "consulting" gig. It seems to rule here. You know the routine. Consulting shop places an individual at a client site and charges the client $100 an hour, and then turns around and gives the consultant less than half of it. I can see the argument of the consulting firm viewing their people both as profit centers and cost centers.

Why are they even called "consulting" firms? They are really just contracting agencies. And why are they so prevalent in the midwest and the insurance/banking/healthcare segments? Is it so that employers don't have to lay people off? Do they record the costs differently on their books versus full time employees? It just seems so obviously not in the interest of a company to use them with regards to culture, turnover, cost.

<comment><USER19> My last consulting firm accounted their consultant salaries as a cost center, despite our hours worked being directly billed to the client. I left about two weeks after finding out.

<comment><USER20> Does that affect you financially, or did you just think it showed the wrong perspective?

<comment><USER19> It was many. The numbers the company provided to me failed to account for a significant portion of my billed revenue. Presumably the missing money made it to the top level in some way.

I also objected to the idea that someone who _directly generates revenue_ was being labeled a _cost center_. I left, as did my junior consultant, and shortly after the company failed to gain ongoing contracts at the very large financial services corporation they were trying to break in to.

My main problem with that job however, was that they recruited me as a greenfield .NET developer, but then had me analysing some 800 columns over dozens of tables looking for software errors that were causing incorrect results in the 401k accounts for which our client was the steward.

</comment></comment></comment></comment></comment></comment></comment><comment><USER21> This might be an unpopular opinion on HN, but another example of this problem manifests in the sheer volume of companies that require a HackerRank screening test these days. Apart from the clumsy web editor, recording someone under a time constraint means nothing in the larger context of how a programmer's actual work happens. Sigh.

By using such automated tests, companies want to identify top talent by taking a shortcut and not investing any time on their side.

<comment><USER22> People who ask for more complicated code than "reverse a string" or "fizzbuzz" in a remote code screen is doing it wrong.

People who can't code, compile, and run a fizzbuzz in an hour are probably not fit to be hired.

Asking someone to implement a proper Diffie-Hellman over Hackerrank is ludicrous, on the other hand. Interviewers should err on the side of stupidly simple problems. A surprising number of people can't code a loop in the languages on their resumes.

<comment><USER23> >A surprising number of people can't code a loop in the languages on their resumes.

I guess you can reach two conclusions from that:

1) A surprising number of applicants are totally misrepresenting their abilities – either through deceit or wild ignorance.

2) Something about your interview process makes a surprising number of people unable to perform at their normal level – from nervousness, unrealistic and artificial constraints, etc.

Certainly many of those applicants fall into the first bucket, but I'm betting a large portion fall into the second. So, you might reconsider whether the false negatives and highly unpleasant experience for many interviewees are worth the perceived value. Maybe there's a better way to get the same insights.

<comment><USER24> Misrepresenting abilities ... yes, I did that in my first job interview. The job posting said PHP, HTML, MySQL skills. Well, I knew HTML well enough but my PHP and MySQL skills were from a few side projects doing copy-paste-modify with PHP BB's code base to make my own web app, which I never did finish. So I only kinda/sorta knew those languages.

But then at the end of the interview I was given a coding challenge to do at home over the next few days. PHP and MySQL have good online documentation so I was able to knock it out quickly and I got the job. So, yes I misrepresented my skills, but I also knew I could live up to what I was claiming I could do.

<comment> shawn-furyan Yes, it seems that most companies misrepresent their requirements in job postings. It also seems that most candidates misrepresent their skills in responding to those job postings. There's a certain symmetry there.

Employer: First job out of school pay, requires four years of experience in our exact tech stack.

Candidate: Sure I'm willing to take first job out of school pay (BTW, just graduated in May). Yeah, totally have 4 years of experience, and what do you know, it covers exactly your tech stack!

</comment></comment></comment></comment></comment><comment><USER25> This fear of not hiring the very best explains why everyone in the Valley seems to be interviewing candidates like crazy but nobody is hiring. When I interview I try to tease out potential, and look for signals that show the candidate will work hard and learn fast. Then someone comes in and says, "Well I hazed him and he couldn't implement a red-black tree on a whiteboard. No hire." This mad pickiness causes the mythical "shortage of engineers" meme to spread.

<comment><USER26> This might explain the string of interviews I've taken place in where it's typically down to one person that shuts everything down because they want to play stump the chump. You know, instead of looking for qualities in candidates that would bring value to the company.

</comment></comment><comment><USER27> I've said it for many many years...hiring selects for those whom interview well and have good social engineering skills, not _necessarily_ for those whom can get the job done and make the company successful.

The utterly meaningless "top 1%" metric always makes me laugh. By definition then 99 of every 100 engineers don't make that cut, which means, again by definition, your team has very few if any of them, no matter what hiring practices you employ.

Plus I've found that very often management uses the "oh we hired the wrong people" as an easy cover for its own failings.

</comment><comment><USER28> In the spirit of this advice, if you are serious about really finding the best people, you should offer very comprehensive severance packages as part of every offer -- on the order of 6-10 months of salary, possibly even "grossed up" so that it results in at least 6 months of salary after taxes.

Instead of spending money on needlessly complicated hiring processes, with back and forth phone calls, panel Skype interviews, foolish interactive coding exams, multiple on-sites, etc., you can spend that money on severance.

Use a cheaper and more straightforward hiring process. Talk to people, dig into their background and preferred working style a little. If they appear to be competent, then just hire them. If they are not qualified for the job or they are not a cultural fit later, just fire them.

Because you will have explained to them that their first month on the job is still part of the overall fit assessment, and that you value the risk they are taking by offering them severance to re-engage in a job search if it turns out you made a mistake by hiring them, you are not doing a disservice to the new hire. You're merely letting both parties gather more evidence about goodness of fit.

This is money well spent, and for most companies, 6 months of salary is easily affordable for severance. In fact, an unwillingness to offer at least that much to each new hire would be a huge red flag.

<comment><USER29> >Talk to people, dig into their background and preferred working style a little. If they appear to be competent, then just hire them.

If I am very good at this assessment, then this may work. However, if I trust my skills to assess someone accurately, I am unlikely to have a complicated hiring process.

If I am a company owner (or manager!) who is not good at assessing people this way, then wouldn't substituting my process with this proposal make me spend a lot of money twice?

1) Paying salary to more people than open positions (Because I don't spend money on a hiring process and rely on my assessment skills, I may end up with many not-so-best-fits)

2) Severance package to let them go

<comment><USER28> > I will end up with many not-so-best-fits

I am not sure I believe this. First, if you are aware that you're not good at assessing it, then have someone else in your company do the assessment, or hire someone who can (possibly on the advice of your investors or something).

If you can't do either of those, I am afraid your business just isn't going to work out.

So, almost by definition, the person doing the assessment is reasonably good at it. For otherwise, you won't be around very long regardless.

Also, if you find that you're hiring a lot of people who seem good, but ultimately are fired, maybe look in the mirror. Maybe it is that your expectations are unrealistic, or maybe you expect people to adhere to "culture" standards that do not support human flourishing.

Unless the tech problem you need to solve involves lasering in on a fleetingly tiny population of candidates (most don't), then a sequence of looked- competent-but-needed-to-fire people is probably more a reflection on the company than the candidate stream. It's unlikely that all of them were elaborate fakers.

The costs of (1) should be low unless there's a fundamental problem with the company (in which case the costs of (1) are way cheaper than hiring a management consultant to help you not fix it).

(2) is a real cost, and yes, some companies can't afford it (so maybe they scale back to 3 months severance? Maybe they add continued health coverage. Maybe they let you pick a foosball table to keep) ... but it is just the cost of getting useful information about an employee, instead of the not-very- useful info that most hiring processes generate.

</comment></comment></comment><comment><USER30> My team does take-home project, a small problem to solve that should take at most a couple hours. It's the same problem for every candidate so we're judging them on common work. It's not real work, it's made up.

In interviewing discussions in places like HN, there is enough pushback against this idea, which is a bit surprising to me. I thought a few hours work was reasonable when I was interviewing. But my point is that just this small bit of work seems already too big for many people, let alone working 10-20 hours a week moonlighting. It's cool that they pay for it, but that pay is pretty insignificant in the overall scheme of things. (Also, now you're not really interviewing, you're doing client work. Different relationship.)

When I have tried moonlighting in the past I found the stress incommensurate with the additional income. So I don't think I would do it as an interview, personally.

It sucks that companies take a risk during hiring. But I'm not really interested in making that my problem, as a job seeker.

<comment><USER31> You allude to a bigger problem: anyone outside the industry who looks at the hiring process for developers would be put off. I know anecdotally that the industry is struggling to get students interested in software development as a career, and good developers are loathe to leave their jobs. I don't blame either group.

Would I want my kids to spend their careers being put through the wringer of multiple high-stakes interviews or be forced to moonlight in order to get jobs, something that gets progressively harder as people reach their thirties and gain extra responsibilities? No. Rather stay away from the field entirely and look for a more stable career.

<comment><USER30> I don't disagree that we have our problems, but to me most industries seem worse to work in than ours. Not that we should stick up for ourselves but everything is terrible everywhere. Or you just don't get paid very much.

<comment><USER31> I wonder what the lifetime earnings of a new software developer/engineer would be, compared to other careers, especially for those that turn out to be non- rock stars in the medium to long term, which would be most. I suspect that the great earnings initially would plateau and be overtaken by careers where time in the game and cumulative experience are primary drivers of experience.

</comment></comment></comment></comment><comment><USER32> I really agree with the sentiment of audition projects. The interviews I have enjoyed the most all involved some sort of take-home project, although I have never been paid for one. On that note, how expensive does it become for a startup to dole out many interview projects across a wide range of candidates? I think a better strategy would be to conduct preliminary interviews and then based on some granularity, assign projects. One more issue I have with take home projects is that it is not always possible to tell who did the work. When it comes to interviews at startups I doubt that there would be much cheating, but for large companies where candidates are more easily able to slip through the cracks, I image this may present an issue. Can anyone speak to this experience?

<comment><USER33> Here's a problem with audition projects: I would never be able to take part in one, since my current job contract has a clause forbidding me from simultaneously working for any competitor in the same field. (This is a German job contract; I don't know if such clauses are common in the US or elsewhere, too.)

So in order to work on an audition project, I'd have to be unemployed already.

<comment><USER34> Talk with your solicitor. A lot of companies like to include such clauses in contracts even if they're not legally enforceable, particularly in the case of US companies operating in a country with relatively strong workers' rights like Germany.

<comment><USER33> It's a German company, and my previous employer (a German SME) had a similar clause, so it's likely not just them.

</comment></comment></comment></comment><comment><USER35> Jeff mentions some studies of something known as 'Implicit Bias'. One of the leading Implicit Bias research institutions, out of Harvard, makes some of their tests available online. I highly recommend going through a few of them - [https://implicit.harvard.edu/implicit/takeatest.html](https://implicit.harvard.edu/implicit/takeatest.html)

</comment><comment><USER36> Happy to see someone calling out what is happening in our industry, namely: this morbid fear of "hiring the wrong candidate" is making people ... hire the wrong candidate!

A word to the hiring managers out there, look to the future, cast the vision, and onboard people who want to go there with you.

</comment><comment><USER7> The concept of "The Best" is meaningless anyway.

When someone says "We Hire The Best", ask them to quantify _precisely_ what "The Best" means. They can't. They weasel around and avoid answering. And that is because they can't define in a tangible way what "The Best" is. And if you can't define it then how do you know you found it?

Assuming you can define "The Best", an even bigger problem is working out a provable mechanism for measuring - in a quantifiable way - whether someone meets the criteria for being "The Best".

And the final absolute ripper problem is that the more you strive for "The Best", the less likely tou are to find _anyone_ so you'll spend months interviewing and hiring no-one until the boss decides to pull the budget for that position because you didn't hire someone and anyway the commercial opportunity that validated the hire is now evaporated because we couldn't get the code written.

My term for this is "Voodoo Recruiting" in which there are rituals and dances and songs and meetings and processes and tests but it's all just a magic show because in the end the decision is not scientific, it's a magical outcome based just on personal likes and biases. In Voodoo Recruiting a company forms a set of beliefs about its recruiting processes and practices that become sacred and magical - such as "everyone has to do our test, and it actually tells us something meaningful about the candidates and we know how to interpret the results in a meaningful way".

Here's a few posts I wrote on the topic:

I sent one of the best developers I know to a job interview, he was rejected. [http://fourlightyears.blogspot.com.au/2014/12/i-sent-one- of-...](http://fourlightyears.blogspot.com.au/2014/12/i-sent-one-of-best- developers-i-have.html)

Employers don't want great developers, they want what they want. [http://fourlightyears.blogspot.com.au/2014/12/employers- dont...](http://fourlightyears.blogspot.com.au/2014/12/employers-dont-want- great-great.html)

Is your developer recruiting process just stroking your company ego? [http://fourlightyears.blogspot.com.au/2014/12/is-your- poor-d...](http://fourlightyears.blogspot.com.au/2014/12/is-your-poor- developer-recruiting.html)

<comment><USER37> At the risk of being rude, some of it is just foam finger, jingoistic narcissism. Much is swept under the rug of "fit".

And employers want what they _think_ they want. I've been forced to (inadvertently) undermine the Great Developer too many places to think otherwise.

Lest ye think otherwise, I'm not that good. I'm just rigorous but I can switch modes and hack like a shameless... hacker.

</comment></comment><comment><USER38> I worked for companies which "hire the best." My experience was always exactly the same - a group of very talented engineers who couldn't accomplish a damn thing together because egos got in the way.

My current company doesn't hire the best, but instead focuses on people who enjoy making impact in a small team, share the same vision and have a bit of an entrepreneur in them. We don't quiz people or give them tests. We just sit down with them and start talking tech. The results are really amazing and make for a great place to work because everyone feels like the project they work on is their baby.

</comment><comment><USER39> Great post. "Try different approaches. Expand your horizons. Look beyond People Like Us and imagine what the world of programming could look like in 10, 20 or even 50 years – and help us move there by hiring to make it so." We are helping companies to do that at [https://stayintech.com/](https://stayintech.com/). In the future people who build technology should represent the people who use it.

</comment><comment><USER40> I love the first graph on Jeff's article. It shows how versatile the "best"-word can be in such a context: \- If you have the best programmers in the world but they failed to help you identify when/where to pivot, you fail. \- If you have the best programmers in the world but let them run too fast and burn, you fail. \- If you have the best programmers in the world but let their ego/drive ignore customer feedback, you fail. \- ...

There is no definition for "the best" beside a "well balanced human being"...

I have been researching this exact space for the past few months (www.developersjourney.info) and am now more and more convinced that once you reach a technical-threshold, in order to close onto "better-developers", you need to hunt for the 3-C-values: create, care and criticize. A balanced team should be a patchwork of cultures, backgrounds, desires and skills. But I think the drive toward those 3-Cs isn't optional...

Plug: This is very much an ongoing thoughts-process for me. If you have further input for my DevJourney Project and/or want to appear on my podcast on this subject, please contact me!

</comment><comment><USER41> "Only hiring the best" can paradoxically lower the average quality of the candidate you end up hiring, anyways. Suppose there's two ways for someone to pass a strict interview: they're either a good programmer, or they're good at bullshitting you. With a higher bar, you're giving bullshitters more opportunities to bullshit you.

From the perspective of a subordinate doing hiring, raising the bar makes perfect sense. You don't want to get blamed for a risky hire going bad, so you optimize for making your choice defensible rather than good. Non-hiring is also risky - it's just risky in a way that damages the company rather than the person doing the hiring.

</comment><comment><USER42> "We hire only the best"

"What do you pay?"

"Market Rate."

<comment><USER43> Nice! The same conversation in the context of sports, where they really do want the best:

"We hire only the best"

"What do you pay?"

"Between 10 and 30 million USD per year"

<comment><USER44> So...... market rate?

(I know, I know, it was a terrible joke.)

<comment><USER43> Good point :-)

</comment></comment></comment></comment><comment><USER45> Tokenadult isn't around to chime in here, so I'll take his place today. Hunter and Schmit did a meta-study of 70 years of research on hiring criteria. [1]

There are three attributes you need to select for to identify performing employees in intellectual fields.

      - General mental ability (Are they generally smart)

      - Work sample test (NOT HAZING! As close as possible to the actual work they'd be doing).

      - Integrity (The first two won't matter if the candidate is a sociopath).

This alone will get you > 65% hit rate. [1] [http://mavweb.mnsu.edu/howard/Schmidt%20and%20Hunter%201998%...](http://mavweb.mnsu.edu/howard/Schmidt%20and%20Hunter%201998%20Validity%20and%20Utility%20Psychological%20Bulletin.pdf)

</comment><comment><USER46> I really like this post, that most companies require workers to be at a specific location is very strange considering our type of work.

I don't want to work in Sillicon Valley, even if the work is interesting. I live in Scandinavia and for me scandinavian countries are the best to live in the world.

<comment><USER47> It boils down to 2 things: Management is incompetent to tell when work is actually being done, and management doesn't trust their employees. I'm just waiting for the day when requiring on-site commutes is regarded as backwards as it deserves.

<comment><USER46> Exactly, it costs more for the company (office space is expensive, especially in a larger city). I am also waiting for it.

</comment></comment></comment><comment><USER48> A few things have happened in the last few years that make me believe that the meaning of the best is a lot more influenced by our own biases than we will ever be ready to admit. This is a huge issue with hiring:

1\. The study about blind interviews in orchestras mentioned in the article. Think about it, most people in symphonic orchestras have a university education, and often with more years of education than your average engineer, they learned all about critical thinking etc... They are artists, whom are usually considered more open minded (ok debatable). But, they as a group, were able to acknowledge that they have strong biases to the point of trying (and eventually adopting) blind interviews. This, tells me that these people have a strong sense of the fact that they are aware that they biased, and able to admit it, and aware that it might influence their interview process, yet, the experiment showed that they were not able to see passed gender! This has seriously made me rethink about my beliefs about being conscious of my own biases.

2\. I have worked for company A, which hired only the best (besides me I guess ;-) ) pretty much as described in the article, I have recommended people I had worked with previously and whom I knew were amazing, but they didn't get hired. I was seriously surprised, but you know the "it's better not to hire one of the best than err and make one bad hire". Ok.

3\. I then worked for company B. I recommended somebody who was hired at company A. That person was not a friend, but somebody who passed all interviews with flying colours at company A. I worked with that person and they are extremely smart. Everybody at company A was amazed how smart that person was, even after seeing them fly though all the oh-so-though interviews. Working for close to a year with that person, and everybody was still positive about how smart and good that person was, so they aren't just good at interviewing. That person was turned down at company B.

PS: Yeah, maybe I just need to stop recommending people, I now realise I'm the common thread in people not getting hired in my story!

</comment><comment> FLUX-YOU >I think our industry needs to shed this old idea that it's OK, even encouraged to turn away technical candidates for anything less than absolute 100% confidence at every step of the interview process. Because when you do, you are accidentally optimizing for implicit bias.

Now you've got to spend time optimizing your interviewing team. What if one guy just says yes to everything? He might as well not be there but he's still a weight in that decision. What about the opposite where he says No every time? When do you decide he is actually going to say No every time and not worth being part of that decision process?

The more people you put on this decision table, the lower the chances that any one candidate will make it through. But there's an opportunity cost of time/money to that, so you've got another thing to balance.

I think it would be really, really hard for one person to simultaneously impress 10 people beyond a doubt just because of how many people have to reach consensus. And can you imagine the stress of knowing one dude with a nitpicky attitude (that none of the others know about yet) could sink your chances?

</comment><comment><USER49> The missing part of the advice is that you need to hire the best _for your company_. But there isn't an objective definition of 'best.' People can be great at one job and not right for another, great in one company and not right for another. Hiring and job hunting is about fit.

I've worked with people who were A players, hired into a new firm, and quickly spun out. Other people were C players, found a new job, and quickly became A players.

If you're a company who's great at training people, you can hire for energy and eagerness to learn. If you expect people to know everything on day one, hire for experience. The same people who succeed in one of those companies will fail in the other. A big part of hiring is knowing yourself and knowing what makes people successful.

</comment><comment><USER50> To put this in context, "Hire the Best" means: adopt an incredibly risk tolerant nature, initiate an incredibly risky business venture, and then tolerate zero risk in your hiring decisions.

</comment><comment><USER51> tldr:

"The most significant shift we've made is requiring every final candidate to work with us for three to eight weeks on a contract basis. Candidates do real tasks alongside the people they would actually be working with if they had the job. They can work at night or on weekends, so they don't have to leave their current jobs; most spend 10 to 20 hours a week working with Automattic, although that's flexible. (Some people take a week's vacation in order to focus on the tryout, which is another viable option.) The goal is not to have them finish a product or do a set amount of work; it's to allow us to quickly and efficiently assess whether this would be a mutually beneficial relationship."

<comment><USER52> That sounds like it would scale well for the applicant.

<comment><USER51> It works well in my experience, but we have only used it at smaller scale. 2-3 days working together with somebody is already way more telling than stupid interviews, buzzword compliant skillsets and unrealistic tests.

<comment><USER16> How would it work in "your experience" if you were the job seeker and not the interviewer? Taking a week of PTO to interview and then not get the job is a pretty big sunk cost. I guess you can only do one of these a year.

<comment><USER53> If you make weekends and evenings available, it lessens the cost of the job seeker. If you allow for remote work using one of the many online collaboration tools, it lessens the cost for both the job seeker and the employer.

</comment></comment></comment></comment></comment><comment><USER54> My favorite is when you see companies droning on about how they only hire "the best" and their advertised salary ranges are at or below market.

</comment><comment><USER55> There's a very big time cost to hiring just the best. If you're afraid of even one bad hire, then a growing company must be willing to have all their managers and top employees commit 20+% of their time to hiring. Then you ask "Is the 1-2 standard deviation in performance improvement worth it?" If the answer is yes, then it's worth it.

And... Interviews are awful. Seeing how someone work is even better. This is one reason why employee referrals are so important, and audition or temp- projects a good second-best method.

In the end I think it's a Fools Game though - someone who is best in one environment may not be that great for the next. Managing people post-hire is something that can't be avoided.

<comment><USER56> It's not just a time cost. The graph near the top of Jeff's article shows "Ran Out of Cash" as the #2 cause of startup failures, ahead of anything else hiring-related. I say anything _else_ because hiring the best means paying for the best. If you hire nobody else, then salary costs rise. Attrition probably does too, because the best are often among the first to jump elsewhere.

Every startup needs a few of the best. You should definitely seek out and pay for those few. After that, even a startup has jobs that don't require the best. Hire for potential, attitude, chemistry. Hire for special knowledge when you have to (though you should try to avoid it). But don't demand that every hire be among the proven elite.

<comment><USER55> You could argue that the best pay for themselves, and that running out of a cash could come from hiring bad people.

The absolutely best employees I've seen haven't been frequent job hoppers. At most it's every 3-5 years. I'm thinking of an unscientific sample size of 5 or 6 people who have had sustained outstanding technical performance of 10-25 years. Companies don't let people like them go. And they tend to be loyal to the mission if treated fairly.

Now a company with $1mm of seed money that's supposed to last 12-18 months can't afford to hire 5 people like that. There's not enough cash or equity to go around.

</comment></comment></comment><comment><USER57> This is one of those great articles that open up a collection of other articles to look at, whether you agree with the author or not (or somewhat). The links in the body are very informative.

Thanks for sharing.

</comment><comment><USER58> I really enjoyed the article until he got to the audition process. That would shrink the pool of candidates so much that all the previous advice about widening and diversifying the pool becomes irrelevant. Almost no one with significant experience would agree to that. Almost no one with a family would do it either. And let's face it, it's a buyer's market, not just for "the best", but even for the "just OK".

</comment><comment><USER59> > What I like about audition projects: > It's real, practical work. > They get > paid. (Ask yourself who gets "paid" for a series of intensive interviews > that lasts multiple days? Certainly not the candidate.) > It's healthy to > structure your work so that small projects like this can be taken on by > outsiders. If you can't onboard a potential hire, you probably can't onboard > a new hire very well either. > Interviews, no matter how much effort you put > into them, are so hit and miss that the only way to figure out if someone is > really going to work in a given position is to actually work with them.

I'm finally sitting down to read Peopleware, and from what I can tell, this is what they recommended back in 99 or 87 or whatever. Alongside portfolios of work. I need to find a 2013 edition, to see if they mention GitHub portfolios at all.

</comment><comment><USER60> The description of "Audition Project" as presented is questionably ethical, almost certainly violates almost everybody's pre-existing employment agreement, and puts Automattic and the contractor in a very compromised legal position in many states over the IP that the employee of the primary company is creating while on a spurious contract with Automattic.

It seems like a colossally bad idea almost all-around. I mean, would Automattic tolerate an employee working contract gigs for a potential future employer if Automattic were to be made aware that's what the employee was doing?

Weird.

</comment><comment><USER61> When every company hires only "the best" (top 1%), what are the rest of us (99%) suppose to do?

<comment><USER62> When they say top 1% they generally mean the top 1% of applications. A very large portion of the applications you get for an opening are sent by those who need to send out hundreds of applications to get a job.

</comment></comment><comment><USER63> You hire the best? How come your offer package for a full stack developer is 100,000-115,000?

</comment><comment><USER64> In regards to the paid trial period method. My experience is mixed, on one hand you get a real insight into how someone works and approaches their tasks but you lose that crucial emotional distance, so to say... you go soft on them.

</comment><comment><USER65> A rehash of [http://www.joelonsoftware.com/articles/HighNotes.html](http://www.joelonsoftware.com/articles/HighNotes.html)

Haven't heard so much from Joel these days - sad :(

</comment><comment><USER66> > Using screens to hide the identity of auditioning musicians increased > women's probability of advancing from preliminary orchestra auditions by > fifty percent.

I thought that the increase was largely attributed to _more_ women being willing to audition anonymously?

> if that describes you, and you have serious Linux, Ruby, and JavaScript > chops, perhaps you should email me

I don't know why, but I always thought the Atwood was 100% invested in Microsoft technologies. Not that it matters, it just surprised me.

Speaking of Atwood, has anybody ever used one of his keyboards? Any opinions?

<comment><USER67> Why would professional musicians be unwilling to audition in a non-anonymous situation? That sounds quite dubious to me.

<comment><USER66> I had to Google for it and I don't have the story right.

Claudia Goldin was one of the authors of this study: [https://www.aeaweb.org/articles.php?doi=10.1257/aer.90.4.715](https://www.aeaweb.org/articles.php?doi=10.1257/aer.90.4.715)

She was able to attribute 25% of the increase in hiring of women by orchestras was due to the blind auditions. She also found that there was an explosion of auditions when orchestras adopted the blind format.

So it had an effect, just not as large as I thought.

<comment><USER68> That's weird. From what I've seen of women in classical orchestras, if I were the one in charge of auditioning and hiring musicians (not blind), I'd probably be hiring mostly women....

Honestly, if you're a straight guy, why _wouldn 't_ you want pretty young women working with you?

<comment><USER67> I'm not sure hiring women with the aim of sexually harassing them is really what we're all talking about.

<comment><USER68> Hey, I'm just pointing out that this common trope about men discriminating against women for jobs doesn't really make that much sense, unless all the men in charge of hiring are gay (which obviously isn't the case or the claim).

Seriously, what kind of straight man only wants to be around men all day long, and then (assuming he's married) come home every day to the same woman, and never get to socialize with any other women? Maybe a religious fundamentalist, but not any normal man.

<comment><USER67> Well, there are a few responses:

1\. Why should women be judged on attractiveness? Men are not generally judged on this standard to join orchestras or do office work. It also, perversely, punishes women for being experienced while men benefit from it, handicapping their lifetime earning power. Professional women probably do not want to spend their lives judged as eye candy.

2\. Because of the first point you will still end up with a strong male bias on top of whatever natural one training creates; after all, we're looking at men of any age versus young women, for the most part, in this scenario.

3\. The numbers clearly do not bear out the assertion you're making in the first place, since blind auditions significantly increase the likelihood of women being hired after auditioning. It seems your "self-evident" reasoning does not fit the facts.

4\. I do not think it is true that all men want to spend more time socializing with women. I don't see how the logic you're positing works unless sexual harassment is just outright permitted. If you're not convinced that sexual harassment is bad then I guess you're operating on a different plane than most of us.

<comment><USER68> Thanks for the response, but I really don't understand where you're getting the idea that I'm advocating sexual harassment at all.

I'll go backwards: 4\. So you think that most men would prefer to not have any women around them most of the time, and only want to socialize with other men? I don't know if that's true or not, but it certainly isn't the case with me. I don't really want to work in a monastery-like atmosphere devoid of females (attractive or not).

3\. Maybe, but that's what I'm asking about: why would straight men only want to be around other men? Seriously, I really don't understand this at all. Are most men repressed gays or something? I actually like being in mixed environments, even if I'm not attracted to most or even any of the women. Am I weird that way?

1-2. You seem to be claiming that men aren't also judged on attractiveness, and this seems wrong. I'm quite sure a lot of studies have shown that men are indeed judged on attractiveness, though the standard is somewhat different than for men (it doesn't disfavor older men as much). Just go find a short guy (or worse, a short fat guy) and ask him how his life is going and if he perceives any discrimination.

Anyway, my point all along has not been that only young pretty women should be hired, as you seem to think, my point was that I don't understand why men would discriminate against women in hiring, because to do so would mean you're surrounding yourself with a bunch of dudes, and as I said above, I don't know about other men, but I for one do not enjoy "sausagefests"; I like mixed environments.

<comment><USER67> I've heard enough men vocalize such thoughts to think that a fair number of them do.

The reason I get the idea that you're advocating sexual harassment is that you keep casting this in sexual terms -- why would you want to be surrounded by men, unless you're gay? Work is not a sexual environment (let's ignore the exceptions for this conversation); why is sexual orientation relevant? Saying "hey, aren't you heterosexual? Then why don't you hire women?" manages to promote a progressive cause with regressive reasoning.

I will concede that men, too, are judged by appearance, but I think that the standard is far more lenient and, as you said, tolerant of age.

In any event, the auditions are meant to judge skill. The conclusion I reach from the success of blind auditions is that evaluators perceive playing as less skillful when they know it is done by a woman.

<comment><USER68> >The reason I get the idea that you're advocating sexual harassment is that you keep casting this in sexual terms -- why would you want to be surrounded by men, unless you're gay? Work is not a sexual environment (let's ignore the exceptions for this conversation); why is sexual orientation relevant?

So you think that if I'm not actively looking for sex from women, that I should be perfectly happy to live a life completely devoid of any kind of female contact whatsoever?

That seems extremely disturbing to me.

Does that also mean that if I'm not actively looking to have a sex partner of a different race/ethnicity, then I should be perfectly happy to never have any kind of contact with people from other ethnic groups?

Wow, I guess on HN I'm just a real weirdo because I don't want to be surrounded by white males and be completely cut off from contact with other kinds of people.

<comment><USER67> No. I'm suggesting that arguing that you don't want to be surrounded exclusively by white males _because_ "hey, I'm not gay" (implicitly, because you want to have sex with these people, or at least would not object to doing so) is somewhere between off-putting and troglodytic.

<comment><USER68> I think you're projecting, or have serious mental issues, to come up with a conclusion like that from what I wrote.

<comment><USER67> "From what I've seen of women in classical orchestras, if I were the one in charge of auditioning and hiring musicians (not blind), I'd probably be hiring mostly women.... Honestly, if you're a straight guy, why wouldn't you want pretty young women working with you?"

This is what you wrote. So, no, I think you're just trying to walk away from the implications of what you wrote because you are embarrassed. How do you propose interpreting that without any sexual bent?

<comment><USER68> You're taking one line I wrote and applying it to everything. I've made a bunch of other statements in this conversation about how I prefer mixed groups, not only of sex but of ethnicity too. One nice side-effect of a mixed group is there might be some dateable people in there, but it's not a given, and it's nice to have a mixed group (IMO) for many other reasons than just sex or seeing pretty faces, but I don't see how it's wrong to want to work in a mixed environment and have that possibility if you're single.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER69> The hidden, but most impactful message in this article is "be a remote first company".

The best programmers are Internet savvy, therefore able to effectively collaborate across time zones.

</comment><comment><USER70> There is always someone better than YOU, even if you hire the best (and you can't), so stop bullshitting wannabe slaves and learn to respect real people. Signed: the best.

</comment><comment><USER71> > Linux, Ruby, and JavaScript chops

One of these things is not like the others.

</comment><comment><USER72> In this world of open source software and super fast servers , hiring is over hyped especially for apps & enterprise solutions. The best enterprise/web app coder is not necessarily the best analytical thinker or apolitical individual. Indeed, there are some domains where you will need specialists.

Any one who is hard worker (can learn etc) and has open mind to discussing design pros and cons is a good hire for 80% of software.

</comment><comment><USER73> A great company is not something that contains great people, it is something that makes people great!

</comment><comment><USER74> > The most significant shift we've made is requiring every final candidate to > work with us for three to eight weeks on a contract basis

I guess that's another, more polite, way of saying that 'we require that you don't need any kind of work permit sponsorship'.

</comment><comment><USER67> Steve Yegge's old essay was arguably better. [http://steve- yegge.blogspot.com/2008/06/done-and-gets-things...](http://steve- yegge.blogspot.com/2008/06/done-and-gets-things-smart.html)

</comment><comment><USER75> Encouraging hiring discretion and audition projects creates a situation where a massive amount of people who don't want to work on a project for a few weeks only to find out they aren't a 100% good match will never apply to your company.

</comment><comment><USER76> Just because everyone is trying to hire the best doesn't make the advice wrong. It just means that some will be able to execute it, and some will not.

A successful sports team should hire the best, even if that's what everyone else is trying to do too.

<comment><USER77> > A successful sports team should hire the best, even if that's what everyone > else is trying to do too.

Yes, but sports teams recognize "the best" is dependent on the other pieces in the organization. Teams that try to stack their rosters with "the best" in objective measure typically crash and burn. Teams that recognize "the best" is whomever fits the team's scheme and current players the best succeed. Too many software companies want the first sense instead of the second.

</comment></comment><comment><USER78> Getting a job is an accident you get involved in (most of the times) knowingly. The interview is the collision (or the contact event) The job represents how well you survive after you come home after treatment. There is no best... only better.

</comment><comment><USER37> If we didn't sort people, we would get better results. Of course we are all different. But the madness of status makes us all crazy.

</comment><comment><USER79> There is no "the best". There are only people. Some people work wonderfully at one shop, but horribly at another. This can have nothing to do with their skill or even their personality. Each working environment is unique as is each candidate. You simply cannot tell which will work perfectly until long after someone is properly hired.

So why bother interviewing? The goal is not "we only hire the best". Hiring is only half the battle and a short term goal at most. The long term goal should be "we only retain the best". Sometimes that means firing people, but more often it means going to the mat to keep the people who work best: Treating people like human beings and, most importantly, paying them. Pay well and the good people will not leave. Actually fire those who don't work out in the long term and even they will do nearly anything to stay.

Or do what most startups do. Pay next to nothing. Treat everyone like widgets in a great machine. Fire only those whose admit having a life outside of work. And hire only those who share similar opinions on ultimate frisbee because culture!

<comment><USER80> > Or do what most startups do. Pay next to nothing. Treat everyone like > widgets in a great machine. Fire only those whose admit having a life > outside of work. And hire only those who share similar opinions on ultimate > frisbee because culture!

What happened that makes you this bitter?

<comment><USER81> I would suggest that he observed reality.

</comment></comment></comment><comment><USER82> > The most significant shift we've made is requiring every final candidate to > work with us for three to eight weeks on a contract basis.

Are you fucking kidding me? What am I going to tell my current employer while I "audition" for the mere possibility of a next job?

Most working adults in the US don't even get three to eight weeks of discretionary vacation that they aren't already using to spend time with family or, you know, recharge after working the salt mines for meager scraps.

This is the wrong approach for anyone except - maybe - very junior candidates. Fresh out of college, zero responsibility, wide open prospects. Those people could actually use 3-8 weeks of paid auditioning. Those of us who have families simply can not afford to do this.

<comment><USER83> So its basically extended interview for like 8 weeks where your every move is being watched/judged.

When did it become ok to treat people like shit and humiliate them with these ridiculous "interviews". Seems like we keep coming up one worse idea after another.

Shame on everyone who thinks its ok to humiliate people with your idiotic algorithm/whiteboard/big O interviews.

This is getting so out of hand. Can we bring some humility and kindness to tech interviews.

<comment><USER84> Am I the only person who thinks algorithmic/big O puzzles are kind of fun? Like they're super high stress when you're interviewing, but basically everything is super high stress when you're interviewing.

<comment><USER85> > Am I the only person who thinks algorithmic/big O puzzles are kind of fun?

They are fun. So company ends with a lot of people who can implement red-black trees and so on, especially under high stress. That could be good in some case. I can't see it that good in general.

"So customer reports server keeps restarting every Thursday, can you take a look?"

"I am not sure how to do it, but I can invert a binary tree in under 10 minutes though, would you like to see that?"

<comment><USER83> >am not sure how to do it, but I can invert a binary tree in under 10 minutes though

Most ppl completely forget how to invert a binary tree in about 1 week after the interview. Which makes the whole interview process based on that stuff even more absurd.

</comment></comment></comment></comment></comment><comment><USER86> > I think there is a real issue around diversity in technology (and most other > places in life). I tend to think of it as the PLU problem. Folk (including > MVPs) tend to connect best with folks most like them ("People Like Us"). In > this case, male MVPs pick other men to become MVPs. It's just human nature.

This theory makes intuitive sense, but some evidence contradicts it. Several studies have found that men and women discriminate against women equally, or even that women are harder on other women than men are:

* Steinpreis, Anders, and Ritzke (1999) [http://www.cos.gatech.edu/facultyres/Diversity_Studies/Stein...](http://www.cos.gatech.edu/facultyres/Diversity_Studies/Steinpreis_Impact%20of%20gender%20on%20review.pdf) ; Moss-Racusin et al. (2012) [http://www.pnas.org/content/109/41/16474.full](http://www.pnas.org/content/109/41/16474.full) ; and Reuben, Sapienza, and Zingales (2014) [http://www.pnas.org/content/111/12/4403.abstract](http://www.pnas.org/content/111/12/4403.abstract) found that men and women were equally biased against hypothetical academic job candidates in a study based on reviewing resumes with male or female names.

* Nosek, Banaji, and Greenwald (2002) [http://projectimplicit.net/nosek/papers/harvesting.GroupDyna...](http://projectimplicit.net/nosek/papers/harvesting.GroupDynamics.pdf) found that in implicit association tests, women show slightly stronger implicit biases towards traditional gender roles in the "Gender-science" and "Gender-career" tests.

* Of course, there's Terrell et al. (2016) [https://peerj.com/preprints/1733/](https://peerj.com/preprints/1733/) (the GitHub gender bias study that was discussed on Hacker News the other day) in which the authors found that women are harder on other women than they are on men but decided not to mention this in the paper [https://peerj.com/questions/2002-do-you-have-data-on-the-gen...](https://peerj.com/questions/2002-do-you-have-data-on-the-gender-of-the-users-that/) .

On the other hand, I also found some studies that concluded that men have stronger gender biases than women:

* Bowles, Babcock, and Lai (2005) [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=779506](http://papers.ssrn.com/sol3/papers.cfm?abstract_id=779506) found that male managers penalize women who attempt to negotiate salary more than female managers do.

* Uhlmann and Cohen (2005) [http://www.socialjudgments.com/docs/Uhlmann%20and%20Cohen%20...](http://www.socialjudgments.com/docs/Uhlmann%20and%20Cohen%202005.pdf) found that men exhibited a stronger gender bias than women did in rating hypothetical applicants for a job as a police chief.

This is just what I dug up in an hour of searching; I'd be interested in finding more research on this. Does anyone know of a review paper on this subject?

</comment><comment><USER87> Amen.

</comment><comment><USER88> >Those of us who have families simply can not afford to do this.

Then don't take the job? Your life choices (Children, wife, loan payments) aren't the fault or social responsibility of your prospective employer.

Why get so uppity about a job you aren't even going to apply for?

<comment><USER81> Children are a life choice? You're part of the problem.

<comment><USER83> >Children are a life choice? You're part of the problem.

Are they not though? Aren't you consciously choosing engage in this optional activity when you decide to have kids.

<comment><USER81> And there we go again. 'optional activity'. And people wonder why there are few women in tech and the situation is not improving. The post above is your answer.

Have a family, it's the end of your career, because you engaged in productivity limiting 'optional activities'. Yes, the tech sector IS that toxic.

<comment><USER88> This is a case of "cake and eat it too" -

If you have a family it's more important than your career. If you don't feel your family is more important, you may abandon it or never have one to begin with. Just because you have a different stack of priorities than another doesn't mean you can blame them for ranking theirs differently than yours.

Analogy is; you wouldn't protest at the Buddhist temple door because you feel that your time availably is less to become a full fledge Buddhist monk because you have a family.

It has nothing to do with women in tech, try and keep on topic please.</comment></comment></comment></comment></comment>


Heatwave hits Iraq as temperature jumps to 50 degrees Celsius - <AUTHOR> http://www.xinhuanet.com/english/2019-07/25/c_138257854.htm <comment><USER2> For those more used to Fahrenheit, that's 122 F. Wow.

</comment><comment><USER3> "Iraq regularly witnesses scorching summer season with temperature sometimes exceeding 50 degrees Celsius, prompting the government to announce general holiday over stifling heat." - apparently quite common.</comment>


Want major TV coverage for your startup? Hint: seize opportunities - <AUTHOR> http://blog.fairsoftware.net/2009/12/07/want-major-tv-coverage-successful-entrepreneurs-seize-opportunities/

<comment><AUTHOR> I know it sounds like simple advice, but you never know where chance will take you. So take the path offered.</comment>


Unoptimize V8 for Easy Debugging - <AUTHOR> http://kolodny.github.io/blog/blog/2014/05/19/unoptimize-devtools-for-easy-debugging/

<comment><USER2> Good tip -- it's also a good reason why you should never use eval() or Function() inside your application code. You should always try to capture a global eval instead:

[http://perfectionkills.com/global-eval-what-are-the- options/](http://perfectionkills.com/global-eval-what-are-the-options/)</comment>


Why git is so fast (or why Java is not as fast as C) - <AUTHOR> http://marc.info/?l=git&m=124111702609723&w=2 <comment><USER2> I find it interesting to read that every single one of his criticisms of JGit would not need to apply to a C# implementation. Unsigned types, unmanaged memory allocation (Marshal.Alloc __), unsafe code with pointers, native P/Invoke access, value types (e.g. fixed arrays for his SHA-1 point), and an IDisposable convention for managing all the unmanaged trickery, C# has pretty much all the needed features.

When optimizing C# for space use in particular (which ends up being a time optimization for I/O heavy loads), I've leaned heavily on arrays of structs, and even bit-packed arrays (e.g. an Int32 array storing 14-bit integers, packed so that they don't align on index boundaries).

Programming at the level of C in C# loses most of the benefits, of course, but at least you can hide the optimizations behind pretty APIs, and write the non- critical parts in terms of an easier to work with lower layer.

<comment><USER3> I actually believe they're accessible in Java as well through JNI and JNA. But I'm hardly a Java expert.

<comment><USER2> Not at the same level of abstraction, IMO. To take a representative example, pointer arithmetic simply isn't really available to you from Java, unless you pretend your integers are pointers and go through JNI functions for indirection, etc., which is going to be slow enough to defeat the purpose.

</comment></comment></comment><comment><USER4> Good article, but it seems to ignore the elephant in the room: the JVM's cold start times.

For me, git's use case is being called from the command line, often interactively, between code editing sessions. It needs to start fast and finish fast, to not interrupt my workflow.

The JVM's cold start times are huge. On the order of a second. Noticeably slow. So slow, that in the common case of committing a few files, the JVM startup time would totally dwarf the time spent actually doing work.

<comment><USER5> JGit isn't meant to be a replacement for git on the command-line. It's meant to be used inside IDEs and web servers that 1) are already running on a JVM, 2) need to interact with git, and 3) don't want to pay JNI costs. JVM start-up times are a non-issue for these use cases.

<comment><USER6> Is the cost of JNI really that high? I'm curious--I haven't used it myself, but a client of mine is using it in a very latency-sensitive Java applet that uses JNI to call libavcodec to decode a video stream and then immediately display it through Java's own native libraries, so I would think the cost isn't _that_ high.

<comment><USER7> The real cost of JNI is when you hotspot crash and take out the entire JVM instance (say your servlet and all your Tomcat instance as well)

I don't like anything calling out to JNI unless it's the only sane way and it's been heavily tested.

</comment></comment></comment></comment><comment><USER6> This has always been true and will continue to be true.

It's possible to build a high level language that's as fast as C? Sure--but only if you restrict the programmer to the same amount of _effort_ in both languages. If your application is one where it's worthwhile applying a great deal of extra programmer time in order to improve performance, a low level language will _always win_ because it exposes more of the native machine.

The goal of a high-performance high-level language should be to provide C-like performance _for a reasonably unoptimized application_. Once one starts to optimize a program down to the last instruction, staying on par with a low level language becomes simply impossible for a high level language.

In my experience, every level of abstraction one creates away from the machine limits your performance by some amount. This can be demonstrated without even leaving assembly language!

Fastest possible: raw assembly code in a NASM-like assembler. With this, you can write basically any code possible with no limitations, at the cost of extremely high programmer time costs.

Shortcut: Use inline assembler instead of NASM to simplify calling convention and other niceties.

Cost: There's now a whole bunch of stuff, like calling convention optimization and computed jumps, which you can no longer do.

Shortcut: Use compiler intrinsics instead of raw assembly.

Cost: You can no longer tweak your algorithm to minimize register spills because you aren't directly controlling spills anymore.

Shortcut: Use a set of macros (like my project does) for handling calling convention, MMX/SSE abstraction, and other such simplifications.

Cost: You tend to overlook optimizations that apply to one possible output of the abstraction and not others, resulting in either messes of ifdefs or suboptimal code--the former of which is of course violating the abstraction.

Shortcut: Use a framework like liboil to write SIMD assembly instead of native code.

Cost: By using generic SIMD operators, you lose access to specialized architecture-specific operations, along with the aforementioned issue of register spills.

Here we _haven't even gotten beyond assembler_ and we're already losing performance. Now scale this up to C and beyond: abstraction inherently comes at a performance cost. It isn't even merely a function of language: abstractions within a language reduce performance as well.

<comment><USER8> Couldn't agree more. One thing to remember though: "Premature optimization is the root of all evil." C Git is optimized and fast. Mercurial, with a combination of Python and C, is almost as fast. Maybe not quite as fast, but fast enough for me. A lot of the time those optimizations just don't pay off in terms of programmer time.

<comment><USER6> Slightly tangential, but I think "Premature optimization is the root of all evil." is the most misquoted statement in the history of computer science. Most importantly, people tend to misinterpret "premature" to mean "any time before the software is done" or similar.

I can't even count the number of times where I've worked on or watched a project where performance is important and the following series of events occurs:

1\. Module is designed with that quote in mind: it must be simple to implement and performance is unimportant. Note that this isn't a prototype: this is a plan for the actual final product.

2\. Module is built and finished, then submitted for a review. The reviewers, knowing the importance of performance for this module, point out a number of ways that the module is extremely suboptimal.

3\. Because of the assumptions so heavily ingrained into the module, implementing these performance improvements--which could have been foreseen as necessary far earlier--requires a near-complete rewrite of a large part of the module.

It's exactly as if we finished our software and our customer decided that his requirements were actually totally different--except in this situation, it's entirely our fault, because performance _was_ a requirement and we ignored it because we didn't want to optimize "prematurely". If you want performance, you have to design with performance in mind; if you don't, and then decide later you want performance, the cost of your earlier decision is magnified a hundredfold.

I have almost never seen that quote used correctly.

<comment><USER9> I always though that what that one quote _meant_ was: measure, then optimize. It's no use tuning the hell out of a function that hardly features in your profiler results.

<comment><USER10> Agreed, though it would be clearer if the quote went, " _Uninformed_ optimization..." or "Doing optimization _without measuring first_...".

</comment></comment></comment></comment></comment><comment><USER11> From the last line:

"But, JGit performs reasonably well; well enough that we use internally at Google as a git server."

Rings the 'good enough' bell to me.

<comment><USER12> Agree. If your bottleneck is your source control tool, you're doing something wrong.

<comment><USER13> _Anything_ that is part of the programming routine should be severely optimized.

Every little bit not only adds up, it often _multiplies_ in big enough projects.

In one of our big products, we have several build steps that touch upon the source control systems. 10 second VCS delay X 6 build steps, 1 second lazily written c++-header slowdown X 300 files, etc. and before you know it something that _should_ take 10-15 minutes for a clean build now takes ~1 hour. True story. :(

Luckily, enough of us got so annoyed about this that it got fixed after a few weeks of dedicated effort. We now have a constant conscious effort to keep build times down.

<comment><USER14> Thank you for reminding me about compilation time.

Now I won't be tempted to go back from scripting language country for a few more years... :-)

Edit: I should add that I have very fond memories about my youth and C, too.

<comment><USER15> Most sane projects I've experienced do "builds" even with scripting languages. It's every bit as much of an annoyance to have a bunch of needlessly slow tests as it is to deal with slow compile times.

<comment><USER14> OK, a point; the pain with compiling languages is the compile cycle where you edit-and-run just local tests, not for the whole system.

</comment></comment></comment></comment></comment></comment><comment><USER3> In strictly language terms, C will always be faster than Java. However, I would dispute that one could say on a general basis that C programs will always be faster than Java programs.

In fact, I would argue that _all things being equal_ , the Java program is more likely to be faster (and yes, I realize there are a metric ton of potential caveats to what I just said). Why? Because Java allows you to focus on the "big picture" optimizations that really make all the difference.

On the other hand, given an infinite amount of development time and experienced developers, the C program will likely be much faster. In some cases this is necessary. But for most cases, I personally would rather just _ship_ something than try to squeeze every ounce of efficiency out of it.

</comment><comment><USER16> Of the three issues mentioned in the post Java's lack of value types is the important one in my view. That's what causes Java programs to use hugely more memory than C, C++, C# or Go programs. Using more memory translates into an orders of magnitude drop in performance for memory intensive applications.

<comment><USER17> Not only memory, but there's also a performance penalty related to boxing/unboxing of primitives. That's why the author of that email described how he hasn't used the standard data-structures from Java, like HashMap ... preferring to write his own specialized implementation.

</comment></comment><comment><USER18> They use the word "high-level languages" and then use Java as the example. This is going to lead to some very wrong conclusions; the problems listed in the article are problems with Java, not problems with high-level languages.

I imagine a Git-in-Haskell would be very close in performance to the C git. (Then why is Darcs so slow? Because it uses an icky imperative, mutable model, whereas git uses a immutable functional model.)

</comment><comment><USER19> While I'd never claim Java is comparable to C, I'd like to note that the C codebase has, by their admission, 4 years of work in it. I'd be surprised if the JGit codebase isn't much faster in 3/4 years.

<comment><USER17> The Git codebase has been heavily-optimized from the start. Its speed when branching/merging was its main selling point, ever since Linus started talking about it.

The only way JGit would ever be equal-to or faster than Git is by using better algorithms. And somehow, I don't see this happening ;)

<comment><USER19> Nobody's claiming equal-to or faster - currently JGit is twice as slow so there's a lot of room for improvement. Faster than now, not faster than C.

<comment><USER20> The linked article actually shows quite a few non-trivial optimizations already being done in JGit (e.g. storing an SHA-1 in 5 ints to avoid the extra heap block). I'd be surprised if they got much farther than they are, honestly.

</comment></comment></comment></comment><comment><USER21> One thing I have been wondering as a non-git user: is git really CPU-bound in most operations? Maybe someone who is a regular git user can answer me this question. If it's not, I wouldn't expect Java to matter too much to its performance.

</comment><comment><USER22> Im not wholly convinced that version control is an area where microsecond speed advantages matter. Rather versatility, portability and compatibility :)

</comment><comment><USER12> >> "why Java is not as fast as C"

Not actually true in reality. Modern JVMs can make on the fly optimizations based on the runtime profile, which would need to be done by hand in C.

As said elsewhere though, Java excels when used for long running tasks - servers - backends etc where it can optimize for the long term. It doesn't excel when you try and start up the jvm loads of times for quick individual jobs.

I don't understand why people are optimizing source control :/ fast vs fast meh I don't think it's an issue really.

<comment><USER23> You're bringing theory to a shootout based on facts. Hypothesizing that Java might be faster with a strong enough headwind doesn't make the actual, factual JGit run faster or C-git run slower.

I mention this because programmers seem prone to this, and letting theory trump fact is a great way to make sure that you never learn anything.

<comment><USER12> I was countering the headline, which wasn't correct. Java isn't slower than C in general. It may be in specific cases, for specific programmers, etc but that's not what the headline stated.

The title takes one specific application in a particular niche, used in a certain way which a particular programmer can't get to run fast enough, and concludes that Java isn't fast enough. Faulty logic.

The argument about JGit vs C-git for me isn't something I feel you can learn anything from.

<comment><USER24> > Java isn't slower than C in general.

Really? In general? That statements seams worse than the original headline. Is Java faster than C for _anything_?

<comment><USER12> It completely depends. Both are silly generalizations.

Yes Java can be faster than C in some situations.

Can C ever be faster than assembly? Well, in theory no. But in practice, sometimes.

Depends if you're a master assembly programmer who hand optimizes everything.

<comment><USER25> "Yes Java can be faster than C in some situations."

Unless the person writing the C implementation is grossly incompetent, I would like to see even one example for that.

<comment><USER12> You can't see a situation where the JVM can optimize things, inline code, etc at runtime and beat a general C implementation? :/

<comment><USER25> I would say that any C programmer worth his salt (unlike me) knows how to profile the code under a meaningful workload and how to optimize it to be faster.

I remember I used the shortest possible integers and the register keyword in the late 80's far too many times to count.

The point of somewhat higher-level languages like Java (I refuse to say Java is a high-level language - it would be one in the late 80s, but not today) is not to make programs run faster, but to make it easier to make them run correctly.</comment></comment></comment></comment></comment></comment></comment></comment>