Three virtues of a great programmer(thethreevirtues.com)
thethreevirtues.com
Three virtues of a great programmer
https://thethreevirtues.com/
140 コメント
> Perl […] incredibly terse (perhaps too much so)
I used to like Perl, but I found it hard work at times not to create something that, without ample commenting which arguably removes a lot of the benefit of terseness, even I wouldn't understand without some thought when looking at it a few months down the line.
Perl was (is? - I assume it is still used a fair bit) often referred to as a write-only programming language for this reason.
I used to like Perl, but I found it hard work at times not to create something that, without ample commenting which arguably removes a lot of the benefit of terseness, even I wouldn't understand without some thought when looking at it a few months down the line.
Perl was (is? - I assume it is still used a fair bit) often referred to as a write-only programming language for this reason.
I'm curious about the usage. I've seen it mostly replaced with ruby, but wonder if this is a bubble phenomenon.
'all the unix tools like awk...'
Not ad-hominem but where were you 95-2006 because Gawk, Sed and Burne shell were the answer to read only perl scripts. That is one of the reasons Perl is basically no longer used: it was used without discipline.
There was actually a progressive mode amongst those systems programmers I knew who knew what they were doing at the time.
* bash + sed for the easy stuff * bash + gawk or just gawk for the ETL stuff * TCL for systems glue + swig * C when you are bespoke or need performance
Perl was great in theory but I cringed every time I saw a script.
Not ad-hominem but where were you 95-2006 because Gawk, Sed and Burne shell were the answer to read only perl scripts. That is one of the reasons Perl is basically no longer used: it was used without discipline.
There was actually a progressive mode amongst those systems programmers I knew who knew what they were doing at the time.
* bash + sed for the easy stuff * bash + gawk or just gawk for the ETL stuff * TCL for systems glue + swig * C when you are bespoke or need performance
Perl was great in theory but I cringed every time I saw a script.
Agreed, Perl scripts were often write-only, especially when people get cute with the shorthands.
At the same time, it is rare for me to see a Bourne/Bash script without obvious serious defects in it.
(Many people don't understand the shell script textual substitution evaluation model at all. And even those people who do, the model gets very hard to reason about as soon as you try to do some data value handling that's absolutely trivial in most high-level languages.)
At the same time, it is rare for me to see a Bourne/Bash script without obvious serious defects in it.
(Many people don't understand the shell script textual substitution evaluation model at all. And even those people who do, the model gets very hard to reason about as soon as you try to do some data value handling that's absolutely trivial in most high-level languages.)
And then, python.
I love Python, but basically 96% of Python code and developers absolutely suck at everything, I'm fixing a shit python codebase right now. It's like a language which people love to use to write shit code.
Python has become my goto for anything more complicated than a 3 line bash script, but not so complex it need multiple files to logically separate the code. Argparse isn't perfect, but it lets you get 90% of the way to a nice functional argument parsing system, with auto-generated help output that mostly doesn't suck. It's also built in so I can rely on it being anywhere python is already installed. And python is ubiquitous enough in default installs now I can pretty much rely on it being present as much as I can rely on bash being present.
As a result, every command line bit of glue code I've written for the last decade or so has been in python. At a certain point, it does start to get unwieldy and you can indeed write some awful code in it, but then again, I've seen some pretty awful bash scripts too.
My favorite trick is the fact that you can tell python to
As a result, every command line bit of glue code I've written for the last decade or so has been in python. At a certain point, it does start to get unwieldy and you can indeed write some awful code in it, but then again, I've seen some pretty awful bash scripts too.
My favorite trick is the fact that you can tell python to
It's evolution. I like Python, it gets love and support. And it's all about the data structures - really. With python all I have to do is figure out the data - the rich set of OO, functional or imperative approaches and APIs does the rest.
It's the same as in Visual Basic: those who request programming languages for dummies, they have a tendency not to be the brightest software developers in the toolbox.
Visual Basic as a language is just C# for people who want to type more to do the same thing.
Visual Basic as a tool for building Windows programs with GUIs was pretty hard to beat though.
Maybe there are tools that churn out fully-polished react just as easily nowadays, but I wrote a janky little data visualization app in 2 hours at my internship and they ended up using it for almost 15 years.
Visual Basic as a tool for building Windows programs with GUIs was pretty hard to beat though.
Maybe there are tools that churn out fully-polished react just as easily nowadays, but I wrote a janky little data visualization app in 2 hours at my internship and they ended up using it for almost 15 years.
Because it's so easy the average quality of the user is lower. This isn't surprising to me.
At least people still love it :D
Python is great for prototyping...
Then you write it again in a better language...
Then you write it again in a better language...
Or you could just write it the first time in the real language.
Python isn't appreciably faster than something like Typescript to someone with actual experience making programs professionally.
Python isn't appreciably faster than something like Typescript to someone with actual experience making programs professionally.
shit code is proportional to number of people developing. on average, about 98.56% of developers don’t know what they are doing and with millions of them writing their shit in python you end up with…
I'd say rather - ruby.
Ruby has the syntactic power to write stuff very succintly, lot of good apis (and some crappy too), had since its inception a good repl which perl always ignored..
There was a time, just before the rails boom, when ruby had a lot of traction in admins and that-era-devops circles
Ruby has the syntactic power to write stuff very succintly, lot of good apis (and some crappy too), had since its inception a good repl which perl always ignored..
There was a time, just before the rails boom, when ruby had a lot of traction in admins and that-era-devops circles
Python isn't a serious language for programmers.
It's for non-programmers.
It's for non-programmers.
For a non-serious language there are a lot of successful non-programs written with it.
I’ve had a variety of responses to this list over my programming life (~10 years hobby, ~10 years professional).
When I first encountered them as a hobbyist, they were surprising, as perhaps intended, due to the framing of classic vices as virtues. On some reflection though, it made sense, and shaped my understanding of programming as somehow _inherently different_ than other types of creation.
When I got started with a professional career, they functioned to soften the edge of anxiety. It meant that the community of programmers who came before me - which presumably included Larry Wall - would understand that these patterns in coder behavior were ultimately beneficial and that I would maybe fit in with a corporate programming environment. (Now I know that this isn’t always true; sometimes coworkers, both programmers and non-programmers, don’t always realize these unintuitive points, and in some special cases, those programmer instincts aren’t actually valuable.)
At some point, I disagreed with the framing. As others have pointed out, the patterns can be reframed as classic or functional virtues such as curiosity. Then I backpedaled and realized that the framing is important because these are unintuitive patterns and it makes us re-think habitual incentives that reward, e.g., work that is more productive but not more effective.
How did it hit me now? I realize that it’s also related to power dynamics. Programmers are assets to their employers but they’re also potential disrupters. The traditional “virtuous” framing of potentially-less-effective behavior, like patience, is related to the organizing and taming of a workforce.
It’s also related to the types of problems we encounter. When we work with computers, Larry’s list does usually lead to more effective outcomes. But when working with other humans, who have their own agency and idiosyncrasies, the traditional virtues are better-adapted behavior. This is also more true for the complex technical systems we deal with nowadays. So, as our careers transition from programming to system engineering and/or management, the traditional virtues become more relevant.
Anyhow, this is an evergreen and thought-provoking nugget of wisdom. Thanks to Larry Wall and those who have preserved it.
When I first encountered them as a hobbyist, they were surprising, as perhaps intended, due to the framing of classic vices as virtues. On some reflection though, it made sense, and shaped my understanding of programming as somehow _inherently different_ than other types of creation.
When I got started with a professional career, they functioned to soften the edge of anxiety. It meant that the community of programmers who came before me - which presumably included Larry Wall - would understand that these patterns in coder behavior were ultimately beneficial and that I would maybe fit in with a corporate programming environment. (Now I know that this isn’t always true; sometimes coworkers, both programmers and non-programmers, don’t always realize these unintuitive points, and in some special cases, those programmer instincts aren’t actually valuable.)
At some point, I disagreed with the framing. As others have pointed out, the patterns can be reframed as classic or functional virtues such as curiosity. Then I backpedaled and realized that the framing is important because these are unintuitive patterns and it makes us re-think habitual incentives that reward, e.g., work that is more productive but not more effective.
How did it hit me now? I realize that it’s also related to power dynamics. Programmers are assets to their employers but they’re also potential disrupters. The traditional “virtuous” framing of potentially-less-effective behavior, like patience, is related to the organizing and taming of a workforce.
It’s also related to the types of problems we encounter. When we work with computers, Larry’s list does usually lead to more effective outcomes. But when working with other humans, who have their own agency and idiosyncrasies, the traditional virtues are better-adapted behavior. This is also more true for the complex technical systems we deal with nowadays. So, as our careers transition from programming to system engineering and/or management, the traditional virtues become more relevant.
Anyhow, this is an evergreen and thought-provoking nugget of wisdom. Thanks to Larry Wall and those who have preserved it.
The main annoyance I have with Larry’s take is that efficiency is confused with laziness, which are entirely different things. Laziness, at its extreme, is to delay doing something until absolutely necessary, or even avoid entirely, efficiency is to optimize for the least possible effort, which is sometimes the same as being lazy
It was kind of a thing at the time. In the Afterword of Æleen Frisch's Essential System Administration (also 1991) subtitled "Don't Forget to Have Fun", there are listed _seven_ virtues of a system administrator:
* Flexibility: being able to wriggle out of tight spots and escape when irate users seem to have you cornered
* Ingenuity: realizing that you can use syslog to send messages to your friend on another system
* Patience: remaining capable of waiting until the final sendmail bug is fixed
* Persistence: the compulsion to try just-one-more-thing to fix a problem before going home
* Adherence to Routine: insisting on real milk and sugar-in-the-raw in your coffee (which is Kona or nothing)
* Attention to Detail: noticing that the clock on one of your systems is using Aleutian time, and changing all the others to match
* Laziness: writing a 250-line Perl script to avoid typing 15 characters
I took the last one to heart and have admired those who could utilize the first one, because I never could.
* Flexibility: being able to wriggle out of tight spots and escape when irate users seem to have you cornered
* Ingenuity: realizing that you can use syslog to send messages to your friend on another system
* Patience: remaining capable of waiting until the final sendmail bug is fixed
* Persistence: the compulsion to try just-one-more-thing to fix a problem before going home
* Adherence to Routine: insisting on real milk and sugar-in-the-raw in your coffee (which is Kona or nothing)
* Attention to Detail: noticing that the clock on one of your systems is using Aleutian time, and changing all the others to match
* Laziness: writing a 250-line Perl script to avoid typing 15 characters
I took the last one to heart and have admired those who could utilize the first one, because I never could.
My whole life I have been called lazy. In filmmaking as an assistant this was a weakness, work harder not smarter and all that. I still feel insecure about it sometimes but over the past few years of transitioning into coding full time I have learned that this is my best trait. Life is short, you must demand to live your life how you want otherwise you will be convinced that working hard for someone else makes sense.
Congrats on the jump, changing careers is hard!
I don’t have the time or want to read the page, but I’m sure I’m already as good as him.
Maybe someone can do a quick TL;DR; version of it? :)
You're only dunking on yourself here, the page is four sentences long. Being proudly ignorant is still just ignorance.
Yikes
You missed the joke. Should I diagram it for you?
In UML, the joke would be much longer. And is the punch line solid or dotted?
Self-composite diamond for recursive association.
whoosh
I'd add Curiosity instead of Impatience. Impatience is related to Laziness. In both cases we want the computer to do the work instead of us.
But Curiosity is orthogonal and important. The best programmers I know were always curious: Why was it built that way? Why does it give that output? Why did she say that? Curiosity is the beginning of knowledge. If you're not curious, you will miss out on a lot of opportunities for learning and improvement.
But Curiosity is orthogonal and important. The best programmers I know were always curious: Why was it built that way? Why does it give that output? Why did she say that? Curiosity is the beginning of knowledge. If you're not curious, you will miss out on a lot of opportunities for learning and improvement.
It doesn't work as well rhetorically as having all 3 virtues be typically thought of as flaws.
You're right! I didn't catch that.
Maybe Snooping? Nosiness? Meddling?
Maybe Snooping? Nosiness? Meddling?
Disruption? "Fixing what isn't broken"?
Im going with: Making perfect the enemy of the good.
Im going with: Making perfect the enemy of the good.
Kinda works anyway: "curiosity killed the cat"
I was thinking that something about having communicative skills should be added to the list, but struggled to reframe that as a flaw… any ideas?
Curiosity is a classical vice, I think it works
yes but not one of the seven deadly sins https://en.wikipedia.org/wiki/Seven_deadly_sins although impatience isn't one I think it should actually be wrath here.
Seconded, and I’d add this is a quality of a great human being.
Curious people are curious about others too, not just systems.
It’s related to caring. You have to care to be curious and we could use more people taking care in their lives.
Curious people are curious about others too, not just systems.
It’s related to caring. You have to care to be curious and we could use more people taking care in their lives.
That last one ("hubris") I'm going to call out. Maybe the author means another word, for what he describes, but the actual "hubris" I'm seeing among my colleagues is the belief that lots of people out there don't know how to write code, but that their own $%^& doesn't stink.
It's the utter subjectiveness of "best practices" that aren't tied to actual issues of performance, security, or flexibility, or worse - blowing one or more of these attributes of good code way out of proportion to the actual importance of the code.
And "readability"? Don't get me started ... there's hardly a linter rule that I haven't seen turned into a caricature of what it was intended to do.
What devs do is part art and part science, and there's hardly consensus on which part is which.
It's the utter subjectiveness of "best practices" that aren't tied to actual issues of performance, security, or flexibility, or worse - blowing one or more of these attributes of good code way out of proportion to the actual importance of the code.
And "readability"? Don't get me started ... there's hardly a linter rule that I haven't seen turned into a caricature of what it was intended to do.
What devs do is part art and part science, and there's hardly consensus on which part is which.
My interpretation of hubris in this context is actually "pride" and it's what I've chosen to substitute the word for.
Having pride means that I want to write code that others view as good code and won't look at in the future as a mad hatter's ramblings.
Having pride means that I want to write code that others view as good code and won't look at in the future as a mad hatter's ramblings.
I interpreted this "hubris" to mean that I believe I can make a difference, rather than feel that I can't contribute.
You can understand why I, personally, would think this is a virtue.
You can understand why I, personally, would think this is a virtue.
“audacity” might be a better word for you for that :)
(To be clear: I mean this as a good thing. Audacity… seems pretty important, and very nice to have, at the right times and places)
(To be clear: I mean this as a good thing. Audacity… seems pretty important, and very nice to have, at the right times and places)
Write code "that other people won't want to say bad things about" sounds like using the hubris (arrogance?) to throw up walls to be left alone. Maybe in some organization you might be the star player that can do this to the benefit of the greater good, but in most places collaboration of some sort is paramount, and the hubris thing doesn't sound good. Wouldn't want to hire this archetype.
I especially love it when these people turn code which can be debugged (breakpoints can be set and hit) into one-liners for no reason which you have to rewrite in order to even set breakpoints. Well done, I hope you’re proud.
you can't debug within a line?
Yea, if you cannot set a breakpoint on an arbitrary expression, then your tools are bad and you should feel bad. On the other hand the dev tools in the average web browser lacked that capability until relatively recently, so it’s not an uncommon experience.
Good luck debugging linq one-liners in VS.
I just look at popular Github projects and ask myself why doesn't my code look that nice?
I completely agree with your take though. There is so much "distraction" in what are best practices, readability, etc.. It's all so subjective. Best practice for what? Readability for who?
I feel like software engineering : engineering :: psychiatry : medicine.
I completely agree with your take though. There is so much "distraction" in what are best practices, readability, etc.. It's all so subjective. Best practice for what? Readability for who?
I feel like software engineering : engineering :: psychiatry : medicine.
I recommend this talk on that subject:
https://youtu.be/CmIGPGPdxTI?si=vOxiooCemwR7CygI
I found it incredibly interesting.
https://youtu.be/CmIGPGPdxTI?si=vOxiooCemwR7CygI
I found it incredibly interesting.
Yeah, "pride" fits better with his description.
One missing virtue is never impart programming advice or wisdom on the internet - Because 10 other programmers who know nothing about you or your job will tell you in detail all the ways in which you're doing it wrong.
The internet is famously hostile. If only two other people complain about my methodology I think I must have done something right.
This is essentially Cunningham's law, eh? Perhaps you want to learn how you could do it better!
Yeah, good point.
Related:
The Three Virtues of a Great Programmer - https://news.ycombinator.com/item?id=32487944 - Aug 2022 (2 comments)
Larry Wall's Three Great Virtues of a Programmer - https://news.ycombinator.com/item?id=24107571 - Aug 2020 (1 comment)
Develop the three great virtues of a programmer: laziness, impatience, and hubris - https://news.ycombinator.com/item?id=11516215 - April 2016 (72 comments)
The Three Virtues of a GREAT Programmer - https://news.ycombinator.com/item?id=10942079 - Jan 2016 (4 comments)
The Three Great Virtues of a Programmer: Laziness, Impatience, and Hubris - https://news.ycombinator.com/item?id=9788088 - June 2015 (67 comments)
The Three Virtues of a Great Programmer - https://news.ycombinator.com/item?id=32487944 - Aug 2022 (2 comments)
Larry Wall's Three Great Virtues of a Programmer - https://news.ycombinator.com/item?id=24107571 - Aug 2020 (1 comment)
Develop the three great virtues of a programmer: laziness, impatience, and hubris - https://news.ycombinator.com/item?id=11516215 - April 2016 (72 comments)
The Three Virtues of a GREAT Programmer - https://news.ycombinator.com/item?id=10942079 - Jan 2016 (4 comments)
The Three Great Virtues of a Programmer: Laziness, Impatience, and Hubris - https://news.ycombinator.com/item?id=9788088 - June 2015 (67 comments)
Interesting that the title bounces between the "virtues of a great programmer" and the "great virtues of a programmer", which have two very different meaning. I can get behind these "virtues" as being part of the psyche that drives programmers to do what they do, which is what I think was Larry Wall's original point. These have nothing to do with what makes someone a great programmer, though.
The most reposted four lines ever?
I would say that the character arc of Perl, and the profession generally, leads me to this observation: laziness and impatience are virtues. Be careful with hubris.
Hubris was really about building the community. It encouraged you to build things that you would want to share, so that we could all benefit from your Laziness and Impatience.
I'd even go so far as to say !hubris
Pride often leads to unintentional blindness and irrational defensiveness. Humility is where the fun is.
Pride often leads to unintentional blindness and irrational defensiveness. Humility is where the fun is.
I'd argue hubris is balanced by laziness and impatience. Where I don't believe the three are equal.
I'd add a conditional lesser virtue when working on certain codebases that should have been accounted for when making perl6: Fear.
I'd add a conditional lesser virtue when working on certain codebases that should have been accounted for when making perl6: Fear.
It's funny, I can't get myself to do many other creative activities I think I should enjoy (illustration, leather working, cooking) because of the tedium of doing the same thing over and over inherent in those activities. Programming is great because every single thing you're doing isn't tedious. It's the opposite of tedium.
Maybe it's not so much laziness, but more so a hatred of tedium.
Maybe it's not so much laziness, but more so a hatred of tedium.
I would also like to add one more thing: hesitation. From my own experience, in my programming career, the most time my team wasted was on redoing something from scratch. Why redo it? Because the previous design was not comprehensive enough to meet subsequent requirements. If everyone could spend more time researching and discussing the plan before starting, and get things right in one go, in my view, this is much more effective than rushing into development work.
> Because the previous design was not comprehensive enough to meet subsequent requirements.
YAGNI.
Hesitation to avoid unnecessary work, sure. But not to anticipate future requirements.
The number of times I've had to fight a fancy design that left expansion points / abstractions for future features that were never needed (or not in the form the designers expected) enormously outnumber the times any such thing was useful.
Just make the code do its current job in the simplest way possible. That's the easiest design to expand later.
YAGNI.
Hesitation to avoid unnecessary work, sure. But not to anticipate future requirements.
The number of times I've had to fight a fancy design that left expansion points / abstractions for future features that were never needed (or not in the form the designers expected) enormously outnumber the times any such thing was useful.
Just make the code do its current job in the simplest way possible. That's the easiest design to expand later.
There's "simple" and there's "naively simple". I agree 100% with YAGNI, but you can also wedge yourself into a corner with a design that allows no room for growth unless you scrap it and start from scratch.
Hindsight / survivorship bias affects this viewpoint.
You will never get it "right" the first time as much as you can avoid doing it "very wrong".
The key is to have enough experience and taste to appropriately break down problems into pieces that encapsulate the volatility of the various domains.
Then you can refactor easier which should be the real goal.
Prune and tend to the garden.
You will never get it "right" the first time as much as you can avoid doing it "very wrong".
The key is to have enough experience and taste to appropriately break down problems into pieces that encapsulate the volatility of the various domains.
Then you can refactor easier which should be the real goal.
Prune and tend to the garden.
Reversible decisions are a simple enough concept to grasp, but a difficult one to really comprehend.
Some people see effective people making 'bad' decisions and miss the bit where there were eight bad ways to accomplish something and they rejected 6 as being more work overall. Then they take their misreading of the situation as justification for YOLOing decisions to avoid analysis paralysis.
Some people see effective people making 'bad' decisions and miss the bit where there were eight bad ways to accomplish something and they rejected 6 as being more work overall. Then they take their misreading of the situation as justification for YOLOing decisions to avoid analysis paralysis.
Yeah. It's easier to not do something stupid than it is to do something smart. Take the time to avoid doing stupid things (which takes somewhat more time than you expect!) and don't take the time to try (and usually fail) to be overly smart.
> Why redo it?
Is a reason like, "being built like shit by the cheapest contractors that won the bid" ever a good reason?
My work is huge on what I call, "fire, forget, then rewrite." Basically, we have tons of legacy apps that have lifespans of like 10 - 20 years, many of which never receive a single update. So, they eventually get old and unsupported enough that it's honestly just easier/quicker to rewrite them.
And in case you were wondering, yes, I work in Gov..
Is a reason like, "being built like shit by the cheapest contractors that won the bid" ever a good reason?
My work is huge on what I call, "fire, forget, then rewrite." Basically, we have tons of legacy apps that have lifespans of like 10 - 20 years, many of which never receive a single update. So, they eventually get old and unsupported enough that it's honestly just easier/quicker to rewrite them.
And in case you were wondering, yes, I work in Gov..
Impatience also makes you write more performant software because you can't stand waiting on build/test/run cycles.
This aligns well with ADHD. As someone who has ADHD and is also a programmer this is why I love programming so much!
I would add stupidity. I know I'm stupid, that's why I write types, tests and documentation.
If you're not familiar with Larry Wall's style this might seem a bit off putting.
The first time I ever saw him speak was the 1997 first annual O'Reilly Perl conference. I remember thinking, "This guy is a jerk" while also thinking "I love this guy"
The first time I ever saw him speak was the 1997 first annual O'Reilly Perl conference. I remember thinking, "This guy is a jerk" while also thinking "I love this guy"
By all accounts he's actually a really nice guy.
Is there any publicly available talk of Larry Wall that might evoke it today?
A quick explanation of the Three Virtues by Larry and then an impromptu explanation of why Hobbits would make good programmers
https://www.youtube.com/watch?v=G49RUPv5-NU
https://www.youtube.com/watch?v=G49RUPv5-NU
Any of his "State of the Onion" talks. https://www.youtube.com/watch?v=a1SEt_-QMDo
Oh Larry, never change.
I often give a similar list as a glib answer in interviews when asked "what are your greatest strengths?"
Mine are usually: I'm stupid (not smart enough to overcomplicate), lazy (prefer turning MVP in on time rather than adding too many bells and whistles), and forgetful (document everything because I won't remember what I was doing the next day).
I often give a similar list as a glib answer in interviews when asked "what are your greatest strengths?"
Mine are usually: I'm stupid (not smart enough to overcomplicate), lazy (prefer turning MVP in on time rather than adding too many bells and whistles), and forgetful (document everything because I won't remember what I was doing the next day).
What is your biggest weakness:
"I work too hard" -- humblebrag
As someone currently recovering from burnout, that is indeed my greatest weakness, and it's anything but a brag!
Working too hard means you're liable to disappear for 6+months, no sane employer should want that!
Working too hard means you're liable to disappear for 6+months, no sane employer should want that!
As someone who has worked hard for years (at some point I had three con-concurrent jobs), I’m not sure working hard is the variable that causes burnout :thinking_face:
I will say tho, it gave me persistent back problems and RSI for two years :). But that again is not just “working hard”. It was bad posture, lack of stretching, breaks and exercise, I think.
Edit: Perhaps it’s the nature of the work or working hard unhealthily (physical and mental?) or the person’s characteristics.
I will say tho, it gave me persistent back problems and RSI for two years :). But that again is not just “working hard”. It was bad posture, lack of stretching, breaks and exercise, I think.
Edit: Perhaps it’s the nature of the work or working hard unhealthily (physical and mental?) or the person’s characteristics.
I remember hearing about burnout, that it becomes more likely to happen the less meaningful work you do.
Not sure about that.
Do you work too hard or spend a lot of time on work? (before downvoting me, please consider that those things maybe different)
A bit of both I suppose. In my case I think taking on too many responsibilities and stressing out too much over any production issues that arose were the main ingredients for disaster.
But there were others as well. Burnout is complicated.
But there were others as well. Burnout is complicated.
Are they still asking that ridiculous question?
"That I have no strengths"
I've never been asked "my greatest weakness" or "my greatest strength" in an interview. What sort of jobs have asked you those questions?
(I've worked (and interviewed) as a programmer at VC backed startups and FAANG in SF and NYC over the past 12 years)
(I've worked (and interviewed) as a programmer at VC backed startups and FAANG in SF and NYC over the past 12 years)
That kind of cuteness in an interview would be a red flag for me. OTOH, I also wouldn’t ask that question.
I think programming is an basically an exercise in effective communication. Edsger Dijkstra said that
"Besides a mathematical inclination, an exceptionally good mastery of one's native tongue is the most vital asset of a competent programmer."
This means being able to write down a description of a problem or a solution in a clear and concise way. This is the test I would use if I hired people (not only programmers). At my job I have noticed that quite a few people cannot write proper sentences or are way too verbose in their writing.
"Besides a mathematical inclination, an exceptionally good mastery of one's native tongue is the most vital asset of a competent programmer."
This means being able to write down a description of a problem or a solution in a clear and concise way. This is the test I would use if I hired people (not only programmers). At my job I have noticed that quite a few people cannot write proper sentences or are way too verbose in their writing.
> ”… an exceptionally good mastery of one's native tongue …”
Does that imply that one cannot be a competent programmer if working on an environment where the spoken tongue is not their native one?
Does that imply that one cannot be a competent programmer if working on an environment where the spoken tongue is not their native one?
I don't think so. I think the core of Djikstra's thought is that mastery of your native tongue coincides with strong communication skill and ability to logically organize and present thoughts. You can articulate your thoughts and do so in a way that others can understand. Working outside your native tongue may add hurdles, but from my experience having worked with brilliant people who's native tongue is not English, those hurdles can be overcome. The skills still translate.
No, I'm 90% certain both Dijkstra and OP meant that what's critical is mastery of any tongue. In context, he was talking about what makes someone good at programming, not about the need to contribute to a team or communicate ideas.
https://www.cs.virginia.edu/~evans/cs655/readings/ewd498.htm...
https://www.cs.virginia.edu/~evans/cs655/readings/ewd498.htm...
Presumably the point is not the specific emphasis on your native tongue exactly, but rather a mastery beyond what might be regularly implied by mastery of a language (able to converse like a local) and rather mastery unique even among native speakers (able to convey ideas many different ways with a particular glibness that others can easily understand)
I've never really liked his inclusion of hubris here. Hubris is often defined as unjustified arrogance. Justified confidence, even if you're a jerk about it, was never the fatal flaw of a Greek hero.
So I've always substituted arrogance for hubris: the belief that you better understand, and can better address, the requirements than any off-the-shelf library/program/ecosystem.
So I've always substituted arrogance for hubris: the belief that you better understand, and can better address, the requirements than any off-the-shelf library/program/ecosystem.
I read hubris here as...you want to be the best, you don't want to be criticized, so you will work hard and be super motivated to make your program work very well, handling all the various edge cases, making it better than the competition.
Yes, but that is not what the word hubris means. It means pride in the seven deadly sins sense. The pride that comes before a fall. Hubris would not mean working hard to reduce the scope for criticism. It would mean not accepting valid criticism because you think you are better than the critics.
He could have just used the word "pride" (which is far broader and has positive meanings too) instead. In some ways "ambition" might be a better fit.
He could have just used the word "pride" (which is far broader and has positive meanings too) instead. In some ways "ambition" might be a better fit.
Ambition might stand out in the same list as laziness. Plus I'd be reticent to tell programmers to "be more ambitious!" - I see greenhorns esp just trying to do too damn much at once.
In the context of "code that is going to be reviewed" maybe even "vanity" might have been closer to what he was getting at? (did you even RUN this?) Except us old neck beards obviously don't care about how WE look ;)} - just how our code reads.
I think "take pride in your work" would have substituted well; but given the options, maybe hubris was fine - he explains what he means in a couple of sentences.
In the context of "code that is going to be reviewed" maybe even "vanity" might have been closer to what he was getting at? (did you even RUN this?) Except us old neck beards obviously don't care about how WE look ;)} - just how our code reads.
I think "take pride in your work" would have substituted well; but given the options, maybe hubris was fine - he explains what he means in a couple of sentences.
Or just "pride" and then an explanation.
Using a word and then redefining it seems very humpty dumpty "a word means what I want it to mean"
Using a word and then redefining it seems very humpty dumpty "a word means what I want it to mean"
so they try to describe a balanced sense of pride and values
When you learn programming, you are told to never roll your own crypto, or to always use the ready-made libraries, or to avoid manual memory management - and you can have a perfectly fruitful career following rules like that.
But you don't get big changes or ambitious intellectual growth without spotting that - if you did choose to break those sorts of rules - you could build something really new and exciting.
Anyhow that's how I've always taken the "hubris" part - knowing when there's an opportunity to achieve something in a way that someone will tell you is too risky.
But you don't get big changes or ambitious intellectual growth without spotting that - if you did choose to break those sorts of rules - you could build something really new and exciting.
Anyhow that's how I've always taken the "hubris" part - knowing when there's an opportunity to achieve something in a way that someone will tell you is too risky.
> When you learn programming, you are told to never roll your own crypto, or to always use the ready-made libraries, or to avoid manual memory management
I've always taken this sort of advice, such as "never reinvent the wheel" to mean "inventing the wheel is time consuming so give yourself an advantage by using already existing wheels", which really has nothing to do with hubris.
I never took it as "Don't bother trying to reinvent the wheel because you aren't capable of it"
I've always taken this sort of advice, such as "never reinvent the wheel" to mean "inventing the wheel is time consuming so give yourself an advantage by using already existing wheels", which really has nothing to do with hubris.
I never took it as "Don't bother trying to reinvent the wheel because you aren't capable of it"
My take on that was that rolling your own crypto is hubris, but for all other ready-made libraries it's just about saving time[0].
There's only one person I ever met who thought manual memory management was a good idea, and their code was terrible in lots of other ways besides that, so I can't say I've ever thought about that particular example.
But after a decade or so of "don't roll your own crypro", I've also heard that if you specifically want to get into cryptography, the only way to do it is to research existing crypro libraries and work your way upwards, starting from "can I find bugs someone else already found, without reading the full details of their report?" and eventually rolling your own.
[0] That said, I'd now also add that libraries serve as Schelling points to make it easier to find jobs and to find workers.
There's only one person I ever met who thought manual memory management was a good idea, and their code was terrible in lots of other ways besides that, so I can't say I've ever thought about that particular example.
But after a decade or so of "don't roll your own crypro", I've also heard that if you specifically want to get into cryptography, the only way to do it is to research existing crypro libraries and work your way upwards, starting from "can I find bugs someone else already found, without reading the full details of their report?" and eventually rolling your own.
[0] That said, I'd now also add that libraries serve as Schelling points to make it easier to find jobs and to find workers.
You can build a better wheel if you want to focus on that.
If you want to build a car however, focus on building the car and not creating a new kind of wheel.
If you want to build a car however, focus on building the car and not creating a new kind of wheel.
If you want to build a better car than everyone else's current cars, you might need to create a new kind of wheel.
Look at the Apollo moon rovers, for instance: they couldn't use off-the-shelf wheels for those.
Look at the Apollo moon rovers, for instance: they couldn't use off-the-shelf wheels for those.
He gives his meaning for hubris. Seems silly to disagree based on a different definition that he's not using.
Its just not a common one. My disagreement is founded in the fact that he uses an uncommon (arguably wrong) definition of hubris.
Part of the impact of jokes of this form is that you are supposed to be able to sort of reason your way there without explanation. But while laziness and impatience rely on the common usage of the terms, hubris is off in left field, and not even in a way that's commonly understood amongst software developers. Hubris is not "pride, but more so", it is specifically "unjustified pride". A lot of people first encounter the word "hubris" in high school literature/English class, talking about the common tropes of ancient Greek tragedies, where it is necessarily unjustified pride. I guess there's a way to understand "hubris" as "excessive (abrasively so) justified pride", but that seems vanishingly rare. I'd argue that that distinction makes "hubris" here misleading. When I (and, I expect, most people who learned the word in high school), read that a good programmer should have hubris, I understand that to mean a good programmer should be confidently wrong.
Part of the impact of jokes of this form is that you are supposed to be able to sort of reason your way there without explanation. But while laziness and impatience rely on the common usage of the terms, hubris is off in left field, and not even in a way that's commonly understood amongst software developers. Hubris is not "pride, but more so", it is specifically "unjustified pride". A lot of people first encounter the word "hubris" in high school literature/English class, talking about the common tropes of ancient Greek tragedies, where it is necessarily unjustified pride. I guess there's a way to understand "hubris" as "excessive (abrasively so) justified pride", but that seems vanishingly rare. I'd argue that that distinction makes "hubris" here misleading. When I (and, I expect, most people who learned the word in high school), read that a good programmer should have hubris, I understand that to mean a good programmer should be confidently wrong.
Hobby programmer perhaps. But a professional systems developer in a larger corporation? Not so sure...
How about making a static website that doesn't require extensive hosting lest it crash for a few thousands of visitors?
Serving static blog content should be trivial if your code isn't absolute lunacy.
Serving static blog content should be trivial if your code isn't absolute lunacy.
You can't mention these without explaining false laziness, false hubris, and false impatience.
I think Larry Wall gives us some great insights wrapped in great humour.
I think Larry Wall gives us some great insights wrapped in great humour.
Curiosity, we waste time learning a thousand useless 'shiny' things at the same time, then we apply all we learnt solving problems easily
One could have also titled it Three Virtues of ChatGPT
i always thought that the Laziness virtue was a tacit reference to lazy evaluation of arrays (LISP-like) ... I get the feeling that most ML languages have quietly dropped this aspiration (Haskell, ML, ELM, I'm looking at you) ... meantime Larry's opus magnus "raku" (renamed from per6) is still lazy at heart
I always said the fourth virtue is fear (of complexity). Keeps the others in check, particularly hubris:)
Discernment:
The virtue of not thinking you're building something great when you're building something awful
The virtue of not thinking you're building something great when you're building something awful
I'd add a variation on that third one - it's all they've got going for them.
The really great coders I've worked with live and breathe the work, and come 5pm on a weekday they just continue on coding only this time for fun at home themselves.
The really great coders I've worked with live and breathe the work, and come 5pm on a weekday they just continue on coding only this time for fun at home themselves.
If you come at 5pm or past to work on an OSS project or your own side project more power to you. For a corp job why work longer than you need to when you are not paid for it? Bragging rights?
Hugged to death by HN again. Here's the archive version.
https://archive.is/yS4op
Oldie but a goodie
I found my new bible
(1991)
[deleted]
"Laziness, impatience, and hubris" ~ "Lean manufacturing, short iteration cycles, and ?"
Perl. Lol
The best programmer saves their earnings and retires early
Perl was a gazillion times more powerful than Bourne and C-shell (including all the Unix shell tools like `awk`), much more rapid than working in C, incredibly terse (perhaps too much so), and also portable (to all the oddball systems you might have).
And the purposes to which Perl was put were often to automate things you'd been doing manually, or that you couldn't do without Perl.
You'd be quietly doing big things with Perl. And there were sayings about how you'd automated your job, and presumably spent your time writing more Perl scripts and reading Usenet. And the occasional joke of replacing someone else with a one-line Perl script.
Also, note that not only was this before the dotcom boom (when programmers suddenly were no longer nerds but getting rich and fashionable), but also-- a lot of the programmers using Perl professionally weren't even professional programmers, but actually sysadmins or random university researchers, who happened to have the power of Perl. The majority of professional programmers on Unix actually didn't know Perl.
So, Perl people speaking of Perl people in terms of vices could be seen as a self-deprecating, joking spin conscious of the unusual power that they wielded.