Hacker News new | ask | show | jobs
by edw519 5594 days ago
I lack the fundamentals of Computer Science, the things every programmer should know: Algo's, Data Structures, Operating Systems an understanding of compilers and being profficient with linux.

Relax. That's true for 99% of all programmers.

Eventually I plan on going back to a real University and getting a CS degree

Absolutely not necessary. You will probably learn more building anything than learning it in school.

I'm starting to think I may have a learning dissability

Maybe you do, maybe you don't. Just because the rest of the world is quick to diagnose everything doesn't mean you have to.

I have come to accept that I'm really not smart. I'm slow, forgetfull, concepts never seem to stick

Your performance shortcomings could be for many reasons. Being "really not smart" is the least likely of any of them. They are much more likely caused by other things like uninteresting work, poor environment, personal issues, nasty people, or even health issues. Whether you're "smart" or not, thinking that your aren't is pretty much a guarantee for failure. Please don't do that.

I have started going through the basic Algo's and Data structures again with a basic Java book about algorithms

Sorry to say, but you're just doing it the hardest way you can. You don't need a book; you need a project. I (like many others here, I'm sure) have achieved much, but have always had difficulty learning from books and theory. It's hard! You need to find work where the things you need to learn will be required. Funny how quickly and easily you'll find a way to learn them when you actually need them. I'm not sure how you should go about finding such work, but I imagine many responses in this thread do.

I just don't want to be a cargo cult programmer anymore.

Good. That makes your normal.

And finally trying to memorise all those linux commands I ALWAYS forget.

Then use less commands. I have never used more that 10% of what was available in any technology and I always got the job done.

I have to force myself

This is the most important thing you have said.

Have you ever actually enjoyed building stuff? Have you ever gotten really "jazzed" about the project you were working on? Have you ever leapt up out of your seat and danced when you got something working?

If you answered "yes" to any of these questions, then you really do have the passion to be a programmer. Stop selling yourself short and listen to the great advice you're sure to get here from fellow Hacker News'ers.

If you answered "yes" to none of these questions, then there's no sense for you to continue wasting your time searching for the passion. If you haven't experienced any by now, then you probably never will. No one should have to "force themself" to love what they're doing. Find something else.

P.S. Sorry about your father. Loss affects each of us differently. And don't worry about your English. It's fine. Please give yourself your best chance to succeed and keep us posted. Best wishes.

4 comments

While I agree with virtually of what you said, the following statement I do disagree with: You don't need a book; you need a project. (in reference to laerning algo and data structures).

There are too many non-trivial algorithms that you are just likely to not rediscover. Many are the result of some of the best minds in various fields over decades. Dynamic programming isn't something that will likely just show up in your code w/o knowing about it (it may, but probably among the more skilled). Balanced trees almost certainly won't. Heck, even standard binary trees probably aren't obvious to someone who hasn't thought about the problem.

And definitely not things like the Fast Fourier Transform or stability of Gaussian elimination, etc...

I'd at least recommend spending a weekend reading a pragmatic algorithms book like Sedgewick, http://algs4.cs.princeton.edu/home/Algs4Flyer.pdf.

Have a project that you're working on too, but don't do it without also learning algorithms and data structures more formally. Otherwise you'll end up finding a lot of poor solutions for problems that have known good solutions.

I'll second the recommendation for Sedgewick's book. The pictures in there are so good that you hardly even need the words, and I successfully learned algorithms from it.

The other algorithms book I would recommend is Steven Skiena's "Algorithm Design Manual", which has less depth than Sedgewick or Cormen et al., but is very well written and has a chapter that's a field guide to most algorithmic problems you commonly run into, and how to solve them. Looking through this algorithmic bestiary is well worth the time. The rest of the book is also good.

I have a smart co-worker who also likes Skiena's Algorithm Design Manual. I found that book to fluffy, though. But then I enjoy books like "Combinatorial Optimization - Polyhedra and Efficiency" by Alexander Schrijver.

(Not a beginner's book, but it has anything you ever wanted to know about P and NP.)

Yes I agree that there are algorithms that I would have never known about without hitting the books, I came across this recently. I was trying to solve one of ITA software hiring puzzles(Just for fun somebody mentioned it in SO) the "instant search" puzzle, I could never find a solution to the problem I spent days playing with it until I decided to give up, a few months later I found out about "Suffix trees" from wikipedia and found an implementation in Java, I'm still trying to understand about how it works but I used it in the ITA puzzle and the thing actually works and its freaking FAST!.
Was "not knowing" that algorithm preventing you from doing anything before you actually found it? If your goal is to learn for learning sake, then fine go buy some books and learn. If on the other hand, you are trying to build stuff, then by all means start building stuff and learn what you need along the way.
What if the goal is getting hired at ITA Software?
Any suggestions on a book describing algorithms useful for the ITA-style problems? I looked at those problems a while back (just out of curiosity, not to get a job) and realized that I didn't really know how to solve those optimization / approximate-solution-to-NP-complete problems. Is there an AI text, maybe, that would fill this gap in my knowledge?
There are too many non-trivial algorithms that you are just likely to not rediscover.

I agree, but would also (respectfully) ask, "So what?"

OP needs to learn to crawl, then walk, then run. And he seems like a great candidate to do all 3.

Even so, even if he works 30 years having a ball delivering great product to satisfied customers, he may never encounter "Fast Fourier Transform" or "stability of Gaussian elimination".

I think of "advanced" subjects like dynamic programming, functional programming, and even algorithms and low-level code like mountaineers think about Mount Fuji: A coward never climbs it. A fool climbs it more than once.

I haven't written a b-tree traversal in 10 years and hope I never do again. I'd rather stand on the shoulders of new giants and get other cool stuff done.

OP's not there yet. Give him time.

Also, he needs a reason to learn this stuff. "Because I need it for this project" is a better reason then "Because everybody else is doing it and I think I need to, too".

"Because I need it for this thing I'm doing" is the only motivation that ever works for me. That said, taking that weekend to read the book to know what might actually be available for that thing you're doing is also a good thing to do periodically.
Let me echo VivTech. You dont need to memorize all the algorithms and variants, but you do need to know what is there, so that sometime later when you need a solution, you know where to look. Also you need to dive deeply into some aspect such as sort or lists so that you get a good feel for big O notation and analysis. You may never implement a sort or tree algorithm, but is good to know which one to pick when you need it.

I've never had to use FFT, but sorts, trees, and graph traversal are pretty common.

My introduction to algorithms oh so many moons ago was Sedgewick when it was a single volume in C(?). I found it easy to read and use.

The problem is that there are a lot of projects you can go into as a cargo cult programmer, do an OK job, and come out more or less still a cargo cult programmer - you can build a pretty good web site by iterating on tutorials and copy-and-pasted snippets.

If you follow the guidance of, say, SICP, there're "projects" geared to expand your abilities.

So, I agree, but look for the right project - don't learn a framework, learn to do something.

>> There are too many non-trivial algorithms that you are just likely to not rediscover.

> I agree, but would also (respectfully) ask, "So what?"

Well, if you're trying to sort big arrays with bubblesort, you may have to wait a long time...

http://warp.povusers.org/grrr/bubblesort_eng.html

>Teaching bubble sort as some kind of "basic sorting algorithm" has real-life negative consequences. This is a real-life example: this is a piece of code in the gnu flex program:

    /* We sort the states in sns so we
     * can compare it to oldsns quickly.
     * We use bubble because there probably
     * aren't very many states.
     */
    bubble (sns, numstates);
>There's absolutely no rational reason why bubble sort was used here instead of insertion sort. Bubble sort can only be slower, and it's not in any way easier to implement.
Actually for small values of n, an n^2 sort can be quicker than an nlogn sort, depending on how it is implemented.
Yeah, hence insertion sort (the best n^2 sorter) is used to speed up quick-sort. It's insane to think of using bubble sort for the same task. (And for n=2, you don't need a sorting algorithm.)
I don't know about the OP or anyone else, but I've always found it easier to learn about a fundamental algorithm when I've got a real problem to use it on, in a real project that's in front of me. The problem isn't one of rediscovery, it's knowing that a solution exists in the first place.
http://en.wikipedia.org/wiki/List_of_algorithms

This site is probably has a more extensive list, but it seems to be down right now: http://www.itl.nist.gov/div897/sqg/dads/

Google's cache of it is only 2 days old, so it's probably temporary.

I would argue, both. Pick up a project you find interesting to drive the directions of your learning, and supplement it with book-learning as you go.

For instance, if you wanted to do some game programming for iOS/Android, pick up books that focus on algorithms appropriate to that context, not just a general book of algorithms.

That particular book is listed as being released on March 21 2011. Is there something I'm missing or are you recommending his earlier books on Algorithms in C?
Any of his algorithms books. I believe he has C, Java, and Pascal. But unless you need the book right now, I'd be inclined to wait a few weeks to get this latest edition.
Thanks for your words.

Most of the stuff I've been doing for the last year or so is bug fixing as I have found that I'm better at finding and fixing bugs and even adding stuff to code that is already written and I really get excited when I get something working, It just takes a very long time for me to develop something from scratch mostly because I'm never comfortable with my code and I end up re writing everything and thus never getting anywhere.

> I'm never comfortable with my code

I've been doing this professionally for around 12 years (and for the record, no CS degree -- my degree was technical communication with a CS emphasis) and to be honest, I'm still not very comfortable with a lot of my code either.

I generally think that if you don't look at code you wrote six months ago and think "Dear god, what is this crap?" it's a sign you're not learning enough as a programmer, so I wouldn't say that being uncomfortable with your code is a bad thing by any means. The key thing in my mind is if you're always looking to improve.

I'm never happy with my code either. I seem to write parts of it over and over because it just doesn't look or feel right.

I believe that's extremely common and from my experience, most of the really good programmers that I've known do it.

My personal take is that it means you have some semblance of taste, which I think is essential. Otherwise you end up like the people who think "temp1", "temp2", and "temp3" are perfectly fine variable names and who don't think whitespace is an important concern when programming.

There's a video of Ira Glass floating around that I was sending to all of my friends a few years ago, on the nature of creativity and self-criticism.

One of the great points he made was that if you ever finish a project of any kind and think it's really great -- just perfect, and just what you wanted to achieve -- it's time to hang up your hat and go home, because you're done. You aren't going to improve from there, and you won't learn anything new (though there's always more to learn, in any field).

The harsh self-critique just means that your skills still don't measure up to your taste, and if you find yourself doing great without much trouble, that just means you have really poor taste.

Thanks for your words.

Your welcome. Posts like yours often help other people as well, so thank you too.

I'm never comfortable with my code

Neither am I. I don't think that feeling ever goes away. Whenever I look at something I wrote last year, I think 2 things: "I can't believe I wrote this," and "I hope no one else ever sees it with my name on it."

It just takes a very long time for me to develop something from scratch

Then don't write anything from scratch. I have about 2 dozen "base programs". Whenever I need to develop something new, I grab the closest one, "save as" something else and get to work. I'm always tweaking, improving, and adding to those base programs, kinda like automating my own continuous improvement. I'm too busy focusing on my user's dilemma and the task at hand to waste valuable brain space memorizing syntax. Every little boost helps. We all do it.

I have about 2 dozen "base programs". Whenever I need to develop something new, I grab the closest one, "save as" something else and get to work.

That's an interesting method. Could you give an example of those 'base programs'—what are they, how long, how much do they do, etc.

   1. basic form
   2. form with multi-valued lines
   3. form with data set (multi-valued parent/children)
   4. form with grid
   5. tabbed form
   6. form with skins
   7. batch (loop thru something)
   8. batch update selected records in a table
   9. batch dump table records --> .txt or .xml file
  10. batch .txt or .xml file --> update table records
  11. batch file --> create & populate database table
  12. cut an email
  13. traverse internal tree function
  14. traverse file index(es)
  15. build html from parameters
  16. build javascript from parameters
  17. build .pdf from parameters
  18. build hp esc sequences from parameters
  19. benchmark a process
  20. how does that syntax work?
  21. which way is faster?
  22. batch string parser
  23. batch source code search
  24. batch source code changer
I have more, but I don't have time to find them right now. OK, I think I'll add:

  25. batch parse source code, identify routine for reuse
a lot of these sound like they should be libraries.
I found this presentation helpful, you might, too: http://rubyconf2008.confreaks.com/fear-of-programming.html
Relax. That's true for 99% of all programmers.

I just died a little...

http://thedailywtf.com/

Look around a bit, you'll die some more. No, a lot more.

I've got a project for you:

In terms of algorithms and data structures, this is about the best that you can get: Given a list of 10k unordered sets of 5 letters (let's say a .txt file, 5 letters per line), print what set occurs most often.

It's much more challenging than you'd expect, and my suggestion would be to implement any sorting that you wish to do, yourself. (not use Arrays.sort, or any library like that).

It's a problem that I was given in highschool, and was pretty exciting.

For an example data set, my suggestion would be to get a random character generator printing 5 characters per link, 10k times.

Would this work as a solution:

i) convert the array of arrays of chars into an array of arrays of integers (the letters ASCII values).

ii) create a new integer array containing the sum of the cubes of each ASCII value for each entry

iii) create an empty hash table and fill it with (key|value) pairs containing (integer|number of occurrences) by looping through the previous array

iv) sort the hash table by 'number of occurrences' and store the biggest (key|value) pair

v) look for the first match in the original array to find which chars it represents

Efficient/correct or not?

Why not just use a tree?