It can be better to copy a little code than to pull in a big library for one function. Dependency hygiene trumps code reuse.
A programmer does not primarily write code; rather, he primarily writes to another programmer about his problem solution. The understanding of this fact is the final step in his maturation as technician.
Telling a programmer there's already a library to do X is like telling a songwriter there's already a song about love.
Almost without exception, the best products are developed by teams with desire to solve a problem; not a company's need to fulfil a strategy.
(...) Thinking this way will teach you two things about computers: One, there’s no magic, no matter how much it looks like there is. There’s just work to make things look like magic. And two, it’s crazy in there.
Well-designed components are easy to replace. Eventually, they will be replaced by ones that are not so easy to replace.
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
Big data is like teenage sex: everyone talks about it, nobody really knows how to do it, everyone thinks everyone else is doing it, so everyone claims they are doing it...
And the reason these things take a generation is because ultimately we do not change people's minds. We have to wait for the previous generation to retire or die before we can get critical mass on the next idea. So it's like we look around: "Are they gone?"
There is no single development, in either technology or management
technique, which by itself promises even one order-of-magnitude
improvement within a decade in productivity, in reliability, in simplicity.
The best reaction to "this is confusing, where are the docs" is to rewrite the feature to make it less confusing, not write more docs.
Data dominates. If you’ve chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.