Saturday, October 23, 2010

30 lessons learned in computing over the last ten years

In looking at the last ten years of my life, I realized that I've learned many things. Mostly about how wrong I've been, and how stupid I've been. So, having looked at the 80+ projects I've worked on in the past ten years (excluding coursework, current start-ups, and graduate studies), I have reduced what I learned to a blog post. (In bullet format no-less).
  • If you plan to write a programming language, then commit to every aspect. It is one thing to translate between languages; it is an entirely different effort to provide good error/warning messages, good developer tools, and to document an entirely different way of thinking. In writing Kira, I invented a whole new way to think about how to code, and while much of it was neat to me; some of it was very wrong and kinda stupid.
  • Geometric computing is annoying, always use doubles. Never be clever with floats; floats will always let you down. Actually, never use floats.
  • Lisp is the ultimate way to think, but don’t expect everyone to agree with you. Actually, most people will look at you as if you are crazy. The few that listen will revere you as a god that has opened their eyes to computing.
  • If you plan on writing yet another Object Relational Mapper, then only handle row writing/transactions. Anything else will be wrong in the long term.
  • If you want to provide students with a computer algebra system, then make sure they can input math equations into a computer first.
  • Don’t build an IDE. Learn to use terminal and some text editor. If you need an IDE, then you are doing something wrong. When you master the terminal, the window environment will be cluttered with terminals and very few “applications”
  • Learn UNIX, they had 99% of computing right. Your better way is most likely wrong at some level.
  • Avoid XML, use JSON. Usage of text formats is a boon to expressiveness and the fact that computing has gotten cheap. Only use binary based serialization for games.
  • If you plan to build an ORM to manage and upgrade your database, then never ever delete columns; please rename them.
  • Never delete anything, mv it to /tmp
  • Never wait for money to do anything; there is always a place to start.
  • Optimize complexity after people use a feature and complain. Once they complain, you have a real complexity problem. I’ve had O(n^3) algorithms in products for years, and it didn’t matter because what they powered were not used.
  • Text games can be fun too; if you want to write an MMO, then make a MUD. You can get users, and then you can use that to get traction to build something bigger. Develop rules and a culture.
  • Don’t worry about concurrency in your database until you have real liabilities issues.
  • Backup every day at the minimum, and test restores every week. If your restore takes more than 5 minutes of your time (as in time using the keyboard), then you did something wrong. If you can’t backup, then you have real issues and enough money to solve them with massive amounts of replicationg.
  • Never write an IDE; it will always be a mistake. However, if you do make it, then realize most people don’t know that silver bullets don’t exist. You can easily sell it if you find the right sucker; this will of course become a part of your shame that you must own up when you die.
  • JavaScript is now the required programming language for the web; get used to it. JavaScript is also going to get crazy fast once people figure out how to do need based type inference. Once JavaScript is uber, learn to appreciate the way it works rather than map your way of thinking to it.
  • Master state machines, and you will master custom controls. Learn enough about finite state machines to be able to draw pictures and reason about how events coming into the machine affect the state.
  • There is more value in learning to work in and around piles of crappy code than learning to make beautiful code; all code turns into shit given enough time and hands.
  • If you want to build a spreadsheet program, then figure out how to extend Excel because Excel is god of the spreadsheet market.
  • Write five games before writing a game engine.
  • Debugging statistical applications is surprisingly difficult, but you can debug it by using R and checking the results with statistics.
  • Don’t design the uber algorithm to power a product; instead figure out how to make a simple algorithm and then hire ten people to make the product uber.
  • Learn to love Source Control. Backups are not enough. As you age, you will appreciate it more.
  • Communicate to people more often, don’t stay in the cave expecting people will know your genius. At some point in your life, you will need to start selling your genius.
  • Realizing that every product that exists solves some kind of problem. Rather than dismissing the product, find out more about the problem the product is trying to solve. Life is easier when you can look at new technology and find out that it does solve.
  • Learn to be sold. Keep the business card of a good salesman. Sometimes, they actually have good products, but they are always useful.
  • You can make developers do anything you want. Normal users on the other hand are not so masochistic.
  • If you are debating between Build or Buy, then you should Build. You are debating which means you don’t know enough about it to make a sound decision. When you build, at least you will get something working before you find what to Buy and how to design with it.
  • You will pay dearly for being prickly; learn to be goo and flexible to the changing world. Be water, my friend.
If you got to this point, then good job. The biggest thing I have learned (and probably the most painful) in the past ten years is how to deal with my ego. Ego is supposedly your best friend, but it also your worst enemy. Ego is a powerful force, but it isn't the right force to use. While I admit that I've used ego to push myself in very positive direction, I think I would have been better off if I didn't as the side effects trump the pros.


  1. I think the IDE lesson has been really important for you :) I was really amazed when I read your previous post with all these projects. It was... well, plain amazing.

    A good selection of lessons, but I am sure that you have countless more buried inside tons of source code. Waiting for the next batch in 10 years.


    Latest in my blog: What It Takes to Be a Winner? Embracing Failure


    - Kunjan Kshetri

  3. This comment has been removed by the author.

  4. thanks, very usefull, I'll look for lisp

    p.s.: which text editor do you recommend me? emacs?,
    p.s.2:why only use an text editor? isn't MUCH more slowly use an text editor than a IDE? what are the benefits?

    Thanks in advance

  5. I would agree with the lisp comment but I would change it to 'Haskell' if I wrote it; call it personal preference. It would probably be better off as 'Functional Programming' to be fair to everyone. Other than that I would agree completely; my past ten years in the programming world have taught me roughly the same lessons; especially how everything can be, and alot should be, done from the terminal.

  6. Pretty good advice. I really liked the "all code turns to shit" and "be goo" ones.

  7. I liked the build-or-buy lesson.

  8. DavidT said:
    "why only use an text editor? isn't MUCH more slowly use an text editor than a IDE?"

    if by text editor you mean notepad, yes, much more.

    "what are the benefits?"

    non-cluttered UI? hands on keyboard?

    But that's not quite the point: the point is that if the language you are using is demanding tons of text for you to feel the need for an IDE to handle all that complexity, then the language is getting in the way by not providing enough abstractions to concisely state a solution...

  9. 1. Don't darn add to the programming language shitbag.

    2. Yeah, sure. Why not use strings as math types? They offer perfect and infinite precision! (/sarcasm)

    3. LISP....I'll just try to ignore you ever said that.

    4. ORM; that depends on what you will be using it for.

    5. How about this. Next time you're teaching anything computer related, check the plaque outside that it doesn't say "Catering Hall".

    6. Why use a terminal? Real Programmers use typewriters and punch cards.

    7. UNIX...yeah, the very first clever thing they did was that they assumed no one would be using spaces in file names. Clever indeed.

    8. JSON; I agree on that. Though the use is subjective most of the time.

    9. Delete...I've always found out, in one way or another, that software never real deletes stuff. Except while saving.

    10. Thank goodness windows did one good thing in throwing "deleted" objects to the recycle bin. Sounds a cleaner approach than mv-ing to c:\windows\temp

    11. ...

    12. ...

    13. Sounds like a good place to start:

    14. I would add "store names and surnames in separate tables".

    15. Better still, throw away your "trusty" UNIX box and get someone to run a real server.

    16. The one true god is the terminal....isn't it? 20 years of bleeding-edge development...and we're still stuck with a 1980's terminal.

    17. What's besides javascript? VBS? Flash? Java? JS ain't "uber", it's just "unique", "monopolistic".

    18. Though SMs are always a nice exercise, they really aren't the best of paradigms.

    19. ...

    20. ...

    21. I would advise against it. The world needs less game engines and more quality ones.

    22. ...

    23. ...

    24. Source control is crap. It's one of the worst time wastes in computing. Don't learn SC and wait till a real one (eventually) comes by.

    25. ...

    26. ...

    27. ...

    28. ...

    29. ...

    30. Says someone who's pricklier than an urchin when it comes to programmer's tools.

  10. There is one other lesson that you hint at: Never use or design a GUI. It is a sign of weakness to use any tool that you don't memorize a thousand commands for. Original UNIX got away without it, and there is no real point to it. Users that need GUIs aren't worth writing code for and will only cause you trouble as they tend to be stupid.

  11. Good points, but i cant understand why an IDE is so evil . . . like why would we progress, we should write everything in C {/sarcasm}, because it can?

  12. Speaking words of wisdom!! hail to you

  13. I definitely agree with the exception of:

    "Never wait for money to do anything; there is always a place to start."

    Though I agree with the latter portion of the statement ("...there is always a place to start") I can't agree with the former part ("never wait for money to do anything"). In my experience, you should (are) to at least know that the money has arrived and is on it's way to clearing with the bank before doing anything. Getting a "head-start" is a good practice, but if you start before some re-assurance of payment, you'll get burned when the client delays and delays and delays or never makes payment. Then the "head-start" becomes wasted time and effort.

  14. @Christian V. Sciberras

    I see you like using patches, tarballs and directory copies instead of SC.
    Your post can be generally described as "This cat is pushing out a water melon out of a lake, your arguments are invalid.". No arguments whatsoever.

  15. Dear M.G,

    You might like to see a few items on programming at

    2. (How to
    write computer programs)

    3. and a bunch of other programming/math stuff.

    - g knott

  16. Interesting writeup some things I disagree with though.
    There is no such thing as an Uber language, no matter how much you like LISP and a good IDE is a better choice for development simply because ---> Programming langauges, IDEs, Operating Systems, Algorithms, Computers and all of that are TOOLS we use. Some jobs require one set of tools others another. Restricting yourself to one thing because it is "uber" can and will lead to disaster.

    My few lessons of programming:
    1. Master the basics [Memory, Logic, Math].
    2. Understand the problem.
    3. Define a solution.
    4. Choose your tools [Also, know your tools].
    5. Test and code.
    6. Backup on a regular basis.
    7. Version Control, never leave home without it.
    8. There is no such thing as a FINISHED program.
    9. Everything else is fluff on the water.

    If you want to write an IDE go ahead, why not, who are you to tell someone what to do or not to do?
    If Unix got it so right how come it's
    constantly being updated?
    And hello, Terminal/Editor/Compiler is just a really basic form of IDE, why not use something just 'slightly' better?? The only programming not done on IDEs is done on paper..

  17. Very very wise. true power of a UNIX terminal is endless.

  18. very good, felicitaciones !!!

  19. write five games before writing a game engine.

  20. After knowing a bit javascript, dig into coffeescript. You can learn it in 5 minutes and you'll be much happier.

  21. "If you need an IDE, then you are doing something wrong."

    Huh? What? I've also done a lot of programming and know the command line, but really, an IDE makes me so much more productive. I cringe when I see my coworkers struggle with five different programs and searching for the cause of the syntax error.

  22. @openid, IDE tools are great for rapid development, however if you can't do programming with simple notepad but always need an IDE to start, thats something not soo good

  23. an amazing list of thoughts! your wisdom is beyond criticism: you have mastered a way of learning through deep shit! which is of course all yours

  24. GUI has its place as a sort of personal stack extender and I find it helpful when I'm in the poorly defined problem phase. But when I'm doing something I know how to do, the focus that the terminal promotes is where I turn.

  25. Ricardo Saracino asks "i cant understand why an IDE is so evil". The answers are that the IDE tends towards driving the development. This is not so bad when the team has good control over the IDE but few development teams can afford to development the product AND the IDE at the same time. This is why, in part, that the Unix command line can be so powerful: The development team can afford to develop the product and scripts at the same time.

  26. Care to elaborate on why not to delete columns? With our orm it hasn't been a problem...

  27. I would say learn all computing paradigms: object, imperative, functional and logic (we all love our prolog).

    You meant Haskell not lisp right? :)

    And the JSON vs. XML debate - your point of view is absolutely correct as far as a dev goes. But people use XML for documents (books, contracts) and writing those in JSON is just plain ugly and dumb. Just like making a DSL to express HTML in JSON would be total crap. So yes JSON is great for developers and things developers (wrongly) use XML for. But dismissing XML all together? You'll end up reinventing XML.