HN user

raganwald

45,002 karma

http://braythwayt.com

http://github.com/raganwald

http://twitter.com/raganwald

Posts632
Comments4,259
View on HN
www.washingtonpost.com 12y ago

Dropbox’s hiring practices explain its disappointing lack of female employees

raganwald
19pts13
braythwayt.com 12y ago

Sturgeon's Passionate Revelation

raganwald
14pts8
braythwayt.com 12y ago

If I can do it, you can do it

raganwald
25pts15
raganwald.com 12y ago

Prototypes Are Not Classes

raganwald
64pts43
braythwayt.com 12y ago

Was Alan Kay wrong? And why does that matter?

raganwald
31pts30
braythwayt.com 12y ago

Communication? Check

raganwald
28pts7
braythwayt.com 12y ago

Herd Thither, Me Hither (revised)

raganwald
35pts12
braythwayt.com 12y ago

JavaScript Allongé is free

raganwald
199pts51
blogs.scientificamerican.com 12y ago

How a tiny wasp may save your life

raganwald
2pts0
www.globalnerdy.com 13y ago

Mobile is Eating the World

raganwald
1pts0
www.washingtonpost.com 13y ago

NSA growth fueled by need to target terrorists

raganwald
3pts3
raganwald.com 13y ago

Infinite HashLife in Canvas and JavaScript

raganwald
1pts0
www.asktog.com 13y ago

Jef Raskin on "Intuitive Interfaces" [1994]

raganwald
2pts1
raganwald.com 13y ago

Inelegance

raganwald
1pts0
braythwayt.com 13y ago

Calling All Hackers

raganwald
92pts43
blog.fogus.me 13y ago

Announcing underscore-contrib

raganwald
12pts0
raganwald.com 13y ago

Another Look at Sequence in JavaScript

raganwald
3pts0
raganwald.com 13y ago

Did you ever take that test yourself?

raganwald
6pts1
www.joeydevilla.com 13y ago

How to Mine Bitcoins for Fun and (Probably Very Little) Profit

raganwald
6pts0
adam-lynch.github.io 13y ago

Ked, the first scripting language from Cork

raganwald
3pts0
raganwald.com 13y ago

Explicit vs. Clever

raganwald
196pts97
braythwayt.com 13y ago

Quote Meritocracy Unquote

raganwald
164pts124
raganwald.com 13y ago

Trampolines in JavaScript

raganwald
13pts0
raganwald.com 13y ago

Counting Crows

raganwald
2pts0
alisdair.mcdiarmid.org 13y ago

It is our responsibility to teach

raganwald
2pts0
raganwald.com 13y ago

A Surreal Encounter With a Winged Elephant

raganwald
20pts4
raganwald.com 13y ago

What's the difference between Currying and Partial Application?

raganwald
6pts0
vooza.com 13y ago

Vooza says no to remote workers and non-handcuffed workers

raganwald
4pts1
raganwald.com 13y ago

Hilbert's Grand JavaScript School

raganwald
2pts0
raganwald.com 13y ago

Twenty Thirteen

raganwald
67pts23

Paul Graham wrote an essay called "Things You Can't Say." He should update it so I'll know what things I can't say on Hacker News, like "Let's discuss this idea like reasonable people without, heaping shame on people who have ideas we disagree with."

I took this entirely as a conversation between developer and "stakeholder," be that client, employer, whomever, but not the end-user.

I've built many such forms, and all of them have included traditional forms of address. I may build another with traditional forms of address, but I certainly have no problem discussing the subject without laughing the idea off.

You may disagree, but it's not ridiculous. It's perfectly reasonable. In fact, by calling it ridiculous, you're sending a very strong signal that people who ask questions about whether we should keep doing this the way they've always been done will be shamed.

Is that your intention?

So does this mean you don't write any software that doesn't save lives? That you don't come onto Hacker News and make comments?

For whatever reason you find yourself doing a task. Gardening, washing dishes, building a web form, saving a life. Whatever it is you choose to do, why not do it as well as you know how? Why denigrate something as not being worth doing well because there are more important problems in the world?

Your entire comment seems to be based on the premise that either companies have a strong insider/outsider culture or they are soulless places to work. When in reality, there are many, many companies that have strong company cultures without somehow alienating a large number of otherwise qualified prospective employees.

Speaking as a person with a fair chunk of experience managing software development, I find it difficult to believe that management's only choices are frat-boy culture or soul-sucking bland corporation.

I'll speak very frankly. When a company has a half dozen or a dozen employees, when a company is scrambling for traction, it can be a great motivator to have a strong insider culture. Steve Jobs hung a pirate flag up at the Macintosh offices for a reason.

But companies grow, and part of growing is, well, growing. You need to select from a larger pool of prospective employees. You need to bring in some new DNA instead of doubling up on the DNA you already have.

I can't speak to this specific company, but as a general principle, successful companies become less exclusive and possible--I am not speaking about Dropbox--less discriminatory as they grow.

If you want an example, look at Apple. It's hyper-successful, and famous for how hard they work at inclusiveness and tolerance.

Of course, correlation does not equal causation. If there is something about their "culture" that is off-putting to women, you can't "fix" it by changing the hiring practices. You fix the culture and the hiring practices follow suit organically.

I suspect that the title is wrong, and that the thesis of the article is that there is something strongly biased about Dropbox's culture and the experiences recounted about interviewing there are one symptom of many.

I'm speaking to what I read in the article, of course. I'm not a woman and I don't work at Dropbox.

I do not speak for GitHub, but anonymous sources inform me that the feature only works with prose formats that have a built-in renderer. So basically, if you can preview the file, you can get a rendered diff for it.

This seems to confirm your suggestion :-)

I don't know if this is true for CoffeeScript, but sometimes an unfamiliar syntax enables something new and very useful. You won't experience that unless you embrace something very different.

eS6 will have fat arrows, but comparing CS today to JS today, I find the -> and => constructs are more than just an abbreviation, they make it radically easier to write AND READ code that makes heavy use of functions.

YMMV, of course!

Even if he happened to be right about his contention, this isn't the point at all. The question here is, "Should a programming service be offered in a language other than English?" Whereas ESR is claiming, "Programmers should learn to write English proficiently."

Imagine, if you will, that Silicon Valley is THE place to live if you want to be a programmer. Alice has job advice: "Move to Silicon Valley."

Now imagine that Bob wishes to open a hackerspace code+cafe in New York. Should we really tell him that this is a bad idea? Is it somehow a terrible idea to help programmers who chose to ignore Alice's advice to be productive? Is it somehow undermining TheGrandPlan™ to support a programmer in New York City?

Are we "fragmenting the hacker community" by opening a cafe in NYC?

I can't think of any good reasons not to make Stack Overflow available in Portuguese. And any or every other language. An argument to keep SO English-only might as well be accompanied by an argument that there should be no conference talks in any language except English, no programming books in any language except English, and no help or online documentation in any language except English.

They are mistaking the indicator for the thing indicated.

This is one of the most important (and neglected) insights in business. People often optimize for the indicator at the expense of the thing it is supposed to indicate.

Example: One metric is of customer dissatisfaction is unsubscribes. If you make your unsubscribe process difficult, unsubscribes go down. In reality, dissatisfaction might be climbing through the roof, and a difficult unsubscribe process may actually make it worse, not better.

That being said, there is a difference between: "If you don't care, go work somewhere else so that the only employees left here are the ones that care," and, "Do it even if you don't care or else I'll fire you."

The former might be about getting rid of unmotivated dead wood. Some people are good no matter what, leave them alone. Some are terrible for your company no matter what, fire them or entice them to quit. The remainder are the ones to manage.

But then again... You don't want to fire or push out the people who might be able to tell you that the dogs hate the dogfood because it tastes like shit. Which was the punchline of the joke that the entire "eat your own dog food" expression is based on.

I agree, let's flip this around and think like customers. We go out to choose a vendor for some important service.

Vendors A and B have roughly equal parity on features and services, but vendor A's employees eat their own dogfood and vendor B's don't.

Now in one sense, who cares? Eating your own dogfood is a means to an end, not the end itself, so it's like finding out that McDonalds employees don't eat McDonalds food. As long as they wash their hands, who cares what they eat themselves?

But on the other hand, I'm a human being, and I'm personally a lot more comfortable doing business with a company that seems to care about its product from top to bottom, and isn't staffed with people who don't like their own product enough to use it.

I also don't think being in over your head or having architectural issues is a crime - it's the default state for startups, especially ones trying to keep up with big growth.

While this statement is usually true, let's not generalize. There are some kinds of business or services where you are doing a disservice to the world by being in over your head.

Example: If you decide to "disrupt" home construction and sidestep the various annoying and taxing construction regulations. You simply must not go around selling houses to people unless you are actually very, very confident that you are not building a dangerous product.

Same thing for making food that people eat, pacemakers, radiation devices, and taking people's money to safeguard. It's not a crime to make mistakes that nobody with reasonable experience could foresee, but it is absolutely wrong to make avoidable mistakes that hurt your customers due to industry inexperience.

A lot of the dynamics you're describing here on Hacker News also apply to Hacker News. It's the same problem: Surface quality content and don't allow the items on the front page to choke out new submissions just because they're on the front page attracting all the votes.

Donate or don't donate, that's your call. But why are you complaining about him asking for a donation? Why try to "shame" him? What is he doing to harm you?

Mastering "engineering" in a language and maximizing your interview "performance" are loosely coupled at best.

Also, leave the affiliate links in. Those who care to remove them know how to change the affiliate code to benefit their favourite charity.

Exaggerated in one way, possibly under-reporting in another. What if athlete sexual activity follows a power law? A very small number of athletes might have hundreds of hookups during the games while most may have zero or one.

Exactly. But it doesn't degeneralize to "Everything is so different that rules of thumb are not useful guidelines," but rather that within a particular "genre" or "world," there are sensible defaults that don't work in other genres or worlds.

Am I missing something?

Yes. If you went to high school, you may recall a certain type of person: They'd pick someone else, anyone else, and make fun of them for no reason other than to elevate themselves as an arbiter of taste.

"Ewww, reg is wearing a bow tie. What a fashion disaster!"

The original word for that is "verisimilitude." I may be alone in this, but I consider "truthiness" to be something that you want to be true even though it's obviously not true.

From where I'm sitting, Mayor Rob Ford being the victim of a "lefty elitist conspiracy" has zero verisimilitude but plenty of truthiness amongst his supporters.

Mind you, the observation that "90% of the companies advertising for passionate programmers are crud" is uninformative about the nature of passion does not mean that Avdi's article was uninformative. It's highly useful to be reminded that such companies are nothing special, and that working 80+ hour weeks is nothing special. 90% of all that is crud, and that's ok.

And speaking personally, it's very important to be reminded that being passionate about programming isn't anything special, it's a personal choice. I don't believe that in and of itself it makes me necessarily worse than if I was "moderately enthusiastic," but it doesn't make me any better.

    "hello"
Not an object.
    new String("hello")
Object.

Along the way, autoboxing will convert a string to an object delegating to String.prototype if you write something like "hello".foobar(). But primitive value strings are not objects.

It is correct to say that typeof(null) returns the string 'object' because of a bug that is now written into the standard to prevent old software from "breaking" if they fixed this.

It is not ever correct to say that null in JavaScript is an object. Just ask javaScript itself:

    Object.getPrototypeOf(null)
      //=> TypeError: Object.getPrototypeOf called on non-object

Paul Graham once said, "Where there's muck, there's brass." He explained that there is often an opportunity to be had if you dive deep down into ugly, unpleasant things and find a way to make them work.

Thank you, although please note that "JavaScript Spessore" is (a) a work-in-progress, and (b) about "Thinking in objects" more than "The idiomatic way to program in JavaScript.

An operating system whose main goal is not performance is forever going to be a toy of professors.

Be careful! That statement was once true of programming languages.

Over time, larger and larger numbers of people relaxed their expectations for performance in exchange for benefits like greater safety. Simultaneously, implementors invested in optimizing the performance of languages previously considered "slow."

Operating systems may well wind up with the same dynamic.

Is it copying all process data? Or copying a reference to the process data and then performing copy-on-write when a process makes changes locally?