The Ultimate Code Kata
codinghorror.com
codinghorror.com
An odd example, since I'm pretty sure we've all got a lot better at typing without really trying.
I just did a test to find out, and it turns out that in the last fifteen years that I've spent not learning to type, I've gone from about 35 wpm to 81. Fifteen years ago, 81 wpm would have been a pretty impressive typing speed, but nowadays I guess it's pretty normal, since the whole world has got better at typing. It doesn't seem so long ago that people were still putting their typing speed on their resumes, but nowadays high-speed typing is taken for granted -- it's gone from being a skill to being a reflex, for most people.
I'm not sure about programming, though. I'm sure it's possible to get better without really trying, but really trying will get you there faster. I guess the real difference is that typing is an "easy" skill where you can reach the maximum reasonable level of competence quite easily (who really needs more than 60 wpm?), whereas programming is a "hard" skill where there's far more to learn than you can possibly fit into one lifetime.
That's a skill that's more on the same level as programming.
And getting started on a web site for myself. But that one will be considerably more visually oriented than most of the stuff I work on, so it's going to be a bit longer in coming. :)
Reminded me of an argument between 2 great billiards players, Willie Mosconi and Minnesota Fats. Willie was the best player in the world at the time, winner of many championships. Fats was a hustler who never won anything except money. Each vowed to kick the other's butt in a match. Of course, Willie kicked Fats's butt, to which Fats responded, "So what. If there was money on the table I would have won."
This article made me realize I am more like Fats than Willie. I have interviewed and worked with many great programmers, but hardly consider myself in their class. They may know 27 ways to sort data, but being like Fats, I only need to know one to get the job done (and take the money).
If there was a competition, they would kick my butt. But if a client had to get something done, I could hold my own against any of them.
The advice in each person's list was excellent. To become a better practitioner of the art and science of "programming". Which is not quite the same thing as "getting the job done".
A typical scenario I have seen over and over: Competitor A is doing B, so we have to do C. This means that we'll have to modify our app to get data x from source y and present it to certain people so they have what we need to compete. We're losing $10,000 per day by not doing this, so we need it ASAP. My solution is rarely optimal, sometimes clever, sometimes not, and often a hack. But it gets done quickly, it works, and it "does the job".
That makes me more like Fats. But since I still aspire to be more like Willie, I'll start doing a few more things on these lists.
Quite frankly, I hate "solutions" like that. I have spent way too much time supporting code written by people who "get the job done," but do so inefficiently, and cause the system to keel over two months later. Or do so poorly, and so the system mysteriously breaks when the "hacks" don't quite work.
Penny-wise, dollar-foolish. Sure, you save some time up-front coming up with the hack, and "get the business up and running." In my experience, it never takes long for "the business" to come back and say "I thought you fixed this."
In all fairness, though, this often has more to do with management than anything technical. No matter how much I teach my customers, sometimes they just don't learn.
When I started out as a developer, I was one of the best. Over the years, I've gotten rusty because my work has been so mind-numbing that the last thing I've been wanting to do after work has been to look at more code.
Yes. But the problem is that without the sub-optimal time-saving hack the business might not have come back at all.
A business that can afford to pay people to fix the hacks that kept it solvent last month is called successful. [1]
So, there's a balance. Inevitably, it's impossible to get the balance quite right, so even the optimal software engineering job involves spending half your time complaining about overengineered code and the other half complaining about underengineered code.
[1] Of course, many businesses just pay people to paper over last month's hacks with a new month's worth of hacks, ad infinitum. That is sort of like success... for as long as the house of cards stays up. But it is also hell.
There have been times at JTV where I've implemented some feature and put it into production, only to find it doesn't stick - nobody really wanted it. In cases like these a quick hack is definitely the right thing to do - there's no point worrying about a system keeling over in two months if that system won't even exist in two months.
The reality is that most real-world problems are not particularly complicated, yet most have exceedingly complicated solutions, and as a result, disproportionately large maintenance overhead -- and that maintenance is largely code archeology (wow, what idiot came up with this bit dumbass approach? Why does this framework require 6 new classes in order to add a simple pair of pages to the site?), not productive time.
"For the non-mathematician, probability is an indecipherably complex field. But Taleb makes it easy by proving all the mathematics wrong. Let me introduce you to Brooklyn-born Fat Tony and academically inclined Dr John, two of Taleb's creations. You toss a coin 40 times and it comes up heads every time. What is the chance of it coming up heads the 41st time? Dr John gives the answer drummed into the heads of every statistic student: 50/50. Fat Tony shakes his head and says the chances are no more than 1%. "You are either full of crap," he says, "or a pure sucker to buy that 50% business. The coin gotta be loaded."
The chances of a coin coming up heads 41 times are so small as to be effectively impossible in this universe. It is far, far more likely that somebody is cheating. Fat Tony wins. Dr John is the sucker. And the one thing that drives Taleb more than anything else is the determination not to be a sucker. Dr John is the economist or banker who thinks he can manage risk through mathematics. Fat Tony relies only on what happens in the real world. "
This is why I reckon it's better to learn C before you learn any of the higher-level scripting-type languages. Same reason you should learn to drive a manual before you learn to drive an automatic.
(Of course in both cases I'm just advising people to do the same thing that I did, which is always the weakest form of advice.)
"Core War (or Core Wars) is a programming game in which two or more battle programs (called warriors) compete for the control of the MARS virtual computer (Memory Array Redcode Simulator). These battle programs are written in an abstract assembly language called Redcode. The object of the game is to cause all processes of the opposing program(s) to terminate, leaving your program in sole possession of the machine."
Ruby is, on the surface, not very different from Python. But in terms of philosophy, coding style, and community it is like night and day. There is more to a language than syntax and core libraries. Every language uniquely expresses its communities particular bias on How To Solve That Hard Problem.
In this regard, Python and Ruby could not be more diametrically opposed. Ruby values elegance and terseness, sometimes to the detriment of readability. Python actively eschews some elegant features to ensure readability. They feel very different.
If you want something more esoteric to teach you more purist OO (of which Python is definitely not), then Smalltalk would be the next step forward after Ruby.
I don't mean to diss Ruby too hard, but I don't see the points here as strong enough to detract from an argument for learning C.
You can even use more than one pair of parens sometimes:
fun()()
(If fun returns a function.)
And that isn't an argument _against_ C. Everyone needs to learn C. Go for it. But I think that Python and Ruby programmers stand at a distance and both look down on each other, and most of that is because of social and not technical reasons. Pythonistas spout crap about readability and Rubyists spout crap about OO-ness. Both have something to teach.
You might get angry reading this comment and say, "That KirinDave is so arrogant! He's implying I'm _not_ a good programmer and that by learning Ruby I will be a better one." But really you're the one who opened that can of worms by saying "a step backwards for someone who knows Python", and talking about "awkwardness." By saying that, you've basically said that thousands and thousands of smart programmers are totally wrong and wasting their time.
And it's not true. The programming language that's so bad it has nothing to teach is a rare bird indeed. Ruby and Python are so instructive because of how similar-yet-different they are.
Which part in particular would you like me to reformulate?
I'm down to have the debate in another forum if you'd like. It's a good chance to learn some more about Ruby.
jdennis@gmail
eg Ruby has no named params, no biggie, just use the convention that you pass around hashmaps, something like
foo :bar => 42 etc etc....
close enough for rocknroll. In python they wouldn't necessarily like that, and named params are available (I am just making this up, they could have been in there for the start, but my point remains...)
You do not need to care for C++ much now.
It is sort of like learning Haskell and Scheme simultanously with "Write Yourself a Scheme in 48 Hours - A Haskell Tutorial".
(http://halogen.note.amherst.edu/~jdtang/scheme_in_48/tutoria...).