arghbleargh's comments

When this kind of device is being used outside, does it actually have a noticeable impact on the air quality? Purifying enough air to fill Madison Square Garden sounds impressive, but it's nothing compared to the volume of air that cycles through the atmosphere.

> "He just wants to invent good things for mankind,” said Ahmed’s father, Mohamed Elhassan Mohamed, who immigrated from Sudan and occasionally returns there to run for president.

Wait... run for president?

Interesting that engagement seems to be waning from a lot of Evernote users (based on this anecdatum and the article). Is it because the product has gotten actively worse, or do you find less need to use it these days (e.g. you realized it was more hassle than it was worth)?

So... can somebody explain what the difference between "essential" and "non-essential" Flash content is, and how Chrome can tell the difference?

I think the article agrees with you, but another point it makes implicitly is that programmer A is also on the hook for creating a brittle abstraction. The article is specifically warning against the temptation to deduplicate things for its own sake, without having in mind a good abstraction that describes the shared functionality implemented by the duplicated code.

> It’s worth noting that none of these approaches fundamentally change the N^2 nature of the work to be done, but do substantially reduce work at reasonable levels of contention.

I don't think that statement from the article is true if I understood correctly... the performance gains are precisely because you're reducing from N^2 to N log N.

An interesting theoretical question would be to identify the optimal backoff policy. I think FullJitter should be close to optimal, but maybe you can squeeze out a little more with something more sophisticated.

Edit: I just realized the DecorrelatedJitter (not sure why it's called that?) makes a lot of sense as a minor optimization because if you already waited a long time and still failed, that suggests there is a lot of contention, and you should wait even longer.

I played with Legos a ton as a kid, and I have a completely different view on what made Legos good. Building Legos with only basic bricks can be fun, but there's only so much depth to it. It was actually the special pieces that enabled you to make really interesting things, and I didn't feel like they stifled creativity at all. Not having the special pieces would be like cooking with only flour, butter, salt, and water. You can probably make a few tasty things, but I don't think you would want to eat that every day.

Here's an interesting small extension of the problem: prove that it is not possible to guarantee survival if 64 is replaced by some number that is not a power of 2.

In the same vein, an easy way to get the tests to pass is to add a bunch of "if" statements to handle each test case. Of course, that is counterproductive in terms of the usefulness of the software.

However, because so much weight is put on testing, that is essentially what happens in school a lot of the time. For some reason, it seems more obviously absurd in the software context.

What about Sandbox doesn't suit your needs?

I agree with most of these points, but there is one niche where this could make a lot of sense: programming contests (e.g. topcoder, google codejam). These are very similar to sports to begin with, and it can be quite interesting to watch somebody implement a moderately complex algorithm in 15 minutes.

As you noted, the biggest thing is practice. But here are a few specific tips that I believe significantly improved my programming ability:

1) Try to get the implementation 100% correct on the first try. I don't mean that you should implement the whole system in one go, but the part you implement should do exactly what you want it to do (i.e. no typos, mixed up variable names, etc.). At first I thought this was a bit harsh, but it was amazing how much debugging you can avoid with a little more focus in the beginning. Also, it forces you to adopt good coding practices and make sure your algorithms are fully specified.

2) Don't tolerate tedious work. If there's any part of your workflow that's tedious, spend a lot of effort trying to minimize it. Some examples of things you might do: write a script, refactor your code, use a better editor, use a different programming language. You won't learn much from changing 100 variable names to camel-case, other than how painful it is. You will learn something from writing a tool to help you do that.

3) Think about how various libraries and frameworks you use are implemented, especially if they have features that seem like "magic". Try to reverse-engineer their design, or take a look at their source code (if available). This is a natural way to gain exposure to new ideas.

Regarding more "theoretical" subjects like algorithms and data structures that you might need to know for interviews, you could practice on programming contest websites (e.g. www.codeforces.com) or read some textbooks. However, in my opinion, those are not nearly as important for a software developer as the three things mentioned above.

Moreover, you don't even need to get to the "testing" step in a lot of cases. Are people going to like your spicy anchovy and cottage cheese pizza topped with ice cream? Answer: no. I didn't have to interact with a single customer to know that. Other ideas are not so obviously bad, but I feel like a lot of these failed startups would not have existed in the first place if the founders had been really honest with themselves.

If you don't have a reasonably strong belief that your idea is going to work, why bother testing it at all? At the least, you should probably try it on a tiny scale first (i.e. on yourself or a few friends) before taking investments, hiring employees, etc.

It would definitely help if you said more about what your product is. But generally speaking, from the customer's perspective, you should charge for the thing that the customer can predict better up-front, so that it's easier for them to assess your value proposition. You might want to take into account your own costs as well, if applicable.

The interesting thing about Github vs. Bitbucket is that both usage patterns can make sense depending on the project and user. For individuals, you might have a lot of repositories for small projects that end up abandoned after a while. For teams, it might make more sense to have a flexible headcount.

Some feedback:

1) There's a lot of miscellaneous info on the front page, but none of the things that I really care about. The basic info I want to know: price, what areas you serve, and what times you're available. It would also be helpful if you had this information all in one place so I don't have to keep scrolling around or clicking links.

2) It's hard to pin down exactly why, but the visual design of the landing page seems rather inconsistent. The various graphic elements seem like they've been designed individually without regard to the look and feel of the site as a whole. A more specific issue is the "Book Now" bar in the first screen. I have no idea what the input field to the left of it is for, and when I type into it, the text is really faint. Also, because of point (1), I am far from ready to "Book Now" as the first action upon visiting your site.

P.S. On this page https://sweetlyclean.com/booknow/ there's a typo where "Your" should be "You're".

I do think "learning styles" can be easily used as an excuse to give up at the first sign of difficulty. However, I'm not sure that it's "rubbish". I've always been very good at spatial reasoning, so I often try to explain things in terms of pictures. Among generally intelligent people, some of them understand me immediately, and others require a lot of tries with different variations on the explanation.

I would be tempted to say that the people who don't understand should just be more willing to think spatially instead of being stuck in their other modes. However, then I imagine how it must feel for someone with perfect pitch to try to explain to me how to recognize pitches. I can't do it just by "trying" harder; I don't even understand what it is I'm supposed to be doing.

This is not to say that e.g. people who are not good at spatial thinking shouldn't still try to get better at it. But it does lead me to think that to some extent these learning styles really are, if not genetic, at least deeply embedded in our personalities and early childhood development.

Just like you said! Start a project with it, and learn what you need along the way. Obviously your code will not be all idiomatic on the first try, but that's OK. Along the way you will run into situations where you'll think, "There's got to be a better way," or "If only I could use X feature from Y language." Or maybe you need to debug something with a library you're using but you don't understand how it works. Those are perfect opportunities to learn more advanced concepts.

This is a pretty interesting concept, but the site doesn't do a good job of explaining exactly what it does. A realistic step-by-step example would help a lot. Is it doing some kind of static analysis, or is it looking at the object graph at some specified point in the program's execution?

I think it would be really useful to have a tool that visualizes execution paths of programs to help you understand the general architecture of someone else's project. I believe debugging tools are able to do this to some extent, but I haven't seen anything that exactly fits, especially for JS. I would want to be able to do some interaction (e.g. mouse click) and see a visualization summarizing all the lines of code that were run without stepping through them one-by-one. Maybe this is a direction that PojoViz could go in eventually.

It might not be an accurate comparison to consider how language has been lost in the past 10,000 years to predict how much will be lost in the next 10,000. Surely nowadays we leave behind many more artifacts than before, and our literacy rate is much higher. Of course there is always the possibility of a catastrophic event, but even in that case it seems unlikely that future humans won't be able to reconstruct most of the English language, unless the event is so catastrophic that digging up nuclear waste is the least of your worries.

I am not experienced in these matters, but my intuition is that an IOU as you described isn't really fair in all situations. As an extreme example, if you invented and quickly prototyped a genuinely new technology that no one else knew about, then I would say your contribution is much more than whatever it cost you to make the prototype.

It's commonly asserted that ideas are worth next to nothing, the difficulty is all in the execution, etc. I don't think that's entirely true. If your idea is just a vague one-liner like "facebook for pets", then sure, it's not worth much. But as you start building out a prototype, you're forced to be more specific and refine the idea, and it becomes more valuable. If you've got a handful of users and you've gotten some feedback, that's yet a bit more value. And if you've thought about the problem for a long time, you will probably have a good sense of what are the main challenges and what approaches won't work. That's valuable too.

I don't think there is a well-defined line between refining your idea and "executing" on it. Obviously there is a limit to how much you can accomplish in the planning and prototyping stage. However, I suspect it is a lot higher than is commonly believed. Working for 3 months may sound like not very much on the scale of a startup's lifetime (let's say 2-5 years before it either fails or grows big), but consider this: maybe the OP did 4 or 5 failed 3-month projects before he or she got to this one, which seems somewhat promising. Suddenly that looks a lot more significant than 3 months.

For this specific case, we don't have enough details to assess whether the OP has really hit on something big, or if there is still a lot of uncertainty about whether the idea will pan out. So unfortunately, after all that discussion, I don't really have an answer to the original question. I think what I would do in your situation is to make my best guess as to the "fair split" based on what I've contributed and the expected future value (let's say I decide it's 70/30), offer the friend that split, and if he/she accepts, I would immediately change it to 65/35. That way, they should be happy, but things are still close to fair from my perspective.