计算机名言

Jun 24, 2017 20:00 · 672 words · 2 minutes read

计算机方面的名言警句

Any fool can write code that a computer can u nderstand. Good programmer write code that humans can understand. – Martin Fowler

You think you know when you learn, are more sure when you can write, even more when you can teach, but certain when you can program. – Alan Perlis(Yale University computer scientist)

Make it run, make it right, make it fast –Butler Lampson

The best writing is rewriting –E. B. White

Programs must be written for people to read, and only incidentally for machines to execute. – Abelson & Sussman, SICP, preface to the first edition

A man is a success if he get up in the morning and get to bed at night and in between he does what he wants to do

– Bob Dylan

Emacs outshines all other editing software in approximately the same way that the noonday sun does the stars. It is not just bigger and brighter; it simply makes everything else vanish. -Neal Stephenson, “In the Beginning was the Command Line”

Most people just make the mistake that is should be simple to design simple things. In reality, the effort required to design something is inversely proportional to the simplicity of the result. – Roy Fileding

If a problem is not completely understood, it is probably best to provide no solution at all. – principles of X

I hate code, and I want as little of it as possible in out product – Jack Diederich

The old adage “don’t reinvent the wheel” doesn’t apply when the wheel comes attached to locomotive engin. Inventing your own wheels give you a deep appreciation and understanding of how wheels work and what makes a good one.

The signature of “this shouldn’t be a class” is when the class has two methods, and one of them is the constructor. Any time you see these signs, you probably should have just written a function.

Refactoring > Rewriting

The most important element of successful software development is learning.

Good IT workers really don’t like saying “I don’t know.” If they say it, they probably mean it. So stop pushing for a definitive answer when one doesn’t exist. It’s perfectly resonable to want some sort of plan up front. I’m actually one of those funny types who believe up front planning is a necessity. So long as everyone understands an estimate is just that: an estimate. You learn as you go along and discore more detail. So you revise the estimate accordingly.

“If people knew how hard I worked to get my mastery, it wouldn’t seem so wonderful at all.” - Michelangelo

Building something by gradually refine a prototype is good for morale because It keeps you engaged. In software my rule is: always have working code. If you’re writing something you’ll be able to test in an hour, you have the prospect of an immediate reward to motivate you. The same is true in the arts, and particularly in oil painting. Most Painters start with a blurry sketch and gradually refine it. – From P.G. Hakers and Painters

Just like an expensive guitar won’t make you a great guitar player and the best running shoes won’t get you out of the door every day, productivity techniques won’t finish your project. They might help, but you have to put the work in. You have to keep showing up and keep chipping away at it. No tool will ever do that for you.

https://thorstenball.com/blog/2017/01/16/what-i-didnt-do-to-write-a-book/

If they don’t have the money to pay you, you’re not an employee, you’re a founder and you get the same deal that they get.

If they balk, suggest that they find another code monkey while you find another biz monkey and let the market decide who ends up with the bananas. – From https://news.ycombinator.com/item?id=287767