grueful

Are we reading the same articles?

The Python 3 support page is full of "this should work in theory, it's very under-tested, almost nobody is using it, don't blame us if you try it anyway and get rooted."

They did everything to warn you short of installing giant neon signs saying "radioactive, don't use in production."

Make up a number. Double it ASAP. Then double it again.

Then move to daily billing, or project-based billing if you have a lot of high-similarity work with relatively time-definite scoping. Either way, not hourly.

For a developer, floor should be like $50 if you are REALLY new, and totally lack confidence to pitch any other way. Then with the doubling after you have some success to bolster your confidence.

Typical rates for iOS are north of $100, often well north (think multiples). Really, really north if you use project-based billing and leverage a domain specialization.

Books are typically quite a bit out of date if it's a rapidly progressing field.

More stuff ends up in journal articles, but about a year or so behind the actual work, and at a level of detail which is often problematic to reproduce. You typically have to treat it as a reverse engineering problem - but once you know the core ideas, that's often possible.

Then there's the mountain of "trade secrets" which never get published anywhere. A lot of compelling work in e.g. graphics falls under this case - although you might see a demo and overview at SIGGRAPH.

Publishing tends to be a net positive for serious commercial research work, even if the release has to be delayed. It's a solid process for documenting internal knowledge. It's also one of the main things that's going to interest other researchers in working for you.

Or find people who know they're doing something inefficiently, but need it done badly enough that they're doing it anyway.

Ridiculously common case.

New pricing strategy: the low-end tier is metered.

That's also a big argument in favor of formulating seat-based pricing models as blocks as opposed to per seat. It reduces the update frequency.

Failed according to you, me, and the prevailing majority of the medical community isn't equivalent to failed in the minds of the overwhelming majority of the public. The segment which believes or doesn't strongly disbelieve things like homeopathy is manifestly non-negligible.

Anti-vax nuts wouldn't be the public health threat that they are if there were two of them in a pool of hundreds of millions. The segment acting on these beliefs is manifestly large enough to enable outbreaks of diseases we otherwise could suppress almost totally.

I'm all for that. The key problem is defining it. There exist historical examples of quackery which wasn't, e.g. hand washing.

Stricter rules about null hypothesis testing would be a start, but the bigger problem is one of education. We're still plagued by government that gives the nod to creationism and horrifically distorted sex ed in public schools.

I'd like to say we've become empirical enough about what practices we place belief in that we could just treat all cases of quackery as malicious fraud - but the very prevalence of such issues tends to support the opposite conclusion.

I did this once, decided it was a dumb idea, then quoted the next guy triple. It was a good learning experience, if nothing else.

The current market is drastically tilted towards the engineering talent, provided that you actually negotiate. If companies want freebies in spite of this - walk. It's a target-rich environment.

I think one of the major turning points in the future will be to trigger a "space race" which makes a grand project of developing substantive improvements to medical care and quality of life.

There have been significant improvements here motivated by e.g. battlefield medicine, and great results out of academic or humanitarian labs, but much of our current work is stuck in a loop between patents and the FDA approval process. Good intentions aside, the system acts to motivate certain patterns of action in order to stay profitable and continue growing year-to-year which aren't optimal for our long-range interests.

How one would go about motivating such a grand project - I have no idea. Perhaps it's a matter of continuing to make such small improvements as we can until the system is primed for one giant leap. The road of progress was never a well-paved or straight one except in hindsight.

I think that small teams and open sharing of knowledge are both key ingredients. The amount of resources currently in play in medicine is staggering, but social systems tend to lose efficiency very quickly as they scale. Perhaps startup culture will be a key piece in making this happen, but the timescales involved in speculative medical research tend to be beyond the scope of the typical VC-backed endeavor.

It's also way the heck easier to get emails, provided that you give them some motivation to sign on. It's inherently a private, low-risk transaction (provided that your signaling is consistent).

As to domain expertise, "well-known value-producing field" x "very specific customers whose needs you deeply understand" is both sufficient and awesomely effective.

"Actual customers" is about as overloaded as "talking."

You need people you can connect with, provide value to, extract value from - and you have to make all that into a reproducible and reasonably predictable process given all of the constraints in play.

If you can do that, you're often well down the path towards a viable business. If not ...

It's also functional, in the "tell me three times" sense. Effective teaching tends to involve lots of repetition.

Yeah, you can't just take the responses at face value.

Watching five subjects in a row get to one point and then get confused is important, but they might never mention it if you just ask them directly afterwards.

I've also observed talk between users that started out "oh, I hated it" - then they'll go on to praise the functional aspects - and it turns out they just didn't like the color scheme. Which is equally valid if it generates consistent responses.

My experience is limited to sisters, but they played with the normal legos just as much as I did. I suspect these would have been a hit.

Users care about things like color far more than engineers often suspect. If changing the color makes a substantive improvement to outcomes you care about - change the color.

My knee-jerk response to that: Do they make pink girly legos? Maybe there are reasons why that's the wrong approach, but I tend to regard interaction and packaging as two very distinct design components. If the packaging is the problem, fix that first.

Changing the interaction should come second. Dumbing it down is almost never the solution, yet it's often the first solution people turn to when trying to deal with a gender gap. It's as if they think the issues will go away if they speak very slowly and loudly.

(I admire the objective, but I believe I would like the project better if it said "an engineering toy" instead of "the engineering toy." The implication differs.)

  I already had a leg up because I had most of my product put together. I just needed to figure out how to market it.

  And the first thing I learned was that my product was dead, would remain dead, and was a waste of further time and effort. I fundamentally had begun in the wrong place and needed to first find what people wanted.

You could put a million MBAs in a room for a million years and they'd never come up with any strategy more effective than talking to actual customers first.

Most consumers neither understand nor care about the spec sheet. Reasons that make sense to an engineer are alien to most of the market.

They typical consumer asks for more gigahertz either as a status symbol or because something is slowing down their existing machine to the point that routine interactions are painful.

But does Google actually provide support for GCS?

I'm perfectly happy paying $0.005/GB more if it means I can actually contact someone when things break.

"Statistical significance is irrelevant when you’re doing customer research."

There is a time and a place for carefully-written Likert surveys with control questions and large samples. Psychological research, election polling.

Customer research is about learning the realities of someone else's world. What you're aiming for is more a structured conversation than a statistical survey. Are you both speaking the same language, are you overlooking any major cultural or procedural factors, what emotional responses occur repeatedly and what triggers them?

You know all those jobs claiming you can earn up to $big_number a week?

That's their all-time record. The odds of real numbers resembling it are low.

They're often on the tail of years of anxiety and depression, plus environmental stressors which aren't going to disappear through talking or medication.

Sometimes you take a pill and the problem is solved. But often, it's a matter of a struggle for better, not fixed. Or a decision between the illness and the side effects of continuous medication.

But ignoring it is a terrible option.

Screenshots

https://dl.dropbox.com/u/2111778/HN-Front-Page-Reader1.jpg

https://dl.dropbox.com/u/2111778/HN-Front-Page-Reader2.jpg

App store

https://play.google.com/store/apps/details?id=vladocar.hn

Both screenshots only show the list styling. They should tell me a story about the interaction experience.

All I want for Photos-Are-Broken Christmas is a plugin to take a Dropbox folder and display a nicely formatted gallery on a Wordpress blog.

It also wouldn't hurt if Dropbox would stop trying to wrap image links in a gallery page. Anyway, here's a picture of a robot's shadow on Mars.

https://photos-3.dropbox.com/thumb/AADVCsDpEacRaKHkyoPhQUU86...

Uploading was trivial. Sharing was a bit harder because they made it harder.

Anyone want to make and sell that Wordpress plugin? It would make sharing trivial for a broad audience with a habit of paying for useful plugins.

Between your post and the site, the ONLY thing I know about it is that it's related to project management. I could maybe give more useful feedback if you gave more detail.

In general, if something is almost done - finish it. If nothing else, it gives you something to show off.

This is tangent to the idea of a "truck number" - the number of people who can be hit by a truck before your org is endangered.

Orgs with a low truck number really shouldn't be offering significantly below-market compensation to critical staff in high-demand professions.

I disagree with some of the meta-cognition.

Take the "seems like a bad idea" bit. Many of the big hits are really well-worn ideas done with better marketing, better timing, and a user experience which makes it available to new markets.

Dropbox? File sharing. Facebook? Geocities. Both are interesting in that they take something that was a giant pain in the neck but useful enough to put up with anyway, and then they make it usable enough that virtually anyone can do that stuff routinely.

But the meta-cognition isn't all that important. What's important is that they're getting out there and helping new companies learn and grow. They can be wrong all day (or not) about the why because they've developed a process which provably works, and which they can measure and improve upon.

This is quite good, and it briefly hits a couple of the more obvious ways in which naively applying an FFT will lie to you (superposition, harmonics).

If you really want to kill it, you could always come in with a learning model which accounts for the characteristics of the instruments and the way in which the sound evolves over time. An FFT is effectively looking for the integrated power in a frequency band. This is often more than enough to do the job, but it misses potentially useful information found in the time domain.

The perks come in where situations like "I want to set up an experiment in the lab, but I want to monitor it from home so I'm not stuck there all weekend" are only slightly more difficult than Hello World.

Academic classes that introduce Labview tend to focus on basic programming tasks. This is not a good way to showcase its benefits.

I use Labview.

For anything reasonably complex, it is by far the slowest language I've worked in.

It's still 100% worth it for its use case, and 90% of what you'd want it for is not all that complex.