Forums  > University  > How to become a better programmer  
Page 1 of 2Goto to page: [1], 2 Next
Display using:  


Total Posts: 215
Joined: Mar 2011
Posted: 2012-01-09 10:20
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)

"My hands are small, I know, but they're not yours, they are my own. And they're not yours, they are my own." ~ Jewel


Total Posts: 82
Joined: May 2006
Posted: 2012-01-09 15:48
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

Total Posts: 306
Joined: Sep 2010
Posted: 2012-01-09 17:53
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.

in the words of one such quant ‘were on the whole either less quanted or not quanted at all’.


Total Posts: 225
Joined: Apr 2009
Posted: 2012-01-09 18:50
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.


Total Posts: 3
Joined: Jan 2012
Posted: 2012-01-12 19:35
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.

Stock Market Simulator


Total Posts: 303
Joined: Mar 2010
Posted: 2012-01-13 00:37
Measuring code in lines per day is a sure way to be bad at programming.


Total Posts: 165
Joined: Aug 2010
Posted: 2012-01-13 00:40
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


Total Posts: 481
Joined: Mar 2007
Posted: 2012-01-13 03:07
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


Total Posts: 9
Joined: Mar 2006
Posted: 2012-01-13 04:03
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.


Total Posts: 1245
Joined: Feb 2007
Posted: 2012-01-16 10:49
"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.

"Learning, n. The kind of ignorance distinguishing the studious."

Founding Member

Total Posts: 8372
Joined: Mar 2004
Posted: 2012-01-16 13:32
I agree 100% with jslade. "Good programmer" requires further specification. Just as "good athlete" is not enough to make you very useful in professional sports. Okay so you are "athletic". Does that mean that you'll be good at professional football, or skiing, or swimming, or gymnastics? No it doesn't. It's sort of a requirement, but that's about it. The equivalent for a professional programmer is that he or she (or heshe... a corner case) has to be smart. You can get a certain amount with training, but at some point, you will hit a wall (a fairly low one)

That being said, to continue with jslade's analogy, there are different disciplines in programming (just as there are in ninjutsu, and in sports). And in fact, some of these disciplines are diametric. Being good at the one is almost guarantee that you won't be good at the other. Being a world class marathon runner will prett much prevent you from ever becoming a good sumo wrestler.

Of course, disciplines aside, for almost everyone what has already been said applies: the more you train, generally the better. However, just as the best professional sports players train intelligently, you have to learn intelligently. Just lifting weights for 12 hours a day will not gain you anything. Accordingly, just reading lots and lots of code and writing lots of code all willy nilly will do nothing for you, unless there's some kind of plan and overarching design to your studies.

So the appropriate question to ask is: what kind of programmer so you want to be?

The Figs Protocol.


Total Posts: 80
Joined: Jul 2007
Posted: 2012-01-16 15:27
after the basics, if you can increase your curiosity and creativity that would lead to better (or at least more fun) programming.


Total Posts: 41
Joined: Apr 2010
Posted: 2012-01-20 21:56
If you want an advantage over the expert C++ coders , then learn about parallel computing. Don't spend time searching for deadlocks in pthread code. Instead, keep it high-level with OpenMP(I) and ZeroMQ. Building distributed systems that scales to 10,000s of processes, and handles node failure will be a welcomed change to worrying about cache thrashing.

Don't learn about OO design patterns:

"Object-oriented programming is eliminated entirely from the introductory curriculum, because it is both anti-modular and anti-parallel by its very nature, and hence unsuitable for a modern CS curriculum. "

Basic Algorithms and data structures is essential, and you will need it to get a job.

Embrace functional programming, and make Haskell your get-shit-done language.

Build stuff, and contribute to open-source projects.


Total Posts: 215
Joined: Mar 2011
Posted: 2012-01-24 00:20
Thanks to everyone who responded so far. It's great to see so many different opinions.

Jslade and FDAX said I should clarify what I mean by "good programmer" so I'll endeavour to do that. Although, I'm not sure I know what skills are diametrically opposed or even partly opposed. I also don't necessarily know what the categories of skills are, or what's valued by whom in finance. That said:

What I'm asking is less about learning to write faster programs and more about learning to write big programs that make sense. I don't want to get lost in my own muck, and I want to be able to conceive large programs easier.

Right now I'm like the opposite of a six-sigma factory worker. If I wanted to write a trading system from scratch today, I would run around the yard like a maniac until I collapsed, having expended a lot of energy but accomplished little.

I imagine that if I were somehow...smarter, or better trained, that I would be able to build a bridge between what's in my head and what's happening on the hardware with less "wasted movement" (back to the ninjutsu metaphor for just that). Or, even if I couldn't build the whole bridge myself, I would (if smarter) be able to build the scaffolding and say where the concrete needs to go, although leaving the optimal installation of concrete up to someone else.

I should have used the "train smarter" metaphor in my original question. That is exactly what I'm asking how to do.

If that doesn't really explain my question, I'll try again. Thanks again to everyone who's answered.

"My hands are small, I know, but they're not yours, they are my own. And they're, not yours, they are my own." ~ Jewel


Total Posts: 1009
Joined: Jun 2004
Posted: 2012-01-24 01:15
different programming languages are tools in the box. the one thing that stuck with me from computer science (cuz it shure won't the proofs i did), is what my professor told me: programming is about managing complexity.
i back the others, get your 10,000 hours in. there is nothing wrong with running around the yard like a maniac until you collapse. your next go will be better. honestly, everyone writes requests like this (i find nothing wrong with yours) as if there is some answer key. there isn't. you've received some terrific responses.
if you are interested in writing a trading system (as you seem to suggest), go to interactive brokers and write to their api. write a spreader of some sort. it doesn't have to produce pnl, just work on a problem.

Too many people make decisions based on outcomes rather than process. -- Paul DePodesta


Total Posts: 215
Joined: Mar 2011
Posted: 2012-01-24 06:25

"My hands are small, I know, but they're not yours, they are my own. And they're, not yours, they are my own." ~ Jewel


Total Posts: 69
Joined: Dec 2005
Posted: 2012-01-27 19:57
I'm nowhere near as good as most people on this forum, but this is how I try and write the tools we work with:

“Code wants to be simple… I had to give up the idea that I had the perfect vision of the system to which the system had to conform. Instead, I had to accept that I was only the vehicle for the system expressing its own desire for simplicity. My vision could shape initial direction, and my attention to the desires of the code could affect how quickly and how well the system found its desired shape, but the system is riding me much more than I am riding the system.” – Kent Beck


Total Posts: 54
Joined: Apr 2007
Posted: 2012-09-29 00:10
You will learn a lot by writing something that is all yours, and of a non-trivial size. The problem is to try and find something that interests you enough to write programs in.

My way in to languages is writing games.

I learnt assembler that way as a kid, and my first non-trivial C++ program was a networked version of BattleZone. Quite the thing at work until Doom appeared a few months later. It taught me so much as I hacked my way around it.

Another good idea is to find authors who you can learn from. I personally find Gerald Weinberg a very good thing; he has a four volume series on software development and many other good books besides. He's good on the meta-cognition blah. Others may have recommendations too - I haven't found much else useful on programming in general, though you always get language-specific experts worth a go.

Another idea worth focusing on is being absolutely solid on handling exceptions and resource management. This realm is a real sheep-from-goats discriminator as far as programming experience goes. An aspect of this is trying to turn your head away from the natural tendency people have to be optimists - to focus on the successful path. Very good programmers naturally tend to focus on the other cases too. What if this fails? What if that fails? How can such things be catered for without mucking up the main structure of the program?

Yet another important theme is the realisation that any program's current form is a static solution to a problem in the real world, where everything is constantly in flux. Your program will need to evolve, and you need to tailor your process and abstractions appropriately. Not every problem domain is the same here. If you are writing a computer game it's fire-and-forget. If you are writing a quant library then the library needs to stick around for many years, even if the code gets revisited/rewritten many times - so things like testing/validation get really important.

Finally, by asking everyone here you've taken the most important step of all. Because the most important way you get to become a better programmer is constantly assessing what works and what doesn't - turning your analytical skills on the way you work itself. Meta-cognition is a somewhat fancy way of putting the idea. If it's a new process, do a quick retrospective every time something is delivered. That kind of thing.

Good luck.

Down pokey quaint streets in Cambridge / Cycles our distant spastic heritage


Total Posts: 1677
Joined: Aug 2005
Posted: 2012-09-29 02:22

Nice thread!  I'm glad this one got bumped up to the top, I missed it last time around. 

I think there's tons of great advice here, probably all you need.  The Skeina book is one of my all-time favorites, it's really great.  Hank, JSlade, FDax - all great advice.  You could do worse than reading a few good blogs like JoelOnSoftware, or some of Steve Yegge's stuff as well.

It's easy to get lost in all of the possibilities, but keep in mind: The more abstract it is, the more likely you probably don't need it.  Trying to study something like design patterns before ever writing a large implementation is like trying to learn musical theory before touching a piano - maybe you can do it, but what's the point?

I've run into coders freaking out about writing things perfectly, and ultimately I'm sure their code is beautifully immaculate, but I seem to encounter them working on the same systems for really long times.  I think the best way to write the code well is to re-write the code several times. 


the only reason it would be easier to program in C is that you can't easily express complex problems in C, so you don't. -comp.lang.lisp


Total Posts: 215
Joined: Mar 2011
Posted: 2018-08-12 02:16
Answering my own question: compilers, operating systems, and network programming. Not SICP, FP, OOP, or monads.

For me, I needed to really understand what a file is (like, *where* is it?), how parsing works, what a process is, why lines are read one at a time (vs slurped), what memory is, what a socket is, what a pipe is, ...., ---- putting more meat on the bones of the abstractions rather than serving up more analogies ----- to make better progress in "I want X to happen in the real world, now what do I need to program to do that?". This also helps me be level-headed in what kinds of outcomes I want from the program, whereas "apps" and "databases" often gain a mystique that obscures what can and can't be done on the computer.

MJ's book (r.i.p.) and "Ruminations on C++" stood the test of time about code rewriting more than any "school of thought" regarding how to interface with other programmers. And new languages have never done much for me. (Huge time investment, can't achieve much more.) Learning C (read K&R), UNIX (K&P*), and reading many many man pages (maybe start with or even, as well as enough of the history of specific corporations (ok, corporatioN) and the technology of its time (line printers, dumb video terminals), which led to so many seemingly arbitrary choices and vocabulary which are nevertheless here to stay. Try to set up a LAMP stack or static apache for a friend's website, you would encounter so many pieces and technologies (systemd, /etc/, /proc, postgres, chmod) which would otherwise seem really circuitous and arbitrary, if you don't know a bit of computer history. (Using a tool that's already there is easier and less likely to break than the tool you craft for yourself---unless you're an expert already or set aside loads of time---therefore everythign was built on the good stuff that came before.)

Plus, you need to know a lot of arbitrary stuff to link and compile a program, if you want to move outside ruby/R/python/javascript or just want to build a program you found on the internet (even github). Check out Karl Broman's "minimal make" series to get started easy---never try to read gdb or make manuals. has a lot of "why make this thing and why make it like this?" , and the 500lines one is obviously made to be digestible. This is the approach Andy Aiken takes in his compilers course (free online): hack on a small, UN-popular conceptual system *designed for teaching* --- small enough to wrap your mind around the whole thing (Rob Pike alludes to this on twitter, as do many others in reference to creativity and productivity). is hit or miss but has some really excellent stuff.

playing around with a few of the most important Amazon services and its cli (or linode / digital ocean ... and mailgun, very nice cli) -- probably just S3 honestly --- and you can use ssh newsdforg or (if you're university affiliated) WRDS for remote (headless) terminal using.

curl, rsync, ssh, and nc were important gateway tools. pick mercurial over git and start logging and diff'ing your work, even if it's just word processing.

For me looking at some graphical packages (there is a good PNM chapter in Real World Haskell) was helpful because, I really don't care about BigInt vs SmallFloat vs utf-8 string vs CJK string (ok, when it bites me in the ass I have to care). But images, sound, and video are inherently much more interesting than numbers and, whichever way the banking world goes, human beings are going to audiovisual and want to store+transmit+search+edit those things digitally. Plus it's much easier to invent Boomerang than compete with Assistant Professors for who can make the most complicated sounding securities pricing engine.

There always seem to be new languages people want to talk about and I never seem to be glad that I put in effort to it.

* It's shocking, and perhaps a bit like in academic mathematics---if you read only a narrow cluster of tippy-top thinkers (in math, look at Zariski's descendants; in programming, look at A+W+K, K+R, K+P, ...), you actually end up doing quite well. Or maybe it's that after a chorus of many voices, I appreciated the clean writing and mature perspective.


Total Posts: 70
Joined: Apr 2014
Posted: 2018-08-20 02:54
"Answering my own question: compilers, operating systems, and network programming. Not SICP, FP, OOP, or monads."
If your question had been about better intellectual masturbation techniques, however...

I think an understanding of why relational databases are designed and implemented the way they are is quite useful, too.


Total Posts: 415
Joined: Mar 2018
Posted: 2018-08-20 11:07
I picked a top universities website, worked out what the core CS modules were, and the read the first text of each.


Total Posts: 486
Joined: Jan 2015
Posted: 2018-08-20 21:08
Honestly, the answer to this question may just be go work for Google for a year.

Finance as a whole has some pretty horrendous habits, beliefs and practices when it comes to the discipline of software engineering. Personally I blame the tendency of our industry to always be fighting fires. A lot of shoddy hacks get rushed out, merged into git-master, then completely forgotten about until the brittle code fails in prod spectacularly six months down the line. Devs play second-fiddle to "front-office", who are always pushing for new revenue-generating feature. So code rarely gets refactored or cleaned up

Another issue is that products requirements are often vague and underspecified. The PMs don't know exactly what they need until the researchers run the analytics. But the researchers can't run analytics until the framework gets built. But the framework can't built until the PM can outline to the devs what's needed.

For all its warts, Silicon Valley does tends to be ahead of the curve in this area.

EDIT: s/SV/Silicon Valley/

Good questions outrank easy answers. -Paul Samuelson


Total Posts: 459
Joined: Jul 2008
Posted: 2018-08-21 00:19
Yeah, Google is a fantastic work environment for software developers. But if you go there for 1 year, half of this time will be spent learning the ropes. Two years is more likely to teach you something.


Total Posts: 415
Joined: Mar 2018
Posted: 2018-08-21 11:03
@EspressLover Whats SV?
Previous Thread :: Next Thread 
Page 1 of 2Goto to page: [1], 2 Next