I base the 100-hour week thing on reports that it's the expectation at SpaceX and Tesla.
HN user
joedrew
disintegration of innately self-evident core values like "working hard to make a good thing good is good"
Working hard is necessary to make something good, of course. Working "hardcore", where 100-hour weeks are _required_, and only "exceptional" performance is acceptable, is _inhuman_.
I'm saying this as someone who's managed several teams over several years, but also someone who's read the literature: the surest way to get bad performance out of someone is to put that kind of pressure on them, _especially_ long-term. People in that situation get tired and/or sick, can't straight from the anxiety and pressure, and because of all of that that they'll make simple mistakes that take a long time to sort out (because everybody else is in the same situation).
In my experience the best work comes from people who are calm, healthy, and well-rested, _especially_ over the long term. Those well-rested people are the ones who are capable of putting in the discretionary effort to make something good.
Wattpad | Toronto (ONSITE) | Full-time
Wattpad is a mobile social app that connects people all over the world with stories that matter to them. It enhances the storytelling experience, and makes it possible for people to be captivated by something they love. We’re proudly based in Toronto, but our reach is global. Every day, millions of people use Wattpad to create and discover stories they can’t find anywhere else.
The Wattpad platform serves over 2 billion requests a day, with millions of users worldwide.
We're hiring for several positions, including our front end web and platform teams.
Our web client is a single-page Javascript app, primarily using Backbone, served by an Express NodeJS server.
Front End Developer: https://www.wattpad.com/life/job.html?id=job_20160323191710_...
The platform team is in the process of changing the Wattpad platform from a PHP monolith to microservices in Go.
Software Engineer - Platform: https://www.wattpad.com/life/job.html?id=job_20160315152912_...
Please apply to those links, or see if there's something else that interests you here: https://www.wattpad.com/life/?jobs
And it was me who did it!
Pluto in particular would be a problem, though, because it is a) very small, and b) very far away. In order to get there in a realistic time, your probe has to be going _very quickly_; in order to stay in Pluto orbit, the probe has to be going _very slowly_.
So, unfortunately, to stay in Pluto orbit, either you carry a lot of fuel with you to slow down (which makes launch incredibly difficult, because you need more fuel to accelerate the fuel you need to slow down, and then you need more fuel to accelerate _that_ fuel, and so on), or you wait a long time to get there.
The bigger, closer planets and planetoids, though, will see a lot more exploration as the cost of launch decreases.
It's impossible to have 'enough' parking spots. Induced demand shows that cars, like goldfish, always grow to fill the space they're given. It's politically difficult process, but just refusing to try to solve this problem (which leads to more New Urbanism-friendly locations) is often the right solution.
Read this paper ("Set up to fail: How managers create their own poor performers"): http://www.insead.edu/facultyresearch/research/doc.cfm?did=4...
The paper's basic tenet is that managers, by over-focusing on "poor performers", actually cause their poor performance by interfering with their work and putting them on performance improvement plans. Are there measurable differences between these people and your high performers in terms of output, or are you simply observing that to be so?
And listen to jonstewart. Being a manager is very different from being a programmer. Be humble and introspective, and work on becoming better at your craft.
The whole point of advocating for fewer work days is that we are just as productive in fewer hours. That's why overtime doesn't work long-term; you wear out and do less per unit time.
They don't buy, or they buy something else. If there's one thing that economics has taught us, it's that people will reduce their consumption when prices go up; even water demonstrates price elasticity: http://www.nber.org/papers/w13573.pdf
Having people's sick days deduct from their vacation is an incentive to go to work when you're sick, jeopardizing the health (and productivity) of the team.
A much better solution is vacation days and unlimited sick days, as well as generous work-from-home opportunities for days when you're under the weather but not too sick to work.
Honestly, animated GIF (like all other image formats) is a terrible format for video-style stuff. It's fine for line art (well, sort of fine, anyways), but if you actually using it for video you really should be using <video>, because it takes into account temporal information. (gfycat is a service based around this already.)
It might be possible to do an APNG-style backwards-compatible animated JPEG, but it'll still be worse at it than video formats will be.
(Note: I used to be employed by Mozilla, and in that capacity I was the owner of Mozilla's image decoders. I've been disconnected from all decisions for almost a year, though.)
The main take-home here is that while Google's numbers all show WebP as being objectively better, the metrics they chose for comparison were relatively bad (i.e., some of them didn't take into account colour or didn't model colour correctly), and once you accounted for that the numbers were not nearly as good a story for WebP; in some cases, JPEG outperformed it.
The facts that (1) WebP was not terribly compelling technically, (2) JPEG is already supported by everything on the web, not to mention devices and mobile phones etc, and (3) there's still headroom to improve JPEG in a backwards-compatible way, meant that WebP was (and, it seems, remains) a non-starter.
I'll have to look into the exact data, but conversions dipped at least 33% — even on the 'A' side.
The #1 problem I've had in using external A/B testing platforms is that they allow flashes of the old content before the new is shown (if perhaps only for some users). We've seen huge problems with conversion when testing with those tools which we don't see when running A/B tests using server-side implementations.
If Wingify/VWO has solved this once and for all, it'd be wonderful.
Oh, totally. But heck, as long as we're wishing...
I don't count as a user, since I am relatively affluent, tech-savvy, and always pay off my credit card every month.
I'm thinking of the average person who buys with Interac to avoid debt, and feels an impedance to buying online because of credit-card-only. I'd love to have the ability to enable those people's purchases through Stripe.
(I agree that the bank-redirect flow is awkward slash awful. However, you solved exactly that problem with your Alipay integration! :) )
As a Canadian, I'm most interested in when Stripe will start supporting our Interac debit cards. At that point, from my point of view, it'll have taken over the world. :)
Honestly, in a city with good transit like SF, you shouldn't be driving to the places you want to go anyways.
That sounds like depression, to be honest. As someone who has depression, and is trying to get better, my best advice is to start by at least mentioning it to my GP. Doctors can help!
No, but the hostile workplace environment that's (apparently) already there will probably not be helped by this move. http://tim.dreamwidth.org/1840066.html
Edit: A more descriptive link: http://tim.dreamwidth.org/1761874.html
The kerning differences you're seeing only show up on Windows when not using hardware acceleration (Direct2D). When not using hardware acceleration, Firefox draws text with GDI. GDI doesn't deal well with arbitrary scales applied during text drawing and this explains why the same problems show up in Chrome and Firefox. When Firefox is using DirectWrite/Direct2D (i.e., is using hardware acceleration)—like IE 10—these problems don't show up. Short of heroics, there's not much that can be done to improve text drawing at arbitrary scales with GDI.
It has nothing to do with Chrome, and everything to do with 6-weekly updates.
Think of it: You have no way to know, going in, whether the changes in any given update will be big enough to "warrant" a major version change. Worse, what if those features aren't stable enough to release and are turned off? It's very difficult to go from version N to version (N-1).
For these reasons (and others), it's a lot easier for us to unconditionally bump the major version every 6 weeks.
Source: I am a Firefox developer and a Mozilla employee.
Kijiji not only caught on in Canada, it's dominant here. I don't even bother listing things for sale on Craigslist any more; the buyers are simply only checking Kijiji.
> How is it even feasible to find a specific tab without doing a time consuming linear search?
Firefox searches open tabs in the awesomebar; selecting one of those entries switches to the tab.
Yes. We make no guarantees whatsoever on binary compatibility between versions.
This new release policy just doesn't make any sense.
Speaking as a Mozilla developer - sure it does! We release every 6 weeks, and don't hold new releases for features. In the past, we ran into far too many cases where new feature X that wasn't ready held up a release for all the other features that were ready. Now, we'll just remove or disable that new feature and ship.
OSX and Ubuntu release like clockwork. People appreciate consistency.
Two things: 1) OS X releases at the whim of Apple, not "like clockwork." 2) Every 6 weeks is "like clockwork"! :)
It's not a technical difficulty. It's pointless, because WOFF does everything SVG fonts do, but is actually supported by font foundries and the Web in general.