
On The Value Of Fundamentals In Software Development - skorks
http://www.skorks.com/2010/04/on-the-value-of-fundamentals-in-software-development/
======
alanthonyc
I think he makes a good point. I was thinking about posting an "Ask HN" about
what would be considered the fundamentals of programming/software development,
but will ask it here instead. Does anyone know of a decent list of to start
with? Basic algorithms and data structures would be on there, off the top of
my head.

~~~
devinj
Which data structures would you call "basic"?

I mean, past pairs, linked lists, [dynamically resizing] arrays, and binary
trees, it gets either more complex or more esoteric. Are quadtrees basic
everywhere? Is knowing the way a red-black tree works, by heart, useful? Does
it really help to know exactly how hash-table based dictionaries work, or is
it sufficient to have a vague understanding that a function transforms
identification numbers into "bucket" slots? This isn't rhetorical, I just
don't know.

I doubly don't know for algorithms. To me it seems the algorithms themselves
are never fundamental, it's the techniques and thinking behind them that is
fundamental. Nobody cares about binary search, we care about "divide and
conquer"-- you can rebuild binary search from that.

~~~
weaksauce
Yeah, learn the basics of divide and conquer, greedy, and dynamic programming
algorithms and you will be doing well. Of course to learn that you also need
to learn how to apply those to basic data structures such as graphs, skip
lists, and various n-ary trees.

The algorithms that the MIT lectures go over in the introduction to algorithms
course should be a good stepping stone to knowing enough to get you by in an
interview for a junior programming job.

MIT course: [http://ocw.mit.edu/OcwWeb/Electrical-Engineering-and-
Compute...](http://ocw.mit.edu/OcwWeb/Electrical-Engineering-and-Computer-
Science/6-046JFall-2005/CourseHome/)

I guess I should amend this to say that if this is the first time going
through the material you might just want to pay cursory attention to the big-
oh notation proofs and just look at the overall speed of the algorithm. Ignore
the proofs and look at the result. Though in a job scenario they will want to
know the overall running time of the algorithm that you created so it is
beneficial to know. (IE quick-sort is generally a good algorithm and will run
in O(n logn) on the average but there is a degenerate case in which it will
run O(n^2) namely a sorted list.

