'My team will be able to program circles around everyone else' (2002)
lemonodor.com
lemonodor.com
In 2020, I think we have many more viable languages that have squeezed out the sort of general crappiness we had in 2002 in programming languages, and the ability of a startup to choose $LANGUAGE and attain a systematic multiplicative advantage over incumbents is small. You have a modest opportunity to win over incumbents by choosing better operational mechanisms (I call it "marginal" because the incumbents are switching to k8s or whatever at a decent speed too), but mostly your big technical advantage is the ability to greenfield something, even as it is also a nearly-crippling disadvantage in some ways too.
Those were definitely interesting times. I'd say that Perl was a little bit more generalist, though, it was not exactly down at the PHP level but was what "serious" websites were using (I say that as a guy who started to learn Python in 2003 because I was too afraid to start and learn Perl).
Back to the post, I wonder if reddit would have still been picked by YC if it hadn't been originally written in Lisp (this I think was late 2004, early 2005?). I'm sure the whole story is written somewhere in a blog-post/dedicated reddit thread but I'm too lazy to check right now.
Don't know about the parent, but I did use Python from 2000 to mid-2000s doing web programming - mostly Zope. So there's that...
Of course, you only need that one job. But it was nowhere near as useful as C++, Visual Basic, or even Java already. (Sun spent a crapton of money buying Java credibility, and it worked! I'm not sure it ever profited them, but by golly it worked. It came out of the gate far stronger than its technical internals at the time warranted.)
And in 2002, "one job" was hard to find....
When you construct code to exactly fit your own mental model of the universe, you filter out a lot of other potential collaborators. You create a system where you have to do certain work because nobody else can. It's easy to interpret this as being about your qualities instead of your failings.
And eventually this bites everybody on the ass. These people will often become a bottleneck, because while it may look like they won't delegate to others, the truth is that they cannot. They don't know how, and they're standing at the bottom of a hole before it becomes apparent.
Peculiar to cycling, hiking, rowing, and only a handful of other team activities is how concretely they demonstrate both failing or succeeding together, and how our strengths and weaknesses complement each other. A person having a good day can bolster the person having a bad one, via literal load shedding, and that feedback is immediate and obvious to all. With basketball, football, or many other sports, this can be pretty subtle, and may be lost entirely on spectators.
I was a varsity wrestler and football player in high-school and in football you can have one break out star and it really can considerably change the game but they are still largely supported by everyone on the field playing their position as best they can. Your QB can be absolutely amazing but if a guard or tackle is slacking that QB is going to be sacked over and over but in most cases it's a lot harder to see the impact.
In wrestling everyone can individually perform amazingly but at most you're only contributing 6 points to the score but if you've ever seen one wrestler perform well at the top of the lineup you can just see how it influences everyone else and triggers a run, like you said immediate and obvious to all.
My project is "general", "flexible", and what I consider "done right" (time<->quality issues aside), and definitely requires a specific mindset. As you suggest, I often find myself, internally, blaming others for not being able to "see" it or caring enough to understand it, but I can make it dance beautifully when something new/strange needs to be incorporated, often "saving the day".
I know that if I left now, it would swiftly collapse, bringing the whole team to a halt. Management has also realized this, resulting in some nice shiny golden handcuffs.
The new developer we hired (since I did become The bottleneck) isn't the greatest (his performance reviews agree), and is slowly breaking things, but I'm only half stopping him because I'm trying to assume my rigidity in the "correctness" must be flawed, and I don't want to damage the relationship any more than it has been.
Now I'm in the progress of scaling this 10x, and I don't want to be a 10x bottleneck.
The only thing that holds back m imposter syndrome, and makes me think it's my, as you say, qualities, is that, after nearly 3 years, the churn from many of the other teams are finally converging towards the one implementation that I've had working, stably, in that same time span, for all of the same reasons that I implemented it the way I did.
tldr;
> It's easy to interpret this as being about your qualities instead of your failings
This is probably me. So, what's the solution? Re-think the whole concept to come up with a different implementation? Simplify?
A little pair programming or watching someone use the new thing you wrote can go a long way toward informing you on how to close the gap. The tricky bits may not be that tricky for others, and the obvious bits often aren’t.
It’s not all roses, of course. The person who doesn’t understand that you built a ladder for them to climb may complain loudly about how long it took you to get to the top of it. It takes a somewhat special team to be able to do the right thing and not get punished for doing so.
Somewhere in between that and Lord of the Flies is most teams.
Whenever a request came in for something regarding the system, I would have to force myself to sit down with one of the other admins and walk them through making the change to close the ticket. It took 3-4 times as long to do the work that way, but after a few weeks, I could start assigning some tickets to them directly and eventually the time savings exceeded the expenditure and I could go back to big-picture planning.
It's a hard lesson to learn the first time, but worth the pain of going through.
"I will be able to point to various examples where Lisp programmers have written not only 3-5 times faster, but they wrote things other programmers thought were impossible" -> in all fairness, and sincere curiosity, "citation needed ™" (though it's hard to point to any successful software, as pretty much all of it is crap, whatever I wrote included)
"Strong typing is for weak minds" -> hey, here is a function that takes an argument called "participants". Quick, what are the functions that you can call on it ? Assuming it's a collection, what kind ? What are the elements made of ? Is it heterogenous ? Is the field "name" specified for each of them ? Is it always there ? Are there cases where it's a string and others where it's a tuple ? Does it depends on user input ? Has it been sanitized ? Has it been produced by code you have not written ? Or by code you wrote a year ago ?
What do you mean, "you don't know ?" Oh, you must be one of those "weak minds" MIT guys like to make fun, of. Welcome to the club ! No big deal, we're still nice. We sometimes get things done, and we get to repeat the same weak/strong arguments every so often whitout anyone ever saying anything that might change each other minds. Kinda like social science and militant politics, but with waaaaay higher pay.
Cheers !
Play "Jeopardy" - what is the question he's answering, and why is he answering it that way?
Given the intentionally radical thought experiment nature of the group, the hyperbolic language takes on a somewhat different flavor.
In retrospect, the J2EE hype was wildly overblown, optimized for problems nobody needed solving, and introduced unnecessary complexity and boilerplate at every level of the stack. I can only imagine how frustrating it was to have a full understanding of how bad the status quo was, yet have your alternatives dismissed out of hand because "not Java".
I remember thinking people like Paul Graham[0] and Phil Greenspun[1] were pretty brave for going against the J2EE dogma--to suggest that these "little languages" not only had interesting properties, but should actually be used in production. I found their arguments convincing, but didn't have the guts to push for them at work.
[0]: http://www.paulgraham.com/avg.html [1]: https://www.amazon.com/Philip-Alexs-Guide-Web-Publishing/dp/...
For those unfamiliar with him, I suggest reading some of Richard Gabriel's other writing. He is known for "Worse is better" but that's the tip of the iceberg.
This isn't the piece of writing you should take away from him, especially out of context. You can probably find a lot of silly things other people have written on Usenet 20+ years ago.
It was an interesting experience, since I didn't actually have convenient access to a Lisp runtime. I would write my Lisp assignments with pencil and paper, and (procrastinating) a few hours before the assignment was due make it to the computer lab and enter my program, just as I imagined my predecessors worked in the 60s and 70s.
The odd thing about Lisp was that my programs almost invariably worked (modulo a mismatched paren) the first time. I've rarely had that happen in other environments.
There was the one time where the set of library functions I thought were present weren't available in the Lisp variant available. I simply implemented the functions I needed in a few minutes.
I only wish I'd have had an opportunity to explore the Lisp world more. It seemed like it was from the past and the future at the same time.
Is that not simply because you thought it all out beforehand and made sure to check the code an extra time before submitting it because you wrote it on paper and had to go through a lot of effort to get it executed on a machine?
Preach brother. Safety rails on mountain roads are for weak drivers. My team could drive down a mountain pass in a semi truck drifting around corners such that the trailer hangs out over the edge of the cliff during the drift and never lose a single dollar of inventory.
On the other hand I've managed to build a good career out of being the guy who shows up after a mess is made, and cleans it up. (BTW, this is not a bad spot to be in if you like learning either, you will get good at actually -reading- code, other people's code. And, all the crazy stuff you see, eventually you start to realize there is a -right- way to use some of it. :)
One thing about the software -development- process (be it software engineering or something else) is that there should still be some form check/balance to avoid insanity. As an example, at the moment I'm working on some performance stuff for an open source library. But there's a certain point where I said "I'm stopping here, any work onward is going in a new branch, since it's going to be impure to the rest of the project and IDK if that's what people really want, even if it's a decent gain". Common sense.
That's at least a bit of an assumption. Perhaps it hits close to home from my days in a Lisp shop, but some of the most brilliant Lisp programs I've seen weren't even written by programmers or software engineers; they were written by drafters who were clever at math. And while I know I'm waxing poetic, I do consider that a credit to Lisp's purity.
Hell, in the drafting industry I would say this story is (or certainly was) absolutely true. I wrote a whole bunch of LISP that I believe is still in use today, 8-12 years later alongside a number of small C#/VBA applications. Amazingly what was put together was not only a 'non-disaster', but done thoughtfully enough that the team was able to take that code and evolve it over that same time period since I've left (I keep in touch with some of that team, specifically the guy who got 5 days of me offboarding 6 years of work...)
On the other hand, I've seen the opposite as well. In the C# world, writing one's ORM is often seen as a trial of passage where one should hopefully by the end realize the difference between programming and engineering.
BUT, but... I've seen things blown the other way as well. I've seen PDD (Presentation Driven Development) in it's worst form; where engineering principles are so overvalued that nobody actually does anything. It wasn't even bikeshedding the architecture; it was bikeshedding the project itself.
I think we also sometimes forget differences in engineering philosophies. A Youtube channel called Regular Car Reviews did a great video once upon a time discussing the failure of the Chrysler-Mercedes merger from the late 90s. One of the things touched on was differences in engineering philosophy. The way a High performance 'european' car used to get made was often a measure of precision, lots of fancy pieces working in unison (and, as anyone who had a late 90s BMW with VANOS can say, expensive to fix.) American Engineering? Just make it bigger!
We see some of this difference in engineering philosophy today; consider folks who prefer ground iron or cloud iron vs functions as a service.
The first lesson I learned about programming versus engineering was about disasters left behind.
The second lesson was that sometimes the disasters had a good reason.
Sure. But those drafters probably weren't on a "we're so much smarter than everyone else, strong typing is for people with weak memories" ego trip. People who know they aren't programming experts tend to be conservative and careful in what they write. People who want to throw away all the guardrails so that they can show what great coders they are... look out.
https://web.archive.org/web/20101217145038/https://lemonodor...
> However, after a series of the inevitable, endemic startup setbacks that the Internet boom all too often left in its wake, Gabriel grew weary of the cold, cloistered, celibate tedium of engineering culture, and fell willing prey to the lure of the exotic social and intellectual stimulation and blandishments that only the Liberal Arts could offer.
He specifically tries to write in a poetic style. See his website - https://dreamsongs.com/
In 2002 he was 53 years old.
Epiphyte Corp.’s business plan is about an inch thick, neither fat nor skinny as these things go. The interior pages are slickly and groovily desktop-published out of Avi’s laptop. The covers are rugged hand-laid paper of rice chaff, bamboo tailings, free-range hemp, and crystalline glacial meltwater made by wizened artisans operating out of a mist-shrouded temple hewn from living volcanic rock on some island known only to aerobically gifted, Spandex-sheathed Left Coast travel bores. An impressionistic map of the South China Sea has been dashed across these covers by molecularly reconstructed Ming Dynasty calligraphers using brushes of combed unicorn mane dipped into ink made of grinding down charcoal slabs fashioned by blind stylite monks from hand-charred fragments of the True Cross.
The actual content of the business plan hews to a logical structure straight out of the Principia Mathematica. Lesser entrepreneurs purchase business-plan-writing software: packages of boilerplate text and spread sheets, craftily linked together so that you need only go through and fill in a few blanks. Avi and Beryl have written enough business plans between the two of them that they can smash them out from brute memory. Avi’s business plans tend to go something like this:
MISSION: At [name of company] it is our conviction that [to do the stuff we want to do] and to increase shareholder value are not merely complementary activities—they are inextricably linked.
PURPOSE: To increase shareholder value by [doing stuff]
EXTREMELY SERIOUS WARNING (printed on a separate page, in red letters on a yellow background): Unless you are as smart as Johann Karl Friedrich Gauss, savvy as a half-blind Calcutta bootblack, tough as General William Tecumseh Sherman, rich as the Queen of England, emotionally resilient as a Red Sox fan, and as generally able to take care of yourself as the average nuclear missile submarine commander, you should never have been allowed near this document. Please dispose of it as you would any piece of high-level radioactive waste and then arrange with a qualified surgeon to amputate your arms at the elbows and gouge your eyes from their sockets. This warning is necessary because once, a hundred years ago, a little old lady in Kentucky put a hundred dollars into a dry goods company which went belly-up and only returned her ninety-nine dollars. Ever since then the government has been on our asses. If you ignore this warning, read on at your peril—you are dead certain to lose everything you’ve got and live out your final decades beating back waves of termites in a Mississippi Delta leper colony.
Still reading? Great. Now that we’ve scared off the lightweights, let’s get down to business.
EXECUTIVE SUMMARY: We will raise [some money], then [do some stuff] and increase shareholder value. Want details? Read on.
INTRODUCTION: [This trend], which everyone knows about, and [that trend], which is so incredibly arcane that you probably didn’t know about it until just now, and [this other trend over here] which might seem, at first blush, to be completely unrelated, when all taken together, lead us to the (proprietary, secret, heavily patented, trademarked, and NDAed) insight that we could increase shareholder value by [doing stuff]. We will need $ [a large number] and after [not too long] we will be able to realize an increase in value to $ [an even larger number], unless [hell freezes over in midsummer].
DETAILS:
Phase 1: After taking vows of celibacy and abstinence and forgoing all of our material possessions for homespun robes, we (viz, appended resumes) will move into a modest complex of scavenged refrigerator boxes in the central Gobi Desert, where real estate is so cheap that we are actually being paid to occupy it, thereby enhancing shareholder value even before we have actually done anything. On a daily ration consisting of a handful of uncooked rice and a ladleful of water, we will [begin to do stuff].
Phase 2, 3, 4, . . . , n-1: We will [do more stuff, steadily enhancing shareholder value in the process] unless [the earth is struck by an asteroid a thousand miles in diameter, in which case certain assumptions will have to be readjusted; refer to Spreadsheets 397-413].
Phase n: before the ink on our Nobel Prize certificates is dry, we will confiscate the property of our competitors, including anyone foolish enough to have invested in their pathetic companies. We will sell all of these people into slavery. All proceeds will be redistributed among our shareholders, who will hardly notice, since Spreadsheet 265 demonstrates that, by this time, the company will be larger than the British Empire at its zenith.
SPREADSHEETS: [Pages and pages of numbers in tiny print, conveniently summarized by graphs that all seem to be exponential curves screaming heavenward, albeit with enough pseudo-random noise in them to lend plausibility].
RESUMES: Just recall the opening reel of The Magnificent Seven and you won’t have to bother with this part; you should crawl to us on hands and knees and beg us for the privilege of paying our salaries.
EDIT they will also burn out and leave once real operational issues drive through fixes that break your well thought out abstractions and you don’t have the safety net of a type system to catch you and progress grindS to a halt as technical debt mounts and we just want you to fix the damn bug not hear about your artists journey!
Please explain to me how this mode of thinking is distinguishable from being in a cult.
I would not work with this man. Anyone who cares enough about how "smart" they are by some arbitrary metric to write screeds about it would be intolerable to work with. Imagine what happens when they are, at long last, wrong about anything.
If this guy represents self-professed "winners", I'll take the losers any day.
How realistic is the idea that there are talented people trapped in some obscure language that could be underpaid? Unless you're looking for passionate zealots I can't help but think talented engineers could easily change languages if they so chose.
It wasn’t a mistake.
E.g. a Haskell programmer, regardless of the suitability of the language itself, is probably serious about programming, and has advanced skills in certain areas of mathematics — you don't hear of too many "Haskell script kiddies".
Whether such programmers would accept being systematically underpaid, I don't know. It seems an unethical idea in any case, and if the language is truly N times as productive, programmers versed in it should be well worth more than a standard industry salary.
I know, I know, usability and design and modern capitalism etc. etc. But a guy who uses e.g. Linux and the command-line extensively and yet doesn't program for a living can dream...
---
Though it's not relevant, I would argue like this:
My team will be able to program circles around everyone else. They will be able to construct rapidly a language specific to the problem we are solving rather than using a language designed by computer scientists worrying about their place in history and a herd of library writers working in cubicles a thousand miles from our business. My team will be able to use a language without training wheels. Strong typing is for weak minds, and it's exactly like they say at MIT: Our current popular languages are designed to help losers lose less.
I will be able to point to various examples where Lisp programmers have written not only 3-5 times faster, but they wrote things other programmers thought were impossible. In this regard, I'd tell the CEO, our competitors will be spending all their time trying to figure out that it's really possible we're doing what we're doing, because they will be thinking in terms of customization at compile time or link time, not at runtime.
Moreover, we will be operating where the CEO is focusing on his or her specialty and not imposing his or her knuckleheaded view on technology.
Because Lisp is dead, I'll get better programmers for less money. I'll be able to guarantee 50 more IQ points for the same pay. And my guys will be able to spend their time typing in value not book keeping overhead and typing in type descriptions because their guys are too stupid to know when they type + numbers are involved.
Because no one uses Lisp, I'll have my pick of thousands of great, experienced programmers looking to work for someone with a non-zero IQ, not the ones fresh out of college with 10 programs under their belts.
I'll be compatible with everything because it is right now. And if someone throws me a bug, I can code around it in a few minutes. Being a niche market means we're more proprietary. People will not use Lisp to compete with us because they are lamebrains listening to the latest fashion statement from Sun or Microsoft.The open source crowd isn't even smart enough to notice C++, so they are especially nowhere in the picture.
Of course, no CEO will belive this because every one of them is stupid.
- Posted October 2002