lol not really, but I do find myself using a Java hashmaps and not knowing how hashing works, using a regex that was copied and pasted from google without understanding what it does, programming in java and not knowing how the GC algorithms work, or working with threads and not knowing the basics of OS schedulers, programming and not being proficient with bitwsie opperations... and the list goes on, at least that is my interpretation of a cargo cult "java" programmer.
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.
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?
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.
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.
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
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.
The difficult part for me is that I have to force myself to ask the questions that you talk about, it's definitely not intuitive for me and my first reaction is not to think about the different solutions a problem could have, like you said I can't break a problem into chunks, and this I think is essential to be a programmer.
These are things you can't do yet. The yet is the important part- never forget that.
I read somewhere above that you spend a lot of time fixing bugs. Congratulations! You're already a programmer!
To move onward and upward, the biggest thing you can do is change your mindset from "how do I make this problem go away?" to "what is causing this problem to happen?" At the end of the day, you'll still get those bugs fixed, but you'll have a deeper understanding of the things that led to them in the first place.
Once you know that, breaking things down and shuffling ideas becomes second nature.
Yes! thanks for mentioning that book I forgot about it but I plan on getting to it eventually, there's just so many things to learn, so many books...sometimes I feel overwhelmed.
You might also consider trying out Arch Linux. (www.archlinux.org)
I moved to Arch after a few years with Ubuntu and I love it. It's a little higher-level than Gentoo in that you don't have to make your own file system or compile your own kernel, but it is an educational experience in that you have to install anything you'd like to use. When the 15 minute install is complete, all you have is a bash prompt. Getting a GUI, the ability to print, wireless, etc is all up to you.
They give you a great package manager and they maintain an excellent Wiki that can walk you through almost any task. Arch taught me loads about configuration.
Then again, I did Gentoo back in the day too. It might take 4 days to complete the installation, but you sure will learn some things! :D
Perhaps try it inside a VM. Installing gentoo from scratch is a brilliant way to learn linux, but it's not so much "trial and error" as "trial by error" (message.)
If you do it in a VM or on a spare machine then you will have convenient access to web resources, which you will need :)
