Hacker News Reader

Comment by jniedrauer | Hacker News Reader

There aren't a lot of areas left in CS where "clever" solutions are warranted. If you're writing clever code, then chances are you're doing a disservice to anyone who has to maintain the mess you're creating. Code is mostly just plumbing. Boring code is better 99% of the time.

View on HN

The flip side of this is that because digital plumbing is "boring", the industry is constantly seeking ways to avoid it. Writing assembly language was (usually) really boring, so we developed good compilers to do that for us.

I look forward to the day where I can send data from one place to another and not have to bother with file formats, text encodings, port numbers, network protocols, and so on. IP (and especially TCP/IP) is so prevalent today that we use "IP connection" and "network connection" interchangeably. Someday I hope we have that consistency at some other layers of the stack. I shouldn't have to say "send me that file -- what app did you use to make it?"

I've been thinking through this for a while now and I've come to the conclusion that the details keep getting more complicated faster than other things can automate them. For example, I remember a time when software served ascii and when the Canadian government asked to buy a version of some software we were writing for the Americans the reason the head of the company said no was because we'd have to support French and that meant non-ascii characters.

Now, UTF-8 is a given and there is a mess of potential issues. No longer are byte-by-byte comparisons reliable, especially in some languages like Vietnamese.

Your example of IP connection and network connection is true, but overall connections are more complicated. Some clients can't use HTTP2, some clients are behind firewalls, some clients need CORS support, etc.

And plus there is this accelerating wave of advancements everyone is trying to keep up with, but that come with real investment. Upgrading OSes, programming languages, frameworks, libraries. Figuring out how to keep data secure.

I really don't see things getting less complicated as time goes on. At least not until we have some real form of AI, but even there I have my doubts because there will always be tradeoffs.

That's why we have libraries and frameworks to do complicated, human-facing bits. If you're rolling your own dateTime, it's a bad idea, but fortunately other people have solutions for this. If you want to get into the nitty gritty you can but you do so at your own peril, similar to how the vast majority of people are not reinventing TCP/IP.

It'll take a bit of evolution to get there depending on how new the problem is, but it also took a bit of evolution to get where we are today, and nothing is ever perfect.

My argument is that, as a function of time, there are more things to consider, not less. Abstraction works to a point, but it doesn't keep up with the growing complexity.

Except by the time those libraries and frameworks become stable and well documented enough for serious use, we decide to reinvent the wheel and move on to something new.

In fact, that's already been solved for the most boring of digital plumbing. The data is JSON (which requires UTF-8), and the port number either 80 or 443 - the library automatically handles that depending on if the URL starts with http or https. `requests.get(URL).json()` will grab that data for you (Python). That only covers a very specific but very prevalent use case, just like TCP/IP covers the most prevalent use case for networking.

What are you doing where that can't covered by that use case? Actually, I can think of tons. What are you doing that can't be covered by that use case, but is still boring?

I think you are coming from a common perspective for people on HN and elsewhere in IT, where you can just install anything and provision any equipment to install it on and direct others to do the same.

A lot of people aren't in a position to do this. I think actual plumbers also have to deal with similar constraints.

It's nice to not be constrained, but it's also more impressive to do a good job under severe constraints, IMO.

Something I find myself doing repeatedly is implementing arcane protocols that were created long before JSON. Bit-packed mainframe protocols. After the second or third time of working with another binary format, there's no new knowledge to gain, and it's not interesting work. But it requires meticulous attention to detail and can't be automated. Most industries don't require you to solve this specific problem but it's all variations of this. Shuffle data from one format to another format. Even if it's JSON, you're still moving it from one business domain to another, or one tech stack to another. Backend to frontend. Etc.

There aren't a lot of areas left in CS where highly generic clever solutions are warranted. There are plenty of cases where a specific business has specific needs and the solution to those needs is more interesting than glue code.

Agree 100%. Programmers that love 'clever' code should think twice about using it. Writing code that can be maintained over a long time is many times more important than saving a few bits here and there by using clever coding.

Mostly it's not the clever code that is the problem, but the way people tend to use it. Instead of covering that clever piece code in a structure with an easy-to-understand interface and a lot of documentation explaining what things allow this to work properly, it's left without any clues what it is and how it works. Essentially a puzzle in the middle of code base to solve for everyone reading.

I don't think they're talking about clever code, more about challenging solutions. Plenty of problems that have challenging solutions, though they are not often easy to recognize.

The flip side of this is that our industry has a huge affection for laziness, incompetence and anti-intellectualism. The moment they get their first job, a lot of people seem to forget that this field is a profession, where learning things is actually a part of the job. Instead, they freeze their development at junior level and whine at anything that's beyond what they know. Often times when I see actual complaints about clever code, the code isn't really all that clever - it's the complainer who can't be bothered to take two hours off and read up on a feature of the language or library they're using 40 hours a week.

When seeing something one doesn't understand, the default reaction of an intelligent person should be to ask oneself what one should learn to comprehend it. It shouldn't be dismissing it as "clever".

I'm in the opposite opinion, CS is filled with clever things we taken for granted. A lot of stuff in this field are innovations or clever stuff already figured out. The remainder is a puzzle like approach to fit it all together alongside moments of novel innovation and puzzle solving.

Reply on news.ycombinator.com