I’m a researcher in programming languages, and I’ve dabbled a little in discrete math and algorithms research. Though my advice may be a little slanted, “algorithmic insight” is what I’m most expert in. Perhaps, then, the following is right.
If you “blank” on programming, but already know system administration and shell scripts, then the “lack” you’re describing is probably pretty small.
I strongly believe that what might look like “algorithmic insight” is mostly the product of obsessively picking apart designs and implementations—not just computer programs, but any engineered mechanism. It’s a great habit to inculcate, and (I think) leads naturally to gradually understanding how everything works.
I bet, though, that you could massively boost your own algorithmic insight by the following program of reading and practice:
First learn (if you haven’t already) a worthwhile programming language. C has a certain simple charm, but most industry-standard languages are pretty horrible. Java is mediocre, but limiting. I suggest starting with Python, and learning C, Racket, and either Haskell or OCaml. (Again, though—I’m a PL researcher, so this is possibly biased.)
Actively, carefully read CLRS. It’s detailed, doesn’t assume much prior knowledge, and covers 98% of the algorithms any good programmer ever uses outside specialties like graphics or scientific coding. By “actively read”, I mean to actually do some of its exercises, and actually implement some of its algorithms. Rephrase its ideas in your own words; stop and review whenever any idea is unclear.
Work some of the exercises on Project Euler or SPOJ. These are excellent sources of small, algorithmically-rich problems. You can do them in essentially any language you like, and they give good feedback.
As a sysadmin, you’ve probably already learned some of the pragmatics of managing complex systems. Other than algorithms, as above, and the most core-basic ideas about computers, good programming is about managing system complexity. Thus, implement at least a full program or two that you’d like to see exist. Games and toys are nice, as they’re rich with creative opportunities, and so the work you’re duplicating isn’t so irritating. Demand of yourself the freedom to fiddle with and re-implement that program until the code feels clean—until it feels like solid mathematics, where every piece connects to every other piece for only sound, solid, logical reasons with fairly short descriptions.
I’d mix these activities all together. Learn algorithms and languages by implementing with them; learn the techniques of good implementation by implementing interesting algorithms and programs that you want to exist, and (eventually) solving problems with code.
fiddlemath originally sent this as a private message, and I suggested they post it publicly because it is an excellent comment! I might even do some of the stuff in it …
I’m a researcher in programming languages, and I’ve dabbled a little in discrete math and algorithms research. Though my advice may be a little slanted, “algorithmic insight” is what I’m most expert in. Perhaps, then, the following is right.
If you “blank” on programming, but already know system administration and shell scripts, then the “lack” you’re describing is probably pretty small.
I strongly believe that what might look like “algorithmic insight” is mostly the product of obsessively picking apart designs and implementations—not just computer programs, but any engineered mechanism. It’s a great habit to inculcate, and (I think) leads naturally to gradually understanding how everything works.
I bet, though, that you could massively boost your own algorithmic insight by the following program of reading and practice:
First learn (if you haven’t already) a worthwhile programming language. C has a certain simple charm, but most industry-standard languages are pretty horrible. Java is mediocre, but limiting. I suggest starting with Python, and learning C, Racket, and either Haskell or OCaml. (Again, though—I’m a PL researcher, so this is possibly biased.)
Actively, carefully read CLRS. It’s detailed, doesn’t assume much prior knowledge, and covers 98% of the algorithms any good programmer ever uses outside specialties like graphics or scientific coding. By “actively read”, I mean to actually do some of its exercises, and actually implement some of its algorithms. Rephrase its ideas in your own words; stop and review whenever any idea is unclear.
Work some of the exercises on Project Euler or SPOJ. These are excellent sources of small, algorithmically-rich problems. You can do them in essentially any language you like, and they give good feedback.
As a sysadmin, you’ve probably already learned some of the pragmatics of managing complex systems. Other than algorithms, as above, and the most core-basic ideas about computers, good programming is about managing system complexity. Thus, implement at least a full program or two that you’d like to see exist. Games and toys are nice, as they’re rich with creative opportunities, and so the work you’re duplicating isn’t so irritating. Demand of yourself the freedom to fiddle with and re-implement that program until the code feels clean—until it feels like solid mathematics, where every piece connects to every other piece for only sound, solid, logical reasons with fairly short descriptions.
I’d mix these activities all together. Learn algorithms and languages by implementing with them; learn the techniques of good implementation by implementing interesting algorithms and programs that you want to exist, and (eventually) solving problems with code.
fiddlemath originally sent this as a private message, and I suggested they post it publicly because it is an excellent comment! I might even do some of the stuff in it …