The Importance of Humility in Software Development (2020)

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.

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.

I would argue the post is primarily about complexity, and in school you probably haven't seen how complex software can get because most projects have to be started and finished within two to three months. Once you start working, you'll quickly discover that the complexity of existing systems can be overwhelming, but this is normal.

After 3-6 months working on a complex codebase, ideally with a team to help you, you'll have some idea of how the complex system works, and even if that idea is wrong (in many, many places), it will help guide future changes to the system.

The point then, of reminding programmers to have humility, is less about hearsay on the internet and more about the need for tools and languages to make life easier for the individual programmer trying to read the code, then plan, make and deploy changes to a live system. If you're lucky, you'll feel like the system makes sense but changes too quickly. If you're unlucky, the system will make little sense and it'll be entirely your job to fix it or put up with it. Usually, hopefully, there's a middle-ground, where the system works well enough you don't have to make changes, but you're probably not entirely satisfied with it either.

Humility can also be the reminder that just because a system looks broken (to you) doesn't mean it needs fixing right this second. If you can spare the time, it's almost always better to try and understand an existing system's quirks before you set out to redesign it and end up re-implementing some of the same quirks yourself.

I'll echo mentions elsewhere in this thread and suggest John Ousterhout's A Philosophy of Software Design as a good book on the subject of complexity and API design, but to newcomers to the field, I'll leave the warning that it doesn't cover TDD as much as it could and it also doesn't cover modern Scrum/Agile practices and how development fits in with product design and company goals. But I still highly recommend it.

HN is a great community, but it has a very narrow perspective on the world.

As a beginner it is fine to chose to master one language first, but in the long run you should not "choose a language", but rater learn to learn any language, and understand they all have their strength and weaknesses.

But there are so many choices of tools and technology in this industry and it is impossible to learn it all. Tribalism makes the world simpler because it narrows your perspective.

It's kind of like with assembling a tricky 1000-piece jigsaw puzzle. You assemble the frame first (like everyone always does), and wonder how to fill it in. You could pick the most obvious feature on the reference picture, start there and focus on expanding it piece by piece until the picture is done. But what I imagine most people do is first speculatively placing all the pieces that seem trivial to match to corresponding picture features, in order to reduce the number of unplaced pieces quickly, and give themselves lots of starting points to expand their solution in parallel. This approach is useful despite it commonly turning out later that some of such early starting points are placed completely wrong - puzzle blobs get easier to position correctly once they grow in size.

It's a long way of saying, if you keep track of confidence levels of your beliefs, instead of taking everything you read on the Internet as certain, even off-hand remarks on HN can be useful in navigating the enormous space of technologies and philosophies that form the software industry.

As a TA I see a lot of people who also made these same decisions, maybe just add Arch Linux and zsh to complete the cliche. So you don't have tl worry, as this is actually relativly commom.

But I don't think it is wrong to have intuitions based on stories, as long as these don't prevent you from trying out said tools or languaged yourself. They can be right, but they might also be outdated. Just stay curious.

In my experience, I can learn a new language (and general style) serviceably well, in just a few weeks, but it can take years to learn the language in-depth, with the language being a “moving target,” as it evolves. I decided to specialize in Swift, and still have a lot to learn (I’ve been programming in Swift since the day it was announced, in 2014). Part of the reason for the time it’s taking, is because I have been using it to ship products, which slows exploration and research.

What really takes time, is platform SDKs and frameworks. They can be real rabbitholes, with all kinds of idiosyncrasies and caveats. They, too, are generally “moving targets.”

Good luck in your endeavors. I really enjoy programming.

> This made me arrogant, because I saw myself as above my classmates

As others have said, "good" and "bad" depend on the use-case; everything has pros and cons; but some things are still objectively better than others (e.g. if tool A supports more data formats than tool B, whilst being just as fast, just as secure, just as supported, etc. then A is a "Pareto improvement" over B; there is no reason to choose B for a new project).

Whilst it's common to explain why something is "bad" (e.g. PHP encourages 'stringly typed programming', which makes SQL injection and cross-site-scripting vulnerabilities more likely); it's also important to explain why such "bad" tools are nevertheless widely used. For example, PHP is widely supported by free/cheap web hosts, is easy to set up (just copy a .php file to the server) and run (the URL is the .php file's path); it runs concurrently without needing shared state/threading/etc.; it has a built-in Web framework ('$_GET', '$_POST', 'echo', etc.); it can be embedded inside HTML files; and so on. This all helped it grow a large community in the Web 2.0 days, and lead to useful applications like Wordpress and MediaWiki, whose 'plugins' got many people into programming. This community of pragmatic (but often inexperienced) developers and their ability to quickly churn out Web apps has sustained itself to today; whilst the developers have matured, applications/libraries/frameworks have grown much more complex, the demands on the language are more diverse, and the language maintainers add new features and fix some of the language's underlying problems.

I still consider PHP to be a particularly bad language, and would need an incredibly compelling reason to choose it for new project. Yet I know there are many reasons why people have chosen it, and continue to do so. Those aren't necessarily "pros" for the language, e.g. it often comes down to historical inertia and 'what we know', which is much less important for those just starting out, or working in a different field (e.g. data scientists), or facing a different context (e.g. Web apps implemented client-side, fetching data from managed cloud services).

If we see the arguments against, but don't know much of the context or reasons things still get used, it's easy to make the assumption that others made bad choices due to ignorance. I think this is similar to Chesterton's Fence https://en.wiktionary.org/wiki/Chesterton%27s_fence i.e. we should understand the reasons why someone did things in a particular way before we scoff at their poor life choices (after all, sometimes those reasons make it even more hilarious!).

I think that these opinions are mostly correct, but you and anyone else would learn a lot if you chose to actually try Java and PHP and experience this verbosity and inelegancy first-hand, as opposed to just hearing about it.

I feel that if we will use a tool, we need to take the time to become proficient with it.

Here's an article that I reference fairly often. It's sort of a "reality check": https://veekaybee.github.io/2019/05/10/java8/

Well... PHP is inelegant, and there's a reason that it's been abandoned. However, it's actually worthwhile to spend some time discovering that for yourself - if not about PHP per se, then about a different "blunt" tool. Part of the modern computer science discipline is working through exactly why so many simple-seeming solutions fall apart - it isn't obvious, and it's really important to internalize.

I would say humility is the most important quality for an engineer to have if they want to be able to grow as an engineer. I've come across a small number of engineers that have lacked humility and acted as if they knew everything and they were a nightmare to work with. The first instinct they have when they approach most problems that they come across is that the issue can't possibly be caused by their code and you have to provide an unreasonable amount of evidence or a smoking gun to convince them to investigate their code. They design solutions as if they know the perfect way and they seem to lack empathy for users or others that may have to maintain that code.

If your journey is anything like mine you will end up driving yourself lower and lower into the stack until you wear yourself out. Ideological buoyancy will take over and you'll float somewhere higher, but you'll be much more knowledgeable and valuable as a result. All that to say, don't be too hard on yourself.

I see it all the time in my daily life, people are insecure and mostly want some confirmation that choices they made are good ones.

They buy a car and then they start saying that other car brands are bad or breaking so easily. They cannot face the truth if their car turns out to be a crap. Seems totally like programming language bros, and some people cannot stand that in other language they could make more money. So what? There are probably people using that language that make less then them.

I don't want to live such life, I want to make mistakes and pay for them if needed. Lots of choices are reversible or can be changed, be flexible.

https://www.oreilly.com/openbook/opensources/book/larry.html

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.

Heh, I don't think there are a lot of proven abstractions out there. And most so-called "abstractions" are in fact not. Let me explain using two popular abstractions, ones that are so low-key that they wouldn't even considered by most.

1) Function calling. This is an abstraction that abstracts away the logistics of setting the state in a process in the right way such that the next piece of code can continue. When that code finishes, it will leave a well-defined state as well (first, in terms of the call stack, but maybe a return value as well).

Now, I contend that function calls can be the wrong abstraction in many situations, at least more often than people think, and many many functions seen in the wild should never have been created. Functions remove a lot of control where values are stored, and the storage locations can't be shared across functions, which results in a lot of nested calls that tunnel through many of the received arguments - instead of just leaving them in a common, predefined place. Also, lots and lots of functions in practice tend to amass local state, and as it is with the tree-shaped nature of function calls, once you give up control, that state is gone, so you'd better clean up after yourself. This is in fact a great burden, and very complicated systems arise to "solve" this problem, like constructors/destructors, try/catch, functional unintelligible academic theory (Monads), and other resource tracking systems.

2) Streams. In my mind, they are arguably one of the most successful abstractions ever created. A stream abstracts one of the endpoints of a unidirectional connection (the read or write endpoint). You use it by just saying "read" or "write", and very little of the complexity of interacting with that other endpoint shines through - lossyness of the connection, flow control, packet size, error handling... streams don't provide access to most of these.

This can be a very unhappy situation to the point where the code that deals with that stream would be much better off just dealing with the underlying connection directly. A huge aspect of this is flow control and scheduling - we mostly act like transmission was an atomic operation, but there is a lot of logistics involved. To hide this, OSes invented blocking interfaces, putting your process to sleep until the operation is completed, or providing simplistic non-blocking interfaces. All of this is very bad for performance and predictability, especially blocking interfaces.

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.

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++); 

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.

https://news.ycombinator.com/item?id=22348386

> 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_St..., 2nd edition, 1978

He wasn't particularly humble in his writings.

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.

https://medium.com/@acidflask/this-guys-arrogance-takes-your...

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.

The "business value" of software optimization is not well known.

So is humility underconfidence ?

Is their a word for the right amount of confidence ? Maybe confidence ?