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!
I didn't know it was possible but /r/iamverysmart has a winner.
---
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.
Thus speaks someone who doesn't know anything about the difference between computer programming and software engineering. They may be able to program circles around everyone else, but they can't software engineer their way out of a wet paper bag, and they're going to produce a disaster. But they'll be on their way to the next place before it becomes clear how much of a disaster they created at this place, so they'll go cheerfully on their way, basking in their own smartness as they create destruction.
Indeed, I’ve seen the type a couple of times before. They usually show up when an aloof management admits to themselves they have run out of ideas and want to introduce “transformational” thinking into an established team. They’ll typically fanny around for a few weeks, make a few noises that sound like no true Scotsman, annoy everybody, break a few things and then move on to the next thing when they burn out. How do I know this? I have been that guy.
As I mentioned in another post, sometimes it becomes a rite of passage, especially if you are put in a situation where you weren't properly mentored/checked. I've only left one real 'mess', it was a smaller one and mostly because I left the org before we were able to get to the final state. However I gave plenty of notes to make sure they could finish it up.
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.
> Thus speaks someone who doesn't know anything about the difference between computer programming and software engineering. They may be able to program circles around everyone else, but they can't software engineer their way out of a wet paper bag, and they're going to produce a disaster.
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.
> ... 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.
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.
> 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.
I prefer Stephenson's description of the team in Cryptonomicon:
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].
Be sure to view this through the lens of 2002, where Python is still a niche language and Perl is only used by certain UNIX crazies, at least in the eyes of most of the business competition of the time. Most statically-typed languages are fairly awful at this point and you could get big wins by switching to something else. A language I consider fatally flawed in 2020 could be a huge differential advantage in 2002, because the competition is that much worse.
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.
"Python was a niche language"? What niche were you in in 2002? Java was going great guns and Pascal/Delphi were definitely a thing. Or are you just saying "a pox on all statically-typed houses"?
I can't parse your comment properly, but the answer is in the Perl and Python niche. So I know it was a niche. It was farther along then than, say, Nim is now, but if you started your job search out and limited it to just Perl and Python, and I'll even toss in PHP for free, you cut out 90%+ of the listings.
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.)
You might be right that that's how a Lisp advocate might have viewed Python and Perl back then but in reality they (plus PHP) were the go-to tools of the day for non-enterprise web programmers. Enterprisey people would view this as cowboy development.
So if I understand this right, you (the author) are the only one who knows whether anything is good, your people are the only ones who can fix anything, and anyone who doesn't believe you is an idiot?
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.
He was building circles around other languages. It worked great. All circles were nice, neat, perfectly round like Lisp parenthesis and inside those circles other developers using unenlightened languages were getting actual work someone cared about done.
To my chagrin, or even dismay, I've discovered that most of the time people who 'code circles around someone' have found a way to handicap everyone else.
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.
Even the idea of "coding circles around someone" is kind of odious -- team sport everybody. Yes you will have better and worse developers but if it's actively your aim to code circles around someone on your team you're not doing your team a service.
I tried my hand at basketball as a youth and the specter of the ball hog loomed big in the head of the coach. Fast forward six years and I'm a club cyclist, where I learned a lot about teamwork that I think most programmers never really learn. When you understand something but have no shared context, there can be a lot of resistance to change.
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.
Yes I believe I understand and agree with what you are talking about.
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.
Sometimes I think/know that I'm this person, and it worries me because I see it as squeezing my future to a very narrow path.
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?
Don’t take on straightforward tasks in the name of expediency. That’s the hole you’re already in and you have to stop digging.
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.
I've been there. I an built entire deployment/change-management system in very small IT teams (1 other person with different skills from mine). We eventually got the go-ahead to grow the team, including more admins with my skill set. At that point, I had written pretty much the entire thing while the other admin had been focusing on tasks related to their skills.
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 have one experience with Lisp, an undergraduate AI class in the late 90's.
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.
> 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.
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?
Given Richard Gabriel is the author of the long essay "Worse is Better" and the wonderful book Patterns of Software (which you should all read), and given it's out of context, I have to read this as both tongue-in-cheek and heartfelt.
Play "Jeopardy" - what is the question he's answering, and why is he answering it that way?
every step of the way my brain is going 'oh no no no oh geeze no'... The only thing they sort of got right was experience does mater, then messes it up but they want to pay peanuts for them.
"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.
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.
This was obviously written in a purposely inflammatory style. I'd like to see the context, which is unfortunately missing here, and on the blog.
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.
While I can't disagree that this is quite flamebaity, I think it's worth considering why this still resonates strongly among significant number of people (myself included) And i'd go with something along the lines of "A lot of publicly used software is crap, and getting software out there by people who work this way would probably give us better software."
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...
For some historical context, the late 90's/early 2000's was a time when Java/J2EE and the n-tier architecture were absolutely dominant in the startup world, and the ideas of functional programming were considered academic or outdated. Saying the word "closure" to most programmers back then would give you the same suspicious look you'd get for saying "monad" today. At least that was my experience as a junior programmer bouncing between web startups in those days.
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.
70 comments
[ 5.2 ms ] story [ 123 ms ] threadhttps://web.archive.org/web/20101217145038/https://lemonodor...
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!
---
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
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.
> 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, ....
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....
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.
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.
http://winestockwebdesign.com/Essays/Lisp_Curse.html
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.
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?
Given the intentionally radical thought experiment nature of the group, the hyperbolic language takes on a somewhat different flavor.
Play "Jeopardy" - what is the question he's answering, and why is he answering it that way?
"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 !
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.
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.
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...
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/...