3 ms·

I would suggest learning algorithms and data structures. I know that is suggested a lot, but I did not realize how little I knew until I studied these things. A

by 16s 16y ago

I would suggest learning algorithms and data structures. I know that is suggested a lot, but I did not realize how little I knew until I studied these things. And I think that is part of what makes good programmers stand out as these things apply to all languages. I then looked at my primary programming language (C++) differently. I wasn't just always using vectors any longer. I knew when to use them and when to use a queue or stack or hash. In short, studying algorithms and data structures and then applying what I studied in C++ made me a better programmer.

elblanco 16y ago
As someone with a CS background who has worked with several very talented self-taught programmers in the past I can echo this. Even if they knew a particular language or environment better than I did, I could usually write faster or more efficient code simply because of my deeper knowledge of data structures. One in particular comes to mind, I was working a temp job during my 3rd year at college with a very talented friend who was self-taught. He had written a rather brilliant dynamic reporting system for a very large e-commerce site in Perl, allowing the management to interactively drill down into recent sales and inventory activity. It worked fine for a few years until the volume of data became very large. Try as he might he couldn't get the software to be performant any longer and had to resort to a 10-11 hour batch crunch every night with the output dumped out to static HTML files for the mgmt to review. Finally one night, the process failed -- out of memory. Throwing more hardware at it only bought another few days. A dive into his code (most of which was really quite well done) turned up the following: he was using Perl hashes everywhere to operate on the data because they made the code easy to read and convenient to write and maintain. I rewrote many of the particularly inefficient parts to use arrays over a few weeks and suddenly, the entire batch took 10 minutes to run! A few more tweaks and we turned it off of batch mode and back into full interactive mode. Mgmt never had to wait more than a minute or two to return back a report of a huge amount of data. The key of course was that he simply didn't understand how much overhead the associative arrays created because he didn't understand the data-structures involved. He had simply relied on the magic of the language to do that work for him. A few days spent with http://blob.perl.org/tpc/1998/Perl_Language_and_Modules/Perl%20Illustrated/ http://blob.perl.org/tpc/1998/Perl_Language_and_Modules/Perl... and he never made that mistake again.

by 16s 16y ago

elblanco 16y ago

As someone with a CS background who has worked with several very talented self-taught programmers in the past I can echo this. Even if they knew a particular language or environment better than I did, I could usually write faster or more efficient code simply because of my deeper knowledge of data structures. One in particular comes to mind, I was working a temp job during my 3rd year at college with a very talented friend who was self-taught. He had written a rather brilliant dynamic reporting system for a very large e-commerce site in Perl, allowing the management to interactively drill down into recent sales and inventory activity. It worked fine for a few years until the volume of data became very large. Try as he might he couldn't get the software to be performant any longer and had to resort to a 10-11 hour batch crunch every night with the output dumped out to static HTML files for the mgmt to review. Finally one night, the process failed -- out of memory. Throwing more hardware at it only bought another few days. A dive into his code (most of which was really quite well done) turned up the following: he was using Perl hashes everywhere to operate on the data because they made the code easy to read and convenient to write and maintain. I rewrote many of the particularly inefficient parts to use arrays over a few weeks and suddenly, the entire batch took 10 minutes to run! A few more tweaks and we turned it off of batch mode and back into full interactive mode. Mgmt never had to wait more than a minute or two to return back a report of a huge amount of data. The key of course was that he simply didn't understand how much overhead the associative arrays created because he didn't understand the data-structures involved. He had simply relied on the magic of the language to do that work for him. A few days spent with http://blob.perl.org/tpc/1998/Perl_Language_and_Modules/Perl%20Illustrated/ http://blob.perl.org/tpc/1998/Perl_Language_and_Modules/Perl... and he never made that mistake again.