You aren't getting any better(robertheaton.com)
robertheaton.com
You aren't getting any better
http://robertheaton.com/2013/03/04/you-arent-getting-any-better/
33 comments
>Hackers are behind stories like
You are probably a little behind the times. Like 15 years. The term "hacker" has stopped meaning exclusively these kind of guys for agres...
You are probably a little behind the times. Like 15 years. The term "hacker" has stopped meaning exclusively these kind of guys for agres...
> You are probably a little behind the times. Like 15 years. The term "hacker" has stopped meaning exclusively these kind of guys for agres...
No. What we're dealing here actually is the effect of the urge of wannabe-hacker kids using inflected forms of "hacking" in unheard before ways next to achievements often barely worth mentioning, especially under the "hack" hat.
I'm hacking new code - I'm programming new code.
I'm hacking in a new language - I'm learning new language.
I'm hacker - I'm a bit above average programmer/web developer/whatever.
...
I simply cannot agree to these alleged redefinitions. To be honest, I also don't care if it feels so-15-years-old or so-70s. HN as a community is the last place I would like to see wholeheartedly accepting casual things as hacking. Hacking is about deep, profound understanding of computer-related stuff and things (far from trivial) you're able to achieve thanks to that.
No. What we're dealing here actually is the effect of the urge of wannabe-hacker kids using inflected forms of "hacking" in unheard before ways next to achievements often barely worth mentioning, especially under the "hack" hat.
I'm hacking new code - I'm programming new code.
I'm hacking in a new language - I'm learning new language.
I'm hacker - I'm a bit above average programmer/web developer/whatever.
...
I simply cannot agree to these alleged redefinitions. To be honest, I also don't care if it feels so-15-years-old or so-70s. HN as a community is the last place I would like to see wholeheartedly accepting casual things as hacking. Hacking is about deep, profound understanding of computer-related stuff and things (far from trivial) you're able to achieve thanks to that.
For you and me, hacking means grokking stuff.
For the mass-media influenced population, who are about 90% of population, hacking means breaking into systems and damaging or controlling them.
Now what you mention is another different redefinition of hacking. Like a watering down effect, going from grokking to simply tinkering to even dabbling something.
I don't like it either, and I would rather have hacker to keep its original meaning, but it is what it is.
For the mass-media influenced population, who are about 90% of population, hacking means breaking into systems and damaging or controlling them.
Now what you mention is another different redefinition of hacking. Like a watering down effect, going from grokking to simply tinkering to even dabbling something.
I don't like it either, and I would rather have hacker to keep its original meaning, but it is what it is.
>I simply cannot agree to these alleged redefinitions.
How about the most blatant redefinition -- from "a guy hacking trees with an axe"?
>HN as a community is the last place I would like to see wholeheartedly accepting casual things as hacking.
Well, Paul Graham might have been a great hacker (and Robert Morris!), but HN was built more around an entrepreneurial community (YC et al).
As such, a lot of people here don't do deep hacking stuff. They do simple web services (and sometimes, reading some articles they make it sound like they're doing rocket science). Even the most celebrated of them, Facebook, Instragram, Groupon or what have you, are dead simple stuff, CS wise. There might have been some difficulty in handling their scaling, but that too is hardly a hard problem. (Stuff like what Google and Orbitz do are another matter entirely).
So, seeing that HN has tons of introductory or trivial Node, Mongo and similar articles, why should you expect to see the "old meaning" of hacker here? It's not like it's Lambda the Ultimate.
How about the most blatant redefinition -- from "a guy hacking trees with an axe"?
>HN as a community is the last place I would like to see wholeheartedly accepting casual things as hacking.
Well, Paul Graham might have been a great hacker (and Robert Morris!), but HN was built more around an entrepreneurial community (YC et al).
As such, a lot of people here don't do deep hacking stuff. They do simple web services (and sometimes, reading some articles they make it sound like they're doing rocket science). Even the most celebrated of them, Facebook, Instragram, Groupon or what have you, are dead simple stuff, CS wise. There might have been some difficulty in handling their scaling, but that too is hardly a hard problem. (Stuff like what Google and Orbitz do are another matter entirely).
So, seeing that HN has tons of introductory or trivial Node, Mongo and similar articles, why should you expect to see the "old meaning" of hacker here? It's not like it's Lambda the Ultimate.
> How about the most blatant redefinition -- from "a guy hacking trees with an axe"?
I'm not saying that words cannot get new meaning in some new emerging contexts. Languages evolve, that goes without saying. But when people start to deteriorate their meaning within the same context, mostly to be able to use these terms themselves, thus feeling a bit better or cooler (because these terms used to describe exceptional people), then something wrong is happening.
> As such, a lot of people here don't do deep hacking stuff. They do simple web services...
And it's fine, really. I'm not bashing HN community for submitting stories not worth of "hacking" (according to "old meaning", as you named it) emblem (it's really nice when such stories appear, though), because on-topic is "anything that gratifies one's intellectual curiosity". I'm criticizing overuse of all hack* nouns, adjectives, adverbs, verbs and what not. I believe that most people here can tell the difference between slick and shiny CSS date picker and system emulation done using JS for instance (to stay in the browser realm). Not everyone is like Bellard, but does it mean we need to redefine "hacker" to allow its wider use and prevent covering this term in dust as the time goes? Hell no.
> So, seeing that HN has tons of introductory or trivial Node, Mongo and similar articles, why should you expect to see the "old meaning" of hacker here?
Because it's part of computer-related legacy.
Doing fun things (everyone perceive "fun" differently) doesn't need to be hard and is quite healthy. Sharing and spreading the fun is definitely ok too. But let's not pretend that doing anything fun in CS field is immediately hacking, because it's not. HN is thankfully full of people aware of it, so I'm not afraid about HN future, yet.
I'm not saying that words cannot get new meaning in some new emerging contexts. Languages evolve, that goes without saying. But when people start to deteriorate their meaning within the same context, mostly to be able to use these terms themselves, thus feeling a bit better or cooler (because these terms used to describe exceptional people), then something wrong is happening.
> As such, a lot of people here don't do deep hacking stuff. They do simple web services...
And it's fine, really. I'm not bashing HN community for submitting stories not worth of "hacking" (according to "old meaning", as you named it) emblem (it's really nice when such stories appear, though), because on-topic is "anything that gratifies one's intellectual curiosity". I'm criticizing overuse of all hack* nouns, adjectives, adverbs, verbs and what not. I believe that most people here can tell the difference between slick and shiny CSS date picker and system emulation done using JS for instance (to stay in the browser realm). Not everyone is like Bellard, but does it mean we need to redefine "hacker" to allow its wider use and prevent covering this term in dust as the time goes? Hell no.
> So, seeing that HN has tons of introductory or trivial Node, Mongo and similar articles, why should you expect to see the "old meaning" of hacker here?
Because it's part of computer-related legacy.
Doing fun things (everyone perceive "fun" differently) doesn't need to be hard and is quite healthy. Sharing and spreading the fun is definitely ok too. But let's not pretend that doing anything fun in CS field is immediately hacking, because it's not. HN is thankfully full of people aware of it, so I'm not afraid about HN future, yet.
I don't think it's an insult to anyone that the meaning of the word has changed. People call themselves hackers in admiration of the kind of hacking you point to. Also, as another commenter pointed out, programmers call themselves hackers to speak to say "I would be programming even if it didn't pay the bills."
If anything I'd say your reverence for the term itself is dangerously close to hero worship, if not outright hero worship. Identifying with the culture of the hackers you're referring to helps us keep our sights on being our best selves and serves as a reminder what kind of work is top notch.
If anything I'd say your reverence for the term itself is dangerously close to hero worship, if not outright hero worship. Identifying with the culture of the hackers you're referring to helps us keep our sights on being our best selves and serves as a reminder what kind of work is top notch.
> I don't think it's an insult to anyone that the meaning of the word has changed.
I see that only people clung to their misuse of hacker and related terms are advocating that the meaning has changed. Well, for mass-media hackers are computer criminal, should we acknowledge it and stop using the term in an original computer-related meaning?
Hackers in fact rarely refers to themselves by this term. They are also quite modest and open to any critique, contrary to many boastful youngsters calling themselves "hackers".
> People call themselves hackers in admiration of the kind of hacking you point to.
Hackers admiration is fine, but the logic is flawed. Admiration alone doesn't change you into the one you admire, so it's quite awkward calling oneself someone she or he is not yet, don't you think?
> Also, as another commenter pointed out, programmers call themselves hackers to speak to say "I would be programming even if it didn't pay the bills."
"I would be hacking even if it didn't pay the bills." -> thinking or saying that doesn't make anyone a "hacker", even more if we're talking about "programming".
Hacker - programmer that is not afraid of starving. Amusing definition.
> If anything I'd say your reverence for the term itself is dangerously close to hero worship, if not outright hero worship.
Worship? I call it accuracy.
> Identifying with the culture of the hackers you're referring to helps us keep our sights on being our best selves and serves as a reminder what kind of work is top notch.
Sure, I don't see anything wrong in identifying with (meant as aiming to become part of) the culture of the hackers, but calling myself a hacker just because of my aspirations would be plainly wrong, so I cannot commend such practices.
I see that only people clung to their misuse of hacker and related terms are advocating that the meaning has changed. Well, for mass-media hackers are computer criminal, should we acknowledge it and stop using the term in an original computer-related meaning?
Hackers in fact rarely refers to themselves by this term. They are also quite modest and open to any critique, contrary to many boastful youngsters calling themselves "hackers".
> People call themselves hackers in admiration of the kind of hacking you point to.
Hackers admiration is fine, but the logic is flawed. Admiration alone doesn't change you into the one you admire, so it's quite awkward calling oneself someone she or he is not yet, don't you think?
> Also, as another commenter pointed out, programmers call themselves hackers to speak to say "I would be programming even if it didn't pay the bills."
"I would be hacking even if it didn't pay the bills." -> thinking or saying that doesn't make anyone a "hacker", even more if we're talking about "programming".
Hacker - programmer that is not afraid of starving. Amusing definition.
> If anything I'd say your reverence for the term itself is dangerously close to hero worship, if not outright hero worship.
Worship? I call it accuracy.
> Identifying with the culture of the hackers you're referring to helps us keep our sights on being our best selves and serves as a reminder what kind of work is top notch.
Sure, I don't see anything wrong in identifying with (meant as aiming to become part of) the culture of the hackers, but calling myself a hacker just because of my aspirations would be plainly wrong, so I cannot commend such practices.
I think that was the parent's point...the term "hacker" has been diluted to where it can mean anything and everything. Just like the "pivot", "traction", etc.
Well, words do change with the times. The world hacker once meant the guy with an axe, hacking things.
But it's not like its diluted to the point where it can mean "anything and everything".
Now, the original meaning that the parent laments (something like the historical MIT hackers), has been long gone (as an exclusive meaning).
All through the late eighties - nineties "hacker" in the mass media meant the computer intruder. Like the movie "Hackers" and all. Geeks have tried for years to get them to use "cracker" instead.
Later (circa 1998-2000), it was mostly re-associated with the OSS crowd, Linux, the Mozilla guys, et al.
Nowadays, it seems to mean the developer in general (when used casually) and the more "adventurous" kind of developer --e.g one that dabbles in multiple languages, knows his Lisp etc (when used in a more positive way).
Perhaps the only kind of developers disqualified by the current use of the terms are "corporate drones", Java/Visual Basic guys making tedious enterprise stuff and the like.
But it's not like its diluted to the point where it can mean "anything and everything".
Now, the original meaning that the parent laments (something like the historical MIT hackers), has been long gone (as an exclusive meaning).
All through the late eighties - nineties "hacker" in the mass media meant the computer intruder. Like the movie "Hackers" and all. Geeks have tried for years to get them to use "cracker" instead.
Later (circa 1998-2000), it was mostly re-associated with the OSS crowd, Linux, the Mozilla guys, et al.
Nowadays, it seems to mean the developer in general (when used casually) and the more "adventurous" kind of developer --e.g one that dabbles in multiple languages, knows his Lisp etc (when used in a more positive way).
Perhaps the only kind of developers disqualified by the current use of the terms are "corporate drones", Java/Visual Basic guys making tedious enterprise stuff and the like.
Not a fan of this post. Link bait title followed by almost zero substance.
Stockbroker performance would be an ok point of comparison for another non-deterministic profession, like an athlete. But programming is deterministic. Your code either performs the desired function in the desired way or it does not.
Additionally, there are clear skills you can pick up. You either know these things or you don't.
You really can objectively improve at programming, without room for any interpretation or argument. There's no randomness involved.
With being a stock broker, there's a luck factor. Your pick may have been based on sound objective reasons. Made better by more thorough processes than picks you made in your 20's. But natural disasters or internal corruption which was not disclosed may cause an outcome completely against what everything else predicted thus ruining your performance.
Unpredictable disasters for us can be setbacks, but they don't ruin our performance as developers.
Stockbroker performance would be an ok point of comparison for another non-deterministic profession, like an athlete. But programming is deterministic. Your code either performs the desired function in the desired way or it does not.
Additionally, there are clear skills you can pick up. You either know these things or you don't.
You really can objectively improve at programming, without room for any interpretation or argument. There's no randomness involved.
With being a stock broker, there's a luck factor. Your pick may have been based on sound objective reasons. Made better by more thorough processes than picks you made in your 20's. But natural disasters or internal corruption which was not disclosed may cause an outcome completely against what everything else predicted thus ruining your performance.
Unpredictable disasters for us can be setbacks, but they don't ruin our performance as developers.
I think you're making a dangerous correlation between the determinism of software and the supposed determinism of skill at software development. Yes, one of the most important aspects of software development is making code that runs correctly, but that is not the only aspect. Even if we focus on that alone, we run into many issues:
- How do we determine whether anything but the most trivial program is correct?
- Are the specifications so clearly defined that you could actually say your program is "correct" assuming that you could reason perfectly about its behavior? If you are the one writing the specifications, you know that the preceding question has no answer, because the specifications are just as hard to match to the problem as the program is to match to the specifications.
- Can a program be said to be complete and production-ready if both it and the specifications are correct? What about security, performance, legacy support, and other concerns?
Correctness, even if you take that alone, is not so simple. Even if it was simple, that's not the only metric for measuring skill in software development, and it's not the only (or even most) important thing to focus on.
- How do we determine whether anything but the most trivial program is correct?
- Are the specifications so clearly defined that you could actually say your program is "correct" assuming that you could reason perfectly about its behavior? If you are the one writing the specifications, you know that the preceding question has no answer, because the specifications are just as hard to match to the problem as the program is to match to the specifications.
- Can a program be said to be complete and production-ready if both it and the specifications are correct? What about security, performance, legacy support, and other concerns?
Correctness, even if you take that alone, is not so simple. Even if it was simple, that's not the only metric for measuring skill in software development, and it's not the only (or even most) important thing to focus on.
You missed my point. Of course there are subjective qualities to code. That's irrelevant to my point.
Which was that a stockbroker is a bad analogy because he can be 10x better than he was in his 20's and bad luck can negate all his skill and effort.
That doesn't happen with programming. There's not that luck factor. Even to the subjective aspects.
Which was that a stockbroker is a bad analogy because he can be 10x better than he was in his 20's and bad luck can negate all his skill and effort.
That doesn't happen with programming. There's not that luck factor. Even to the subjective aspects.
Important parts of programming are subjective, such as usability, code readability, maintainability, requirements elicitation.
Yes but totally irrelevant to my point.
Then I'm afraid I may have misunderstood you.
I enumerated those subjectivities because they make room for "interpretation or argument", and there is a kind of "randomness" involved. Even between "Your code either performs the desired function in the desired way or it does not", there's the classic case where it does what someone asked for, but not what they meant (bad elicitation).
If that's really irrelevant, please do explain your point a bit further.
I enumerated those subjectivities because they make room for "interpretation or argument", and there is a kind of "randomness" involved. Even between "Your code either performs the desired function in the desired way or it does not", there's the classic case where it does what someone asked for, but not what they meant (bad elicitation).
If that's really irrelevant, please do explain your point a bit further.
After 34 years, my recipe for the best way to get better:
Find customers. Satisfy them. Repeat.
They will pull you kicking and screaming into your excellent future much faster than you can ever do it yourself.
Find customers. Satisfy them. Repeat.
They will pull you kicking and screaming into your excellent future much faster than you can ever do it yourself.
After 15 years, my recipe for getting better.
Remain curious and constantly confused.
Do not use 'to be' verbs when describing interests or skills.
Oh and most important. To do it all for fun not because you want to 'improve' yourself. The rest follows.
Remain curious and constantly confused.
Do not use 'to be' verbs when describing interests or skills.
Oh and most important. To do it all for fun not because you want to 'improve' yourself. The rest follows.
I'm curious, would you elaborate on your reasons to avoid "to be" verbs?
Maybe its an avoidance of identity with these things? Typically people regard things that they claim are part of their identity as more fixed than other things.
Alternatively, he could be following the advice of Korzybski, in Science and Sanity en.wikipedia.org/wiki/Alfred_Korzybski
Alternatively, he could be following the advice of Korzybski, in Science and Sanity en.wikipedia.org/wiki/Alfred_Korzybski
It's the first and part of the second. I've never heard of Korzybski but I arrived at a similar idea that makes physics easier to grasp. I prefer to say gravity is well modeled as curvature of a manifold instead of saying gravity is a bending of spacetime. I also prefer to say someone is acting foolish than to say they are foolish. Never realized they could be connected as part of the same general philosophy. Thanks.
It's very easy to slip but I've gotten better in time.
It's very easy to slip but I've gotten better in time.
There's a form of English called E-Prime [1] that does this, the idea (I believe) is to clarify what you mean and be clear about how your ideas of things came about. It stops lazy assertions and gives you perspective.
For example, you can't say: Lua is better than Python[2]
Instead you say: I prefer Lua to Python
Or perhaps you say: More projects that I rate highly use Lua over Python.
Or maybe: Lua scores more highly on common performance benchmarks than Python
[1] http://en.wikipedia.org/wiki/E-Prime
[2] Just an example; I'm not actually saying Lua is better than Python
For example, you can't say: Lua is better than Python[2]
Instead you say: I prefer Lua to Python
Or perhaps you say: More projects that I rate highly use Lua over Python.
Or maybe: Lua scores more highly on common performance benchmarks than Python
[1] http://en.wikipedia.org/wiki/E-Prime
[2] Just an example; I'm not actually saying Lua is better than Python
I hate to stray so far from the main thread, but anyone who finds E-Prime interesting might enjoy reading about Evidentiality[1]. Some languages allow encoding the nature of evidence in verb forms, with the most cited example (Pomo) having forms to distinguish direct evidence (visual and nonvisual), circumstantial evidence, and hearsay. Somewhat esoteric but pretty cool. Make the observations and give the facts to the listener and let them reach a conclusion - contrast with American English where it is incredibly common to qualify the confidence we have in our own judgement ("It must.." "I suppose.." "I think.." "It probably", and of course all forms of "to be") rather than qualifying the confidence of your knowledge in an objective way.
[1] http://en.wikipedia.org/wiki/Evidentiality
[1] http://en.wikipedia.org/wiki/Evidentiality
Greek and Latin can do this in "indirect speech" ("He said that ..."). Depending on the verb forms, the actual speaker can indicate either that he agrees himself, or that it is just an assertion of the other person. So maybe not so esoteric!
Has anyone ever defined E-prime in E-prime? The wikipedia page doesn't offer one but I'd imagine it would have to be a series of prolog-like assertions about E-prime. You obviously can't just say "E-prime is ..."
E-prime begins with English and then removes the being verbs.
E-prime removes all conjugations of "to be" from English. <-- Not sure if quoting "to be" as a noun counts. :)
E-prime removes all conjugations of "to be" from English. <-- Not sure if quoting "to be" as a noun counts. :)
Shuzan held out his short staff and said, "If you call this a short staff, you oppose its reality. If you do not call it a short staff, you ignore the fact. Now what do you wish to call this?"
How does calling it a name oppose its reality? It still has a reality even if you concurrently give it a name.
Hofstadter's "Gödel, Escher, Bach" explains this well in chapter 9 (Mumon and Gödel). I believe the argument goes that by calling it a specific thing you "oppose the reality" of all the other things it also is - no single name will ever suffice. Closed world assumption and all that.
[deleted]
There is no science I can point to but I feel using language that way makes it as if the skill has become part of your identity. Makes it hard to detach. So that I insult Ruby or Apple and now I am insulting you. Google is dying means a big part of your self is becoming obsolete. I am a "pythonista/rubyist/haskeller" encourages tribal thinking. Them vs Us. I find this also explains much about flamewars. I don't like.
To avoid that I prefer to say I know Z. I use X instead of I am a X user. I am most skilled in Y not a Y'er. I really like A. It is still hard to see A die but I don't need to defend every affront as if I was the one insulted. I allow only a few things to help define part of my identity. Doing this actively, also triggers to conscious how much I don't want to slip into tribalism or stagnation.
And by being ok with confusion it means I don't fear new things, by being confused it means I'm learning, by being curious I'll actively seek to put my self beyond my ability.
To avoid that I prefer to say I know Z. I use X instead of I am a X user. I am most skilled in Y not a Y'er. I really like A. It is still hard to see A die but I don't need to defend every affront as if I was the one insulted. I allow only a few things to help define part of my identity. Doing this actively, also triggers to conscious how much I don't want to slip into tribalism or stagnation.
And by being ok with confusion it means I don't fear new things, by being confused it means I'm learning, by being curious I'll actively seek to put my self beyond my ability.
>I am a "pythonista/rubyist/haskeller" encourages tribal thinking. Them vs Us. I find this also explains much about flamewars.
PG talks about exactly this point in Keep Your Identity Small [1].
[1] http://www.paulgraham.com/identity.html
PG talks about exactly this point in Keep Your Identity Small [1].
[1] http://www.paulgraham.com/identity.html
Psychologically, this is called ego identification.
It's also the reason you shouldn't talk about religion or politics at work or with the in-laws. For exactly the reason you mentioned: attacking Ruby will feel to the Rubyist like a personal attack.
It's also the reason you shouldn't talk about religion or politics at work or with the in-laws. For exactly the reason you mentioned: attacking Ruby will feel to the Rubyist like a personal attack.
> do it all for fun not because you want to 'improve' yourself
Some skills/knowledge aren't fun to develop, yet it's worthwhile to keep learning them, so what you're saying sounds to me like it'd result in skipping some important things.
Some skills/knowledge aren't fun to develop, yet it's worthwhile to keep learning them, so what you're saying sounds to me like it'd result in skipping some important things.
Mine just adds one step before the first: Learn how to find customers.
And, if you aren't working directly for those people, get out.
A typical corporate scenario can be that you are satisfying some very real needs, but you are reporting to other/different people than those -- people who may have or come to have very different goals.
This is a recipe for getting screwed.
A typical corporate scenario can be that you are satisfying some very real needs, but you are reporting to other/different people than those -- people who may have or come to have very different goals.
This is a recipe for getting screwed.
Stock brokers are a bad example, because that is essentially gambling.
Also playing around with some API will make me better in using that API.
What are some meaningful metrics for becoming a better developer?
Personally, I'd like to launch more.
Also playing around with some API will make me better in using that API.
What are some meaningful metrics for becoming a better developer?
Personally, I'd like to launch more.
Came in to post this point as well.
Even if you don't consider it gambling, you judge a stock brokers talent based on their average return of investment for their portfolios.
Unless that average is increasing every year, its hard to say they are improving their talent.
Not many brokers and traders work on improving their ROI, they focus on compounding the capital they have at targets like 1% to 3%.
The law of diminishing returns also plays a big role in a stock brokers career, there are swing traders who may make only a few transactions a year, then there are day traders who make hundreds of trades a day. There isn't a strong correlation of hours trading to profits.
Comparing this at all to programming is like comparing apples to kittens.
Even if you don't consider it gambling, you judge a stock brokers talent based on their average return of investment for their portfolios.
Unless that average is increasing every year, its hard to say they are improving their talent.
Not many brokers and traders work on improving their ROI, they focus on compounding the capital they have at targets like 1% to 3%.
The law of diminishing returns also plays a big role in a stock brokers career, there are swing traders who may make only a few transactions a year, then there are day traders who make hundreds of trades a day. There isn't a strong correlation of hours trading to profits.
Comparing this at all to programming is like comparing apples to kittens.
Nassim Taleb explains this very well in one of his books (not sure which, Fooled by Randomness or Black Swan).
Assume you have 8 traders and their chance of making a win/loss in a given year is 50% (i.e completely random).
On average, after 1 year, you'll have 4 traders who made money. After 2 years, you'll have 2 and after 3 years you'll have 1.
That one trader can now proclaim loudly that he's outperformed the marked for 3 years in a row. Even though his own influence in this was zero, and he reached it through pure luck.
Luck plays a large role in everyone's life, but for traders much more so, and comparatively for programmers much less.
Assume you have 8 traders and their chance of making a win/loss in a given year is 50% (i.e completely random).
On average, after 1 year, you'll have 4 traders who made money. After 2 years, you'll have 2 and after 3 years you'll have 1.
That one trader can now proclaim loudly that he's outperformed the marked for 3 years in a row. Even though his own influence in this was zero, and he reached it through pure luck.
Luck plays a large role in everyone's life, but for traders much more so, and comparatively for programmers much less.
Ditto to the gambler comment. Read Nate Silver's book on predictions for more. Working as a stock broker shouldn't be compared to software development without some explanation of why the link is valid, which it isn't in this case.
I don't think it's as bad as you think.
While there is luck involved with the stock market, those trading in it are not machines trading randomly (which would make it truly gambling) - they are thinking humans trying to make the best decisions they can. It's very easy to spent years playing in the market - but not focusing on improving yourself as a player. The same is true for poker (which is my background).
I'm pretty new to code, but I would think that it's possible to reach that level after a few years. Building things that are easy for you and not pushing to deepen your knowledge.
You get me bro?
While there is luck involved with the stock market, those trading in it are not machines trading randomly (which would make it truly gambling) - they are thinking humans trying to make the best decisions they can. It's very easy to spent years playing in the market - but not focusing on improving yourself as a player. The same is true for poker (which is my background).
I'm pretty new to code, but I would think that it's possible to reach that level after a few years. Building things that are easy for you and not pushing to deepen your knowledge.
You get me bro?
As we're getting older we simply can't keep getting better in at the same speed. If you're a mentally balanced person your live will contain more and more unpredicted variables like a partner, kids, older parents and family members, health issues and what not. Things beside your work that require your time and attention.
Absolutely - I feel it's then still important to be honest about what you are doing and whether or not it's helping you in this way if that's what you want it to do. If you want to focus on other things then that's great and healthy, but recognise that flicking through Rails blogs and noodling around with ideas is what you do for recreation, and has very little impact on your professional development.
Totally agree. Nowadays I try to be laser-focused about what I do in my 'free' time. The bar is set much higher than when I was younger. It's not so easy to stay focused though with all the high-quality distractions these days.
Clarke's third law:
Most importantly how do you define "Better"?
Any sufficiently advanced technology is indistinguishable from magic.
Most importantly how do you define "Better"?
Article title: 100% manipulation, 0% information. Please don't upvote these.
Whilst you are unavoidably picking up points on your CV with every project you complete and every line of code you write, you may not, and indeed probably are not actually getting any better.
I think I understand the gist of what he's trying to say: you can only know you've improved if you know what you're trying to achieve and measure what you do. By that measure doing arbitrary things "to get better" won't lead to improvement.
I think he's wrong in two ways.
First, he ignores a situation I've experienced many times - getting "stuck" in a point of stable local maxima after finding a less than perfect solution to a problem. Playing around with new and unrelated stuff occasionally helped me identify something I initially overlooked in my initial problem and lead me to something better.
Second, and perhaps more important, I believe the simple unconscious act of learning and sharing new things can lead many to live longer, happier and arguably better lives.
I think I understand the gist of what he's trying to say: you can only know you've improved if you know what you're trying to achieve and measure what you do. By that measure doing arbitrary things "to get better" won't lead to improvement.
I think he's wrong in two ways.
First, he ignores a situation I've experienced many times - getting "stuck" in a point of stable local maxima after finding a less than perfect solution to a problem. Playing around with new and unrelated stuff occasionally helped me identify something I initially overlooked in my initial problem and lead me to something better.
Second, and perhaps more important, I believe the simple unconscious act of learning and sharing new things can lead many to live longer, happier and arguably better lives.
I'm sorry but I am too getting better.
It's just that getting better is a draining, exhausting, humbling, confusing, difficult, pain in the ass process where your effectiveness goes to 0 for a while as you do something new.
I think the reality is that people avoid getting better because the process to truly make such strides is a horrible experience.
For instance; after 12 years of vim I'm trying emacs ... intensively; and it's overwhelming. I want to do things in vim but I'm forcing myself to learn the other side of the fence. And you know what? It has been truly invaluable.
Next time you get an idea tell yourself: "I'm going to write this in (pick a random language, like prolog, or ocaml that you don't know)."
And stick to it until it's done. Pretend like you've never used anything else and must learn all of it over again.
Then try something else you aren't good at. Spend many hours a day at it.
Ask yourself "If I was 15 ... how would I approach this?" or "If I was much smarter than me, how would I approach this?". Both systems help you unshackle yourself from your comfort zone and the latter helps you try to get a better handle on things you haven't yet.
Dedicating yourself to the learning process towards mastery outside the institutions of learning takes real dedication and is a pain.
But I certainly write a better parser and lexer than I did out of college. I certainly write better functional and object oriented code. I certainly organize my time better. Across the board, I run circles around my 23 year old self because I continue to endure the unnecessary pains of intellectual growth.
And one day, I'll finally sit down and figure out how to write a mobile app. It's up next. I've had a bunch of failed starts, but my next idea will run on my phone; whether it belongs there or not.
Not because "I can" but because I've told myself that "I will".
It's just that getting better is a draining, exhausting, humbling, confusing, difficult, pain in the ass process where your effectiveness goes to 0 for a while as you do something new.
I think the reality is that people avoid getting better because the process to truly make such strides is a horrible experience.
For instance; after 12 years of vim I'm trying emacs ... intensively; and it's overwhelming. I want to do things in vim but I'm forcing myself to learn the other side of the fence. And you know what? It has been truly invaluable.
Next time you get an idea tell yourself: "I'm going to write this in (pick a random language, like prolog, or ocaml that you don't know)."
And stick to it until it's done. Pretend like you've never used anything else and must learn all of it over again.
Then try something else you aren't good at. Spend many hours a day at it.
Ask yourself "If I was 15 ... how would I approach this?" or "If I was much smarter than me, how would I approach this?". Both systems help you unshackle yourself from your comfort zone and the latter helps you try to get a better handle on things you haven't yet.
Dedicating yourself to the learning process towards mastery outside the institutions of learning takes real dedication and is a pain.
But I certainly write a better parser and lexer than I did out of college. I certainly write better functional and object oriented code. I certainly organize my time better. Across the board, I run circles around my 23 year old self because I continue to endure the unnecessary pains of intellectual growth.
And one day, I'll finally sit down and figure out how to write a mobile app. It's up next. I've had a bunch of failed starts, but my next idea will run on my phone; whether it belongs there or not.
Not because "I can" but because I've told myself that "I will".
I suppose you are correct. Sharpening the saw wears on the saw.
The mere fact of understanding what you do and the pitfalls it may be prone to is a great improvement.
Do not oversimplify life: you are much more than what you do.
Do not oversimplify life: you are much more than what you do.
>Many studies, collected most notably in Geoff Colvin's "Talent is Overrated", find that in a wide range of disciplines experience has absolutely no correlation with efficacy [1]. Lifelong stockbrokers perform at exactly the same level as those in their 20s; or, rephrasing this slightly, lifelong stockbrokers perform at exactly the same level as when THEY were in their 20s. Despite having overseen numerous trades, been to countless conferences and devoted thousands upon thousands of hours to the craft of stockbroking, they are not even slightly more skilled that they were 40 years before.
Yes, but why draw the bizzaro conclusion that experience is overrated in other trades too?
This is due to the fact that the stock market is an unpredictable, multi-variable system based on belief and millions of volatile individual perceptions, and the "experts" are more or less "farting around in the dark". But we already knew that about the stock market.
Not to mention that the above "example", also clashes with his advice later on:
>If [getting better] is what you want, you have to make a conscious effort and chart a deliberate course.
If his own "example" about the traders was universally applicable, then that wouldn't be possible at all. Or does he think that the traders just didn't spent "conscious effort"?
Yes, but why draw the bizzaro conclusion that experience is overrated in other trades too?
This is due to the fact that the stock market is an unpredictable, multi-variable system based on belief and millions of volatile individual perceptions, and the "experts" are more or less "farting around in the dark". But we already knew that about the stock market.
Not to mention that the above "example", also clashes with his advice later on:
>If [getting better] is what you want, you have to make a conscious effort and chart a deliberate course.
If his own "example" about the traders was universally applicable, then that wouldn't be possible at all. Or does he think that the traders just didn't spent "conscious effort"?
Deep practice (or flow) is being in a state where you have some of the skills you need to complete a task, but aspects of the task are just beyond your current skill level. You need to attempt to complete the task, make small failures, learn from them, try again, and repeat this process until you grow the skills required to complete the task. Some research says that being in deep practice for 10,000 hours will take you to the "expert" level. (Or, what I just said defines itself?)
Of course, don't think that sitting in a chair 9 to 5 will give you the experience and education you need to become better than you were the week before. You must be challenged to stretch and grow, and you need some way to learn from failure. Sometimes you can discover why you failed on your own, and sometimes you need some kind of external feedback from a mentor or teacher.
In hacking, you can learn a lot from what others have learned and written about, from other similar problems and solutions, so you can probably consider a site like StackOverflow.com as one potential source of "external" feedback, as long as you understand the solutions you find there (and even better if you discover and solve problems that weren't previously shared.)
Of course, don't think that sitting in a chair 9 to 5 will give you the experience and education you need to become better than you were the week before. You must be challenged to stretch and grow, and you need some way to learn from failure. Sometimes you can discover why you failed on your own, and sometimes you need some kind of external feedback from a mentor or teacher.
In hacking, you can learn a lot from what others have learned and written about, from other similar problems and solutions, so you can probably consider a site like StackOverflow.com as one potential source of "external" feedback, as long as you understand the solutions you find there (and even better if you discover and solve problems that weren't previously shared.)
A question for those who are trying to get better: how do you measure progress?
The biggest problem is selling stocks to suckers hasn't changed much in a century or so. Fred Schwed's hilarious classic shows absolutely nothing has changed in that business in 90 years other than minor terminology.
On the other hand, other than general job title and being in front of a keyboard and looking at a screen, almost nothing I did in 1981 is even remotely similar to what I do in 2013.
I started out with basic and Z80 assembly programming, then 6809 assembly programming, then OS-9 (kind of like unix, sorta..). Then downgraded to crude PC and dos generalist stuff in the late 80s to early 90s. I did lots of linux sysadmin work in the early (well, 93ish onward), mid, late 90s, then I took a detour for a couple years into being (mostly) a BGP operator at a regional ISP, then a phase of mostly DBA and data importer/exporter work, then went thru a CRUD web app phase, etc. Along the way I did a lot of microcontroller work mostly 68hc11 and a lot of the ancient and current PIC families. I also had a weird side trip thru the joys of mainframe work circa mid 90s, someday "modern" PC stuff could catch up to BAU in the mainframe world as of 1994, but probably not. And I did some microwave RF work which does actually relate to this discussion when you program a PLL synth using a microcontroller or implement stupid sequencing tricks or even just monitor a GPSDO. I simply don't have 32 years experience in anything. Adding to the weirdness I never really stop anything, I still do enough linux sysadmin stuff to stay current but probably not advance much beyond where I was which admittedly was pretty advanced. And I never stop learning, I still think its hilarious to implement project euler problems in new languages, scala being my amusement of choice right now. I can't count how many Fred Brooks style silver bullets I've seen, dodged, or laughed at in the last three decades.
On the other hand if you were a stockbroker pitching RCA in 1923 to rubes, its not much different to pitch GRPN to rubes in 2013.
On the other hand, other than general job title and being in front of a keyboard and looking at a screen, almost nothing I did in 1981 is even remotely similar to what I do in 2013.
I started out with basic and Z80 assembly programming, then 6809 assembly programming, then OS-9 (kind of like unix, sorta..). Then downgraded to crude PC and dos generalist stuff in the late 80s to early 90s. I did lots of linux sysadmin work in the early (well, 93ish onward), mid, late 90s, then I took a detour for a couple years into being (mostly) a BGP operator at a regional ISP, then a phase of mostly DBA and data importer/exporter work, then went thru a CRUD web app phase, etc. Along the way I did a lot of microcontroller work mostly 68hc11 and a lot of the ancient and current PIC families. I also had a weird side trip thru the joys of mainframe work circa mid 90s, someday "modern" PC stuff could catch up to BAU in the mainframe world as of 1994, but probably not. And I did some microwave RF work which does actually relate to this discussion when you program a PLL synth using a microcontroller or implement stupid sequencing tricks or even just monitor a GPSDO. I simply don't have 32 years experience in anything. Adding to the weirdness I never really stop anything, I still do enough linux sysadmin stuff to stay current but probably not advance much beyond where I was which admittedly was pretty advanced. And I never stop learning, I still think its hilarious to implement project euler problems in new languages, scala being my amusement of choice right now. I can't count how many Fred Brooks style silver bullets I've seen, dodged, or laughed at in the last three decades.
On the other hand if you were a stockbroker pitching RCA in 1923 to rubes, its not much different to pitch GRPN to rubes in 2013.
How does Algorithmic trading fit into this model?
Your average 40 year career stockbroker knows there's some young nerds from the physics, math, and CS departments who were hired into the mostly B-school grad company, but he doesn't work with them or hang out with them or have anything to do with them other than maybe 3 or 4 levels up the org chart they share a boss. So for an upper level manager HFT is a "new thing" in the biz but not so much a broker. And from an upper level manager perspective they're not totally new so much as basically expensive automated hyperactive daytraders.
Yes I'm sure there exist rare individual exceptions but very few experienced brokers pivoted out of sales and human trading/consulting into algorithm design.
Yes I'm sure there exist rare individual exceptions but very few experienced brokers pivoted out of sales and human trading/consulting into algorithm design.
I re-read articles I read and didn't understand and if now I do, I learned something that allow me to better understand a wider range of subjects. If not, I didn't progress.
I retry puzzles that I failed to complete in the past and if they appear easier to do, I progressed. It worked for some Euler Puzzle that I couldn't begin to understand and a few months afterward they seemed trivial.
Redoing anything you struggled to achieve (or didn't achieve) could be a proof of progress, as long as it's actually understood.
I retry puzzles that I failed to complete in the past and if they appear easier to do, I progressed. It worked for some Euler Puzzle that I couldn't begin to understand and a few months afterward they seemed trivial.
Redoing anything you struggled to achieve (or didn't achieve) could be a proof of progress, as long as it's actually understood.
Progress I think is context dependent. In competitive activities like sports, the performance statistics speak for your progress. On the other hand programming, being more like a craft, would measure progress by the quality of the work you produce and also the ease with which you do it.
Does your old work look like shit?
Well yes, but so does the current stuff :)
But now you are in the position where you know your work looks bad. Imagine when you were younger and said, "This, this right here is better than anything anyone has ever written."
At least now you have a decent smell test.
At least now you have a decent smell test.
Link bait title, the post's actual argument is"You aren't getting any better if you're not doing X."
The article is fluffy and wrong. Writers, composers and programmers all get better from doing. For each new program written, you expand your style, your vocabulary and learn to express yourself in a simpler and more precise manner. This enables you to solve larger and more complex problems. Varying your environment, genre and language makes this learning even more intense.
In e.g. stockbroking and mathematics, the vigor of youth may very well make up for lack of experience. But what I've seen convince me that even though the common perception may be that's true for programming too, it's really very, very far from the case.
In e.g. stockbroking and mathematics, the vigor of youth may very well make up for lack of experience. But what I've seen convince me that even though the common perception may be that's true for programming too, it's really very, very far from the case.
Of course it's wrong. If you work at something for 40 years and don't get any better, you have a serious mental deficiency. Hell, even if you do have a serious mental deficiency, sheer basal ganglian muscle memory will make you better. This is absurd.
Focussed practice is effective; unfocussed practice is useless. No surprises there.
I'm not sure that the perception that we have continuous improvement is all that helpful. For one thing there are so many dimensions to improvement, and some of them are probably competing. To try and chase them all we will probably just line ourselves up for some break-down of some-sort.
I think understanding what you can and can't do will be far more useful in the long-run.
Also, a note on the stockbroker example. We're talking about 'average' performance for stockbrokers in their 20s and 40s. I can quite imagine that the 'average' performance is the same. But what's the standard deviation?!
I think understanding what you can and can't do will be far more useful in the long-run.
Also, a note on the stockbroker example. We're talking about 'average' performance for stockbrokers in their 20s and 40s. I can quite imagine that the 'average' performance is the same. But what's the standard deviation?!
Agree 100% that it's fundamentally about understanding what you can/can't do and are/aren't doing. If you are jamming on what you know that that's totally fine, but it pays to realise this.
The stockbroker example was slightly poorly chosen - similar studies have been done on other professions, including physicians, in particular when inspecting scans for signs of cancer.
The stockbroker example was slightly poorly chosen - similar studies have been done on other professions, including physicians, in particular when inspecting scans for signs of cancer.
[deleted]
Always good to read something like this every once in a while. Reminds me just how far i haven't gotten in my short career. Right, I really need to double down on css.
"We want to be ninjas" lol
A ninja coder is a coder with experience in liquidation of companies. I can claim, that I'm a ninja, because I liquidated 3 different companies in the last 20 years.
Of course the main work of a ninja starts, after you fired everybody. You need skills to hack into computers, accounts, databases, retrieve source code, and try to get a sense of what was going on in a company, without allowing anybody of the former employed to access any computer.
A ninja coder is a coder with experience in liquidation of companies. I can claim, that I'm a ninja, because I liquidated 3 different companies in the last 20 years.
Of course the main work of a ninja starts, after you fired everybody. You need skills to hack into computers, accounts, databases, retrieve source code, and try to get a sense of what was going on in a company, without allowing anybody of the former employed to access any computer.
The post has his point, but you can't compare experience from stock market with software development. They are complete different things.
Your experience doesn't help much in the stock market because its random nature.
In software development you really can accumulate knowledge and experience. You may not remember all things you read and do, but at least you will know where to look - and this is the key in this world jammed of information.
I don't take the engineer's and entrepreneur's stance here that every thing that I work toward have a so-called practical application and measurable economic value. You can spend your life on something without expecting it to "make you better".
The efficiency in my craft that I gain may prove to have some value to others in the "real world", but make no mistake, I'm not driven by anything but my interest in the craft itself.
The efficiency in my craft that I gain may prove to have some value to others in the "real world", but make no mistake, I'm not driven by anything but my interest in the craft itself.
I know this is false because people that are younger than me are generally less experienced (and generally know less) and people that are older than me generally know more. This seems to be a tech phenomena only though. When I was practicing structural engineering I found that after 27 or 28 people stopped getting better. Some even got worse (forgetting simple things like sheer flow).
Market success is a very bad example. Success as a trader is related to success in games like poker - it is predicated on the ability to act consistently, against your instincts, and with discipline for long periods of time. The domain knowledge and hands-on experience needed to run a couple of successful market strategies is something you can pick up in a couple of years.
It's because you can learn to build complicated systems, advanced algorithms and data structure but in the end, it isn't going to help you build a simple crud application any faster than someone who doesn't know these things.
You could be getting better, but it won't show performance wise.
You could be getting better, but it won't show performance wise.
If you can do all that, you shouldn't be working on simple CRUD applications.
The tool is not the goal.
If you were one of a few surgeons capable of performing highly specialised surgery, wouldn't you leave cuts and bruises for the interns and the nurses?
That's not how capitalism works.
I really liked this post and completely agree with the message. We tend to equate each year of experience with "getting better". That's just not always the case. It has to be deliberate. You have to be curious!
Couldn't force myself to keep reading this after "experience has absolutely no correlation with efficacy"
"Many studies, collected most notably in Geoff Colvin's "Talent is Overrated", find that in a wide range of disciplines experience has absolutely no correlation with efficacy [1]."
You seem to think you're presenting a surprising fact here, but you already explained this in your very first sentence: "hackers have a much greater intrinsic desire to improve their skills than those in other professions."
You seem to think you're presenting a surprising fact here, but you already explained this in your very first sentence: "hackers have a much greater intrinsic desire to improve their skills than those in other professions."
The first sentence seems to be an anecdote based on a specific set of people whereas the mention of Colvin's Talent is Overrated is a presentation of evidence and also a more general pattern. Why do you find the two sentences redundant?
Oh sorry, I didn't mean I find them redundant per say - I think they show a flaw in the main point. The main point seems to be that all the work many developers do to get better isn't working. But this statement was based on a study that encompasses many fields, while it already stated that people in most other professions don't work so hard to get better as developers do. So it makes sense that overall, people don't get better. That doesn't mean developers don't either.
it really boils down to work flow---are you actually producing output or spinning your wheels on unproductive thoughts and actions (reading hacker news, Facebook, talking on the phone). To get better, you have to maintain a consistent strong focus on producing.
Of course not getting better at your craft.
Just staying on top of new ways to practice that craft.
Just staying on top of new ways to practice that craft.
So what's the advice here, try harder at getting better?
This article lost me at "laydeez"
Please get some contrast and also test your site on computers that don't have retina displays or are not Macs.
http://contrastrebellion.com/
http://contrastrebellion.com/
I have a Mac and retina display and found the site hard to read. Perhaps one day, with experience, the site owner can think about and improve his legibility.
Perhaps I am just showing my age bias, but it seems from my perspective that I am handling more challenging problems more quickly with 25 years work experience. I do not have the work ethic (desire to work insane hours) I had then, but I am more effective now.
Perhaps I am just showing my age bias, but it seems from my perspective that I am handling more challenging problems more quickly with 25 years work experience. I do not have the work ethic (desire to work insane hours) I had then, but I am more effective now.
Could also be the tools and tech at our disposal allows us to tackle larger problems faster too.
It's not overly easy to read on a 1920x1200 23" IPS display panel monitor either.
Viewtext.org makes it a bit easier: http://viewtext.org/article?url=http%3A%2F%2Frobertheaton.co...
Viewtext.org makes it a bit easier: http://viewtext.org/article?url=http%3A%2F%2Frobertheaton.co...
I agree.
Luckily there are some extensions that help read those kind of pages.
On opera I use https://addons.opera.com/en/extensions/details/cleanpages/
I guess you can find some others ext. for others browsers.
ENOPARSE. Beginning looked promising, but examples of what is cool quickly spoiled it completely. Hacker is most likely a good programmer, but even very good programmer doesn't have to be a hacker. Seriously, using HTML+CSS+JS, while making over 50% (80%?) of HN content, isn't hacking-related stuff at all. Heck, you can "hack" some HTML/CSS/JS platform differences in particular browsers with some workarounds, but it doesn't make you a hacker. If the things will go on, it looks like a hacker term may become a synonym of the web developer. Or programmer using lesser known languages too. It would be huge slap in the face of real hackers.
Hackers are behind stories like:
- X86 MMU fault handling is turing complete -- https://news.ycombinator.com/item?id=5261598
- The 8085's register file reverse engineered -- https://news.ycombinator.com/item?id=5314442
- Dalvik patch for Facebook for Android -- https://news.ycombinator.com/item?id=5321634
to name a few recent ones.