Essays for Programmers

written by Guido Percú on November 10, 2020

Essays on Programming

Peter Norvig "Teach Yourself Programming in Ten Years" is a classic. Read it if you ever found yourself in a hurry to learn a new language or the most hyped Javascript framework.

"Get interested in programming, and do some because it is fun. Make sure that it keeps being enough fun so that you will be willing to put in your ten years"

Patrick Mckenzie on "Falsehoods Programmers Believe About Names".

I have lived in Japan for several years, programming in a professional capacity, and I have broken many systems by the simple expedient of being introduced into them. (Most people call me Patrick McKenzie, but I’ll acknowledge as correct any of six different “full” names, any many systems I deal with will accept precisely none of them.) Similarly, I’ve worked with Big Freaking Enterprises which, by dint of doing business globally, have theoretically designed their systems to allow all names to work in them. I have never seen a computer system which handles names properly and doubt one exists, anywhere.

More essays like this can be found on Awesome Falsehood.

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.

Edgar Dijkstra: Go To Statement Considered Harmful. Meyer explains why "Considered Harmful" Essays are Considered Harmful.

Joel Spolsky on his "12 Steps to Better Code" shares his experiences on what we should measure to improve the quality of our own software team.

Of course, these are not the only factors that determine success or failure: in particular, if you have a great software team working on a product that nobody wants, well, people aren’t going to want it. And it’s possible to imagine a team of “gunslingers” that doesn’t do any of this stuff that still manages to produce incredible software that changes the world. But, all else being equal, if you get these 12 things right, you’ll have a disciplined team that can consistently deliver.

I also recommend reading "Can Your Programming Language do this", "Getting your resume read", "Advice for Computer Science College Students", "Things you should never do" and "The Absolute Minimum Every Sofware Developer Absolutely Positively Must Know About Unicode and Character Sets: No Excuses"

How to Build a Strong Career in Tech by Thiago Ghisi, this article is based on a excellent talk at The Conf. There is some great advice on how to manage your career that can be learned from this article.

You will be good at everything that you put the effort into.

Do you want to be a better leader? Put the effort into it. How? Do the work that nobody is doing but that is critical for success.

The more meetings you facilitate, the better you will be at it.

The more critical communication you do, the better you will be at it.

The more feedback you give, the more comfortable and skilled you will be next time you need to give feedback to someone.

Paul Graham is a programmer and investor who writes some of my favorite essays. A short list of the most influentional on my way of thinking:

Hackers and Painters - that is also the title of his book.

Hacking and painting have a lot in common. In fact, of all the different types of people I've known, hackers and painters are among the most alike.

Maker's Schedule, Manager's Schedule

One reason programmers dislike meetings so much is that they're on a different type of schedule from other people. Meetings cost them more.
There are two types of schedule, which I'll call the manager's schedule and the maker's schedule. The manager's schedule is for bosses. It's embodied in the traditional appointment book, with each day cut into one hour intervals. You can block off several hours for a single task if you need to, but by default you change what you're doing every hour.

Writing, Briefly and How to Write Usefully

I think it's far more important to write well than most people realize. Writing doesn't just communicate ideas; it generates them. If you're bad at writing and don't like to do it, you'll miss out on most of the ideas writing would have generated.

On Why the next language you learn should be functional Yaron Minsky argues in favor of functional programming.

"I've been using OCaml in a production environment for nearly a decade, and over that time I have become convinced that functional languages, and in particular, statically typed ones such as OCaml and Haskell, are excellent general-purpose programming tools—better than any existing mainstream language. They also have an enormous range, being well suited for small scripting tasks as well as large-scale high-performance applications. They are not the right tool for every job, but they come surprisingly close."

Alan Turing is considered the father of Computer Science and a personal hero.

This blog post was inspired by Essays on programming I think about a lot.