mcantor

I wouldn't bother making a comment here to ask; normally I would just sign in and see for myself. But this app wants permission to make posts to my Twitter account, and I never, ever do that. (I hate it when I sign up for something and I later find a post in my timeline that says "A-hyuk hyuk, I just joined SomeSkeezyWebsite and I'm having a blast, LOL!")

(I honestly am not trying to imply that that is the case; I'm just musing.)

http://www.kinesis-ergo.com/

(Talk about "cure for disposable income"... they're actually great to type on once you get used to it; they're just not worth $300).

By the way, this is a delightful and simple site; I signed up for the newsletter, and I want to give you my money somehow. For what it's worth, I wouldn't bat an eyelash at affiliate links. I agree with joshu that curation is a huge value-add. In mere minutes, just based on the design of the site and the content on it right now, you have gained my trust! Treat it well and benefit from it.

And what is wrong with one sub-thread dipping into an utterly related topic? Are you suggesting that no discussion should ever shift from one aspect of a topic to another? Or are you suggesting that every programmer, anywhere, ever, should obviously learn algorithms until they are completely fluent? Both of those are baffling to me, as the former would be a completely unstated expectation in the entirety of internet discussion forums, and the latter is what we are discussing in this sub-thread!

This is one of the most interesting threads I have ever read on Hacker News. It contains a fantastic breadth of perspectives and has remained admirably civil and candid. I've had 2 people e-mail me just based on this thread, and I've purchased two books just based on this thread. I take umbrage that you would call it a waste.

My personal experience completely contradicts what you're saying.

Despite the cushy comforts of server-side scripting languages, I have experienced the occasional performance or scalability problem, and in every single case, I wrote inefficient code on the first pass, discovered unacceptable slowness at a later date, then found the bottleneck and optimized it.

Perhaps I am a brilliant super-coder (unlikely), but I have never ignored a performance problem because I didn't think I could improve it enough to be worth the effort.

I'm only a little farther along in my journey than you; at 26, I finally feel confident in my abilities, but am still humbled by how much I don't know. Last month I spent hours poring over Linux network programming resources so I could implement a performant, scalable, thread-safe game server [1]. After weeks, I finally got it working--replete with tests, sane coding practices and other Good Things--and it felt so good.

Like you said: "All hard stuff that I'll never need to know in order to build a web store site..." I didn't need to reinvent the wheel--there are tons of pre-existing solutions and frameworks out there that I could pick up and use to hit the ground running. But, like most people on this site, you and I were bit by the same bug: the desire to understand how and why it works.

For me, the hard part isn't dedication to learning or writing dime-a-dozen web apps to pay the bills. The hard part is finding the right balance. I think that's probably something I'll keep learning more about until I finally kick the bucket.

If I can presumptuously offer advice, from barely a half-decade down the line: Don't give up, and learn to see the intimidation for what it is: thrill! Do as the sagacious Derek Sivers commands: whatever scares you or excites you, go do it [2]. If you come upon something that seems insurmountably complex; it could be anything: compilers, emulators, algorithms, low-level network programming... do it. You don't have to learn it in a day, a month, or even a decade, but never fool yourself into believing that it's too hard. It isn't. Take breaks to keep yourself sharp, but never give up.

[1] - http://stackoverflow.com/questions/6849239/how-should-i-arch...

[2] - http://sivers.org/scares-excites-do-it

By your definition, I am currently a "bad programmer" because I do not have fluency in algorithms.

(I will leave the objective truth of this statement as an exercise to the reader; God knows it might be so. However...)

I contend that I am capable of learning new material quickly enough that, if I were suddenly called upon at my job to write code which handles all of the slings and arrows of algorithmic complexity, I would be able to do so with very little friction. To phrase it differently: I (probably) don't know enough to write gorgeous, algorithmically sophisticated code on the first pass, but I know enough to know when it's time for me to hit the books, and where to start.

Obviously, it would take me longer than someone with prior experience in writing such code! If the overarching question is "does algorithmic fluency constitute a dealbreaker when hiring at certain positions", then I suppose the answer depends on how much longer it would take. I can only speculate on the difference in a flagrantly biased manner, as I would egotistically prefer to believe that I ought to be hired in more cases than not. :-)

Or, if we look through the Dunning-Kruger lens, we may conclude that lack of algorithmic fluency always constitutes a dealbreaker at certain positions, because even if the developer in question can learn on the job, he or she will still make errors and oversights with far-reaching implications that are invisible--unknown unknowns--to the algorithmically illiterate. This feels less plausible to me than the simpler consideration that "learning on the job" may simply be an undesirable speed bump.

I don't really have any concrete points or refutations to make; I'm just fascinated by the issue in general and enjoy exploring the possible angles.

(Also I shall likely just cut the Gordian knot and go play with algorithms until it simply isn't an issue anymore. Go figure)

EDIT: Actually, there is a point I forgot to make:

In your edit you wrote, "So a lot of "self taught" programmers have only taught themselves 10% of what they need to know and never bother learning the other 90%." I think this is the crux of the "good/bad" problem: "what they need to know" is very subjective and dependent on context.

I think it's reasonable to assert that there are programmers out there who have long and satisfying careers, but never learned X, or didn't learn it for many years. Who's to say whether they are "good" or "bad"? It's a judgment, and judgments are meaningless without context: "good programmers need to know X" doesn't really say anything, but "programmers need to know X if they want to Y" does.

You certainly went down this road in your comment, but your Y was "You do need good programmers to scale your product, add features efficiently, and architect solutions without making a crippling mess of your code.", and I feel like lack of fluency in algorithms is just not a surefire indicator of bad architecture skills (among the others you listed) as well.

the Dunning-Kruger is exactly about ability to notice

It seems like you are saying that every programmer ought to go out of his way to become fluent in algorithms, because without fluency he or she will never notice when their code is running slowly.

If so, I disagree. It requires no skill to notice whether code is running slowly--you needn't look further than my techno-skeptical dad muttering, "Jeez, this thing takes forever to boot up" as he regards his desktop with disappointment. I think this is what the grandparent commenter was talking about: if I'm not fluent in algorithms, but my dad doesn't think it's slow, then where's the problem?

"Premature optimization is the root of all evil."

http://www.amazon.com/Algorithm-Design-Manual-Steven-Skiena/...

I was a bit flummoxed at first because algorist.com doesn't tell you how to buy the thing, and the Kindle edition appears to be out of date (based on the first edition, obsoleted by the second edition from 2010).

Tinkering with the source code for $language is also a great idea! That meshes with my empirical experience that the best way to learn is to "play". These days, it's rare for me to write code that isn't related to some specific personal project or business goal; maybe bringing back a bit of the "play" aspect is one of the keys to improving fluency.

    You should know these data structures inside and out.
    What are the insertion/deletion/lookup characteristics?
    (O(log n) for a balanced binary tree, for example.)

I didn't have a traditional CS education in college. Maybe there's some kind of magic that happens in Algorithms [1-3]01 that permanently etches these characteristics into your brain. But whatever it is, I missed out.

My main problem is that I don't seem to need this information to do what I do. I work predominantly with server-side, interpreted languages, and I just don't run into the bottlenecks and performance problems that Big O-knowledge seems to mitigate. Maybe I've been lucky. Maybe it's because none of my personal projects have gotten popular enough to be subjected to the kind of load that reveals such problems. Maybe it's because I haven't worked on the kind of project that needs this sort of attention. Whatever the reason, I simply have never hit a point in my work (which I assure you has been non-trivial at times) when I sat back and said to myself, "Gosh, if only I were more familiar with the complexity breakdown of the classic data structures, I would be able to solve this problem much more effectively or efficiently."

The thing is, I know that I'm perfectly capable of nurturing greater fluency in algorithms, so it seems like a waste to inevitably flub the more demanding portions of algorithm-based interviews. So what should I do? Is the answer as simple as biting the bullet and using flash cards until I know it all by rote (which feels like cheating), or am I "doing it wrong" somehow? Is my lack of fluency preventing me from understanding just how important it is (a la Dunning-Kruger)?

It's now 11:15. The developers start lunch at around 11:30 - noon every day, so there's no reason to get started on anything now. You get back from your hour lunch break at 12:45. There's a meeting on your outlook calendar at 1 o' clock, but you read the description and decide to skip it since there are already enough developers on the docket to give enough input. You're just gathering momentum at 1:05 when the Project Manager who organized the meeting appears at your desk, asking you to come to the meeting.

"I have a lot on my plate; the other two devs know enough about the system to keep the ball rolling."

"Well," she counters, "I really need everyone's input for this meeting." (Just like every other meeting.)

"There are 20 people on the invite list... if there are any problems, I'm sure I can just follow up with you after you send out the meeting minutes."

"Look, I really need you here for this; this isn't a skippable meeting." (None of hers are.) Finally you fold--you didn't take this job because you were a go-getter who knows how to tell people "no" repeatedly. The meeting is scheduled for 1PM - 2PM, but (like most meetings at this company), it goes until 2:30.

You get back to your desk and there are a dozen new IMs and e-mails blinking on your screen. You fantasize about just closing everything and working, but you've been here long enough to know that un-answered IMs and e-mails will result in people walking over to your desk, just like the jilted business user from this morning. For a couple of months you managed to put your foot down, mark yourself as "busy" in Outlook for the afternoon, and tell people that you simply won't deal with any non-critical problem during that period, but hearing complaints about issue turnaround time come through your boss was too much of a drain.

You answer IMs, follow up on e-mails, flip through high-priority code reviews and take care of other necessary busywork for about an hour and a half.

At 4PM, you get started on your work.

Requesting this on a t-shirt. White text, black background. Nothing else. Maybe a cheeky clip art of a stereotypical neckbeard-sort-of-guy.

  What you will learn
  What you won't learn
  Java.

Then again I also feel a little dirty for comparing the likes of Tchaikovsky and Beethoven to Java...

On the other hand, "fuck", "shit" et al. exist in a bit of a vacuum. "What the fuck" is not offensive to fucks, because (hopefully) very few people identify as "fucks".

So, the vector of offense for "Jew" is different from the vector of offense for "fuck". I'm offended when people use racial slurs. But when someone simply swears, I don't see a reason to be offended. It may affect my opinion of them; for example, I am less likely to respect someone for being articulate if they can't express themselves without swearing every couple of words. But getting offended implies some degree of emotional investment in the words or concepts themselves, which I don't really see the basis for.

To put it another way: I feel like any reasonable, compassionate person can't help but be offended to some degree by slurs; and they should be, because slurs are probably not such a great thing. Conversely, I think that we are taught to be offended by swears, and it's within reach of the average person to disconnect their emotional response from them.

  Mom: What does "WTF" mean?
  You: It's just some internet joke.
  Mom: Well, all right.

  Mom: What does "WTF" mean?
  Me: It's an internet thing; it stands for "What The Fuck".
  Mom: Ha ha!  I love it.  I'll have to remember that one.

P.S. - I still upvoted you because I see where you're coming from, and "s//" is always funny to me for some reason.