Hacker News Reader

Comment by louischatriot | Hacker News Reader

I agree with the OP but I still think the power of algorithms and datastructures should not be understated, as they power most of the software everyone (including "organizational" coders) use, e.g. databases.

For example, I'm writing a pure JS database (https://github.com/louischatriot/nedb), and using indexing I was able to speed it up hundreds fold. That's clearly not something I could have done without knowing about self-balancing binary search trees.

I also think that knowing algorithms does make you a better programmer, even if you don't use them on a daily basis.

View on HN

There really are two classes of programmer : the one that build "tools" for other developers, and the ones that build end-user software.

The first ones needs to be fluent in every types of algorithms and data structure. The other type will have the task of modeling real world processes into a computer (which means "concept organization translation" rather than pure algorithms).

The first ones deal with primitive types, and very rarely more than that. The second ones need to model all the entities of a real life problem and their complex interactions (complex in the sense of combinations and organization).

That's why I think there will always be a gap between those two developers. They are dealing with very different kind of tasks, yet their jobs titles are the same.

"There really are two classes of programmer : the one that build "tools" for other developers, and the ones that build end-user software."

Actual the second group is occasionally saying, "WTF was the first group thinking?" after spending hours trying to get the tools to work for the real world. (Try spending a few hours/days writing wrappers for PKI software with shitty APIs...)

This distinction is artificial. I know I do both every day.

So do I, but those who build basic tools very often also make stuff for end users too, but there is a lot of programmers that only do end user software based on existing tools. They think basic tools is something someone else does, and if there is no such tool, then what they tried is "hard to do". It will never appear to them that they can make the tools themselves, or they don't have the skills to do it.

The distinction is real, in that many programmers never do build basic tools, while it is artificial in the sense that there is no reason for this other than lack of skill and organizational culture that says that that is not something you are supposed to do.

I would think the point is that if you have a job where someone doesn't need to do both, which is many corporate programming jobs, you should't hire for both skills.

There really are two classes of programmer : the one that build "tools" for other developers, and the ones that build end-user software.

Where exactly is the distinction? How would you classify Monodevelop, or git/svn, or the C++ STL, or SQLite, or Emacs, or the Unix shell utilities, or Photoshop?

This Yegge article from 2007 is relevant:

http://steve-yegge.blogspot.com/2007/06/rich-programmer-food...

"If you don't know how compilers work, then you don't know how computers work."

Becoming better at the first class of programming that you describe, will also make you better at the second class.

And a lot of times, "modeling the world" is a pitfall of object-oriented programming, and something that you don't really want to do. But it's very tempting if you've only ever programmed in Java.

Knowing how compilers work is very useful foundational knowledge, but that's different than knowing, off the top of your head, the underpinning algorithms needed to implement a compiler!

Really? They sound exactly the same to me. What, in your mind, does "knowing how compilers work" consist of, other than "the underpinning algorithms needed to implement a compiler"?

The exhaustive list is longer than I have patience for, here's one example: understanding how the parse and lex steps work, and what is accomplished is useful without knowing how to pseudocode a recursive decent parser. It's worthwhile to write said parsing algorithm once in your life, it's not necessary to keep that knowledge warm in your head throughout your career.

Hmm, I guess I don't know what "understanding how the parse and lex steps work" would consist of that didn't involve being able to pseudocode at least some kind of parser, of which the recursive-descent type is the simplest. But maybe I'm blinded by having spent too much time writing parsers. Or maybe you mean "knowing how" in some kind of total back-of-the-hand mastery sense, as opposed to "you could eventually get it to work"?

It's true there is little overlap between these two categories. But I found that the low-level work I do (such as the db mentioned above) helps me understand better and be faster at high-level, "real world" work (such as my startup's website and API tldr.io).

>I also think that knowing algorithms does make you a better programmer, even if you don't use them on a daily basis.

IMO this helps at the most very basic level because it lets us consider "hey, I wonder if there's an algorithm out there that'd help me with this" and gives you the impetus you need to go looking.

Kind of a "you know what you don't know" situation of sorts.

Reply on news.ycombinator.com