I see a lot of people do stupid shit because they don't seem to think it will make a big difference. One mistake isn't a big deal, is it? The problem is that it becomes habit, and then you're making plenty of these, and you think it's okay, but in reality a lot of these mistakes have become normal.
I think the most profound thing about the post was that it showed a striking difference between determined practice and directed practice. Just being determined and putting in the hours will _not_ be sufficient to pass a plateau of learning. Sometimes you need _directed_ learning to push you past that plateau.
Applying that to code, I think this is the difference between just programming a lot and thinking you'll get better, and actually reading texts, reading code and talking to other programmers to see how other people do things better.
For example, you can start using more anonymous functions in your code because all the cool kids are doing it, but unless you really understand how to deal with high-order functions and what a map and fold are, you are just going to be doing stupid shit that doesn't really help your code at all.
Simply using map and folds instead of for-loops is just more stupid shit that doesn't really help your code at all. It's not really any shorter or less bug-prone, and it makes your code harder to follow for people who don't understand map & fold.
The real benefit comes from when you understand the concepts behind map and fold. If you realize that fold is nothing but replacing each n-ary constructor of an algebraic data type with an n-ary function, then you recognize that you can do the same thing for data structures besides sequences, like binary trees, graphs, and ASTs. There you're getting some benefit, because there's no built-in language syntax for iterating over those.
data List a = a : [a] | []
[1, 2, 3, 4] = (1 : (2 : (3 : (4 : []))))
foldr :: (a -> b -> b) -> b -> [a] -> b
foldr (+) 0 [1, 2, 3, 4] = (1 + (2 + (3 + (4 + 0))))
foldr (*) 1 [1, 2, 3, 4] = (1 * (2 * (3 * (4 * 1))))
...by extension ...
data Tree a = Leaf a | Branch (Tree a) (Tree a)
foldTree :: (a -> b) -> (b -> b -> b) -> Tree a -> b
foldTree f g (Leaf x) = f x
foldTree f g (Branch x y) = g (foldTree f g x) (foldTree (f g y)
Then you recognize that the GoF calls this the Visitor pattern, because certain stupid languages don't have higher-order functions or algebraic data types, and so you need to make the equivalencies between concrete subclass => ADT constructor, Visitor => function, and object state => return value. Suddenly a lot of modularized compiler libraries (eg. LLVM) make a lot more sense.
Then you realize that a map is nothing but a list-fold where the binary operation is constrained to be the composition of some arbitrary function of the element together with a cons operator:
map :: (a -> b) -> [a] -> [b]
map f = foldr ((:) . f) []
The cool thing about this formalism is that it makes it explicit that f depends only upon the single element of the sequence, and that the ordering of the resulting list is independent of the actions of f. In other words, map can be parallelized. And that lays the groundwork for MapReduce, which lays the groundwork for massive-scale parallel data processing.
> I think the most profound thing about the post was that it showed a striking difference between determined practice and directed practice. Just being determined and putting in the hours will _not_ be sufficient to pass a plateau of learning. Sometimes you need _directed_ learning to push you past that plateau.
This is exactly right. Ericsson and the related expertise psychology literature calls your directed learning 'deliberate practice'. Have you read the _Cambridge Handbook_ or his 1993 paper http://www.gwern.net/docs/1993-ericsson-deliberatepractice.p... ?
Applying that to code, I think this is the difference between just programming a lot and thinking you'll get better, and actually reading texts, reading code and talking to other programmers to see how other people do things better.
I don't think this follows from the article. "Not doing stupid shit" in the article's term is getting better at the basics. When you're describing is directed study but I can't see how it is directed at "the basics of programming", which would have to be something not off-by-one, not using objects before their initialized or whatever is "really simple".
The problem of overcoming bad habits is a really tough one.
In a performance-based skill like Chess or music, you can drill simple stuff to make them perfect. It's hard to see a simple equivalent in programming.
I'm also not sure if there is an equivalent to perfection in programming. All the things that slow me down do look "stupid" on some level but they're stupidity of different levels, from design to variable name to the creation of functions to understanding and avoiding syntax errors.
If there is an awareness drill to educate oneself against bad programming habits, I'd love to find it.
|Sometimes you need _directed_ learning to push you past that plateau.
That and practice. My chess improved noticeable with timed play. Putting a time limit on a game forces you to do 'something', if only to stop losing. In my case, this forced me to eventually develop a strategy and focus my game on actually attacking particular areas of the board. This really improved my game.
On a side note, I just watched Crockford on Javascript and he said lambda functions are the greatest innovation in computer science. Could you point me toward a resource that will explain why?
In regard to what you said about determined and directed practice, it's essentially a case of it being more about the quality, not quantity of time spent on something. I realised this a number of years ago and have been utilising it ever since. Most people tend to keep going down one particular route when they're trying to achieve something and, when they hit a roadblock, they keep pushing forward. This is working harder. The alternative is to go in a completely different direction where, rather counter-intuitively, we have a chance of picking up information/experience which will get rid of the previously encountered road block. This is working smarter. If something seems too difficult, it probably is, and the reason for that is that one is missing key pieces. Doing the same thing will not find these pieces but looking in non-obvious places will (since if it was obvious, it wouldn't be difficult in the first place).
I think that the mechanics behind this consist of what is basically, to borrow a term from comp sci, an impedance mismatch between our internal maps of the world and the shared maps we call physics or math or piano technique. We tend to organise things in a particular way so that we can communicate about them with each other but this shared set of symbols is never the same as an individuals' internal representation. I think that the reason all internal maps are different is because the subject (the human) is an integral part of them. In other words, one's understanding of gravity will have shared symbolism with completely subjective experiences that have nothing to do with gravity. The process of learning is essentially a mapping of one set of symbols to another. More accurately, there seem to be three levels, the experience itself, the internal symbols relating to the experience and the external shared symbols we use to communicate with each other. Based on this, I think that the categorisations in the shared map rarely make sense internally and that, as a layman, following the lines drawn by the categorisations doesn't make sense, hence the roadblocks that people encounter.
To put it another way, the categorisations we have in our shared knowledge are primarily for communication purposes and are, objectively speaking, irrational. Separating math from physics from music does not make sense in real terms since they are different perspectives on the same system. Or, to put it yet another way, the map is not the territory and those who understand that are much more adept at navigating with maps.
People do stupid shit because most of the time they don't know "what" is the stupid shit in whatever they are doing. It is hard and only looks easy on hindsight. This is the part were a mentor or good teacher can make a HUGE difference.
Same thing applies in job interviews and dating. The people opposite the table from you want you to succeed because no one likes giving interviews or going on first dates. They just want to fill the vacancy.
All you have to do is not disqualify yourself by being stupid or obnoxious.
This is such an important point but people just don't seem to grasp it.
The idea that you have to be the most dazzling job cantidate or the most amazing romantic partner to succeed in these areas probably holds people back a lot. In my experience if you don't do anything overtly stupid, the other party will subconsciously fill in the blanks so that you match "what they were looking for".
I want to accept this advice, but it does go against the basics of risk taking. Also, not to pick on you, the article seems to fall for this too.
I'd say 90% of the stupid things I do are because I wanted to do something new or risky and as such I have a neophytes mind. Sure, when I start to hit an intermediate level I can then self-analyze and make that jump from average to 'sometimes good' but I can't do it all the time and I sure as hell can't do it in the beginning.
So lets look at interviews. I've been on a few. I've played the ultra-conservative role of being super-careful and treating them like I'm on trial. That approach doesn't seem to work. I've recently played the role of someone who is very socialable and even tells a joke or two and other "stupid" behaviors
Hey, you know what? It turns out most humans are far, far from these rational logical creatures. They aren't thinking "Lets fill this position" they're thinking "Lets hire someone I can work with who doesn't seem like an overserious ass or a nut and has at least the basic competency to understand the job and learn more." Geeks of the world need to understand the great importance in social skills, risk taking, socialization, understanding social culture, etc. The idea that we can just solve everything by being super careful and super critical of ourselves is not a smart strategy.
This seems very defensive.. Wouldn't this make you very careful, self conscious and, well, boring? Don't know if this will work in a job interview, but it has to be the _worst_ thing you can do on a date ;)
>The people opposite the table from you want you to succeed. >All you have to do is not disqualify yourself by being stupid or obnoxious.
I dunno, man. I graduated last month. 9 interviews in the last 2 months. Finally landed a job, so I guess I can talk about how the other 8 went. Honestly its not so simple as you describe. There is definitely a supply-demand dynamic at work. Too much supply. Literally too many sailors and too few ships. Every university of repute ( Courant, UCB, MIT, Princeton, Stanford, UChicago, CMU, Columbia, Cornell ) and the 2nd-tiers ( UMich, Rutgers, UToronto, Baruch, Boston ) together graduate some 1500+ solid quants each year. That's 1500 people with a Financial Mathematics Masters, in addition to C++ programming, whether via BSCS, MSCS, or PhD ( several PhDs in my pgm ), with typically another 1-2 graduate degrees thrown into the cocktail! I used to think with 3 Masters I was in a good spot, but I realized I was actually in the middle/bottom tranche. There are many people ( some 25% of class ) seeking a Masters in Financial Math who already have either a Physics PhDs or Statistics PhDs or ofcourse pure Math PhDs ( aka God ). So they get this science/math PhD, realize academia sucks, then head for a financial math degree, then get a C++ certificate ( there's a mini industry minting money off of "C++ certification for quant") and then show up at the interview. A first-timer ( ie. one with just Financial Math & C++ ) has zero chance. These are not the only ones you are competing with. You also have insiders ( people with MBAs and CFAs and 5 years at an IB/PE ) who may not do very well on the C++ or the math, but their experience at a trading desk gives them a huge edge. IBs surely cannot absorb 1500 bodies year after year. So the interviews are super-technical and nobody wants you to succeed. I wouldn't say I was stupid/obnoxious at 8 of the 9. 2 of them said I was "clearly overqualified and would quit in 3 months out of boredom" ! Some others were "not a right fit" type ( too much programming not enough math or vice-versa) , but there were a few hedge funds where I felt Boy this is my dream job but they were technically off-the-charts. The questions were goddamn hard. And the math was hard. Write C++ code for pricing a barrier option on an instrument with some specified parameters where the volatility is stochastic ( ie. use Heston's volatility model to price a barrier call. ) Now that's not the sort of stuff you look forward to without a stiff one. A classmate was asked to walk through a SABR and a GARCH and asked to explain in detail which one would be a better fit for a certain class of fx bonds and why. While the programs give you a good overview of everything, that is also their flaw - they give you detailed knowledge of nothing. So you have to have mandatory side projects to succeed. I had written a few thousand lines of java to price condors & written an optimizer over the holidays, so that was what got me my job. But even that wasn't sufficient. Walk me through your code. Did your model actually make you money ? How much money ? Did you make money because of your model or because of the view of the instrument ? I mean that stupid side project suddenly took a life of its own and became like a real production system which should jump through all sorts of hoops and make money from day 1! There was much more relief than happiness when it was all over and I got the job.
Bottomline, right now there are simply too many good candidates and too few positions. You have to be really really smart and lucky. Stupidity and obnoxiousness is a very trivial filter - most will get past that pretty soon. What happens after that is what counts.
This article echos one of Nassim Taleb's central themes, that what doesn't happen (or that we don't do, or we actively avoid) is often as or more valuable than what happens/what we do/etc. But we tend to discount the value of things that we can't see or that didn't happen, thinking everything of value must be 'actionable', and that's a mistake.
It's a pretty common idea among traders as well. One of the fundamental teaching examples is why it's better to avoid a loss than make a gain:
Say you start with $100 and take a 50% loss down to $50. Now, what percentage gain will it take to get you back to $100? Many people new to the game will unthinkingly answer a symmetrical 50% gain, but of course that's wrong. To get from $50 back to $100, you need a 100% gain.
For every loss, getting back to even requires asymmetrically more % gain. I imagine poker players are very aware of this harsh fact as well.
There's even an old misquoted Japanese/Chinese proverb that hints at it - If you sit by the river long enough, you'll see the body of your enemy float by. Implying the power of doing nothing and letting your adversary shoot themselves in the foot. (http://news.ycombinator.com/item?id=1225153)
The possibility of making game-ending blunders is one of the main reasons I don't play competitive chess any more.
Of course, it's very frustrating to make a "simple" error in a game of chess that might have already taken up a couple of hours of time and which may lose the match for your team, which represents a large geographic region.
But after a lot of reflection it became apparent to me that this kind of frustration is very much an inherent property of the game of chess.
It turns out (once you play enough games and get pretty damn good at it) that it's actually quite a limited and simple game. Once you're down half a pawn or so there aren't many possibilities to generate a counterattack on another part of the board to make it possible to win without relying on your opponent making a subsequent simple mistake.
I did play quite a bit of Go at university and for a while I was confident that I could get good. If I'd stuck at it I would certainly be a low-ranking amateur dan by now but I decided to spend the majority of my spare time learning more about IT.
One reason for my early enthusiasm in the game of Go was because it's such a complex game it's not really clear when a "simple" strategic error has been made. Perhaps more importantly, because both players experience much more difficulty choosing moves than in chess, there's usually a reason to play on when you've made a mistake even when playing a highly competent player.
This has been a long reply. I'm trying to illustrate that the secret to seeming good at everything is to participate in activities which are intrinsically difficult and where your intelligence will have the chance to shine through rather than to participate in activities where one foolish blunder can allow a person of much lesser ability to beat you.
I have used a similar technique for teaching competitive croquet. Instead of this one simple rule, I offered three. The first two rules pertain to strict technique and croquet theory (similar to the specifics about not leaving pieces hanging, and structuring your opening moves). The third rule is always: don't F up your shot.
In the chess example, I reconfigured the 'don't do stupid shit', to something like, a) Open with an intent, b) Don't lose pieces without purpose, and c) Do everything for a purpose. I wanted to add this information to the thread, because I think the 'don't F up your shot' croquet analog includes a more explicit sense of limiting your actions based on your ability. In croquet, all the theory and mental prowess in the world is sacrificed if you can't execute the ideal shot under the circumstances. This is acknowledgement of your current ability is what I think applies to much of programming (and life).
Note that I am NOT suggesting that you avoid moving your abilities forward. However, focus a lot of effort on knowing what you know, and learn how to use it well. The more you use it, the more you learn and expand on that skill set. The more carefully you use what is within the realms of that skill set, the fewer mistakes (and the more successes) you will have.
Not doing stupid shit is important, but what about not being afraid to make mistakes? Making mistakes is healthy and arguably one of the best ways to learn; if your motto is 'don't do stupid shit', then I fear that you'll miss out on a lot of opportunities.
Also, your definition of 'stupid' is going to change throughout the years. You shouldn't be afraid of trying something new now because you might realize in a couple years that what you were trying to do was stupid; doing it is what helped you become a smarter and more experienced person.
I know this wasn't actually the point of the article, but it seems like the 'don't do stupid shit' motto could easily be taken too literally into this interpretation.
A better phrase would be: "Don't do stupid shit twice".
Still better, in my opinion, is: "work on your weakness".
My hobby is Olympic weightlifting. In Oly lifting brute strength can take you only so far, to succeed and progress you need to constantly work on technique.
And the only way to improve technique is to identify something you're doing wrong at the moment and to break that habit. It takes time, effort and buckets of hard, horrible work; but at the end your performance has been consistently improved for good.
If on the other hand you stick only to what you're good at, you will inevitably peak. I am very good at back squats. If I'm not consciously trying to work my weaknesses, I will do buckets of back squats and get strong at them.
But what I ought to do instead is work on getting under the bar faster, or work on my second pull, or work on foot placement during the jerk, and so on. If I put the bulk of my effort into these, I will progress much faster and further overall than any amount of squatting will grant me.
I'm fortunate to have a brilliant Muay Thai teacher and accomplished fighter who preaches this kind of philosophy every class. No matter what you do, you should do it mindfully and in the case of fighting, be aware of trade-offs and price you pay for technical inadequacy. Far too many people have the misconception that fighting or training is about hitting hard, when it's really more about hitting correctly. Parallel to the chess example: if you're getting hit and you don't know why or how, you're not training correctly. You're not studying and identifying your mistakes and then improving on them.
Having an excellent teacher to see and explain those things puts you at such an advantage over someone stuck with a less experienced or educated teacher. I like to think that theses lessons can help carry over into the startup world. That is (in sum), technical execution and winning are the only things that matter.
Oh absolutely. Having a great teacher really accelerates the process. I've been lucky enough to have studied with many great teachers over the years, and this is a common thread I've noticed. I've also noticed that really high-level skills tend to run in "family lines." For instance, my piano teacher can trace her own lineage through Artur Schnabel (one of the greatest pianists of all time), Theodor Lechitizky, and all the way back to Bach.
It's unfortunate (or perhaps a blessing in disguise) that there's no real "Teacher/Student" analogue for CS. On the other hand, the Programming/CS community is far more open about sharing information than some of the other communities I've been in. The piano community for instance is in general somewhat secretive. Ideas about piano playing seem to be passed down from generation to generation. Near the top, the techniques for obtaining "excellent playing" seem to be well agreed upon. As we get closer to the bottom, lots of misconceptions and disagreements seem to surface.
In the programming community, while there are obvious camps, since information is available so much more freely it's vastly easier to make informed decisions about what's stupid and what's not.
What you are really talking is about making a decision to raise your standards. The human mind does not process negatives very well so telling someone to stop doing stupid shit is a hit or miss message. Really the title of this post should have been, "How to be good at everything: Raise your standards." But that isn't as catchy or sticky as "Stop doing stupid shit."
Raising your standards means setting a new bar of what you are going to expect from yourself in a given task or skill. It comes with the presupposition that you can meet the standard thus the added confidence. Many people do "stupid shit" but don't know why. And frankly the 'why' doesn't matter. You have to believe that you can improve and setting standards is concrete way of telling your mind you won't accept certain behavior anymore.
Of course this sounds easy but it's not.
Making the decision is the hardest thing anyone can do. It comes with consequences, both good and bad. Consequences in potentially eliminating the fulfillment of needs you may have or possible coping mechanisms you have grown into. When you make a true decision you cut off possibilities.
Raising your standards necessitates making a 'real" decision and cutting off options. Sometimes doing stupid shit is the only way some people know how to wrap their head around the f*cked up things they have come to understand.
Scumbag article:
Highly provocative title; zero practical information.
I know negative comments are frowned upon but I just wish these knock-off quasi-zen bullshit articles didn't bubble up to the HN twitter bot so often. I'm irritated because I took the time to read this assuming that the author was going to deliver something useful and that wasn't the case, it was just a bunch of hot air. "Succeed by not failing." Very good.
I'd like to give the author full marks for marketing. Provocative title, slick design, little substance... he ought to get a job at Wired!
In the foreword to a book called "In search of stupidity", Joel Spolsky makes the case that the success of Microsoft owes much to the fact that each of their competitors did a lot of stupid shit while M$, mostly, didn't.
The article is a bit dated today, but I think he's still got a point:
For every other software company that once had market leadership and saw it go down the drain, you can point to one or two giant blunders that steered the boat into an iceberg. Micropro fiddled around rewriting the printer architecture instead of upgrading their flagship product, WordStar. Lotus wasted a year and a half shoehorning 123 to run on 640KB machines; by the time they were done Excel was shipping and 640KB machines were a dim memory.
I liked this post but am not quite sure where to start in applying this to software development. I created a follow-up "Ask HN: What are the stupid things Rails developers do?" here:
I'm not much of a rails developer. I refrained from describing what constitutes "stupid" software development since everyone's heard best practices lectures...
Poker players understand this implicitly. They refer to marginal but cumulatively significant errors as "leaks" and good players invest enormous effort in identifying and plugging their leaks. While at the highest level poker requires some very sophisticated skills, the journey from novice to competent professional is mainly one of diligently plugging leaks.
Poker is unusual in being so strongly a game of incomplete information. A top professional may only have a few percent advantage over a complete novice, so skill is rarely evident in the short term. Identifying leaks is painstaking in poker because even in hindsight you are rarely sure of the right way to play a hand. Even over a long session at the tables, a player can do everything right but lose, or play terribly but walk away with bulging pockets.
I think that poker theory has a great deal of relevance to entrepreneurs. The mental fortitude required to invest money in an uncertain outcome based on partial knowledge is an overwhelmingly important skill in both.
But isn't this also a statement that the skill of a poker player and the skill of a programmer are utterly different.
Two skill types:
A. Doing something fairly simple perfectly, plugging even the smallest mistakes.
B. Doing something that is very, very difficult as well as you can - ie, doing it at all. Doing your best to simplify situations that have a potential to become even more complex while still managing great complexity and accepting that you will make mistakes (and guarding against and finding those mistakes).
Notice, the difference between a very good programmer and very bad programmer is absolutely not a few percentage points. Poke and music are each more like skill A whereas programming is more like skill B (though these classifications are of course quite rough).
It seems like if we aren't distinguishing the skill type here, we will wind-up just tossing out vague cliches. "Don't mistakes, dude".
This is BS. If you don't allow yourself to do stupid shit you're not being creative or explorative enough in the pursuit. You may be a technical master but you will never be a game-changing luminary.
In my opinion, in this context, the appropriate time to "do stupid shit" is after you've become a technical master and have the ability to "do stupid shit" with a high level of artistry.
This great post should be really encouraging: you can achieve a terrific competitive advantage right off the bat just by launching a business that manages to avoid doing stupid shit.
A music analogy. I know a woman who is a wonderful harpist. She's a freaking musical genius who comes up with awesome and highly imaginative stuff, and has the guts and skill to execute it. However, she often does this thing where she accelerates near the end of the number. I think she's just being sheepishly modest, but it makes the end feel like a cartoony little apology. Really, instead of speeding up, she might just as well segué into "Shave and a Haircut...Two Bits!"
There's an analogy here for both authors and software developers.
I agree with the overall point here, but isn't this just the same as saying "practice" and/or "keep practicing, especially with those that are better than you"?
I see this more as an alternative way of saying "master the basics".
I can't count the number of times that I've seen developers (or classmates) try really complex things without understanding what's going on underneath, and then not be able to understand why it doesn't work.
Yes and no, the point is to practice smart. Not everything has equal pedagogical value and learning difficult techniques is worthless if you can't avoid idiocy.
To me, it seems closer to "be mindful" or "be deliberate". You can keep practicing with those better than you, but if you don't know what you're doing wrong, or how to fix it, you won't get better.
You have to know what you're doing wrong, so you can stop doing it.
I'm currently obsessed with golf (and for those who write it off as a ridiculous waste of time, I encourage you to give it a go; I used to be of the same mindset as you and I was pleasantly surprised to be very wrong. It's a great thinking man's/woman's game, gives you lots of time with quality friends, and puts you in some of the most beautiful environments you can find).
The post speaks to me as 9 out of 10 amateurs are out there doing stupid shit almost every swing - trying to hit the crap out of the ball at the expense of basic fundamentals (primarily balance), attempting miraculous shots when in trouble only to put themselves in more trouble etc. I was one of those dudes not too long ago (and still am sometimes), but recently tried to 'stop doing stupid shit'. It is unbelievable how quickly your scores can drop (that's a good thing for those who don't play) by accepting the predicament you have put yourself in and playing the next shot with intent, focus, and generally being smart about it.
I never thought of consciously applying this thinking to startups/programming but it's completely doable and probably effective.
If you don't try to hit the ball too hard, just get it back in-play -- you'll beat everyone who's worse than you, everyone who's as good as you, and half the guys that are better than you.
[+] [-] Periodic|14 years ago|reply
I think the most profound thing about the post was that it showed a striking difference between determined practice and directed practice. Just being determined and putting in the hours will _not_ be sufficient to pass a plateau of learning. Sometimes you need _directed_ learning to push you past that plateau.
Applying that to code, I think this is the difference between just programming a lot and thinking you'll get better, and actually reading texts, reading code and talking to other programmers to see how other people do things better.
For example, you can start using more anonymous functions in your code because all the cool kids are doing it, but unless you really understand how to deal with high-order functions and what a map and fold are, you are just going to be doing stupid shit that doesn't really help your code at all.
[+] [-] nostrademons|14 years ago|reply
The real benefit comes from when you understand the concepts behind map and fold. If you realize that fold is nothing but replacing each n-ary constructor of an algebraic data type with an n-ary function, then you recognize that you can do the same thing for data structures besides sequences, like binary trees, graphs, and ASTs. There you're getting some benefit, because there's no built-in language syntax for iterating over those.
Then you recognize that the GoF calls this the Visitor pattern, because certain stupid languages don't have higher-order functions or algebraic data types, and so you need to make the equivalencies between concrete subclass => ADT constructor, Visitor => function, and object state => return value. Suddenly a lot of modularized compiler libraries (eg. LLVM) make a lot more sense.Then you realize that a map is nothing but a list-fold where the binary operation is constrained to be the composition of some arbitrary function of the element together with a cons operator:
The cool thing about this formalism is that it makes it explicit that f depends only upon the single element of the sequence, and that the ordering of the resulting list is independent of the actions of f. In other words, map can be parallelized. And that lays the groundwork for MapReduce, which lays the groundwork for massive-scale parallel data processing.[+] [-] gwern|14 years ago|reply
This is exactly right. Ericsson and the related expertise psychology literature calls your directed learning 'deliberate practice'. Have you read the _Cambridge Handbook_ or his 1993 paper http://www.gwern.net/docs/1993-ericsson-deliberatepractice.p... ?
[+] [-] joe_the_user|14 years ago|reply
I don't think this follows from the article. "Not doing stupid shit" in the article's term is getting better at the basics. When you're describing is directed study but I can't see how it is directed at "the basics of programming", which would have to be something not off-by-one, not using objects before their initialized or whatever is "really simple".
The problem of overcoming bad habits is a really tough one.
In a performance-based skill like Chess or music, you can drill simple stuff to make them perfect. It's hard to see a simple equivalent in programming.
I'm also not sure if there is an equivalent to perfection in programming. All the things that slow me down do look "stupid" on some level but they're stupidity of different levels, from design to variable name to the creation of functions to understanding and avoiding syntax errors.
If there is an awareness drill to educate oneself against bad programming habits, I'd love to find it.
[+] [-] watmough|14 years ago|reply
That and practice. My chess improved noticeable with timed play. Putting a time limit on a game forces you to do 'something', if only to stop losing. In my case, this forced me to eventually develop a strategy and focus my game on actually attacking particular areas of the board. This really improved my game.
[+] [-] doctoboggan|14 years ago|reply
[+] [-] Produce|14 years ago|reply
I think that the mechanics behind this consist of what is basically, to borrow a term from comp sci, an impedance mismatch between our internal maps of the world and the shared maps we call physics or math or piano technique. We tend to organise things in a particular way so that we can communicate about them with each other but this shared set of symbols is never the same as an individuals' internal representation. I think that the reason all internal maps are different is because the subject (the human) is an integral part of them. In other words, one's understanding of gravity will have shared symbolism with completely subjective experiences that have nothing to do with gravity. The process of learning is essentially a mapping of one set of symbols to another. More accurately, there seem to be three levels, the experience itself, the internal symbols relating to the experience and the external shared symbols we use to communicate with each other. Based on this, I think that the categorisations in the shared map rarely make sense internally and that, as a layman, following the lines drawn by the categorisations doesn't make sense, hence the roadblocks that people encounter.
To put it another way, the categorisations we have in our shared knowledge are primarily for communication purposes and are, objectively speaking, irrational. Separating math from physics from music does not make sense in real terms since they are different perspectives on the same system. Or, to put it yet another way, the map is not the territory and those who understand that are much more adept at navigating with maps.
[+] [-] lepacheco|14 years ago|reply
[+] [-] dschobel|14 years ago|reply
All you have to do is not disqualify yourself by being stupid or obnoxious.
[+] [-] westicle|14 years ago|reply
The idea that you have to be the most dazzling job cantidate or the most amazing romantic partner to succeed in these areas probably holds people back a lot. In my experience if you don't do anything overtly stupid, the other party will subconsciously fill in the blanks so that you match "what they were looking for".
[+] [-] drzaiusapelord|14 years ago|reply
I'd say 90% of the stupid things I do are because I wanted to do something new or risky and as such I have a neophytes mind. Sure, when I start to hit an intermediate level I can then self-analyze and make that jump from average to 'sometimes good' but I can't do it all the time and I sure as hell can't do it in the beginning.
So lets look at interviews. I've been on a few. I've played the ultra-conservative role of being super-careful and treating them like I'm on trial. That approach doesn't seem to work. I've recently played the role of someone who is very socialable and even tells a joke or two and other "stupid" behaviors
Hey, you know what? It turns out most humans are far, far from these rational logical creatures. They aren't thinking "Lets fill this position" they're thinking "Lets hire someone I can work with who doesn't seem like an overserious ass or a nut and has at least the basic competency to understand the job and learn more." Geeks of the world need to understand the great importance in social skills, risk taking, socialization, understanding social culture, etc. The idea that we can just solve everything by being super careful and super critical of ourselves is not a smart strategy.
[+] [-] gizzlon|14 years ago|reply
and btw, first dates are great!
[+] [-] dxbydt|14 years ago|reply
I dunno, man. I graduated last month. 9 interviews in the last 2 months. Finally landed a job, so I guess I can talk about how the other 8 went. Honestly its not so simple as you describe. There is definitely a supply-demand dynamic at work. Too much supply. Literally too many sailors and too few ships. Every university of repute ( Courant, UCB, MIT, Princeton, Stanford, UChicago, CMU, Columbia, Cornell ) and the 2nd-tiers ( UMich, Rutgers, UToronto, Baruch, Boston ) together graduate some 1500+ solid quants each year. That's 1500 people with a Financial Mathematics Masters, in addition to C++ programming, whether via BSCS, MSCS, or PhD ( several PhDs in my pgm ), with typically another 1-2 graduate degrees thrown into the cocktail! I used to think with 3 Masters I was in a good spot, but I realized I was actually in the middle/bottom tranche. There are many people ( some 25% of class ) seeking a Masters in Financial Math who already have either a Physics PhDs or Statistics PhDs or ofcourse pure Math PhDs ( aka God ). So they get this science/math PhD, realize academia sucks, then head for a financial math degree, then get a C++ certificate ( there's a mini industry minting money off of "C++ certification for quant") and then show up at the interview. A first-timer ( ie. one with just Financial Math & C++ ) has zero chance. These are not the only ones you are competing with. You also have insiders ( people with MBAs and CFAs and 5 years at an IB/PE ) who may not do very well on the C++ or the math, but their experience at a trading desk gives them a huge edge. IBs surely cannot absorb 1500 bodies year after year. So the interviews are super-technical and nobody wants you to succeed. I wouldn't say I was stupid/obnoxious at 8 of the 9. 2 of them said I was "clearly overqualified and would quit in 3 months out of boredom" ! Some others were "not a right fit" type ( too much programming not enough math or vice-versa) , but there were a few hedge funds where I felt Boy this is my dream job but they were technically off-the-charts. The questions were goddamn hard. And the math was hard. Write C++ code for pricing a barrier option on an instrument with some specified parameters where the volatility is stochastic ( ie. use Heston's volatility model to price a barrier call. ) Now that's not the sort of stuff you look forward to without a stiff one. A classmate was asked to walk through a SABR and a GARCH and asked to explain in detail which one would be a better fit for a certain class of fx bonds and why. While the programs give you a good overview of everything, that is also their flaw - they give you detailed knowledge of nothing. So you have to have mandatory side projects to succeed. I had written a few thousand lines of java to price condors & written an optimizer over the holidays, so that was what got me my job. But even that wasn't sufficient. Walk me through your code. Did your model actually make you money ? How much money ? Did you make money because of your model or because of the view of the instrument ? I mean that stupid side project suddenly took a life of its own and became like a real production system which should jump through all sorts of hoops and make money from day 1! There was much more relief than happiness when it was all over and I got the job.
Bottomline, right now there are simply too many good candidates and too few positions. You have to be really really smart and lucky. Stupidity and obnoxiousness is a very trivial filter - most will get past that pretty soon. What happens after that is what counts.
[+] [-] SkyMarshal|14 years ago|reply
It's a pretty common idea among traders as well. One of the fundamental teaching examples is why it's better to avoid a loss than make a gain:
Say you start with $100 and take a 50% loss down to $50. Now, what percentage gain will it take to get you back to $100? Many people new to the game will unthinkingly answer a symmetrical 50% gain, but of course that's wrong. To get from $50 back to $100, you need a 100% gain.
For every loss, getting back to even requires asymmetrically more % gain. I imagine poker players are very aware of this harsh fact as well.
There's even an old misquoted Japanese/Chinese proverb that hints at it - If you sit by the river long enough, you'll see the body of your enemy float by. Implying the power of doing nothing and letting your adversary shoot themselves in the foot. (http://news.ycombinator.com/item?id=1225153)
[+] [-] stcredzero|14 years ago|reply
[+] [-] arctangent|14 years ago|reply
Of course, it's very frustrating to make a "simple" error in a game of chess that might have already taken up a couple of hours of time and which may lose the match for your team, which represents a large geographic region.
But after a lot of reflection it became apparent to me that this kind of frustration is very much an inherent property of the game of chess.
It turns out (once you play enough games and get pretty damn good at it) that it's actually quite a limited and simple game. Once you're down half a pawn or so there aren't many possibilities to generate a counterattack on another part of the board to make it possible to win without relying on your opponent making a subsequent simple mistake.
I did play quite a bit of Go at university and for a while I was confident that I could get good. If I'd stuck at it I would certainly be a low-ranking amateur dan by now but I decided to spend the majority of my spare time learning more about IT.
One reason for my early enthusiasm in the game of Go was because it's such a complex game it's not really clear when a "simple" strategic error has been made. Perhaps more importantly, because both players experience much more difficulty choosing moves than in chess, there's usually a reason to play on when you've made a mistake even when playing a highly competent player.
This has been a long reply. I'm trying to illustrate that the secret to seeming good at everything is to participate in activities which are intrinsically difficult and where your intelligence will have the chance to shine through rather than to participate in activities where one foolish blunder can allow a person of much lesser ability to beat you.
[+] [-] imperialWicket|14 years ago|reply
In the chess example, I reconfigured the 'don't do stupid shit', to something like, a) Open with an intent, b) Don't lose pieces without purpose, and c) Do everything for a purpose. I wanted to add this information to the thread, because I think the 'don't F up your shot' croquet analog includes a more explicit sense of limiting your actions based on your ability. In croquet, all the theory and mental prowess in the world is sacrificed if you can't execute the ideal shot under the circumstances. This is acknowledgement of your current ability is what I think applies to much of programming (and life).
Note that I am NOT suggesting that you avoid moving your abilities forward. However, focus a lot of effort on knowing what you know, and learn how to use it well. The more you use it, the more you learn and expand on that skill set. The more carefully you use what is within the realms of that skill set, the fewer mistakes (and the more successes) you will have.
[+] [-] lotharbot|14 years ago|reply
I use similar rules when investing, playing poker, and in competitive video games. I'd phrase them as:
- begin with a goal in mind
- take deliberate actions (that you are capable of) that advance you toward your goal
- don't give up resources (money, chips, pieces, hitpoints, etc.) unless that advances you toward your goal
[+] [-] rubergly|14 years ago|reply
Also, your definition of 'stupid' is going to change throughout the years. You shouldn't be afraid of trying something new now because you might realize in a couple years that what you were trying to do was stupid; doing it is what helped you become a smarter and more experienced person.
I know this wasn't actually the point of the article, but it seems like the 'don't do stupid shit' motto could easily be taken too literally into this interpretation.
[+] [-] jacques_chester|14 years ago|reply
Still better, in my opinion, is: "work on your weakness".
My hobby is Olympic weightlifting. In Oly lifting brute strength can take you only so far, to succeed and progress you need to constantly work on technique.
And the only way to improve technique is to identify something you're doing wrong at the moment and to break that habit. It takes time, effort and buckets of hard, horrible work; but at the end your performance has been consistently improved for good.
If on the other hand you stick only to what you're good at, you will inevitably peak. I am very good at back squats. If I'm not consciously trying to work my weaknesses, I will do buckets of back squats and get strong at them.
But what I ought to do instead is work on getting under the bar faster, or work on my second pull, or work on foot placement during the jerk, and so on. If I put the bulk of my effort into these, I will progress much faster and further overall than any amount of squatting will grant me.
[+] [-] tintin|14 years ago|reply
[+] [-] coryl|14 years ago|reply
Having an excellent teacher to see and explain those things puts you at such an advantage over someone stuck with a less experienced or educated teacher. I like to think that theses lessons can help carry over into the startup world. That is (in sum), technical execution and winning are the only things that matter.
[+] [-] jinfiesto|14 years ago|reply
It's unfortunate (or perhaps a blessing in disguise) that there's no real "Teacher/Student" analogue for CS. On the other hand, the Programming/CS community is far more open about sharing information than some of the other communities I've been in. The piano community for instance is in general somewhat secretive. Ideas about piano playing seem to be passed down from generation to generation. Near the top, the techniques for obtaining "excellent playing" seem to be well agreed upon. As we get closer to the bottom, lots of misconceptions and disagreements seem to surface.
In the programming community, while there are obvious camps, since information is available so much more freely it's vastly easier to make informed decisions about what's stupid and what's not.
[+] [-] DamagedProperty|14 years ago|reply
Of course this sounds easy but it's not.
Making the decision is the hardest thing anyone can do. It comes with consequences, both good and bad. Consequences in potentially eliminating the fulfillment of needs you may have or possible coping mechanisms you have grown into. When you make a true decision you cut off possibilities.
Raising your standards necessitates making a 'real" decision and cutting off options. Sometimes doing stupid shit is the only way some people know how to wrap their head around the f*cked up things they have come to understand.
[+] [-] sequoia|14 years ago|reply
I know negative comments are frowned upon but I just wish these knock-off quasi-zen bullshit articles didn't bubble up to the HN twitter bot so often. I'm irritated because I took the time to read this assuming that the author was going to deliver something useful and that wasn't the case, it was just a bunch of hot air. "Succeed by not failing." Very good.
I'd like to give the author full marks for marketing. Provocative title, slick design, little substance... he ought to get a job at Wired!
[+] [-] bambax|14 years ago|reply
The article is a bit dated today, but I think he's still got a point:
http://www.joelonsoftware.com/articles/Stupidity.html
For every other software company that once had market leadership and saw it go down the drain, you can point to one or two giant blunders that steered the boat into an iceberg. Micropro fiddled around rewriting the printer architecture instead of upgrading their flagship product, WordStar. Lotus wasted a year and a half shoehorning 123 to run on 640KB machines; by the time they were done Excel was shipping and 640KB machines were a dim memory.
[+] [-] geekfactor|14 years ago|reply
http://news.ycombinator.com/item?id=2848169
[+] [-] greenyoda|14 years ago|reply
[+] [-] jinfiesto|14 years ago|reply
[+] [-] jdietrich|14 years ago|reply
Poker is unusual in being so strongly a game of incomplete information. A top professional may only have a few percent advantage over a complete novice, so skill is rarely evident in the short term. Identifying leaks is painstaking in poker because even in hindsight you are rarely sure of the right way to play a hand. Even over a long session at the tables, a player can do everything right but lose, or play terribly but walk away with bulging pockets.
I think that poker theory has a great deal of relevance to entrepreneurs. The mental fortitude required to invest money in an uncertain outcome based on partial knowledge is an overwhelmingly important skill in both.
[+] [-] joe_the_user|14 years ago|reply
Two skill types:
A. Doing something fairly simple perfectly, plugging even the smallest mistakes.
B. Doing something that is very, very difficult as well as you can - ie, doing it at all. Doing your best to simplify situations that have a potential to become even more complex while still managing great complexity and accepting that you will make mistakes (and guarding against and finding those mistakes).
Notice, the difference between a very good programmer and very bad programmer is absolutely not a few percentage points. Poke and music are each more like skill A whereas programming is more like skill B (though these classifications are of course quite rough).
It seems like if we aren't distinguishing the skill type here, we will wind-up just tossing out vague cliches. "Don't mistakes, dude".
[+] [-] mkrecny|14 years ago|reply
[+] [-] jinfiesto|14 years ago|reply
[+] [-] lutorm|14 years ago|reply
[+] [-] bfe|14 years ago|reply
[+] [-] stcredzero|14 years ago|reply
There's an analogy here for both authors and software developers.
[+] [-] cdelahousse|14 years ago|reply
That's what your piano teacher beat into you (not out of you). That's what those chess drills taught you.
Fundamentals.
Fundamentals are never taught properly for anything.
I say this a programmer, a former music student (university level) and someone who's learned alot of shit.
[+] [-] jamesbkel|14 years ago|reply
[+] [-] pavel_lishin|14 years ago|reply
If you keep practicing the wrong way, you'll never improve.
[+] [-] jsharpe|14 years ago|reply
I can't count the number of times that I've seen developers (or classmates) try really complex things without understanding what's going on underneath, and then not be able to understand why it doesn't work.
[+] [-] jinfiesto|14 years ago|reply
[+] [-] hrabago|14 years ago|reply
You have to know what you're doing wrong, so you can stop doing it.
[+] [-] pjscott|14 years ago|reply
[+] [-] rikthevik|14 years ago|reply
[+] [-] mr_november|14 years ago|reply
The post speaks to me as 9 out of 10 amateurs are out there doing stupid shit almost every swing - trying to hit the crap out of the ball at the expense of basic fundamentals (primarily balance), attempting miraculous shots when in trouble only to put themselves in more trouble etc. I was one of those dudes not too long ago (and still am sometimes), but recently tried to 'stop doing stupid shit'. It is unbelievable how quickly your scores can drop (that's a good thing for those who don't play) by accepting the predicament you have put yourself in and playing the next shot with intent, focus, and generally being smart about it.
I never thought of consciously applying this thinking to startups/programming but it's completely doable and probably effective.
[+] [-] kayoone|14 years ago|reply
[+] [-] rwmj|14 years ago|reply
[+] [-] SolarUpNote|14 years ago|reply
If you don't try to hit the ball too hard, just get it back in-play -- you'll beat everyone who's worse than you, everyone who's as good as you, and half the guys that are better than you.