Hacker News Reader

Comment by jasonkester | Hacker News Reader

Odd list. You can have a very successful developer career without ever needing to write any of those ever. I'm a little over 20 years in now, and have never needed to do any of that.

Maybe in the 90s, I might have actually built a linked list in C for whatever reason, and I guess you could define graph traversal to include walking a tree pulled out of a database. But the rest are things that The Universe Provides For You(tm), which one would only ever reproduce in School, a Job Interview, or a Poorly Chosen Hobby.

As to actual rites of passage? Ship Something that real people actually use. Build an entire thing, be it a piece of desktop software, video game, web application, mobile app, etc. from bottom to top and send it out in to the world fully formed. That, in my mind, is what we're here for.

View on HN

> You can have a very successful developer career without ever needing to write any of those ever.

You write this, but then you go on to mention job interviews, which are becoming more and more algorithmic each passing year. Software engineers are frequently asked to write these during interviews. If you've missed the experience of being asked to implement a hash table or linked list in an interview, or at the very least asked to write a function somehow manipulating some data structure, you've either been lucky or else stayed in the same job for a long time (not a bad thing, but not typical).

I highly recommend all software developers practice implementing data structures (linked lists, hash tables, trees, graphs) and algorithms (sorting, combinatorics, etc) on a regular basis. If you fail to master these, and to understand their underlying rates of growth (ie, "Big O"), you'll be forever pigeon-holed as a lightweight "webdev" forever, even if you have the programming chops required to build complex, reliable, and useful software.

Plus, they get really interesting the more you study them, and the math behind them.

> You write this, but then you go on to mention job interviews, which are becoming more and more algorithmic each passing year.

It's been the opposite experience for me in SF, actually. More startups are realizing that they want people who can build good products quickly, and with more people coming from non-CS backgrounds, they'd rather test for that than see if they can whiteboard a breadth-first search.

I took enough CS coursework to learn the stuff you mentioned, but I've worked with a number of developers who don't know any CS theory. Several of them are stronger engineers than me and have had very successful careers, and I'd rather work with someone who can communicate well and solve hard problems than someone who's read through CLRS.

I agree that for most developer roles most of these are definitely not necessary. I do know from personal experience that learning things that are far removed from any of the regular projects you're working on can provide valuable insights. The thing with these projects is that it's really difficult to know what you don't know yet, and so implementing something that is far removed from your day-to-day workings can provide you with insights that might help you, even though it seems completely alien.

Also, these projects are intended for self-study. Building an entire product from top to bottom is indeed a very valuable skill, but hopefully one you learn on the job.

Actually the number of opportunities you have to build something from top to bottom are not that numerous. In my 30 years I can think of 4 non-trivial projects off the top of my head. In fact I often advise programmers to have a side project where they get to make all the decisions and see how it works (or doesn't). One of the side benefits is that it tends to make people much less "my way or the highway" at work because they have somewhere that they can express themselves fully.

I have been recommending side projects on a similar basis for a while. I usually emphasize learning under the condition of leisure rather than schedule pressure, to enhance focus on good design and allow for a depth-first learning style.

Those kinds of projects are valuable not because of any significant chance of having to do something similar professionally, but because doing them gives you a fuller and more mature mental model for programming. Doing the larger projects listed will give you deep understanding of the stack (compiler/programming language, operating system, network protocols etc) you are interacting with every day. Especially non-trivial bugs and performance issues tend to test this understanding, and if you go through those kinds of experiences, you will be up for the challenge.

(I have personally done a toy HTTP server, small compiler, neural network, etc. and will be forever grateful I did so)

From the list I think he wants to become a great computer scientist instead of a great programmer.

Most computer science degrees will go way beyond this in the theoretical aspects.

I would add bloom filters, and some math like Fourier transforms and bezier curves.

i have just completed that real project, the next thing is deployment. We will see if they will want to use it. As for learning: yes I learnt a little bit of everything, but that programming is not enough to be like you all. There is a difference between a programmer and a hacker. Programmers, I guess enjoy knowing everything. Hackers just want their thing done. I dont know when I will have time to checkmark that list, but understanding every little project developers publish on HN is not my goal.

Reply on news.ycombinator.com