You aren't getting any better
robertheaton.com
robertheaton.com
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.
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.
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.
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.
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 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.
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.
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.
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.
- 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.
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.
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.
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.
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.
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.
PG talks about exactly this point in Keep Your Identity Small [1].
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.
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
E-prime removes all conjugations of "to be" from English. <-- Not sure if quoting "to be" as a noun counts. :)
Alternatively, he could be following the advice of Korzybski, in Science and Sanity en.wikipedia.org/wiki/Alfred_Korzybski
It's very easy to slip but I've gotten better in time.
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.
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.
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.
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.
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.
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?
Any sufficiently advanced technology is indistinguishable from magic.
Most importantly how do you define "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.
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".
Do not oversimplify life: you are much more than what you do.
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"?
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.)
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.
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 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.
At least now you have a decent smell test.
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.
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?!
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.
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 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.
You could be getting better, but it won't show performance wise.
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."
Just staying on top of new ways to practice that craft.
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.
Viewtext.org makes it a bit easier: http://viewtext.org/article?url=http%3A%2F%2Frobertheaton.co...