12 ms·

The Importance of Humility in Software Development (2020)

289 points by raptorraver 5y ago

slimsag 5y ago
I have a hunch that when we (the public) talk about humility in software development, we really mean humility _in the act of writing code_ but not strictly in the rest of the process. Do the programmers that people look up to as role models (Torvalds, Jonathan Blow, Guido, Ken Thompson, Rob Pike, etc.) practice humility in the code they write? I would say yes, absolutely. Do they practice humility in the rest of the software development process? I'm not so sure it is cut-and-dry in this case. Outside of _writing code_, the software development process often leads to situations of "what is the right path to take?" which requires some form of leadership, and clear communication about some leader's own level of confidence in a given approach. It's a communication problem, and while practicing humility in this area often "sounds good" on paper - I think it often leads to death-by-committee. Am I wrong? Have I misinterpreted what people mean when they describe practicing humility in software development?
- Guthur 5y ago
  I think there has been a difficulty for some to delineate between agreeable and humble. Being humble does not mean you are passive and agreeable. It means that you can recognise you own fallibility and stand up to admit your mistakes and accept alternatives.
- deleted 5y ago
  [deleted]
Flex247A 5y ago
I started attending college a year ago. At that time, I didn't know much about programming: just a bit of C and some Python - enough to make first year college projects. After I started frequenting HN, I came across a lot of comments by developers on programming languages, toolchains, libraries, etc. Even though I didn't understand their arguments, I still believed what they said, because I thought they were experienced, so they must be right. Even though I hadn't used the tools personally, I started developing premature opinions on them: Java is verbose, so it must be avoided, PHP is inelegant etc. These opinions also gave a feeling of security: because I thought that I had chosen the right language for programming (Rust!), the right operating system, the right text editor (vim), and the right window manager (i3). This made me arrogant, because I saw myself as above my classmates, who were still using 'inferior' tools and still struggling to grasp the concept of command line arguments. Over time, I realised that I was just basing my beliefs on HN comments, and it is not healthy in the long run. This article helped me a lot towards realising that. Thank you for posting this article :) Edit: grammar
- SilverRed 5y ago
  To be fair though, there are better and worse tools. There are legitimate reasons to say that PHP should be avoided and that Rust is a good choice. It's just important to understand how much weight these opinions have and understand why they apply. If you are building a bulk file rename tool, it doesn't matter how you do it as long as it works. If you are handling untrusted data from remote sources, then you may want to consider if C is a good idea.
  - Flex247A 5y ago
    I agree with your points completely. Some tools are just better designed. I was talking about the premature opinions I had on these tools before I had even used them, or seen them in action. This is a problem as it limits my teamworking capabilities. For example, I decided to do the first year programming project all by myself as I thought nobody else could do it. Edit: added an example
  - moksly 5y ago
    I have a somewhat funny anecdote on this. One of our sister cities had a tool for handling city-water or something along those lines, that was build in ASP Web-forms. All the city engineers were perfectly happy with it, but the developers behind it were worried that ASP web forms were becoming obsolete. Not really an illegitimate concern I supposed, but what they did was hire a company to rebuild it in AngularJS. So now they have a technology nobody else uses around here, while web forms simply turtles on because of how much legacy it has in various places that aren’t upgrading it.
- dmos62 5y ago
  To have access to (or sense to use) better tools for given task is good. To be smug about it is bad. Actually, drop everything about technology in this discussion: being prideful is just bad.
- moksly 5y ago
  Good for you! I think one of the more important lessons is to realise that the programming community can be very disconnected from reality. This is especially true for HN with its heavy focus on “interesting”. Judging by HN, things like Erlang, Rust and previously Go, would see a lot of attention and so would the Kubernetes way of doing CI/CD. Interestingly there hasn’t been a single Rust, Erlang or Go job offering available in the region of the world where I live since I started tracking them out of interest after a similar discussion on HN in 2019. There are however a constant demand for JAVA, C# and PHP developers. Because that’s the languages that are used in my region of the world, and as interesting as something like Rust might be, you’d have a hard time actually finding a job working with it. Even JavaScript isn’t that outspread here, if what you’re after is a full-time JavaScript job, because there is almost always a JAVA, C# or PHP backend to go along with it. You can of course find C++ job, there aren’t many, but there are some and I’m sure some of those places actually use Rust behind the scenes, but they don’t advertise it. Anyway, I think my point is that there can be a big disconnect between HN and what you’re actually going to end up working with, and you’re likely not going to work with just one toolset for your entire career either. Before I became a manager, I spent almost a decade working mainly with .Net, but with the rise of things like Azure Services I stated working more and more with Python and Powershell, these days I almost exclusively work with Python as I’m mostly handling data for BI or management purposes and let the programming get done by my developers. We have recently picked up PHP though, which you likely wouldn’t think would happen in 2021 if you go by how dead PHP is supposed to be. Well, it so happened that there is a big open source project in my country that utilises Drupal to create a “forms generating” CMS system, that we want to be capable of building modules for, which means we needed someone to learn PHP. Another really valuable lesson in humility I learned, and it took me years to do so, is related to the arrogance many software developers adopt when we get into the real world and start building things with the business side. Because our skill-set is so linked to dissecting and understanding problems, some of us adopt the unfortunate habit of thing we know... well everything. I’ve been arrogant enough to think I understood how our payment business process worked better than our director of payments, and of course I didn’t, but it was just so used to handling problems that I though I did. If you can, do better than me and apply your humility to everything, not just tool chains.
vnkatesh 5y ago
Interesting, given Djikstra's 'reputed' arrogance. https://news.ycombinator.com/item?id=11796557 https://news.ycombinator.com/item?id=11796557
- deleted 5y ago
  [deleted]
- goto11 5y ago
  Here he is talking about humility in the act of writing code, by recognizing the limits of the minds capacity and therefore keeping the code simple to understand rather than clever. He wasn't particularly humble in his writings.
  - username90 5y ago
    Why would clever code be hard to use? Dijkstra talked about messy code, there is nothing wrong with clever code. Algorithms are very clever, but they are self contained and therefore easy to read and reason about and therefore not a problem. Trying to achieve the same things without being clever will just create a mess.
    - goto11 5y ago
      The article literally quotes Dijkstra for saying: > The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.
- harry8 5y ago
  Dijkstra's speech is total and complete arrogance. Djikstra is all "You need to get more humility dammit! You think you don't have to listen to me and do exactly what I say because you're smart but I am smart so I /know/ you're not! Be more humble! I'm right and you are not!" You can interpret parts of it in ways that are reasonable. We do need to be humble in any engineering endeavor is a stunning glimpse of the obvious and hardly worth an ACM Turing award lecture. His fondness for simultaneously formally proving what you program have basically very rarely if not actually never been made to work in a useful way by anyone and he falls into the trap of blaming everyone else for this practice not taking off. Everyone else is too arrogant to just do what the great man says when it doesn't work. Humility is a thing. I've just trashed Djikstra which is obviously a thing that must be done with humility... The humility of a random, semi-anonymous internet messsage board post is probably more humble than an ACM Turing award acceptance lecture. I'm a humble person with much to be humble about.
bluetomcat 5y ago
It should be a blend of humility and pride. Humility in approaching problems and possibility of failure, pride in the final solution when it has been carefully and mindfully devised. Without being proud of your work, it’s all too easy to fall in the trap of churning out valueless stuff.
- dmos62 5y ago
  I know it's culturally controversial, but I think pride is a bad emotion. It's better than some, like anger or fear, but when you're prideful you're saying you're better than someone and then being worse than someone is just around the corner. A prideful man thinks that everything needs to be sorted by some concept of good. It doesn't. You can do good things because you care about others, instead of doing them because you want to be good. This distinction is important.
  - RupertWiser 5y ago
    I disagree with this. I’d like to take a step back and even ask what a bad emotion really even means? That sounds a bit hand wavy. I like to get endorphins. I like that the field I chose as a career can give me that when I feel like I did something well. I think an argument goes into pretty vague territory if one tries to argue that it’s more “good” when you get a nice feeling from helping others instead of feeling nice from your own work.
    - dmos62 5y ago
      We know if an emotion is worse than another empirically. You'd rather feel joyful than ashamed, for example. You can aim for pride. That's fine. But there's better things. When you're prideful (self-inflating would be a good synonym) you're coming off as defensive. It begs the question why do you need that. The distinction between the "goods" I was talking about is a question of whether you're motivated by that defensiveness, or some sense of lack, or if it's an act of caring, or an act of joy, or whatever. There's a world of difference between those approaches to action.
quickthrower2 5y ago
Humility is important for all teamwork. And not just humility about the technial task at hand but in general.
gregfjohnson 5y ago
Excellent observations. The essay illustrates what it is advocating by the generous clarity, simplicity, and accessibility with which it is written. John Osterhout wrote what may be the best elaboration of this perspective in his wonderful book "A Philosophy of Software Design." A couple of related thoughts from an old grizzled programmer (moi ;-), gregfjohnson.com): Rule number one: All code must follow the Porthole Principle. The fundamental issue in programming is that we each look out at the world through a mental "porthole" that limits our field of view. We are limited in how much we can see and understand at any one time. Therefore, systems must be structured so that they can be understood completely, at all levels, even though we are only allowed to investigate them piecemeal, through our own limited and finite cognitive windows. Abstraction is the essential tool that allows us to create systems of arbitrary size and complexity. A beautifully designed abstraction is easy to understand and use. It is so trustworthy that you don't feel any need to worry about how it is implemented. Finally, and most importantly, it enables you to reason with rigor and precision about the correctness of the code you are writing that makes use of it.
- berkes 5y ago
  My rule of thumb is that 'the smartest code, is the code that you can work on in your dumbest moments'. Or, in a team, 'the most senior code, is the code where the most junior dev can easily work with'. They may seem obvious. But in practice, far too often do I encounter code that is far too complex, and fails your porthole principle, and extremely hard to reason about, or work in, without worrying. Now, when such code is made by an inexperienced dev, this is fine, and acceptable: finding the right abstractions, or even seeing the need for those, comes with experience. But when senior devs produce such poorly abstracted, hard to reason, complexities, it is inexcusable. It is your task to make complex problems simple. To make unreasonable domains reasonable. To apply the right abstractions in the right places. To make code that you can work on when tired, distracted and stressed. To build structures where a junior can feel at home in, in hours.
  - valenterry 5y ago
    Nice quote, but I would refine it a bit: 'The smartest code is the code that has your back in your dumbest moments and boosts your productivity in your best moments'
labster 5y ago
Larry Wall, father of patch, Perl, and Raku has declared hubris to be one of the key virtues of a programmer, along with impatience and laziness.[0]. But he’s an astoundingly humble man, so what gives? The hubris that he talks about is really about the ability to always say “I can do better,” and then to actually follow through. The pride to let your good works speak for itself looks an awful lot like humility in the end. [0]: http://threevirtues.com/ http://threevirtues.com/
- darkerside 5y ago
  Such verbal economy. It's not just pride, it's excessive pride, to imagine you could write a system that others wouldn't complain about. He says so much about humane as programmers, humans as users, and the nature of programming in so few words.
- rriepe 5y ago
  I just posted this too! It's the same idea but one is presented as humility and one as hubris.
- smoldesu 5y ago
  Absolutely. The number one thing driving me to write better code is knowing that I will likely share it with the world, and that it should be presentable and clean as a baseline expectation.
- nige123 5y ago
  Larry Wall also highlighted the importance of: diligence, patience and humility. https://www.oreilly.com/openbook/opensources/book/larry.html https://www.oreilly.com/openbook/opensources/book/larry.html
rriepe 5y ago
This post fits the definition of hubris under the three virtues[1]. [1] http://threevirtues.com/ http://threevirtues.com/
rasputnik6502 5y ago
You can be humble only when you're competent and you know it. Then you can make a choice. If you barely have the skill to somehow put stuff together so it kinda works then there's no place for such subtleties. So I'd rather have a skilled but showing off programmer than a humble untalented one
- pmiller2 5y ago
  I wouldn't. A humble, untalented (I'd rather say "unskilled" here) programmer is one who knows they're unskilled and wants to learn. I'll take someone who knows they have a lot to learn over someone who thinks they already know it all, any day.
  - rasputnik6502 5y ago
    Most of unskilled programmers i met did not become much better after years. They kinda reached their max and stayed there or got into management. So I wouldn't count on willingness to learn, the capability is the key
  - naveen99 5y ago
    But a skilled programmer knows how to assimilate a new code base. Clearly they aren’t going to claim to know the new code base before looking at it (so they aren’t going to claim to “know it all”)
    - rasputnik6502 5y ago
      Skilled programmer has the proficiency and courage to attack the problem and win. There's some boldness coming from knowledge and experience, and i like people showing that. On the other hand an unskilled person will not be able to understand the design, will be afraid to make changes, will get confused and ignore the parts they cant understand, and will not take the responsibility and initiative - they need to be guided all the time. Then i dont care if they're humble or not, there's nothing to be gained.
      - 5y ago
lstamour 5y ago
(2020), but timeless. If you like this post, you might also like reading the relatively short book, A Philosophy of Software Design by John Ousterhout, or the talk you'll find on YouTube by the same name, which covers roughly half the topics in the book.
watwut 5y ago
It is balance act in social aspect. Humility makes other people feel good about you on emotional level. But, if you dont display confidence and pride too, you will be effectively punished. People like humble people, but don't think they are as good as people who act confident or even arrogant.
- deleted 5y ago
  [deleted]
pmiller2 5y ago
I describe what I do in different ways, depending on who I'm talking to and how I feel about work. Sometimes, when I'm feeling good about things, I say "I make the internet," or "I tell computers what to do, and they do it." Other times, I say stuff like "I let a computer tell me I'm a fucking idiot for 8 hours a day," or, "I tell computers what to do, and they do it." :P The truth is really somewhere in between the two extremes. Another thing I often say is that most of the real hard problems in software development these days are social problems. What I mean by that is that you have to account for the characteristics and limitations of not only yourself, but the users of the software, the rest of your team, and your organization as a whole, when writing code or designing systems. In other words, don't get in over your head, make it usable, document what you've done, think about the consequences of what you're about to do (and write that down), and many other things. This is inherently a humble perspective, because, if you notice, you are the smallest thing that needs to be considered in all this.
cycomanic 5y ago
Did anyone else find it a bit ironic that the person talking about the importance of humility has a large "Microsoft MVP" logo on his blog? Doesn't take away from the validity of his points, but it made me chuckle a bit.
- berkes 5y ago
  The Humility from the article is not meant in the social context, but technical. It is about understanding how well we can reason about code, not about how humble we must present ourselves. The fact many commenters here talk about the social humility, makes me believe many hn readers have read the article (let alone the therein linked articles) poorly or not at all.
  - cycomanic 5y ago
    I think you can not so easily decouple "technical" and "social" humility. Dijkstra's advice/definition of humility was that we should be aware of our own limitations when programming. That is both a "technical" as well as "social" construct, for example to be aware of your own technical limitations is incompatible with saying "I am the best programmer in the world", or "I understand the most complex code", because it demonstrates an unawareness of your technical limitations IMO. However, my observation was largely a unrelated anecdote on the wording and not a critique of the author or the message.
  - username90 5y ago
    Thinking that you can create better abstractions than your predecessors isn't technical humility either. And neither is working hard to streamline processes "laziness". Those words are used to get people to click the link, not because they actually are relevant.
- executesorder66 5y ago
  Personally I'd find that embarrassing. But whatever floats your boat, I guess.
xwdv 5y ago
The importance of humility in software development? Very little. Hubris and flying too close to the sun is what has always pushed tech forward and turned average software developers into legendary ones, both for their success and for their failures.
arwhatever 5y ago
I think an extended conclusion to draw, which is worth articulating rather than leaving off at a vague notion of humility, is to (try your best to) account for all of our intellectual limitations in the design of the systems that we build. None of us remembers particularly well. No one can run all of the code in their head. The future person who has yet to join your team doesn’t even get the chance to “remember” the reasoning for the decisions that we make today.
yoz-y 5y ago
I liked the way Brent Simmons put it: since debugging is 10 times harder than writing code, write the code as you were 10 times dumber, otherwise you will not be able to fix it.
- chj 5y ago
  I thought it was from bwk.
- username90 5y ago
  Writing code is 10 times harder than debugging code if you write the code to be easy to debug. Partly because writing such code is harder and partly thanks to reducing the debug burden.
- graderjs 5y ago
  I thought this was Kernighan https://news.ycombinator.com/item?id=22348386 https://news.ycombinator.com/item?id=22348386
- oblio 5y ago
  https://en.wikiquote.org/wiki/Brian_Kernighan https://en.wikiquote.org/wiki/Brian_Kernighan > Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? From: https://en.wikipedia.org/wiki/The_Elements_of_Programming_Style https://en.wikipedia.org/wiki/The_Elements_of_Programming_St..., 2nd edition, 1978
  - yoz-y 5y ago
    I see. Brent’s blog was where I first read it but this is definitely older. Thanks.
nairodd 5y ago
didnt realize Dijkstra was a language troll xD
marcus_holmes 5y ago
This resonates so much. I love coding in Go because of the emphasis on simplicity. Avoiding clever tricks seems counter-intuitive, but after decades of coding, I completely agree. They give me a buzz when I write them (part of my enjoyment of coding is from finding clever solutions to problems, after all), but they always bite me in the arse later.
29athrowaway 5y ago
Humility is different from being submissive. Humility is accepting you can be wrong, or what you do is suboptimal, etc. Being submissive is conceding arguments even if you know you are right and you can prove it. Companies are not democracies. Companies claim to be meritocracies but are not. Companies are ultimately governed by authority. Authority defines what is truth and what is not: authoritative truth. Each authoritative truth is a fork from reality, and is in a way, a form of fiction. Authoritative truth can go against logic, applied science, empirical evidence, common sense, ethics and morality. It does not have to be correct, authority makes it correct. Because of this, engineering and authority are completely opposite things. An authority with humility will try to lead the team towards understanding things from first principles. An authority without humility will be creating and expanding on authoritative truth.
eraserj 5y ago
Audio of the mentioned 1972 ACM Turing Award lecture by Edsger W. Dijkstra : https://youtu.be/0dGXRK8FUVg?t=148 https://youtu.be/0dGXRK8FUVg?t=148 Transcript : https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340...
alien_player 5y ago
If I'd wanted to bring a thing that modern software development needs right now. I'd say it's optimizations. But, unfortunately, so many companies, big & small, disregard this critical step because of the insane performance that comes from modern hardware. I guess the gaming industry is the most affected and the one where these issues are most easy to notice.
- eraserj 5y ago
  Time spent optimizing is time spent not adding features. /s The "business value" of software optimization is not well known.
  - imhoguy 5y ago
    I wonder if computing resources peak, which I think we are at now with hardware manufacturing shortages and price explosion (GPUs, HDDs, SSDs), is going to change this perspective.
    - EricE 5y ago
      lol - people were saying this in the 80's yet software has shown it can always outstrip the hardware resources thrown at it if one is not careful :)
    - EricE 5y ago
      BTW came across this in some other reading today: https://mechanical-sympathy.blogspot.com/2011/07/why-mechanical-sympathy.html https://mechanical-sympathy.blogspot.com/2011/07/why-mechani...
bumbada 5y ago
It is also important to be extremely arrogant and not know your limitations in the sense of Donald Knuth: Had he known his limitations and the time it will take he would never have started Tex or TAOCP, in his own words. Non knowing my limitations was essential for me as well. When I was a kid I saw a world full of possibilities and I could do much better than anybody else. It was not that easy, it was painful and I needed help for getting things done. But if I had not been the arrogant bastard I was I would have never started the things that later finished for pride. I would also had not improved my skills in the way that I did because I had to give what I promised.
deleted 5y ago
[deleted]
mybrid 5y ago
Money rules software no less than any other industry. Sometimes I think the hubris of software is meritocracy and efficacy rules software. Sure... Software is prone to the tower of Babel, not invented here, tribalism, and greed that permeates all human endeavors. There are islands of productivty just like any other capitalist domain. Software is not special in its place in human endeavors but its practioners like to think they are beyond the mundane aspects of our nature. At times it is cute, but mostly just droll.
grahamlee 5y ago
Maybe not one to practice what he preached; as Alan Kay observed, arrogance in computer science is measured in nano-dijkstras.
- disqard 5y ago
  Indeed, I was also surprised by the provenance of that quote. See: https://medium.com/@acidflask/this-guys-arrogance-takes-your-breath-away-5b903624ca5f https://medium.com/@acidflask/this-guys-arrogance-takes-your...
  - PoignardAzur 5y ago
    I'm not seeing much evidence of Dijkstra being unbelievably arrogant in those letters. This mostly seems to be two stuck-up academics caught up in sniping (very cordially) at each other over petty academic crap. EDIT: Okay, I've read EWD692 and I get why Backus was pissed now. This still feels a lot milder than people are suggesting.
    - grahamlee 5y ago
      Note that Backus's complaint is in relation to EWD638, where Dijkstra tears apart every claim made in a paper and accuses the authors of having a "pre-scientific attitude" and giving "the impression of anti-intellectualistic reactionaries". But none of this explains why the "provenance" of Alan Kay's statement about Dijkstra's arrogance is supplied in a retelling of Backus's statement about Dijkstra's arrogance. The provenance of Alan Kay's statement is that Alan Kay said it, in his OOPSLA keynote.
112 5y ago
This article feels like it's been written by GPT.
deleted 5y ago
[deleted]
muds 5y ago
Reminds me of the first couple of pages from SICP[1]: ``I think that it's extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customers got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don't think we are. I think we're responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don't become missionaries. Don't feel as if you're Bible salesmen. The world has too many of those already. What you know about computing other people will learn. Don't feel as if the key to successful computing is only in your hands. What's in your hands, I think and hope, is intelligence: the ability to see the machine as more than when you were first led up to it, that you can make it more.'' [1] <https://mitpress.mit.edu/sites/default/files/sicp/index.html https://mitpress.mit.edu/sites/default/files/sicp/index.html>
- smithza 5y ago
  I like that. It also reminds me of Fred Brook's second essay in the Mythical Man-Month. He elucidates that SW engineer's optimism can often be an issue with schedule. Too often SW engineers don't carry the humility that they make mistakes and that they constantly expect fewer bugs exist than do by the time test time comes along.
lbriner 5y ago
I think a common issue with cargo-cult technologies/languages/frameworks is that although the ultimate benefit might be great, there is often a significant cost to get there that makes it not worth it for some people/companies. For example, is Go a great language? No doubt. Is it worth ditching a load of code we already have and take the time to learn how to do it well? Not necessarily. Are microservices cool? Absolutely. Should everyone use them? Definitely not. People who see "Go is great" and immediately start down that path do not understand that context is everything.
heisenbit 5y ago
Rather than reading this short blog post read the underlying "ACM Turing Lecture 1972" by Dijkstra https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.... There is a lot more wisdom to it.
username90 5y ago
Humility isn't important, a an accurate assessment of your capabilities is important. A good assessment of yourself isn't humility. Dijkstra wrote a lot of "deep but not really" quotes that makes perfect headlines and generates clicks and traffic for your blog. Doesn't make them good advice. His full articles are better but people just use the short quotes and writes blogs based on those.
smitty1e 5y ago
> Let me be clear. I’m not trying to reinforce impostor syndrome. No, it's just that non-trivial efforts tend to be heuristic in nature.
bitL 5y ago
Nobody gets promoted for being humble, rather pushed out of a company for a lack of ambition. Everybody loves energetic extroverts that could argue well and with proper tunnel vision to skip thinking about potential problems if it helps the bottom line immediately.
- commandlinefan 5y ago
  I read this advice as being humble when coding as in not assuming that you got everything right the first time - in other words, test the hell out of everything, even if you're sure it's right. Then, when you have tested it inside and out, you can be as confident face-to-face that you did get it right.
tored 5y ago
Dijkstra also said For a number of years I have been familiar with the observation that the quality of programmers is a decreasing function of the density of go to statements in the programs they produce. Not so humble.
yread 5y ago
Humility also helps push you to measure things and assume less. And lack of humility can make you trust that your code just works and not test it as thoroughly
- naveen99 5y ago
  /s/lack of humility/overconfidence So is humility underconfidence ? Is their a word for the right amount of confidence ? Maybe confidence ?
doggodaddo78 5y ago
I recall the retelling of a startup interviewee comment who tanked their opportunity by saying "the salary: make it a big number." Furthermore, I notice in clinical healthcare and software engineering that ego tends to be inversely proportional to capabilities because the jerk reaches hubris by stopping learning and assuming they're always right, leading to less knowledge, career development, feedback, and authentic peer interactions. Eventually, they become the "I've been doing this for X years" people. They become infinitely awesome, but in their own minds only.
thrwaeasddsaf 5y ago
The biggest challenge here I think is that we don't have an objective definition of clever code, and if you ask, most people will just try to retroactively justify why the current mainstream way of writing things is good and not at all clever. If you do something unusual, people think you're trying to be clever. I think that a lot of the stuff people take for granted in modern programming languages would've been considered clever tricks or just complex and alien mechanisms by the average programmer around when I started 25 years ago (remember serious business that ran on basic?). The way mainstream code looks today has changed a lot compared to then, and I predict it will still change a lot.
bourgwaletariat 5y ago
We can start by thinking of software as the tool, rather than the product. We tend to pride ourselves on the software we create, rather than priding ourselves on the problem we have solved. We have pushed the concept of tool down. So, what I mean is this, we think of jQuery as the tool and the website as the product. Or Angular as the tool. Insert library. This keeps us in a hamster wheel of learning to use tools to build products, rather than building products to solve problems. The software is not the goal. The solution is the goal. I see this as a human issue in lots of fields. Carpenters love to debate dewalt vs makita vs milwaukee, but it's the thing built with the tool that matters, not the tool. Imagine carpenters striving to learn how to use different brands of circular saw. We debate angular vs react vs jquery. Why do we care about that? Because that is about us rather than the product. I know jQuery. I know angular. Angular is better than react, therefore I am better than you. That is the opposite of humility. That is arrogance. We are stuck in a loop of solving the problem of solving problems. We need to get to the next level. I see it now with Canvas vs DOM.
cryptica 5y ago
Humility is extremely important. As a senior developer with over 15 years of experience, I'm tired of being lectured by junior developers with 5 years experience about things which I know to be incorrect because I used to think the same way but have since learned better. If I try to tell people that some approach x is incorrect in this particular case because of reason y, they think I must be a dinosaur because all the articles they read online indicate that approach x is popular and therefore I must be wrong and lazy... As if I had been twiddling my thumbs for the past 15 years, when in fact I've been working non-stop nights, weekends, day job, open source side projects etc... It's infuriating. I don't know what to say. Nowadays if I encounter such junior dev, I don't even try to start to correct them. Nothing can be done. We have reached peak intellect and things are going down. People will simply get dumber, unsophisticated black-and-white thinking will become more pervasive and I need to learn to live with that; sit quietly in meetings, smile, nod and cash my paycheck.
chhickman 5y ago
This is perhaps going to be an unpopular sentiment, but I think far too much breath is wasted on the "don't be clever" edict. No examples even spring to mind of any past experience where I ran into someone's "too clever" code causing me headaches. It has been dealing with the mountains of "not the least bit clever" code that has sucked thousands of hours out of my career. Mundane, "straightforward" code where they've re-used variables for different purposes, or deeply nested conditionals with multiple, multiple booleans in each check (often redundant, if not contradictory) and generally taken 50 lines of code to accomplish what could be done more cleanly in 10 or fewer. I'll take puzzling a few minutes over some too clever code over slogging through spaghetti code any day.
- ysavir 5y ago
  From your description it feels less like an issue with the code not being clever enough and more like an issue with the code not being organized and architected efficiently. I think the "don't be clever" edict applies to code segments that are best described as "you won't believe what happens next!", and fairly so.
- semitones 5y ago
  imo unclever code != poorly designed / spaghetti code Reusing variables in a way that is confusing is a code smell, and rather than being "unclever", I would characterize it more as just "bad". In my mind, an example of code that is "too clever" looks more like this: while (*dest++ = *src++); Unless you've seen that exact pattern many times, when trying to understand it you will have to unwrap it in your mind into something that looks more like the longer, "unclever" version anyway.
efitz 5y ago
I think that humility is important in all endeavors, not just software development. I know a lot of people who seem to think that expertise on one area somehow magically transfers to other areas. Just because you’re smart or good at <insert computer skill here> does not mean that you automatically will be able to accurately judge <insert non computer related issue here>. And expertise can be incredibly narrow- when dealing with complex systems and interrelationships between such systems, it’s really easy to accidentally encounter problems that you might not have expertise in; in fact you might not even be prepared to even recognize that you’re out of your depth.
deleted 5y ago
[deleted]
ozim 5y ago
My problem is that mostly I see "abstraction" used as a gateway to introduce "clever tricks" instead of making things easier.

289 points by raptorraver 5y ago

I have a hunch that when we (the public) talk about humility in software development, we really mean humility _in the act of writing code_ but not strictly in the rest of the process. Do the programmers that people look up to as role models (Torvalds, Jonathan Blow, Guido, Ken Thompson, Rob Pike, etc.) practice humility in the code they write? I would say yes, absolutely. Do they practice humility in the rest of the software development process? I'm not so sure it is cut-and-dry in this case. Outside of _writing code_, the software development process often leads to situations of "what is the right path to take?" which requires some form of leadership, and clear communication about some leader's own level of confidence in a given approach. It's a communication problem, and while practicing humility in this area often "sounds good" on paper - I think it often leads to death-by-committee. Am I wrong? Have I misinterpreted what people mean when they describe practicing humility in software development?

Guthur 5y ago
I think there has been a difficulty for some to delineate between agreeable and humble. Being humble does not mean you are passive and agreeable. It means that you can recognise you own fallibility and stand up to admit your mistakes and accept alternatives.
deleted 5y ago
[deleted]

Flex247A 5y ago

I started attending college a year ago. At that time, I didn't know much about programming: just a bit of C and some Python - enough to make first year college projects. After I started frequenting HN, I came across a lot of comments by developers on programming languages, toolchains, libraries, etc. Even though I didn't understand their arguments, I still believed what they said, because I thought they were experienced, so they must be right. Even though I hadn't used the tools personally, I started developing premature opinions on them: Java is verbose, so it must be avoided, PHP is inelegant etc. These opinions also gave a feeling of security: because I thought that I had chosen the right language for programming (Rust!), the right operating system, the right text editor (vim), and the right window manager (i3). This made me arrogant, because I saw myself as above my classmates, who were still using 'inferior' tools and still struggling to grasp the concept of command line arguments. Over time, I realised that I was just basing my beliefs on HN comments, and it is not healthy in the long run. This article helped me a lot towards realising that. Thank you for posting this article :) Edit: grammar

SilverRed 5y ago
To be fair though, there are better and worse tools. There are legitimate reasons to say that PHP should be avoided and that Rust is a good choice. It's just important to understand how much weight these opinions have and understand why they apply. If you are building a bulk file rename tool, it doesn't matter how you do it as long as it works. If you are handling untrusted data from remote sources, then you may want to consider if C is a good idea.
- Flex247A 5y ago
  I agree with your points completely. Some tools are just better designed. I was talking about the premature opinions I had on these tools before I had even used them, or seen them in action. This is a problem as it limits my teamworking capabilities. For example, I decided to do the first year programming project all by myself as I thought nobody else could do it. Edit: added an example
- moksly 5y ago
  I have a somewhat funny anecdote on this. One of our sister cities had a tool for handling city-water or something along those lines, that was build in ASP Web-forms. All the city engineers were perfectly happy with it, but the developers behind it were worried that ASP web forms were becoming obsolete. Not really an illegitimate concern I supposed, but what they did was hire a company to rebuild it in AngularJS. So now they have a technology nobody else uses around here, while web forms simply turtles on because of how much legacy it has in various places that aren’t upgrading it.
dmos62 5y ago
To have access to (or sense to use) better tools for given task is good. To be smug about it is bad. Actually, drop everything about technology in this discussion: being prideful is just bad.
moksly 5y ago
Good for you! I think one of the more important lessons is to realise that the programming community can be very disconnected from reality. This is especially true for HN with its heavy focus on “interesting”. Judging by HN, things like Erlang, Rust and previously Go, would see a lot of attention and so would the Kubernetes way of doing CI/CD. Interestingly there hasn’t been a single Rust, Erlang or Go job offering available in the region of the world where I live since I started tracking them out of interest after a similar discussion on HN in 2019. There are however a constant demand for JAVA, C# and PHP developers. Because that’s the languages that are used in my region of the world, and as interesting as something like Rust might be, you’d have a hard time actually finding a job working with it. Even JavaScript isn’t that outspread here, if what you’re after is a full-time JavaScript job, because there is almost always a JAVA, C# or PHP backend to go along with it. You can of course find C++ job, there aren’t many, but there are some and I’m sure some of those places actually use Rust behind the scenes, but they don’t advertise it. Anyway, I think my point is that there can be a big disconnect between HN and what you’re actually going to end up working with, and you’re likely not going to work with just one toolset for your entire career either. Before I became a manager, I spent almost a decade working mainly with .Net, but with the rise of things like Azure Services I stated working more and more with Python and Powershell, these days I almost exclusively work with Python as I’m mostly handling data for BI or management purposes and let the programming get done by my developers. We have recently picked up PHP though, which you likely wouldn’t think would happen in 2021 if you go by how dead PHP is supposed to be. Well, it so happened that there is a big open source project in my country that utilises Drupal to create a “forms generating” CMS system, that we want to be capable of building modules for, which means we needed someone to learn PHP. Another really valuable lesson in humility I learned, and it took me years to do so, is related to the arrogance many software developers adopt when we get into the real world and start building things with the business side. Because our skill-set is so linked to dissecting and understanding problems, some of us adopt the unfortunate habit of thing we know... well everything. I’ve been arrogant enough to think I understood how our payment business process worked better than our director of payments, and of course I didn’t, but it was just so used to handling problems that I though I did. If you can, do better than me and apply your humility to everything, not just tool chains.

vnkatesh 5y ago

Interesting, given Djikstra's 'reputed' arrogance. https://news.ycombinator.com/item?id=11796557 https://news.ycombinator.com/item?id=11796557

deleted 5y ago
[deleted]
goto11 5y ago
Here he is talking about humility in the act of writing code, by recognizing the limits of the minds capacity and therefore keeping the code simple to understand rather than clever. He wasn't particularly humble in his writings.
- username90 5y ago
  Why would clever code be hard to use? Dijkstra talked about messy code, there is nothing wrong with clever code. Algorithms are very clever, but they are self contained and therefore easy to read and reason about and therefore not a problem. Trying to achieve the same things without being clever will just create a mess.
  - goto11 5y ago
    The article literally quotes Dijkstra for saying: > The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.
harry8 5y ago
Dijkstra's speech is total and complete arrogance. Djikstra is all "You need to get more humility dammit! You think you don't have to listen to me and do exactly what I say because you're smart but I am smart so I /know/ you're not! Be more humble! I'm right and you are not!" You can interpret parts of it in ways that are reasonable. We do need to be humble in any engineering endeavor is a stunning glimpse of the obvious and hardly worth an ACM Turing award lecture. His fondness for simultaneously formally proving what you program have basically very rarely if not actually never been made to work in a useful way by anyone and he falls into the trap of blaming everyone else for this practice not taking off. Everyone else is too arrogant to just do what the great man says when it doesn't work. Humility is a thing. I've just trashed Djikstra which is obviously a thing that must be done with humility... The humility of a random, semi-anonymous internet messsage board post is probably more humble than an ACM Turing award acceptance lecture. I'm a humble person with much to be humble about.

bluetomcat 5y ago

It should be a blend of humility and pride. Humility in approaching problems and possibility of failure, pride in the final solution when it has been carefully and mindfully devised. Without being proud of your work, it’s all too easy to fall in the trap of churning out valueless stuff.

dmos62 5y ago
I know it's culturally controversial, but I think pride is a bad emotion. It's better than some, like anger or fear, but when you're prideful you're saying you're better than someone and then being worse than someone is just around the corner. A prideful man thinks that everything needs to be sorted by some concept of good. It doesn't. You can do good things because you care about others, instead of doing them because you want to be good. This distinction is important.
- RupertWiser 5y ago
  I disagree with this. I’d like to take a step back and even ask what a bad emotion really even means? That sounds a bit hand wavy. I like to get endorphins. I like that the field I chose as a career can give me that when I feel like I did something well. I think an argument goes into pretty vague territory if one tries to argue that it’s more “good” when you get a nice feeling from helping others instead of feeling nice from your own work.
  - dmos62 5y ago
    We know if an emotion is worse than another empirically. You'd rather feel joyful than ashamed, for example. You can aim for pride. That's fine. But there's better things. When you're prideful (self-inflating would be a good synonym) you're coming off as defensive. It begs the question why do you need that. The distinction between the "goods" I was talking about is a question of whether you're motivated by that defensiveness, or some sense of lack, or if it's an act of caring, or an act of joy, or whatever. There's a world of difference between those approaches to action.

quickthrower2 5y ago

Humility is important for all teamwork. And not just humility about the technial task at hand but in general.

gregfjohnson 5y ago

Excellent observations. The essay illustrates what it is advocating by the generous clarity, simplicity, and accessibility with which it is written. John Osterhout wrote what may be the best elaboration of this perspective in his wonderful book "A Philosophy of Software Design." A couple of related thoughts from an old grizzled programmer (moi ;-), gregfjohnson.com): Rule number one: All code must follow the Porthole Principle. The fundamental issue in programming is that we each look out at the world through a mental "porthole" that limits our field of view. We are limited in how much we can see and understand at any one time. Therefore, systems must be structured so that they can be understood completely, at all levels, even though we are only allowed to investigate them piecemeal, through our own limited and finite cognitive windows. Abstraction is the essential tool that allows us to create systems of arbitrary size and complexity. A beautifully designed abstraction is easy to understand and use. It is so trustworthy that you don't feel any need to worry about how it is implemented. Finally, and most importantly, it enables you to reason with rigor and precision about the correctness of the code you are writing that makes use of it.

berkes 5y ago
My rule of thumb is that 'the smartest code, is the code that you can work on in your dumbest moments'. Or, in a team, 'the most senior code, is the code where the most junior dev can easily work with'. They may seem obvious. But in practice, far too often do I encounter code that is far too complex, and fails your porthole principle, and extremely hard to reason about, or work in, without worrying. Now, when such code is made by an inexperienced dev, this is fine, and acceptable: finding the right abstractions, or even seeing the need for those, comes with experience. But when senior devs produce such poorly abstracted, hard to reason, complexities, it is inexcusable. It is your task to make complex problems simple. To make unreasonable domains reasonable. To apply the right abstractions in the right places. To make code that you can work on when tired, distracted and stressed. To build structures where a junior can feel at home in, in hours.
- valenterry 5y ago
  Nice quote, but I would refine it a bit: 'The smartest code is the code that has your back in your dumbest moments and boosts your productivity in your best moments'

labster 5y ago

Larry Wall, father of patch, Perl, and Raku has declared hubris to be one of the key virtues of a programmer, along with impatience and laziness.[0]. But he’s an astoundingly humble man, so what gives? The hubris that he talks about is really about the ability to always say “I can do better,” and then to actually follow through. The pride to let your good works speak for itself looks an awful lot like humility in the end. [0]: http://threevirtues.com/ http://threevirtues.com/

darkerside 5y ago
Such verbal economy. It's not just pride, it's excessive pride, to imagine you could write a system that others wouldn't complain about. He says so much about humane as programmers, humans as users, and the nature of programming in so few words.
rriepe 5y ago
I just posted this too! It's the same idea but one is presented as humility and one as hubris.
smoldesu 5y ago
Absolutely. The number one thing driving me to write better code is knowing that I will likely share it with the world, and that it should be presentable and clean as a baseline expectation.
nige123 5y ago
Larry Wall also highlighted the importance of: diligence, patience and humility. https://www.oreilly.com/openbook/opensources/book/larry.html https://www.oreilly.com/openbook/opensources/book/larry.html

rriepe 5y ago

This post fits the definition of hubris under the three virtues[1]. [1] http://threevirtues.com/ http://threevirtues.com/

rasputnik6502 5y ago

You can be humble only when you're competent and you know it. Then you can make a choice. If you barely have the skill to somehow put stuff together so it kinda works then there's no place for such subtleties. So I'd rather have a skilled but showing off programmer than a humble untalented one

pmiller2 5y ago
I wouldn't. A humble, untalented (I'd rather say "unskilled" here) programmer is one who knows they're unskilled and wants to learn. I'll take someone who knows they have a lot to learn over someone who thinks they already know it all, any day.
- rasputnik6502 5y ago
  Most of unskilled programmers i met did not become much better after years. They kinda reached their max and stayed there or got into management. So I wouldn't count on willingness to learn, the capability is the key
- naveen99 5y ago
  But a skilled programmer knows how to assimilate a new code base. Clearly they aren’t going to claim to know the new code base before looking at it (so they aren’t going to claim to “know it all”)
  - rasputnik6502 5y ago
    Skilled programmer has the proficiency and courage to attack the problem and win. There's some boldness coming from knowledge and experience, and i like people showing that. On the other hand an unskilled person will not be able to understand the design, will be afraid to make changes, will get confused and ignore the parts they cant understand, and will not take the responsibility and initiative - they need to be guided all the time. Then i dont care if they're humble or not, there's nothing to be gained.
    - 5y ago

lstamour 5y ago

(2020), but timeless. If you like this post, you might also like reading the relatively short book, A Philosophy of Software Design by John Ousterhout, or the talk you'll find on YouTube by the same name, which covers roughly half the topics in the book.

watwut 5y ago

It is balance act in social aspect. Humility makes other people feel good about you on emotional level. But, if you dont display confidence and pride too, you will be effectively punished. People like humble people, but don't think they are as good as people who act confident or even arrogant.

deleted 5y ago
[deleted]

pmiller2 5y ago

I describe what I do in different ways, depending on who I'm talking to and how I feel about work. Sometimes, when I'm feeling good about things, I say "I make the internet," or "I tell computers what to do, and they do it." Other times, I say stuff like "I let a computer tell me I'm a fucking idiot for 8 hours a day," or, "I tell computers what to do, and they do it." :P The truth is really somewhere in between the two extremes. Another thing I often say is that most of the real hard problems in software development these days are social problems. What I mean by that is that you have to account for the characteristics and limitations of not only yourself, but the users of the software, the rest of your team, and your organization as a whole, when writing code or designing systems. In other words, don't get in over your head, make it usable, document what you've done, think about the consequences of what you're about to do (and write that down), and many other things. This is inherently a humble perspective, because, if you notice, you are the smallest thing that needs to be considered in all this.

cycomanic 5y ago

Did anyone else find it a bit ironic that the person talking about the importance of humility has a large "Microsoft MVP" logo on his blog? Doesn't take away from the validity of his points, but it made me chuckle a bit.

berkes 5y ago
The Humility from the article is not meant in the social context, but technical. It is about understanding how well we can reason about code, not about how humble we must present ourselves. The fact many commenters here talk about the social humility, makes me believe many hn readers have read the article (let alone the therein linked articles) poorly or not at all.
- cycomanic 5y ago
  I think you can not so easily decouple "technical" and "social" humility. Dijkstra's advice/definition of humility was that we should be aware of our own limitations when programming. That is both a "technical" as well as "social" construct, for example to be aware of your own technical limitations is incompatible with saying "I am the best programmer in the world", or "I understand the most complex code", because it demonstrates an unawareness of your technical limitations IMO. However, my observation was largely a unrelated anecdote on the wording and not a critique of the author or the message.
- username90 5y ago
  Thinking that you can create better abstractions than your predecessors isn't technical humility either. And neither is working hard to streamline processes "laziness". Those words are used to get people to click the link, not because they actually are relevant.
executesorder66 5y ago
Personally I'd find that embarrassing. But whatever floats your boat, I guess.

xwdv 5y ago

The importance of humility in software development? Very little. Hubris and flying too close to the sun is what has always pushed tech forward and turned average software developers into legendary ones, both for their success and for their failures.

arwhatever 5y ago

I think an extended conclusion to draw, which is worth articulating rather than leaving off at a vague notion of humility, is to (try your best to) account for all of our intellectual limitations in the design of the systems that we build. None of us remembers particularly well. No one can run all of the code in their head. The future person who has yet to join your team doesn’t even get the chance to “remember” the reasoning for the decisions that we make today.

yoz-y 5y ago

I liked the way Brent Simmons put it: since debugging is 10 times harder than writing code, write the code as you were 10 times dumber, otherwise you will not be able to fix it.

chj 5y ago
I thought it was from bwk.
username90 5y ago
Writing code is 10 times harder than debugging code if you write the code to be easy to debug. Partly because writing such code is harder and partly thanks to reducing the debug burden.
graderjs 5y ago
I thought this was Kernighan https://news.ycombinator.com/item?id=22348386 https://news.ycombinator.com/item?id=22348386
oblio 5y ago
https://en.wikiquote.org/wiki/Brian_Kernighan https://en.wikiquote.org/wiki/Brian_Kernighan > Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? From: https://en.wikipedia.org/wiki/The_Elements_of_Programming_Style https://en.wikipedia.org/wiki/The_Elements_of_Programming_St..., 2nd edition, 1978
- yoz-y 5y ago
  I see. Brent’s blog was where I first read it but this is definitely older. Thanks.

nairodd 5y ago

didnt realize Dijkstra was a language troll xD

marcus_holmes 5y ago

This resonates so much. I love coding in Go because of the emphasis on simplicity. Avoiding clever tricks seems counter-intuitive, but after decades of coding, I completely agree. They give me a buzz when I write them (part of my enjoyment of coding is from finding clever solutions to problems, after all), but they always bite me in the arse later.

29athrowaway 5y ago

Humility is different from being submissive. Humility is accepting you can be wrong, or what you do is suboptimal, etc. Being submissive is conceding arguments even if you know you are right and you can prove it. Companies are not democracies. Companies claim to be meritocracies but are not. Companies are ultimately governed by authority. Authority defines what is truth and what is not: authoritative truth. Each authoritative truth is a fork from reality, and is in a way, a form of fiction. Authoritative truth can go against logic, applied science, empirical evidence, common sense, ethics and morality. It does not have to be correct, authority makes it correct. Because of this, engineering and authority are completely opposite things. An authority with humility will try to lead the team towards understanding things from first principles. An authority without humility will be creating and expanding on authoritative truth.

eraserj 5y ago

Audio of the mentioned 1972 ACM Turing Award lecture by Edsger W. Dijkstra : https://youtu.be/0dGXRK8FUVg?t=148 https://youtu.be/0dGXRK8FUVg?t=148 Transcript : https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340...

alien_player 5y ago

If I'd wanted to bring a thing that modern software development needs right now. I'd say it's optimizations. But, unfortunately, so many companies, big & small, disregard this critical step because of the insane performance that comes from modern hardware. I guess the gaming industry is the most affected and the one where these issues are most easy to notice.

eraserj 5y ago
Time spent optimizing is time spent not adding features. /s The "business value" of software optimization is not well known.
- imhoguy 5y ago
  I wonder if computing resources peak, which I think we are at now with hardware manufacturing shortages and price explosion (GPUs, HDDs, SSDs), is going to change this perspective.
  - EricE 5y ago
    lol - people were saying this in the 80's yet software has shown it can always outstrip the hardware resources thrown at it if one is not careful :)
  - EricE 5y ago
    BTW came across this in some other reading today: https://mechanical-sympathy.blogspot.com/2011/07/why-mechanical-sympathy.html https://mechanical-sympathy.blogspot.com/2011/07/why-mechani...

bumbada 5y ago

It is also important to be extremely arrogant and not know your limitations in the sense of Donald Knuth: Had he known his limitations and the time it will take he would never have started Tex or TAOCP, in his own words. Non knowing my limitations was essential for me as well. When I was a kid I saw a world full of possibilities and I could do much better than anybody else. It was not that easy, it was painful and I needed help for getting things done. But if I had not been the arrogant bastard I was I would have never started the things that later finished for pride. I would also had not improved my skills in the way that I did because I had to give what I promised.

deleted 5y ago

[deleted]

mybrid 5y ago

Money rules software no less than any other industry. Sometimes I think the hubris of software is meritocracy and efficacy rules software. Sure... Software is prone to the tower of Babel, not invented here, tribalism, and greed that permeates all human endeavors. There are islands of productivty just like any other capitalist domain. Software is not special in its place in human endeavors but its practioners like to think they are beyond the mundane aspects of our nature. At times it is cute, but mostly just droll.

grahamlee 5y ago

Maybe not one to practice what he preached; as Alan Kay observed, arrogance in computer science is measured in nano-dijkstras.

disqard 5y ago
Indeed, I was also surprised by the provenance of that quote. See: https://medium.com/@acidflask/this-guys-arrogance-takes-your-breath-away-5b903624ca5f https://medium.com/@acidflask/this-guys-arrogance-takes-your...
- PoignardAzur 5y ago
  I'm not seeing much evidence of Dijkstra being unbelievably arrogant in those letters. This mostly seems to be two stuck-up academics caught up in sniping (very cordially) at each other over petty academic crap. EDIT: Okay, I've read EWD692 and I get why Backus was pissed now. This still feels a lot milder than people are suggesting.
  - grahamlee 5y ago
    Note that Backus's complaint is in relation to EWD638, where Dijkstra tears apart every claim made in a paper and accuses the authors of having a "pre-scientific attitude" and giving "the impression of anti-intellectualistic reactionaries". But none of this explains why the "provenance" of Alan Kay's statement about Dijkstra's arrogance is supplied in a retelling of Backus's statement about Dijkstra's arrogance. The provenance of Alan Kay's statement is that Alan Kay said it, in his OOPSLA keynote.

112 5y ago

This article feels like it's been written by GPT.

deleted 5y ago

[deleted]

muds 5y ago

Reminds me of the first couple of pages from SICP[1]: ``I think that it's extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customers got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don't think we are. I think we're responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don't become missionaries. Don't feel as if you're Bible salesmen. The world has too many of those already. What you know about computing other people will learn. Don't feel as if the key to successful computing is only in your hands. What's in your hands, I think and hope, is intelligence: the ability to see the machine as more than when you were first led up to it, that you can make it more.'' [1] <https://mitpress.mit.edu/sites/default/files/sicp/index.html https://mitpress.mit.edu/sites/default/files/sicp/index.html>

smithza 5y ago
I like that. It also reminds me of Fred Brook's second essay in the Mythical Man-Month. He elucidates that SW engineer's optimism can often be an issue with schedule. Too often SW engineers don't carry the humility that they make mistakes and that they constantly expect fewer bugs exist than do by the time test time comes along.

lbriner 5y ago

I think a common issue with cargo-cult technologies/languages/frameworks is that although the ultimate benefit might be great, there is often a significant cost to get there that makes it not worth it for some people/companies. For example, is Go a great language? No doubt. Is it worth ditching a load of code we already have and take the time to learn how to do it well? Not necessarily. Are microservices cool? Absolutely. Should everyone use them? Definitely not. People who see "Go is great" and immediately start down that path do not understand that context is everything.

heisenbit 5y ago

Rather than reading this short blog post read the underlying "ACM Turing Lecture 1972" by Dijkstra https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.... There is a lot more wisdom to it.

username90 5y ago

Humility isn't important, a an accurate assessment of your capabilities is important. A good assessment of yourself isn't humility. Dijkstra wrote a lot of "deep but not really" quotes that makes perfect headlines and generates clicks and traffic for your blog. Doesn't make them good advice. His full articles are better but people just use the short quotes and writes blogs based on those.

smitty1e 5y ago

> Let me be clear. I’m not trying to reinforce impostor syndrome. No, it's just that non-trivial efforts tend to be heuristic in nature.

bitL 5y ago

Nobody gets promoted for being humble, rather pushed out of a company for a lack of ambition. Everybody loves energetic extroverts that could argue well and with proper tunnel vision to skip thinking about potential problems if it helps the bottom line immediately.

commandlinefan 5y ago
I read this advice as being humble when coding as in not assuming that you got everything right the first time - in other words, test the hell out of everything, even if you're sure it's right. Then, when you have tested it inside and out, you can be as confident face-to-face that you did get it right.

tored 5y ago

Dijkstra also said For a number of years I have been familiar with the observation that the quality of programmers is a decreasing function of the density of go to statements in the programs they produce. Not so humble.

yread 5y ago

Humility also helps push you to measure things and assume less. And lack of humility can make you trust that your code just works and not test it as thoroughly

naveen99 5y ago
/s/lack of humility/overconfidence So is humility underconfidence ? Is their a word for the right amount of confidence ? Maybe confidence ?

doggodaddo78 5y ago

I recall the retelling of a startup interviewee comment who tanked their opportunity by saying "the salary: make it a big number." Furthermore, I notice in clinical healthcare and software engineering that ego tends to be inversely proportional to capabilities because the jerk reaches hubris by stopping learning and assuming they're always right, leading to less knowledge, career development, feedback, and authentic peer interactions. Eventually, they become the "I've been doing this for X years" people. They become infinitely awesome, but in their own minds only.

thrwaeasddsaf 5y ago

The biggest challenge here I think is that we don't have an objective definition of clever code, and if you ask, most people will just try to retroactively justify why the current mainstream way of writing things is good and not at all clever. If you do something unusual, people think you're trying to be clever. I think that a lot of the stuff people take for granted in modern programming languages would've been considered clever tricks or just complex and alien mechanisms by the average programmer around when I started 25 years ago (remember serious business that ran on basic?). The way mainstream code looks today has changed a lot compared to then, and I predict it will still change a lot.

bourgwaletariat 5y ago

We can start by thinking of software as the tool, rather than the product. We tend to pride ourselves on the software we create, rather than priding ourselves on the problem we have solved. We have pushed the concept of tool down. So, what I mean is this, we think of jQuery as the tool and the website as the product. Or Angular as the tool. Insert library. This keeps us in a hamster wheel of learning to use tools to build products, rather than building products to solve problems. The software is not the goal. The solution is the goal. I see this as a human issue in lots of fields. Carpenters love to debate dewalt vs makita vs milwaukee, but it's the thing built with the tool that matters, not the tool. Imagine carpenters striving to learn how to use different brands of circular saw. We debate angular vs react vs jquery. Why do we care about that? Because that is about us rather than the product. I know jQuery. I know angular. Angular is better than react, therefore I am better than you. That is the opposite of humility. That is arrogance. We are stuck in a loop of solving the problem of solving problems. We need to get to the next level. I see it now with Canvas vs DOM.

cryptica 5y ago

Humility is extremely important. As a senior developer with over 15 years of experience, I'm tired of being lectured by junior developers with 5 years experience about things which I know to be incorrect because I used to think the same way but have since learned better. If I try to tell people that some approach x is incorrect in this particular case because of reason y, they think I must be a dinosaur because all the articles they read online indicate that approach x is popular and therefore I must be wrong and lazy... As if I had been twiddling my thumbs for the past 15 years, when in fact I've been working non-stop nights, weekends, day job, open source side projects etc... It's infuriating. I don't know what to say. Nowadays if I encounter such junior dev, I don't even try to start to correct them. Nothing can be done. We have reached peak intellect and things are going down. People will simply get dumber, unsophisticated black-and-white thinking will become more pervasive and I need to learn to live with that; sit quietly in meetings, smile, nod and cash my paycheck.

chhickman 5y ago

This is perhaps going to be an unpopular sentiment, but I think far too much breath is wasted on the "don't be clever" edict. No examples even spring to mind of any past experience where I ran into someone's "too clever" code causing me headaches. It has been dealing with the mountains of "not the least bit clever" code that has sucked thousands of hours out of my career. Mundane, "straightforward" code where they've re-used variables for different purposes, or deeply nested conditionals with multiple, multiple booleans in each check (often redundant, if not contradictory) and generally taken 50 lines of code to accomplish what could be done more cleanly in 10 or fewer. I'll take puzzling a few minutes over some too clever code over slogging through spaghetti code any day.

ysavir 5y ago
From your description it feels less like an issue with the code not being clever enough and more like an issue with the code not being organized and architected efficiently. I think the "don't be clever" edict applies to code segments that are best described as "you won't believe what happens next!", and fairly so.
semitones 5y ago
imo unclever code != poorly designed / spaghetti code Reusing variables in a way that is confusing is a code smell, and rather than being "unclever", I would characterize it more as just "bad". In my mind, an example of code that is "too clever" looks more like this: while (*dest++ = *src++); Unless you've seen that exact pattern many times, when trying to understand it you will have to unwrap it in your mind into something that looks more like the longer, "unclever" version anyway.

efitz 5y ago

I think that humility is important in all endeavors, not just software development. I know a lot of people who seem to think that expertise on one area somehow magically transfers to other areas. Just because you’re smart or good at <insert computer skill here> does not mean that you automatically will be able to accurately judge <insert non computer related issue here>. And expertise can be incredibly narrow- when dealing with complex systems and interrelationships between such systems, it’s really easy to accidentally encounter problems that you might not have expertise in; in fact you might not even be prepared to even recognize that you’re out of your depth.

deleted 5y ago

[deleted]

ozim 5y ago

My problem is that mostly I see "abstraction" used as a gateway to introduce "clever tricks" instead of making things easier.