Bram Cohen Quotes

Adding functionality is not just a matter of adding code.

And, I think that is actually appropriate because I'm really not the world's best programmer, I think it's a good thing that I'm not touching the code.

So Chuck and I looked at that and we hacked on em for a while, and eventually we ripped the stuff out of em and put some of it into what was then called en, which was really ed with some em features.

No matter what, the way to learn to program is to write code and rewrite it and see it used and rewrite again. Reading other people's code is invaluable as well.

I have the ability to get code done, but I'm impatient, and it's scrappy as a result. Maybe that helped me with 'Minecraft,' as it came quickly. But, well, at some point, I'd like to actually become a good programmer.

Don't hurry your code. Make sure it works well and is well designed. Don't worry about timing.

Good code is its own best documentation. As you're about to add a comment, ask yourself, "How can I improve the code so that this comment isn't needed?" Improve the code and then document it to make it even clearer.

Even if you aren't in doubt, consider the mental welfare of the person who has to maintain the code after you, and who will probably put parens in the wrong place.

Don't document bad code - rewrite it.

People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird.

Low-level programming is good for the programmer's soul.

It is easier to write an incorrect program than understand a correct one.

There are two methods in software design. One is to make the program so simple, there are obviously no errors. The other is to make it so complicated, there are no obvious errors.

One of my most productive days was throwing away 1,000 lines of code.

There has never been an unexpectedly short debugging period in the history of computers.

My list of basic tools is a partial answer to the question about what has changed: Over the past few years, large numbers of programmers have come to depend on elaborate tools to interface code with systems facilities.

An individual developer like me cares about writing the new code and making it as interesting and efficient as possible. But very few people want to do the testing.

My favorite language for maintainability is Python. It has simple, clean syntax, object encapsulation, good library support, and optional named parameters.

Program construction consists of a sequence of refinement steps.

In software engineering, we have the term 'technical debt.' When you don't do a job correctly, unaddressed problems become harder and harder to solve.

C is a razor-sharp tool, with which one can create an elegant and efficient program or a bloody mess.

Often in writing programs, articulation and clarity are more important than what you actually say.

All programming is maintenance programming, because you are rarely writing original code.

Good programmers know what to write. Great ones know what to rewrite (and reuse)

Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.