How to become a better programmer

FDAXHunter · Post by **FDAXHunter** » Mon Jan 16, 2012 1:32 pm

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?

ax · Post by ax » Mon Jan 16, 2012 3:27 pm

after the basics, if you can increase your curiosity and creativity that would lead to better (or at least more fun) programming.

h0h0 · Post by **h0h0** » Fri Jan 20, 2012 9:56 pm

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.

Rashomon · Post by **Rashomon** » Tue Jan 24, 2012 12:20 am

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.

apine · Post by **apine** » Tue Jan 24, 2012 1:15 am

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.

Rashomon · Post by **Rashomon** » Tue Jan 24, 2012 6:25 am

redacted

redox · Post by **redox** » Fri Jan 27, 2012 7:57 pm

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

http://c2.com/cgi/wiki?OnceAndOnlyOnce

arkestra · Post by **arkestra** » Sat Sep 29, 2012 12:10 am

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.

tristanreid · Post by **tristanreid** » Sat Sep 29, 2012 2:22 am

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.

-t.

Rashomon · Post by **Rashomon** » Sun Aug 12, 2018 2:16 am

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 datascienceatthecommandline.com? jvns.ca/zines? or even 9p.io?), 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.

aosabook.org 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).

tldp.org 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.