How to become a better programmer

Rashomon · Post by **Rashomon** » Mon Jan 09, 2012 10:20 am

I want to get better at programming. I can write short programs in a handful of languages. I read about buzzwords like: design patterns; data structures; algorithms; functional programming. What is the right way to go?

I feel like an obvious response is: To get better, write more programs. Then at least, what are some things I should try to accomplish in the next program I write? (make it shorter? use some technique to be less confused or circuitous? etc)

gentinex · Post by **gentinex** » Mon Jan 09, 2012 3:48 pm

You should keep in mind that the "buzzwords" you hear about came up out of a motivation to solve specific problems. It's totally possible that you've written an elementary program to do something, and it's perfectly adequate for the problem you're trying to solve. Then you may not need to bring in any other sophisticated techniques to your program, and rather than make up ways to apply them to your current problem, you'd be better off from an educational point of view moving on to other problems for which you may actually end up needing more sophisticated techniques.

That being said, some of the most common questions that come up in practice around writing a program to solve a problem are:

(1) [Before writing a program] Is this a known problem? Have I written a solution to this or something related before, or has it already been extensively discussed within the programming community? This is where knowing material in, e.g., Design Patterns can be useful (at least if you're writing object-oriented code). From the algorithms side, the second half of The Algorithm Design Manual has a catalog of problems that often come up in practice. And of course as a general rule, it doesn't hurt to search Google and Stack Overflow first.

(2) [After writing a program] How can I make this program run faster / use less space? (And related to this: If I've written a program that works fine for small input sets, does it scale well to much larger input sets?) This is where a good understanding of algorithms comes into play. Introduction to Algorithms is one of the standard introductory texts. You may also like UVa Online Judge as a source of algorithms problems, as well as a place to submit and get your own code evaluated online for speed and correctness.

(3) [After writing a program] Now that I've written a program to solve a problem, how can I modify the program to solve an extension of this problem, or a slightly different problem? Do I need to completely refactor the program's code, or could I have written the original program in such a way that I need to make little or no modification to the original program to extend its solution? Along with Design Patterns mentioned above, Mark Joshi's C++ Design Patterns and Derivatives Pricing has a number of good examples of how this question comes up in practice in derivatives pricing.

(4) [After writing a program] Did I write this program in a way that's easy for people to understand? Not just others, but also myself, if I look at this code weeks or months later after not having dealt with it for a while, and it's not fresh in my mind anymore? For this, Code Complete is a good place to start.

Steve Castle · Post by **Steve Castle** » Mon Jan 09, 2012 5:53 pm

SICP - The standard for do-it-yourself

Although I took some intro-level computer science classes, I'm mostly self taught in programming. I found SICP to be equivalent to some intermediate level Comp Sci curriculum friends were learning.

Give it a shot, it was mentioned to me multiple times by other such diy-ers.

Praetorian · Post by **Praetorian** » Mon Jan 09, 2012 6:50 pm

Good coding is all about design and how to name things. In my opinion the best way to get better is to miserably fail. Write more and more complex programs. You will end up with a complex system, that is not manageable by your skillset any more. Then rewrite from scratch. The second attempt will be much better and you will learn a lot.

The second best way seems to be reading source code from experienced people. Check out your favorite open source software and try to understand parts of it. Studying source code from experienced programmers is a good way to see how to structure programs. What's the typical method/function length? Why is highly optimized code often hard to understand?

Hope that gave you some inspiration.

ivedtara · Post by **ivedtara** » Thu Jan 12, 2012 7:35 pm

The key to become a good programmer is practice. The more you do it, the better you get. I learned it this way. Try writing at least 1000 lines of code per day. Write your design in a paper and define a process. The more systematic you are the better.

Hansi · Post by **Hansi** » Fri Jan 13, 2012 12:37 am

Measuring code in lines per day is a sure way to be bad at programming.

sv507 · Post by **sv507** » Fri Jan 13, 2012 12:40 am

I would say it is practise, working on big programs and working with good programmers!

for small programs, global variables, error handling naming conventions etc,etc don't come up. its only when you are dealing with a large program that any of these things matter. If all you need to write is small programs I would question whether you would be better off improving something else than your programming

The one thing perhaps you could do ( if you don't already) is to learn to use libraries

HankScorpio · Post by **HankScorpio** » Fri Jan 13, 2012 3:07 am

1. Programming is not a spectator sport. You have to cut lots of code. It will take time to improve.

2. Learn at least a couple of languages and learn them well. Learn their libraries. It always amazes me how many people regard themselves as competent C++ programmers but couldn't code their way out of a paper bag.

3. Learn some basic CompSci (data structures and algos).

4. Design. Think seriously hard about the problem you are trying to solve. These days, any idiot with an editor is a programmer.

5. Read, understand and try to modify code that others have written. There's plenty on the interweb.

6. Read. (books / websites, etc.)

7. Get yourself a mentor who really knows their stuff.

8. Do a course taught by a professional programmer, not a professional instructor. These are hard to come by, so consider yourself lucky if you can find one.

9. Be humble. Do not write code to impress yourself (and/or others). Try to write clear code, but not necessarily beautiful code. Do not try to shoehorn things into your design that are unnecessary or just plain wrong (i.e., I gotta use this design pattern because it is da bollocks).

10. Work on some projects that really interest you. Don't forget to have some fun! Beer

righttrader · Post by **righttrader** » Fri Jan 13, 2012 4:03 am

Look into test driven development. When you write tests first, it makes it more difficult to write poor code, guides you in the design, and gives you a safety net when you need to refactor.

jslade · Post by **jslade** » Mon Jan 16, 2012 10:49 am

"I feel like an obvious response is: To get better, write more programs"

One of the greatest olympic lifters in the world, Norb Schemansky was once asked by a skinny guy who to improve his numbers on the pressing exercise. "Fucking press!"

Being a "better programmer" is not like being a better golfer. It's more like being a better Ninja. Some Ninjas are good at poison darts. Others are good at concealment. Still others are good at using the kung-fu grip. Some Ninjas are fakers who read a ninja book. It's not like one Ninja can kick the other one's ass at all times, making him the better Ninja; only under certain circumstances.

Similarly, programmers can have all kinds of strengths and weaknesses.

Everyone has given good recommendations, but you have to figure out what kinds of problems you want to solve, and learn how to solve them. Do you want to make a fast networky thing? Web reporting thing? Numerics thing? Once you've solved a problem, optimize the solution (speed, conciseness, whatever). Then imagine you're a pointy headed manager who wants a new feature which completely breaks the paradigm. Do your refactor. Wash, rinse, repeat. That's what most industry programming is like, so get used to it.

At that point you can look into functional programming (if you're not already using it) or design patterns or whatever. If you used test based development, you'll see the utility in that. And the weaknesses.

Another thing to consider: solo versus team driven programming can be very different. Maybe modding up or extending someone's open source code, then going through the refactor exercise above would simulate team programming for you.

I'll never be a good paradigm guy, though on most days I'm vaguely functional; breaking things down into tiny elementary particles that a retard (or, me, a year later) can understand. I'm really a duct tape programmer.