pifflesnort

I admit that I don't understand your analogy. There isn't a bug in the call for papers -- it's fair. There isn't a bug in the review of papers -- the selections model the actual distribution of the larger population.

So where is the problem, exactly?

> Well spotted. The point is that the status quo is a choice, just as being more inclusive is a choice. Which is the better choice?

Better technical content is the better choice for a technical conference.

> 1. That including people from a more diverse background will lead to inferior talks.

No, judging content on the basis of anything other than direct merit will lead to inferior papers and talks.

> Something more than "We didn't get lots of women applicants for talks, so we have 100% white males."

What do you want them to do exactly? They put out a call for papers, they get the papers they get. Of the roughly 200 accepted speakers (authors of papers) presented at Usenix, about 5% were female.

Usenix is well known. It's not new. The call for papers goes out every year. Research arms of corporations and universities send their employees.

So what, in your book, does Usenix do so wrong?

https://www.usenix.org/conference/atc12/tech-schedule/usenix...

> That's not the case for open-source tech conferences. Open source has a preference for social change at its fundamental level - "anyone can edit". This at least leans towards promoting an egalitarian environment.

Open-source is not simply egalitarian. PostgreSQL (for example) doesn't try to apply egalitarian ideals to patch acceptance. Bad code is bad code, no matter who wrote it.

In the ideal, open-source is meritocratic, which also happens to be the ideal criteria applied to selecting conference papers.

> Also, half of the value of tech conferences is networking, not lectures, which is about 'meeting people' rather than 'imparting knowledge' ...

Why do you think these are different things? Some of the best collaborations I've had have resulted from meeting the smart people presenting at conferences, and sharing knowledge.

If conferences break the signal-to-noise ratio by attempting to fill quotas rather than selecting noteworthy papers, then the smart people will stop attending; the social value AND the associated knowledge sharing will be diminished.

> Well I don't exist to facilitate your preferred status quo.

You are not a technical conference. You are a person.

At a technical conference, focused on technical content: if you sacrifice the quality of that technical content for quotas, then you've produced objectively worse conference.

> That's the context of the article - some speakers are exercising their right not to participate on panels or give talks unless the conference makes more than a lip service effort to include people who aren't 30 year old white males.

What would qualify as "more than a lip service effort", exactly?

> If there isn't anyone from your particular group at a highly demanding conference panel, or visible in your industry, you're much less likely to become a part of it... even though you're more than capable of performing at that level if you put the time in.

Technical conferences don't exist to engender your preferred social change, they exist to impart knowledge to attendees, all of whom paid considerable sums to be there.

> I used the phrase "only test what needs to be tested" intentionally. How should I know what you need to test? But if you accept that you should only test what needs to be tested, then there is an implication that some (I'd venture to say most) of what you write doesn't need to be tested. And that's a liberating concept. You aren't obligated to test everything, but you should test what really matters.

In -my- anecdotal experience, this is the excuse developers use while they write bug-ridden code without tests. Maybe they save a little time at the early stage of the development cycle, but the real reason seems to be avoiding work they don't find to be as fun as hacking out code.

After that code is hacked out, we then waste a bunch of cycles across multiple teams while we find and fix out the most obvious of their bugs.

After the release goes out, we spend even more time finding previously undiscovered bugs and fixing them -- which hits actual user satisfaction.

All because some lazy sod thought he was too smart to need tests, and that he could be trusted to decide when his code didn't require them.

Fuck that. I've been doing this too long and seen this happen too many times. If you're on my team, you write the damn tests.

> It's not some kind of man-hating reverse discrimination, it's an attempt to correct very real and very pervasive institutional inequalities.

Your position also assumes that the parties performing evaluations have existing gender biases -- itself a form of stereotyping, discrimination, and bias.

Evaluating papers anonymously solves the problem you claim, while avoiding any issues with quotas or "man-hating reverse discrimination".

I can't comprehend why you're arguing that these complex "upstream" cultural issues should force me to evaluate conference papers on any other grounds other than their technical merit -- something that would be the to the detriment of speakers, attendees, our industry, and my own sense of ethics and fairness to others.

> When "their qualifications" results in a selection rate of men approaching 100%, I think that's prima facie case that one of the most important qualifications is being a man.

Why is this a prima facie case proof of sexist qualification requirements? What evidence do you actually have?

At the 2012 American Academy of Nursing Conference, the expert panels were roughly 100% female. Is this prima facie evidence that one of the most important qualifications was being a woman?

[1] http://www.aannet.org/assets/docs/ConferenceMaterials/2012/c...

> Furthermore, (% of industry that is women) x (% of women interested in presenting at a conference) is exactly what I was referring to when I talked about "outsourcing" the discrimination - the filter was set upstream.

I fail to see the issue here. Conferences have to work with the pool of speakers that they have.

> But when you suggest that no work is accomplished in any meeting, you're wrong.

This is where we disagree. Talking about work isn't tangible work. Talking unblocks work, to a point.

> I'm sorry you've had such a bad experience with meetings; it must be common or the stereotype wouldn't exist.

Given that my experience spans roughly 15 years, major corporations, small and large startups, in both management (director, VP, and C-level roles) and engineering (software, systems) I'm inclined to trust my experience that meetings are generally a work-substitution mechanism and a means of furthering political/social career advancement, and bad PMs (which is, sadly, most of them) are the worst offenders of them all.

> The function being used to evaluate speakers is broken - that much is clear from the rate of women being selected.

What numbers do you have to demonstrate that the function is broken? What percentage of our industry is made up of women, and what percentage of them are interested in presenting at a conference?

> This has an obvious correction: put a counterweight on it in the form of a quota. Does this fix the illness? No. It is a pill, medicine to manage the symptoms of the illness while the illness is fought. The malady is diffused, the remedy is not, so it is easy to pick on the remedy - but it's better than doing nothing.

Why do you believe that enforcing the selection of speakers on a basis other than their qualifications is better than doing nothing?

> The point that you're missing is that just because some meetings add no value doesn't mean that no meetings add value.

The fact that some meetings add value doesn't mean all or even most meetings add value.

My analogy holds; page fault handlers add value. They also incur a heavy cost and you want to avoid faulting if it at all possible.

> Why is it that the coding part is considered "work" and the meetings is considered "not-work"?

In kernel terms, meetings and PMs are the scheduler, and you are the threads/processes being scheduled.

Is the scheduler doing work? Yes. Is that work simply overhead required to keep the pipeline full and fair scheduling of work occuring? Yes.

> Let's try this: meetings are stopping implementing to communicate or from another perspective coding is postponing meetings until new issues/questions have been solved

Or to put this another way, meetings are a page fault interrupt that is taken because the necessary backing store (the solution to issues/questions) is not available.

They're almost pure cost. Spending any more time there than you absolutely need to is a waste.

> When I was working for a large internet company, we got a lot of work done in meetings and lots of PM's were respected.

How did you get work done in meetings? By definition, meetings are stopping work to communicate; the most work-efficient approach is to optimize away the need for meetings as much as possible.

> Response latency makes scripting language unacceptable for some types of problems. But in my experience very few latency problems I've come across are down to language choice vs. badly written database queries, lack of caching etc.

5 ms you save in your runtime -- for free, without any work on your part -- is 5 ms longer you can now afford to spend waiting on the database.

> But there are also plenty of situations where in-memory queues are also not acceptable, and the moment you hit disk, the entire performance profile shifts so dramatically that you suddenly often have much more flexibility.

I can only disagree here. I view CPU cycles and memory as a bank account. If you waste them on an inefficient runtime, you can't spend them elsewhere, and there are always places where they can be spent.

Excluding huge sections of the problem domain -- such as "decoding/encoding framed packet data" -- is a cop-out. There's no valid reason for it, unless you're going to go so far as to claim that Ruby/Python et al increase developer efficiency over other language's baselines so dramatically that it outweighs the gross inefficiency of the languages.

These are all aesthetic complaints, not UX complaints. The UX is standard.

Now, I actually happen to agree that it's not the prettiest app. But it is a very usable app, in ways that a web browser music player is not.

I also get the impression that you're just being willfully contrary and not particularly genuine.

> It's ugly. It doesn't look nice in the slightest. It doesn't scream to me "Boy, this looks like an awesome user experience. I better try it out!"

Why is it ugly? What, specifically is wrong with the UX?

You seem to be saying that the AOT path requires constrained typing and a strict subset of the language semantics, which agrees with the parent's point that static type semantics matter in terms of performance.

> But it didn't touch the important question -- is the development time for Go faster than for scripting languages with critical sections in C?

"Writing critical sections in C" is a terrible cop-out of the Python community, by which they try to make the engineer do the compiler/VM's job.

Compare:

1) Write algorithmically efficient code.

2) Profile for hotspots.

3) Lift out the hotspots by rewriting them in C.

4) Repeat throughout the lifetime of your project.

Versus:

1) Write algorithmically efficient code.

2) There's no step two.

What winds up happening is that A) nobody does steps 1-4 with any regularity, and B) The bar at which a C rewrite is set very high, while Python is very slow across the board. The whole system winds up slow in aggregate, with only a few hotspots optimized, if any.

> You totally miss the point. There are large classes of systems where CPU time in your app is not a significant factor. E.g. my go-to example of this is the first Ruby project I deployed in a production environment:

This is only true if you ignore response latency as a comparative metric entirely.

> But of of that 10%, 90% was spent in kernel space. So even if switching to C (or whatever) were to speed up the user-space part of the code 90%, it would only cut CPU time spent from 10% to 9.1%.

I'm really curious what you were doing in Ruby that spent 90% of your runtime in the kernel. Having implemented similar middleware, I found that nearly all my runtime was spent just performing basic decoding/encoding of framed packet data, and as a kernel developer, I'm having a hard time imagining what an in memory queue broker could have been doing to incur that overhead

> Time of "Getting that shit done" and cost of long-term maintenance are two of the main reasons why people use Ruby/Python, not for the raw performance.

Plenty of other languages "get shit done".

> And anyway, from my experience, Python has never been the cause of the slowness.

Then you're not actually performing performance analysis. Python is S-L-O-W.

I've written large systems in Python. I've profiled them to find the hotspots. I've micro-benchmarked them against implementations in other languages (C, Java). Python lost. Always. By a lot.

So then I had to rewrite critical sections of the Python in C (or accept that we'd need 32 servers instead of 2). Eventually I stopped bothering, and used a different language, because the aggregate cost of a thousand small performance issues (and a few big ones) is actually quite high.

> I like how you're talking about good user experiences and then use that as an example.

What's your point?

> Furthermore, that wouldn't as easily transfer to Windows since taskbar notification icons are routinely hidden.

Mac OS X isn't Windows. Part of writing native applications is working with established platform conventions and user expectations, not trying to rubber stamp the same thing everywhere.

> Perhaps a better way to look at it is this- when I have a great job doing web development and see job listings all over the place for other rewarding web roles, where is my incentive to do desktop development- even if it's close to the (much more booming) mobile app space? The web is in no danger of dying or getting less popular any time too soon.

Because it would provide a better product for your users, which is the whole point.

It also shouldn't be hard to do. A senior engineer that can't easily jump on new technology stacks is not a senior engineer.

> But that isn't why I'm running it. I have a web browser open every minute I'm using my computer, so it's already there. The browser is a multitasking application itself, so using it for music streaming fits in great. I haven't used the Spotify web player, but Rdio has been web-based from the start, and has been great.

An arbitrarily resizable browser window/tab that looks like every other browser window on my desktop, which can't share state between multiple windows, and can't interact with my desktop in any meaningful way, doesn't use native components, goes wonky if I reload, and goes away if I have to restart my browser.

That doesn't make sense. This makes sense: http://www.pandabarapp.com/

> Speaking as a web developer, I can tell you that I am perfectly able to transition to making desktop apps, I just have no incentive to. There are fewer and fewer desktop apps out there, so it's not a great use of my time to learn those skills.

Funny that you speak of it as a dead market, when A) The skill cross-over between desktop and mobile is direct, B) There's a huge amount of unfulfilled demand for mobile developers, and C) There's an enormously underserved desktop market (see also: Spotify, Netflix, HBO Go).

> Back to the Spotify player, the web client makes far more sense than a desktop one to me. All the music is stored in the cloud, so why do I have to download a desktop client on every machine I use to access it? It seems horribly backward to me.

Running a full fledged browser, with the resulting poor application UX, for a lightweight task as music streaming, seems horribly backwards to me.

All I want when music is streaming is a miniplayer, not a web browser. It should work with the play/pause/skip buttons on my keyboard/headphones, support airplay streaming, be able to integrate with my music library, and otherwise fit in nicely to my desktop/mobile experience.

If I worked for Spotify, Hulu, Netflix, or HBO (Go) (which I wouldn't, because they're myopically web-focused), I'd be beating the war drums to provide better, more engaging user experiences via native applications for not just mobile, but desktop too.

Unfortunately, it winds up being a catch 22. They build technological monocultures (web-focused), can't hire for alternative platforms, contract out the mobile development, and then the web developers use their political positioning to try to turn everything into a bad shell around a web rendering view. The users lose.

> They were getting rid of native rendering and replacing it with rendering a webpage. No wonder people were so pissed and no wonder so much functionality was dropped.

I can confirm this, and have heard that this was politically driven by their web-focused engineering management and teams.

Netflix did the same thing, for the same reasons. People built up web fiefdoms and had the political clout to put their job security ahead of user experience.

> ... but when compared to the big disadvantage of having to maintain two codebases ...

It's about your users, not your developers. Of course it costs more to provide a better product, which was the original reasoning behind providing native desktop applications.

What they're doing now has more to do with politics and skillsets amongst traditionally web-focused engineering management and teams, than it does with actually creating a great product. Spotify has a ridiculously hard time hiring outside their management's core competency of web-focused development, including both for mobile and desktop. That has more to do with their management than the job market, though.

As an aside, I can't say I understand why web developers find it so impossible to migrate to mobile/desktop. Time and time again we work with organizations who have built a large server-side web-focused team and somehow simply cannot manage to support the mobile/desktop. What kinds of engineers are they hiring that they can't learn a new platform?

This is a silly false dichotomy. We've built our own business, profitably, from the start, by paying prevailing wages to top-tier talent who are located where we are.

It benefits our community and our country, but it also means that we're getting the best possible talent, locally, without the overhead of managing and communicating with remote non-native speakers.

The author simply wanted higher margins, and achieved them by externalizing costs onto their community. That's not to say that such a thing can't be successful; look at WalMart.

However, it's fallacious to state that they couldn't have built their business otherwise.

Lastly, it was this line that really got my goat:

> At the time of launch, I wasn’t even making that much, so I could I justify paying someone more than I was making myself as a business owner? It was a hard pill to swallow.

You, the business owner, have all the upside. That's how you justify it.

It only looks like a lot when you're not zoomed in. The density here is very, very, very high. The vast majority of buildings aren't covered.

We started using Paychex when we had a total of two founders, making almost nothing, five years ago.

It was painless -- and cheap. On top of that, Paychex has had our back with hands-on personal customer service when things went wrong due to the usual paperwork screwups by NY State.

I'm truthfully not sure what Paychex could do better. This isn't an area where -- as a tech company -- we want things to be particularly technologically complex. A real person makes all the difference to us, and its not like Paychex is a significant cost for what they do, reliably.

Truthfully, I don't know why you'd badmouth them as "legacy solutions" that "don't really work". They've worked great for us, especially as we've expanded to offices in multiple cities and states, with all the attendant per-locale paperwork overhead.

> Heck Verizon FiOS offers fiber to the home in NYC and has speeds of 300Mbit/s

Where? The entire time I've lived in NYC, in neighborhoods with population density between 30k to 70k people per square mile, I've never, ever, ever had FIOS available to me.

Sure, I've heard about the rare building that has it, but as far as I can tell, it's marketing with just enough actual deployment that we can't call it vaporware.