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.
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".
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."
Yes, but on the other hand there's no point perfecting something until you know it's actually going to stick around.
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.
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.
The real world is often messy, and solutions that work in it are often messy. The best you can hope for is that someone uses a lookup table/config file instead of a tangled nest of hard-coded "if" statements. But seeking elegant algorithms to address real world problems is often a wild goose chase.
No one's looking for elegant algorithms for real world problems here.
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.
In my experience, it never takes long for "the business" to come back and say "I thought you fixed this."
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.
Same here. Solutions like that are unfortunately the norm, which is leading to the deplorable state of software industry wide, and the general and growing malaise from the developers.
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.
Sort of related...an excerpt from Nassim Nicholas Taleb (Black Swan):
"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. "
...replying to mail isn't practicing your typing. You have to set aside some time once in a while and do focused practice in order to get better at something.
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.
FWIW, my "code kata" is to try exercises from SICP in whatever language I happen to be playing with, which is really just an excuse to re-read portions of SICP. Always a pleasure...
That's one of mine also; I'm using How to Design Programs as a way to learn Scheme, and also doing some small Rails project work on the side to de-rust my Rails skills...
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. :)
The point about learning more languages that are different from one another seemed interesting. I know that knowing more languages makes you better, so i wish to learn more. I know python and started to learn scheme, can any one suggest me a 3-rd language?
C. Or some form of assembly. Both of them get you closer to the hardware than any high-level language would, and it's important to know what scheme and python and any other language are really doing for you automatically.
Definitely. I hate to sound like an old curmudgeon (especially since I'm only 28) but it's scary the number of people nowadays who call themselves programmers but have never even had to worry about allocating memory.
Honestly, I'd just say "get past started" for now... But yes, implementing prolog would be great... Check out the Reasoned Schemer... but only after Little and Seasoned.
Ruby really isn't sufficiently different from Python to make it a worthwhile third language, is it? Maybe a sixth or seventh language, after C, C++, Erlang, f77 and Assembly.
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.
From my limited experience with Ruby, I'd say it would be a step backwards for someone who knows Python. It will largely show them how things are done awkwardly in another language while attempting to solve similar problems. Something like C, as other posts have suggested, would teach a lot more in the same period of time.
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.
Both Ruby and Python's approaches are beautiful, just in different ways. The reason I suggest learning Ruby is because in learning to see that you'll see why, and be a better programmer for it.
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.
One of the "interesting" things I see in ruby is that people are happy to accept any suitable way of doing something, whereas in python there is general demand for more language or official support.
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...)
It's ok man. No need to have a flame-war here. I consider anyone with a different viewpoint to be offering an argument against my pov. It's not vicious or aggressive, but still an argument. :)
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.
I also have some limited knowledge of ruby and i decidet not to learn it yet because i just don't like how it feels. I noticed that there are a lot of method calls in the tutorial i read. Something like object.method1.method.2 and from python i know that if you have more than one dot, you are mistaking somewhere. It might not be a mistake in Ruby, i know its supposed to look like UNIX pipes, but it just doesn't feel right. I wouldn't call it a step backwards though, for someone it might be, but for others ruby is superior, i just like python better and i will learn ruby some day. But for now C it is, but i will read my scheme book to the end first(its only 99 pages long).
yeah, i started to read a ruby tutorial and in 20 minutes i stopped, i might learn it if i have to. I do own a K&R ANSI C, and i thought of reading it, but didn't find low level programing as fun as python. I will learn it eventually, but i won't learn assembly, C is as low level as i will go. I've been thinking of learning smalltalk any opinions?
I do own a K&R ANSI C, and i thought of reading it, but didn't find low level programing as fun as python. I will learn it eventually
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."
Learning Smalltalk is a great idea, but be warned - its workflow is very different to most other languages (for example, it doesn't really have a command line in the same sense that Ruby or Python does). If you can get over the first couple of weeks of frustration, you'll probably learn a lot.
I have been doing pet projects (some of my dumbest ideas) and some freelance work to "practice". This has been going for at least 3 years now ^_^ so far so good...
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.