arghbleargh

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.

I won't deny that a lot of times you only need to convey a very short message, but what makes this better than just texting?

Maybe you should narrow your focus to the one or two projects you think have the strongest value proposition for the general public and treat all the others as just tools for your own use?

I agree with a lot of what the author says, but I got a little confused at the end when he started talking about fixtures. It didn't seem to tie in with the rest of the article. But I think the underlying thesis of the article could be described as the following: treat testing as an internal tool.

This means thinking of yourself as the user and optimizing for your needs (avoiding repetitive tasks, minimizing bugs in your project). It means sometimes creating interfaces for creating new tests, like how admin pages are nice interfaces for SQL queries. Conversely, it also means things like not writing overly fine-grained tests in the name of test coverage (this would be like if your admin page had two separate tools for "change user first name" and "change user last name").

For me the pointer hand is a little too subtle. I prefer to have the border highlighted on mouseover, which gives a strong visual indication without obscuring the content.

I have to agree though that modern designs, while slick, are often no more usable than designs from the 2000s. For example, take the point about vague icons near the end of the article. Even though you can often guess roughly what those icons do, that moment of uncertainty when you click them to see what happens creates a jarring user experience that could have been avoided with a few words of text.

A major contributing factor to this trend in design is obviously the emphasis on mobile devices (e.g. sometimes you have to use those small icons due to limited screen sizes). It annoys me that a lot of this mobile-driven design gets copied over to the desktop even when the same constraints no longer apply. Unfortunately, this is not completely without reason. To me, words like "refresh" are less ambiguous than circular arrows, but maybe to someone who grew up using only tablets and iphones, the circular arrow is more familiar.

Those are actually matrix multiplications and additions, so it can make a significant difference (e.g. it's way faster to add two 50x50 matrices than to multiply them).

Hmmm.. but how did the theorem prover find the solution? Probably by heuristics + brute force.

I don't see causality as defined in this context as needing any extra "motivation". It's pretty clear that if an agent tries to do A and then B, your system probably should not first execute B and then A. Imagine if the instructions in one of your program threads were not guaranteed to be executed in order. You would never be able to write code that does anything meaningful that way.

Yes, I found the latest post quotes to be rather distracting. There is no context for the posts (not even thread name), so it's all wasted space for me. Maybe it would be more useful to show something like recently commented threads and maybe a preview of latest posts in that thread if you hover. Some other issues for me:

* The usernames do not appear next to the avatars in the posts, and generally users are identified by avatar rather than username. This is very confusing, especially since avatars can change, and it's hard to distinguish faces in images that small.

* Along the same lines, icons are used all over the place instead of text. I find this annoying, as the icons are not self-explanatory, and I have to hover over every little icon in order to understand what I can do. For example, I had no idea what the "topics" and "posts" icons meant before hovering. Similarly, there is no reason to use text in the navigation bar (add an icon next to the text if you must). To be fair, the icons have the advantage of taking up less space on mobile.

* The styling was a bit jarring to me, with the high contrast and lack of strong borders between elements. The whole purpose of going to a forum is to read a lot of text, so it makes sense to use more neutral background colors. Of course, this can be customized I'm sure, so this is more feedback on the demo site rather than the platform.

But overall the implementation seemed solid, and I can see this eventually becoming a nice BB platform.

Edit: this is all based on https://community.nodebb.org/.

Seems like a fine design, but doesn't it require a lot of space? It looks like you would have to widen existing roads by at least 10 ft or so, which wouldn't be practical for a lot of roads in the city.

Or you could do it even faster by solving it directly. First note that all the parities change together, so pick the two smallest groups with the same parity, say wolves and goats. These will be the species to try to eliminate.

Then have all the wolves eat goats until only one of the species is left, say 2k wolves. Then do k iterations of lion eat wolf and wolf eat goat.

I wouldn't be so sure that this isn't exactly what they want. Consciously you get annoyed, but it's those same ads that pop into your head from your subconscious every once in a while.

I'm still in the middle of reading, but I think many people (especially outside of the Bay area) have a certain perception on what the life of a startup founder is like. And the point of the story is to presumably give a real-life view of things that may be different from the popular perception. In other words, maybe you were not really the intended audience.

Yes, I guess the examples shown are indeed "game mechanics" of a sort, but it seems to be heavily focused on game physics, at least for now. When I saw the title I was thinking of something much broader that would include things like how to use items, how to level up, etc.

Disclaimer: I have not read the book either.

One thing I don't understand about the r and g thing is how it makes sense to compare these two values at all. Isn't capital a measure of accumulated wealth, while GDP is a measure of wealth produced in a certain unit of time? For example, what if we just maintained a perfectly steady GDP that exceeded our consumption needs; wouldn't that yield a positive r and explain r > g? Does someone who read the book have a better understanding of exactly what these two numbers mean?

P.S. I find it implausible that Piketty would make such an elementary mistake as the arithmetic mean vs. geometric mean issue discussed in the article. But again someone who has actually read the book should weigh in.

That sounds amazing to me too. What you described is really the only way that making lists of "core values" could possibly achieve something useful. I just never thought it could happen. Usually people just remember the core values as a list of things that sound good, and they're too abstract to offer any real guidance for a concrete situation.

You can always replace dialoguegue with dialogue again afterwards.

For the benefit of those who can't/don't want to watch the video, can someone summarize what Lessig's "cause" is?

EDIT: More specifically, I am wondering why he's calling for the help of "technically enabled" people. What is the relevance of technology here?

The article actually makes pretty good suggestions despite coming off as a little arrogant (our design tweaks will make a world of difference, if only the developers could understand!). I think the key is to realize that the visual design work comes last. Moving things by a few pixels here or there is not going to make or break your product, because the purpose of your product is to provide some sort of useful functionality and not just to look pretty (presumably). And a lot of times it's completely subjective anyway. Get the approximate layout and user interactions nailed down first, ignoring any superficial flaws. Then, at the very end, I don't think the developer will mind if you ask him or her to make one pass of tweaking a bunch of colors and alignments.

Your algorithm seems OK, but what was the "traditional approach" that you compared it to, and how did you compare them? It seems like you actually gain a lot from full document search (e.g. products with multi-paragraph descriptions). Otherwise, you might as well just do a SQL query to get your results.

It appears to be very similar to icedcoffeescript: http://maxtaco.github.io/coffee-script/