Simplistic programming is underrated

I was a nerdy kid who liked to spend a lot of time reading. Back then, we did not have the Internet, we could not even imagine it… so I ended up reading the dictionary, reading my encyclopedia. I had a weird vocabulary. I could easily string sentences that nobody around me could understand. Adults would reward me with special attention when I would use words that they did not know.

That was not good.

I also learned to program relatively young. Information was scarce but I quickly absorbed everything I could. When I learned about structured programming, I rejected anything “more primitive”. Then I learned about object-oriented programming, and it was the end of structured programming. Then I learned about functional programming and thought that I had once more reached another level. I learned about metaprogramming and became a fan. And so forth.

That was not good.

I still write using big words sometimes, but never intentionally. I try to write short and simple sentences.

It took me a long time to figure out that the same is true with programming. If you can write a program using nothing but the simplest syntax, it is a net win.

I should explain. It is absolutely true that if you deploy a larger vocabulary if you use longer, more pompous sentences, many people will think you are smarter. The same is true with programming. If you can cram metaprogramming, pure functional programming, some assembly and a neural network into one program, many programmers will be impressed by your skills.

However, there are important downsides:

  • Your apparent mental prowesses will fail to impress those who find it easy to do the same. I have met my share of college students and professors who excel at dropping the name of a few philosophers, at using words only 1% of the population knows about… but, at a certain level, it does nothing for them. People simply roll their eyes and move on… If you have a job interview with Jeff Bezos or Peter Thiel, quoting famous philosophers or using big words might very well backfire.

    Exactly the same argument works for programming. You might impress your peers with your fancy use of closures… but this no longer works so well on people who have known for a few decades what closure are. You simply won’t convince Linus Torvalds that you are hot because you use all of the features of the latest programming languages.

    If you are used to achieving success by appearing smart… you might hit a ceiling, and you won’t even understand what is happening. There is a difference between appearing to be smart, and being smart.

    Really smart people have no need to show off. If you are showing off, you are broadcasting that you aren’t really smart.

  • Big words and fancy programming techniques are asocial. They turn you into a jerk. Even the people who think that you are smart won’t enjoy working with you. We might be impressed by people who use big words, but we don’t want to hang out with them. It is annoying to collaborate with programmers who throw the big guns every little chance they get.
  • Complexity scales poorly. It is much easier to build on your previous work if it is simple. There is a reason we still teach Newton’s three laws. They are powerful because they can be expressed so simply. A simple piece of code that uses few features is easier to reuse.

I like the concept of “simplistic programming” by which I mean “programming that is so simple that people will criticize you for it”. At first, that sounds strange… can we really get criticized for being “too simple”? Of course, we do.

Daniel Lemire, "Simplistic programming is underrated," in Daniel Lemire's blog, December 6, 2017.

Published by

Daniel Lemire

A computer science professor at the University of Quebec (TELUQ).

65 thoughts on “Simplistic programming is underrated”

  1. I must say that, most of the time I had to deal with complex code, it was often a case of early optimization. Some people just don’t get it : make it work first, optimize only when necessary!

    1. I’d go even further: make it work correctly and let the compiler optimize it. Once it’s written, future maintenance work may completely undo any hand-optimization you have implemented. The compiler, on the other hand, always has (or always should have) a global view of the program. Let it do its work.

    2. This resonates with me – often when I’m dealing with complex code (or at least code that feels complex but shouldn’t) is just to rewrite it in a very simplistic way – collapse multiple classes into one, collapse multiple methods into one, remove leaky abstractions in favor of duplication etc. Often the root of the problem is that an engineer will try to create an abstraction before understanding the contracts and interactions between different objects.

      1. How is one method more simplistic than multiple methods, each simple in itself? Isn’t that the Unix/Linux/etc. way of doing things, to write many simple methods that can work together?

  2. Pure functional programming often has very simple syntax, and is arguably more simple than object oriented programming. Many when they learn it first actually have an easier time than learning object oriented programming and its inheritance, parametric polymorphism, dependency injection as well as the numerous complicated patterns that go with them. Monads, Monoids and all those big mathy words FP users talk about exist in every programming language. People who use functional languages just like talking about them because its a very broad group. Just like every other language, you don’t have to use them, or you can use them without knowing that very broad grouping.

      1. Exactly right. Couldn’t agree more. One time, a number of years ago, I increased the performance of a dealer-locator table generation routine just a bit, replacing a program that took 4-and-a-half days to complete with one that took a little under an hour by writing a simple little C program that took almost no memory (I think it was a 24K COM executable). Extremely simple, and absolutely fast.

    1. I would guess that he did not lose his love of words, he just learned how to contextualize. There is a time and a place (and a people group) for everything.

  3. I totally agree, make it work, then optimize. It’s so exciting when it works then the art of beautification comes later.

    1. When the art of beautification comes later, it many times depends on the business/budget. If the pressure is hight, it’s really difficult to have more time to beautify.
      If you write beautiful code from the beginning, you don’t need to convince anybody that it worths the beautification.

      1. Yup. If you write your code as simple and “pretty” as possible from the start, you’ll find rework less necessary. Getting it right the first time can be done if you just take enough time to think the problem out and put it together a piece at a time.

  4. I’m doing the “Advent of Code” competition for the first time this year and decided to revisit programming languages I’ve used in the past, starting with the oldest. I’ve even decided to stick with deprecated conventions for good measure.

    As a warm up I typed:

    20 GOTO 10

    As childish as it is, I felt great joy seeing this run for the first time in decades. There is definitely something to be said for simplicity.

  5. Writing simple code is actually very hard. You need to have a deep understanding of the underlying concepts.

    Going from complex ideas, to simpler ones is usually a sign of technical maturity. It comes with time, and many many years of writing code.

  6. Focusing too much on “simple” can also be an easy trap to fall into. Good code is a balance between concisely expressing your intent, and minimizing complexity. Less code is better even if the code is more complex, but too much complexity can end up swamping the savings you get from reducing the code. Generally, once you strip away all the things you MIGHT someday need, and get down to what you ACTUALLY need right now, you can express that using concise and simple constructs.

    1. I understand your point, but somewhere this is a boundary between stripping out things that MIGHT someday be needed vs writing code that is easy to modify for the suspected next requirement coming.

    2. I disagree. You can never be too simple in your coding. You can certainly design it with growth in mind but “leaving hooks” in your design to implement said growth can be a natural part of the design if you have that in mind while developing the code.

    3. In general I disagree with less code is better even if it’s more complex. Most of the cost of a program is in maintaining it. If complex code runs a millisecond faster most of the time it does not matter. If it takes longer for you to understand what you did six months ago or hours for someone else to understand and modify the code, then the complexity has a price far above a few extra lines of code.

      That being said, if speed is of the essence, then complexity for the sake of speed is acceptable.

      Simpler code will better express your intent. Especially to someone reading your code for the first time.

  7. I have spent the largest part of my career cleaning up messes. I try to write simple, understandable code because I know that I won’t be on a project forever, and I need to leave the next programmer something that they can actually work with. This doesn’t mean that I won’t use functional programming or metaprogramming, just that if I do, it will be in a defined area where that approach leads to simpler code that makes more sense.

  8. This was a great writeup. Good message, and well elaborated. One suggestion on your writing style though: where’s the ending? It felt about as abrupt as the Sopranos’ finale. A concluding paragraph that ties the whole thing together, would have made this essay even stronger.

  9. “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” – Martin Fowler

  10. Avoid the OO snake oil dealers and the typeclass zealots and the Monoids. If you want simplicity watch Rich Hickey’s videos and enjoy the freedom of Clojure.

  11. Heh. A few years before, but much the same.

    In high school, quickly learned that to communicate effectively, I could not use the majority of my rapidly acquiring vocabulary. Spent a couple years working after high school, to afford University, with the same limitation.

    In University, the chance to fully use my vocabulary of words and ideas was … absolutely freaking wonderful!!

    At this point I have to differ somewhat with the suggestion that going to a traditional college might be a waste. There is something powerful in living with folk of similar ability, and that needs count.

    As a programmer, I have found that when I write a white paper describing a product, the group finds clarity.

    On the flip side, I spent years building a solution for a particularly complex problem. The solution performed extremely well. The problem was … I could not pass on the result to other programmers. They could easily understand subsets, but not the whole.

    More simplistic solutions might be better, when possible.

    On the more theoretic side, I am a bit of a skeptic. The notion of “functional programming” has been around since I was young, but has only limited effect. On the other hand, the last project I worked on – which shipped to customer on time and on goal – used much from the notions of functional programming in the test code. (Trying to explain that code to both old and young programmers … was an effort. Keep in mind I was the oldest guy in the group.)

    So … using too much of your vocabulary might not be good?

  12. Well, i could care less about programming style. That’s not where the core problems exist. 1. Please be able to write unit tests that could approach upwards of 95% 2. Please know some creations, structural and behavioral design patterns. 3. Know SOLID principals.
    Why? Because when one is dealing with hundreds of thousands of lines of code … I don’t want to decipher your code. The unit tests will tell me what I need to know

    1. Concur.

      1. OOP is thought to make programs simpler to understand and modify. There is a possibility that you’ll mess everything up, but that’s the art of programming.
      2. Functional programming – same thing here.

  13. That is this “complexity” that delay if not stall the world’s progress.and peace. Everything should be approached and done simply. Look at GOD’s creation, everything was done by “two’s” or binary. There’s always the opposite of each creation. Example: man-woman, love-hate, hot-cold, white-black, zero-one, poor-rich, up-down, heaven-hell, devil-angel, ugly-pretty, short-tall, fast-slow, war-peace, foul odor-pleasant odor, male-female, north-south, etc. etc… We have yet to explore the universe and only until that point. There is only one that was not created and has no opposite, and that is GOD. Make your programs as simple as possible. Anyway when programs are compiled, it is sent to processors as1 and 0 only. Happy programming!

  14. this is very inspiring i definitely hit that ceiling from time to time, knowing that i am moderately intelligent and reluctant to put effort into things.

    however, here’s an open thought: the next big idea lies beyond all platonic solutions. we’ve witnessed alpha go’s astonishing evolution speed, yet no human go master can understand its reasoning and its skills. some theoreticians agree with the idea that if p=np, a breakthrough solution to that np-complete problem has a really high degree, like x to the one million and it’s just beyond human capacity. ronald graham, a combinatorist once said something like the really interesting mathematics happens at really big numbers, that we have very interesting theories involving astronomical numbers. the hard problem of consciousness appears to have a really complicated solution as well. so maybe the next big breakthrough is done by some more generalized ai that has way more computing ability than any human being instead of a really smart human.

  15. Classical Mechanics is a rich analogy. Newton’s Laws are simple, but difficult to extend. If you do work in Physics, you are almost never going to be using the Equation of Motion formulation (Newton’s Laws); the Lagrangian and Hamiltonian formulations are more complex but are much easier to modify and play with. Lagrangian and Hamiltonian Mechanics are refactorings of Newton’s Laws!

  16. Vocabulary development and finding the chances to use those are completely different from using the latest programming technique (opinion is different). The fundamental differences between these two are revisit and maintenance not required after you speak. Probably winning the audience may matter in this case 😊.

    But using the latest programming technique will solve the problem easier provided, we had knowledge-wise equal people around us. At the same time, we could not make sound using single hand. As you described, if some-one want to be a programming – Sesquipedalian then he must create the audience in this case (peers). Because programming is not about winning single person. It Is always associated with the group of people. It is NOT necessary to use 10 simple words to describe the thing, when we had single word to do same, while the time, cost and maintenance are matter.

  17. If you think easy implementations are same, think twice
    ” if you choose the quick and easy path as Vader did — you will become an agent of evil.” (c)

  18. As a manager responsible for code life cycle I very much agree with your analysis, but would add that this depends a little on the circumstances. I was talking with some of my team yesterday and we were discussing the power of regex in .NET. We never use it because it comes up so infrequently that none of us are proficient at it. The syntax is something we would have to study every time we write or modify code that uses it. Another department with a heavy need for the use of regex may have a team of folks proficient in it. So I guess my point is that complexity can be relative to your team environment.

  19. Old school-programmer here, i have learned to work with to many frameworks in so may languages, made the journey from basic to COBOL, vb, db, c#, .net,php….. I can not emphasize this enough, keep it simple. We are not all writing for Facebook or Netflix. The whole react movement is a great thing, beautiful things are done, but boy, do we make things complicated. I do a lot of code reviews and i’m still surprised that to change a button with behavior you have to touch 26 scripts. ( not always but i have seen it it multiple times during reviews )

  20. The author follows the tenets of KISS very well in his easy to read essay.

    I have always followed a single rule in my 42+ years in corporate development that was promoted in my mainframe days; write for the least experienced person who may need to maintain your code.

    It is a rule that has always kept my code very easy to read and to maintain. What more could a good technical manager want?

  21. I believe that, in our writing, it is not unreasonable to ask the reader to look up a word when they are unfamiliar with it. We should try not to make this demand too often, but motivated readers will do this if our writing contains something valuable for them.

    Perhaps even more so for computer instructions, we should not be afraid of complex expressions, especially when they improve clarity and compactness.

    My coworker recently needed a file transfer procedure for bash/ksh88. Is my implementation a masterpiece? No, but it’s clear and does the job, and pieces of it are already showing up in other departments.


    if [[ -f “${FILE}” ]]
    fage=$(stat -c %Y “${FILE}”)
    now=$(date +%s)

    if [[ ${diff} -gt 600 ]]

    if [[ ${ENV} = “prd” ]]

    x=”$(dirname “${FILE}”)/$(basename “${FILE}” .dat).$(date +’%y%m%d%H%M%S’).dat”

    mv -v “${FILE}” “${x}”

    echo “cd job_orders
    put ${x}
    quit” |
    sftp “trfacct@${HOST}”

    mv -v “${x}” “${VAR_LOG}”

  22. There are here some very big problems. I can talk about two chapters: 1. The Current Software Model (CSM) in which we see C++, C#, Java, classes and objects, databases, clouds, fogs and an unlimited string of programs….., AND 2. The Universal Software Model (USM) in which I work directly with the parameters of the problems and the relationships among these parameters. The name of the unique and universal language is usm (the language of the Universal Software Model). All is different. The usm language works directly in Problem Space with the parameters of the problems. No pointers. No objects. CSM is over. The future is USM. With CSM the entire planet becomes a planet of programmers. The usm language can be learned in a week! The language has a small number of concepts. Our effort have to be done for knowing the real problems. In CSM 95% of the problems are inside the model itself (inside CSM).

    1. Hey Ghorghe, I visited your site. Way too complex for my simple programmer mind. Guess I’ll get back to my if-then-else work now…

  23. As a gray beard I have went from CBasic to Angular/TypeScript. One of the things that I have found is that programmers spend 50-80% of their development time reading code.

    Knowing this, the bottom line is that code must convey intent and be readable. (Clean Coding, SOLID, etc all helps with this). I try to write a lot of small methods. They are easy to unit test, easy to name that conveys intent, etc.

  24. I disagree.

    The analogy between human language and programming languages is specious. (see that? I used an SAT word to be concise)

    Communication is designed to transfer thoughts from one brain to another, and if the receiver is convinced or motivated as a result, the communication is effective.

    Programming is a completely different endeavor. You don’t need to convince or motivate a computer to execute its programs.

    Writing simplistic but voluminous code with lots of small statements is not good programming. Operating at a higher level of abstraction, requiring less code and depending more on patterns, is superior. If other programmers don’t understand the patterns, they need to learn them.

    Programming patterns were inspired by architecture. Following your logic, we would still be living in mud huts as architecture would not have progressed the point at which the “average” architect could operate.

    1. I totally agree.

      When writing my code, I spend some 25% of my just thinking, how am I to approach the problem in terms of responsibility chains, inheritance and so on, how do I make my code scalable. It takes the whole 25% of time because, when the code is written, there is usually no need to come back to it any more, rewrite everything from scratch, fix a thousand bugs that appeared after fixing a single one, and so on and so forth. Extending your metaphor, a crush of a mud hut is much less dangerous than a crush of a skyscraper – but you’ll never build a skyscraper basing on the mud hut technology, for it will collapse inevitably.

  25. I agree with this, and to express one self in the most simple manner a language has to allow metaprogramming so that the programmer can remove all unnecessary information from a piece of code.
    This makes the code say what it needs to say without hard to understand abstractions (like design patterns).

  26. While I agree at some level, there is a reason more complicated programming paradigms were invented. And it wasn’t just to look/sound smart. It was to solve problems inherited by programmers who found themselves having to wade through mountains of unmanageable code. Doing it the simple way often leads to code that repeats itself all over the place, is difficult to modify without breaking other parts of the system, etc.
    And I often hear the…”oh, it’s okay, we’ll refactor it later if it becomes necessary” line. I have yet to meet a professional programmer who is ever given the time to refactor code that “already works…don’t fix it”.

  27. ive been saying these things for years– and theyre the centre of my philosophy about “easylangs.” its not a crusade against complicated languages, its a call for more options that are easier to learn to code in.

    i think coding continues to get more complicated, faster than is necessary. the idea that “computers do more things now, thats why we need more complex languages” is a bit misleading, and less than 100% true.

    i really hope you will consider fig as an example of what youre talking about– a language with < 100 commands, designed as a bridge to python or other languages– designed for the people i couldnt interest in python or even basic.

    ive taught people how coding works in fig in bars, while we were both drinking. its not "just" an educational language, i actually use it for coding. but id like for more people to work on easier languages, not just fig.


  28. I read the first two paragraphs and left.

    Glad I came back to it. After spending so much column length not merely establishing the context that you are smart, but just *how* smart you are, you finally got to the point of how that turns people off.

    Your advice about modesty is sound: “Really smart people have no need to show off. If you are showing off, you are broadcasting that you aren’t really smart.”

    Thinking about other people has other benefits, unless you want to do all the maintenance and extension of every bit of code you ever write. I might suggest “Considerate” coding, or “Modest” coding. Unless I mistook what you laid out as advice.

    The word “Simplistic” just begs the question, and leads to explaining, at length, how it is the opposite of high intelligence, and exactly why you feel the need to explain it that way.

  29. To make the simpliest solution, you have to understand the Problem in ist full complexity. Most of the time, this is not the case. There are programmers, which add to much “sugar” to a solution, but they are not very widespread.
    The simplistic approach bears some inherent problems. The biggest is the question of scaling. A colleague hacked an export to Excel on our web Server in the late 90s. It worked on his 1000 entry data modell. But the customer had 250000 date entries and the algorithm was n^^3.

    But these are the simple problems today. Data Manipulation is testable an reproducible. A running industrial process with hundreds of inputs mapped to a hundred threads, which have to work together at some Moments is the challeging Problem. To much serialisation will break real time communication. To many Looks will break Performance and leads to deadlocks. Unfortunately you don’t get your own Million Dollar machine for testing the stuff in your Office.

  30. I completely agree. The biggest problem is the number of hipsters who have joined the programming ranks. They are always trying to grab on to the latest thing (ORM, TDD, etc.) and they can’t control their narcissism. The other problem is the way programming is taught in our schools. It is divorced from the reality of solving real-world problems in an efficient way.

  31. I don’t know. Writing is not only a means to an end, it is also an art in and of itself. Something is lost to me when the art is stripped away to focus only on the utilitarian end goal. Coding is an art too, but obviously 99% of code has to meet utilitarian goals, so it makes perfect sense to me to focus on that in that context.

    Reading your post, I was reminded of some of my Facebook friends that have training in photography and are more than capable of taking beautiful pictures, yet post FB albums full of blurry, poorly-composed shots. I guess that’s fine if you just see FB as a medium for showing people what you were doing and with who, just like writing short, simple sentences is fine if you just see papers as a medium for telling people what you did and how. I feel like both can be more than that.

  32. I think you’re talking about too many different things at the same time, intertwining them and mixing one with another. I totally agree with showing-off and being smart just for the sake of being smart is harmful. But what does it have to do with using modern, advanced programming techniques? Making your code simple (as an opposite to complex) requires a lot of engineering, requires putting enough thought to make it understandable and easy to maintain; it’s probably the opposite of ‘simplistic code’. There’s a reason people try to abstract away from implementation details – to make programs more declarative and easy to understand. There’s a reason C is a niche language now – I cannot think of a language more simplistic, yet it’s not used nowadays for each and every programming task.
    Complexity scares poorly, I’m totally with you on that; but complexity of a system is, again, a sign that not enough engineering has been put into it. The reason Newtons’ laws are still taught at school is that to understand something more difficult, you should start with something easy. Understanding of Newton’s laws scales way better than understanding of Einstein’s theory, sure, because it’s _easier_. But appliances don’t.
    We won’t get much further without difficult to understand systems, but we gotta work on keeping them simple.

  33. Bingo. IT is the biggest procrastination. My former boss said Industry4.0 does not concern IT. It is so. Real IT is about money, so complications meet this goal. Complications helps to generate more money. Resulting software is not a major goal. Simple things? People are bored with simple solution. At the meeting, they want to talk about difficult issues. It does not matter that those things are not really needed. But it will get budget! 😉 Simple things and solutions frighten people. The ease of being is unbearable. With some problem is easier life. The problem lets you dream a dream of a great future, because reality is boring. Reality is a compromise. Reality may mean multiple points of view. Reality may require dialogue and empathy. Reality may assume cooperation. But the complicated code will rid you of all this junk and give you freedom, peace and budget. Do you already understand why open source is great? Start charging money and you will see … 😉

  34. Another nail in the coffin of software is durability. When I’m reconciled with overenginnering software, it will not even survive. Again money and copyrights…

    Is it something older than last year’s software version?

    That’s why I prefer javascript and open source. no vendor lock. On all sides. Chrome has a 63rd reincarnation. In silence. No problem. And in terms of simplicity and sugestibility, javascript is the first to choose from. Pity it is not case-insensitive. Transpilers can not discard this burden (if they want to be compatible).

    I personally introduced DSL comprehensibility including language (= national), punctuation and caseInsensitive independence. Even in the current world (life), each domain has its native language. It’s normal, no wonder. It’s foolish to want one programming language for everything. Most programming languages ​​originated for technology, not for users. Such techno-languages ​​are a lot today. Languages ​​for users, business decision makers are needed. Even that is understandability and understanding.

Leave a Reply

Your email address will not be published.

You may subscribe to this blog by email.