Williams: Master of the "Come From"

https://github.com/raganwald/homoiconic/blob/master/2011/11/COMEFROM.md

by ColinWright • 15 years ago

195 40 15 years ago

listrophy• 15 years ago

Point this article to any hot-shot developer... if they don't come away with a new smidgeon of self-doubt, slowly back away: he/she isn't worth working alongside.

angelbob• 15 years ago

This is cute. I had to Google to get the Williams / Jim Kelly thing from Enter the Dragon.

An awesome article. Inspirational in the same way as Steve Yegge's Wizard School bit (http://steve-yegge.blogspot.com/2006/07/wizard-school.html).

Harkins• 15 years ago

The author is Reginald Braithwaite; the movie has a character named Braithwaite who begins the plot. I wonder if this whole post is autobiographical or if the Williams/Kelly is just an old joke and Braithwaite is a coincidence.

dasil003• 15 years ago

This is an illuminating example of how different assumptions lead to different definitions of what makes good code. I'm convinced that this is one reason why there is this belief that 80% of programmers are incompetent. It's not there aren't truly incompetent devs out there, but it's also easy to assume someone is incompetent just because they were working from different constraints and experiences than you, and the way they did things just isn't immediately apparent.

ericb• 15 years ago

Having recently lead a round of interviewing, I wish that I could be convinced that your kinder interpretation was true.

But under moderate questioning, most interviewees don't hold up well.

46Bit2• 15 years ago

It's a good point, and one I expect most people have heard quite a few times. However, interviewees probably either don't have a job or aren't doing well with the one they have. As such, I suspect you're likely to get a larger % of the mediocre than you might see elsewhere in the industry.

Retric• 15 years ago

I have often been complemented on how well I code, but I don't think I stand up to many peoples moderate questioning all that well. I think this seems from looking for a clean solution to most problems vs. the perfect or most obvious solution. The vast majority of the time I avoid dealing with the minutia that many people feel is necessary.

For example, I once had school project where we where supposed to implement some fairly simple math function in x86 assembler. My first question in class was what instruction set could we use? (x86 Pentium I) So we can use the floating point unit? (Yep) So while everyone else was implementing floating point functions by hand I simply used the built in floating point unit. I still remember handing in 4 pages of clean code and asked why this was a major project until people started asking for more time to fix their buggy 40+ page programs even though I had told several people what I thought was an easier solution. I even told people that I finished the thing in a few hours while watching TV but they forged ahead I guess thought the sunk cost fallacy or something. I mean sure the way you do arbitrary exponentiation is a little funky, but that's better than doing it by hand.

Oven and over I see the same things. Last week someone was demoing his custom cashing solution created by hand and I was like A this does not fit our architecture and B why did you spend the time on this? Sure it's 'fun' but why bother?

At the same time in interviews I have been asked minutia about the java object system etc, and all I can think of is if this matters your doing something horribly wrong.

CGamesPlay2• 15 years ago

Interviewing is an inherently flawed way of determining skill. This manifests itself in numerous ways; one of which is our inability to properly extrapolate information from an interview: if a good programmer needs to search online for information to solve a problem about once each 8-hour day, then during the interview, the good programmer may ask for help once. But if they do that, then the interviewer sees that they need to ask for help once every hour. Alternatively, if they don't ask for help, the interviewer might be led to believe that they don't use tools afforded to them. Because one cannot ask for help 1/8th of a time, the interviewer has a negative impression of the candidate regardless of the choice the interviewee makes. This sort of lose-lose for the interviewer due to extrapolation can happen for many different facets: anything that is necessary, but only in moderation.

Interviews are a very flawed system for identifying skill.

ellyagg• 15 years ago

In sport psychology, Hull's Drive Theory predicts that introverts perform poorly under pressure. The physiological response from a job interview is as about as close to the pressure of taking the last shot in a basketball game as I've ever experienced, and I've experienced both. Couple this with the fact that most programmers are introverts, and I'm always amazed at the credulity with which people accept these fizzbuzz claims. Is it more likely that 90 percent of experienced programmers can't program, or that something about the evaluation process is broken? I can say that I would never take a programming job where it was critical to do well under performance anxiety inducing conditions.

ZeroGravitas• 15 years ago

The evidence overwhelmingly suggests that interviews and interviewers are unsuitable for the task they are used for (i.e. selecting the best candidate). Assuming this applies to programming interviews as well, then your opinions of these programmers (both good and bad) could be just as incorrect as the Israeli army training example given by the psychologist in this article:

"Daniel Kahneman: How cognitive illusions blind us to reason" http://www.guardian.co.uk/science/2011/oct/30/daniel-kahnema...

"Because our impressions of how well each soldier had performed were generally coherent and clear, our formal predictions were just as definite. We rarely experienced doubts or formed conflicting impressions. We were quite willing to declare: "This one will never make it," "That fellow is mediocre, but he should do OK," or "He will be a star." We felt no need to question our forecasts, moderate them, or equivocate. If challenged, however, we were prepared to admit: "But of course anything could happen."

We were willing to make that admission because, despite our definite impressions about individual candidates, we knew with certainty that our forecasts were largely useless. The evidence was overwhelming. Every few months we had a feedback session in which we learned how the cadets were doing at the officer training school and could compare our assessments against the opinions of commanders who had been monitoring them for some time. The story was always the same: our ability to predict performance at the school was negligible. Our forecasts were not much better than blind guesses."

Another recent article was about the author was discussed here:

"The King of Human Error" http://www.vanityfair.com/business/features/2011/12/michael-...

http://news.ycombinator.com/item?id=3219240

beagle3• 15 years ago

> it's also easy to assume someone is incompetent just because they were working from different constraints and experiences than you, and the way they did things just isn't immediately apparent.

I don't know if it's common, but I tend to judge competence by the bottom line: does it work? is it supportable? what was the cost of getting there?

If it doesn't work, or does work but cannot be supported/modified, and cost a lot, it is a product of incompetence. Possibly the manager's, and not the tech guys.

I've never heard anyone refer to djb as incompetent. Some people dislike his coding style, but I haven't heard any criticism about it that is not about style. And yet, he's working with different constraints and experiences than everyone else. And things are often not immediately apparent.

mikeash3• 15 years ago

I thought people generally assumed that 80% of programmers are incompetent because 80% of programmers can't perform a simple task like e.g. Fizz Buzz without an enormous amount of time and assistance.

headbiznatch• 15 years ago

This nicely draws together several sub-currents of developer thought pertaining to the "am I good at this?" current that all developers have. I found myself bouncing back forth on some of the ideals, waiting to hear how it all turned out for this developer... Basically the same feeling I get from a good short story.

mey• 15 years ago

I hate this coding style. It combines expert system knowledge with spooky action at a distance, which means in anyone else's hands it will break and delay development. Horizontal changes that aren't readily indicated in the code paths that are effected are confusing. (One of the many reasons monkey patching can be considered an anti-pattern)

I guess the longer I've worked with other developers, I prefer readability first, test-ability second.

kiba• 15 years ago

I disagree, as long as they have a consistent system of naming, you can find everything you need. Most of my problem comes from not being able to figure out how to moneypatch it instead of doing it the lazy and brute force way.

grncdr2• 15 years ago

I love this coding style, but I think you have a valid point. Python decorators are a nice compromise in that they allow you to have cleanly factored 'around' advice (which is strictly more powerful then 'before' and 'after') with the implementation defined elsewhere, but still requiring a visible marker at the location the advice is used.

What would be ideal is a system that allowed you to define advice by monkey-patching but indicated what advice was applied to a method at the site of it's definition. As mentioned in this comment http://news.ycombinator.com/item?id=3246215, I think we are bumping into a limitation of what can be easily managed in "unstructured" (I would say "dead") text files.

wladimir2• 15 years ago

I think we are bumping into a limitation of what can be easily managed in "unstructured" (I would say "dead") text files

Yes, I think so too. There are many kinds of relations between entities that we cannot specify just because "dead" text files make them hard to express. Also, it makes that language "wars" focus on shallow concerns such as syntax, instead of semantics.

It would be great to be able to put constraints and relations at the abstract syntax tree level, or abstract semantic graph level (cross references and such that are automatically updated if entities are moved/renamed).

IDEs sort-of work around this by parsing the code and trying to bolt on features, by handing the "dead" text files intelligently. But all this work is lost as soon as you close the editor, so it does not allow the programmer to retain changes at this level.

But I'd love to work on a project that examines different, new ways to represent source code. Which could aid static/dynamic code validation, documentation, code comprehension, refactoring, cross-cutting concerns, and would allow for rendering the source code in any style and syntax that the developer wants.

Of course, this also would present challenges in the area of scm systems, because those are really focused on 'dead' text files. One idea I've had is to represent code as a graph, for example, in a graph database.

bbq2• 15 years ago

This is only true because our tools for reading and exploring source code suck. I mean, we still work at the "unit level" of code (i.e. files and functions, classes, what have you). If our development environments let us viscerally experience the relationships of these units (a systemic perspective) we'd be in much better shape.

beza1e12• 15 years ago

I disagree. The dream of getting a higher level picture of code is pervasive. E.g. UML was born to do exactly that. However, our modules usually do not compose cleanly, so you cannot visualize them as connected black boxes.

One common followup argument is that functional programming is great for this, because pure functions can be treated as black boxes. Sorry, but the problem is on the algorithmic/business logic level, which cannot be solved by the choice of programming language/paradigm.

Example: Remove data from one database and put it into another one, transactionally. At any point in time any other process must see the data in exactly one of the two databases. You can not merge the databases into one.

beza1e12• 15 years ago

The only problem of monkey patching is that other modules might be affected. If module A monkey-patches module B, then module C might break. If we had a mechanism, which guarantees that C does not notice A's monkey-patching, it would be a super-useful decomposition method.

ilaksh• 15 years ago

To me it looks like the increasing popularity of AOP and richer (or at least more functional) syntax in languages like Ruby, the relative ubiquity of property chaining and two-way data binding across different frameworks, is moving towards a more semantic type of software specification where structures and relationships are more important.

I think that's pretty obviously a good thing since it reduces the cyclomatic complexity, coupling, amount of code, and increases reuse, although you can obviously take it a little far when you are actually using a mostly imperative paradigm.

I think this is one of the types of things that is going to (eventually someday) finally wake people up to the limitations of unstructured (although colorful) ASCII source editing.

buff-a• 15 years ago

I think this is one of the types of things that is going to (eventually someday) finally wake people up to the limitations of unstructured (although colorful) ASCII source editing.

This.

46Bit2• 15 years ago

Have to give the author (and Williams!) credit - that's a damned neat developing style to my mind. As always, running into it when a client is yelling down the phone would be painful, but it is interesting to consider. Certainly it's a strange approach with virtues, unlike much of the beyond-spaghetti you sometimes run into.

sloafmaster• 15 years ago

I wonder how much groveling he had to do to get his code to run... http://www.catb.org/~esr/intercal/stross.html

JonnieCache• 15 years ago

The best thing in that article: this link http://en.wikipedia.org/wiki/COMEFROM

Not that the rest of it wasn't great. I think I like this Williams guy. If I could convince him to be a bit less dogmatic I reckon we'd get on.

Williams: Master of the "Come From"

Related Stories