10 ms·
The Three Great Virtues of a Programmer: Laziness, Impatience, and Hubris
- amelius 11y agoI'm not sure if laziness is a virtue of a programmer. Often, writing the program takes a lot more work than the actual use (by that particular programmer) of it would warrant. Take for example the developers of a word processor. Would all that effort spent on that office-automation software really cancel against the probably few letters and/or documents that a developer would write using it?
- aaronchall 11y agoFrom the article:" Laziness: The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don't have to answer so many questions about it. Hence, the first great virtue of a programmer. Also hence, this book. See also impatience and hubris. (p.609) Impatience: The anger you feel when the computer is being lazy. This makes you write programs that don't just react to your needs, but actually anticipate them. Or at least pretend to. Hence, the second great virtue of a programmer. See also laziness and hubris. (p.608) Hubris: Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won't want to say bad things about. Hence, the third great virtue of a programmer. See also laziness and impatience. (p.607) "
- Foy 11y agoJust today I was actually thinking laziness was one of my greatest assets as a developer. Always trying to find a way to make my work do as much of itself as it can, haha.
- vacri 11y agoTo be honest, it's not actually 'laziness' as much 'desire for automation'. I've worked with a few actually lazy developers in my time, and it's not fun. For example, it's hard to be a software tester when the design documentation, in it's entirety, is on an A4 sheet in the lead developer's desk, and he's too lazy to make a copy for you. That was medical software, no less...
- QuercusMax 11y agoI think "desire for automation" is in the right direction, but doesn't quite hit the mark. For me, it's more like "not wanting to solve the same problem twice". I don't really care if it's automated or not, but once I've solved a problem I don't want to think about it again (unless there's some new twist). At my last job I was always getting bugged by support people asking me the same questions over and over. So I wrote documentation/guides telling how to solve the common issues. TL;DR: it's not so much "robots are awesome" as "ain't nobody got time for that!".
- emerongi 11y agoI would categorize it as efficiency. Laziness is when you have the means to do something, but you're just not willing to do it. Efficiency is when you take 2 hours today to save 10 minutes every day for the next 5 years.
- jfoutz 11y agoBeware false laziness. Slamming out a 500 character command line to build something is ok for a little while, but if it ever falls out of history, you're doomed. Write the Makefile and expend less energy overall.
- seanp2k2 11y agoWhy not just copy/paste that into a .sh, put #!/bin/bash at the top, check it into source control, and call it good enough for now? I guess they call that a "Dockerfile" these days :)
- Jweb_Guru 11y agoI do that all the time.
- sdenton4 11y agoTrue laziness is building your own linux kernel because the length of your command line flags overran the limit allowed by the OS.
- tormeh 11y agoI, uh, don't think laziness is the right word.
- degenerate 11y agoI think he misspelled MAXIMUM OCD
- ngoldbaum 11y agoThe true lazy person starts with a cookie-cutter template whenever they start a new project. It helps when the path of least resistance is also the best practice.
- ddrum001 11y ago
- caterwaul 11y ago4) Not being a self-centered, libertarian asshole.
- aaronchall 11y agoYeah, totalitarians make the best programmers - always thinking of other people.
- SwellJoe 11y agoThis seems to be a non-sequitur. Who are you talking about? Larry isn't libertarian to the best of my knowldge, and certainly not an asshole. He's one of the nicest, most genuinely kind and generous, people I've ever met.
- bch 11y agoESR? https://fullmetallinux.files.wordpress.com/2012/01/eric-raymond22.jpg https://fullmetallinux.files.wordpress.com/2012/01/eric-raym... http://www.catb.org/esr/guns/ http://www.catb.org/esr/guns/
- SwellJoe 11y agoSo, a non sequitur, then? Since this article is about something Larry Wall said in Programming Perl (among other places). Perhaps there is some confusion based on their somewhat similar facial hair choices? I can assure you they are separate people with independent thoughts.
- bch 11y agoHa! You're completely right! I was reading some other ESR today and just mentally inserted him as a coauthor with Tom Christiansen, Larry Wall and Randall Schwartz. I can't identify a libertarian among the authors in this article. Edit: spell Tom's surname correctly
- GFK_of_xmaspast 11y ago
- artlogic 11y agoI've found the phrase "long-term lazy" is the quickest way to describe the first virtue: someone who's willing to work hard today so they can be lazy (or have more time for other things) later on.
- sweezyjeezy 11y agoI don't see how 'lazy' is a good word to use though. I would imagine someone who is lazy would be much less likely to write documentation than someone who isn't. Prudent is a much more fitting, if less eye-catching word.
- Retric 11y agoAhh, but the lazy coder only writes the minimum documentation, because it's not automatically maintained. //Here be dragons! Means, look at the commit history and Grock it, before messing with this. A prudent coder might go to great detail about how they think this worked five years ago when they wrote the comment which can be worse than useless.
- bluedino 11y agoLazy coders will pile things into one commit or not use version control
- JoeAltmaier 11y agoCall it lazy; I call it productivity. When the tool introduces more work than the fix, something is wrong. I can do 5 or 10 fixes before lunch. Except I have to go through a ritual of source management that slows me to a standstill, not to mention derailing my train of thought utterly.
- carussell 11y agoI'm curious: are you specifically talking about the GitHub-style fetish for "a fork and feature branch for everything, followed by a merge"? I've been on a tear lately against GitHub after having another go at using it (it's where the collaborators are) and finding that it's still as terrible as it's ever been. Have you used Git extensively outside of GitHub or done much with Mercurial? Patch-based/commit-only workflows are the right solution to, I dunno, probably 75% of fixes and don't get in the way like the aforementioned approach, which tends to be misapplied (read: used 100% of the time because GitHub demands it). Commit-only workflows are very light on ritual, since it's got about the same overhead as leaving a two-line comment. Mercurial makes it even lighter, because you don't have to futz around with the index like you do in Git (so long as you're only changing an existing file and haven't introduced a new one).
- anaolykarpov 11y agoI'm a Perl dev for less than 5 years. Since last week I changed the company I work for. The new company has a project which is 12+ years old. This project has a code base written in Perl which seemingly violates all programming best practices: files of 50k LoC,functions of several thousands of lines, there are frequently 5-6+ levels of nested ifs. It contains all the technical debt it acquired during these 12+ years. However, it took me less than an hour from the moment I got access to a working vm to make the first fix - display the correct currency on invoices which were not paid in usd. And this, in the context that it was the first time I logged into the app and I also had to find such a buggy invoice. Now, tell me again how unreadable and hard to understand Perl is?
- mattmanser 11y agoYou can do that in any language. I've done that kind of thing in an hour in languages I've never even used before (uncompiled ones, obviously). Perversely your first fixes are often easier than your later ones as you're not trying to make things better, you want to show off his good you are to your new boss/client. The problems with bad code come when you have to make bigger changes and you're constrained by the existing design like a straight jacket. Adding a £ or a $ or a € is really easy for any experienced programmer.
- chipsy 11y agoI'm increasingly forgiving of that kind of "primitive" code with giant, heavily nested functions, because the worst that can go _wrong_ with it from a maintenance standpoint is heavy duplication and overreliance on mutable state. Those are knowable quantities, and you can attack them systematically. Otherwise, everything is laid out for you in straight-line order. You can just read it and see "this happens before that" without having to run the program or a debugger, and nobody even has to burden themselves with giving "this" and "that" an explicit name(although a comment can be a real boost to finding what you want). Codebases that are cleverly factored to within an inch of their life are much, much worse. There's no guarantee that the original factoring successfully decoupled anything, and all the additional content allows for new bugs to slip in "between the cracks" - parameters left accidentally unset, a hierarchy of functions getting called in the wrong order, etc. The original programmer has to spend more time coming up with ways to name and enumerate these details, allowing their eyes and thoughts to be taken off of the domain problem. Because more powerful programming tools are used, more powerful debugging techniques become necessary. And when the architecture breaks, the call stacks just get deeper as the heavy metaprogramming guns are brought out to make increasingly clever workarounds to the resulting issues - after all, nobody really wants to try to disentangle the code after it hits the point of architectural meltdown. Of the two, copy-paste coding is definitely the lesser evil. So I allow some of that first and then clean up the low-hanging fruit.
- SwellJoe 11y agoI find it disheartening how much people trash talk Perl, while other languages that are extremely similar (JavaScript, Python, Ruby all share much more with Perl than they do with, say, Haskell or Go or ML), get a pass. It's become trendy to do so, to the point where people who clearly have never learned Perl or worked with it feel entitled to speak with authority on it. Taking it to the point of dismissing anything Perl's creator has ever said (as one of the commenters on this wiki page does) is absurd and means not listening to an extremely bright technologist (I mean, c'mon, Larry invented patch, the basis of a tremendous amount of awesome in modern software development!). There are misfeatures in Perl, certainly, but there are roughly as many misfeatures in JavaScript. It's silly to dismiss it as "awful" when there's so much that is clearly nice about the language for many categories of problem.
- sspiff 11y agoI never used Perl, but I use Ruby where people might have used Perl before. (Small one-off scripts or simple automation stuff) People often attack the appearance and readability of Perl code ("write-only" code), but lot's of Ruby code I come across has the exact same problem, except that people seem to love adding 4 or 5 extra layers of abstraction on top of that.
- krylon 11y agoOne can write totally incomprehensible code in any language if clean, readable code is not a priority. And the opposite is true, too, of course. I have seen some fairly messy Python code and some marvelously clean Perl code. And I am fairly certain that over time, some people have written beautiful PHP code and ugly Lisp code. In my humble experience, it is not so much a property of the programming language as it is of the programmer(s).
- AdieuToLogic 11y agoYou make an excellent point which, unfortunately, is often not remembered by practitioners of our field (myself included).
- 11y ago
- AdieuToLogic 11y agoI was going to click the link, but it takes way too much time to RTFA and I already know where this is going to end up. Too soon?
- raiph 11y agoI got it even if no one else did. :)
- AdieuToLogic 11y agoVielen dank! Getting hammered by the votes was quite disheartening. I assumed indirect reference to one of Larry Wall's most famous quotes would be obvious. Ah well, I guess what happens when I "assume" is it makes an ass out of micro-me ;-).