4 ms·

He saved the best line for last and knew it: >Sooner or later, you will meet some older man who has been around for a while. At some point, this man will lectu

He saved the best line for last and knew it: >Sooner or later, you will meet some older man who has been around for a while. At some point, this man will lecture you about the Laws of Programming. Ignore this man entirely. That said, like everyone else I'm going to add my most salient bits: 1. Keep It Simple, Stupid 2. Programming is a lifelong study of the difference between what you said and what you meant to say. 3. Reflect reality in your modelling. 4. If you have to get creative, you might be doing it wrong. 5. Build tests first when you can. 6. You're coding for two audiences: The computer and the future programmer. Favor the latter, because the computer doesn't need help understanding your code. 7. There are two hard problems in programming: naming things, cache invalidation, and off by one errors.

TeMPOraL 8y ago
> 2. Programming is a lifelong study of the difference between what you said and what you meant to say. This week I finished reading "Startide Rising", a 1983 (!) novel. There was this gem hidden in it: "You don’t have conversations with microprocessors. You tell them what to do, then helplessly watch the disaster when they take you literally."
- mercer 8y ago
  I usually try to imagine my computer/code as an extremely dumb superhero personal assistant. If I want my coffee I have to spend quite a bit of time instructing said assistant to open doors along the way rather than just walk into them (thankfully there's an OpenDoorEx library for that!). I'll also have to carefully come up with an exhaustive list of interactions that my assistant might have with the barista (and agonize over the fact that I can never be sure that this external API is fully covered). And that's just some of it. But when I've done all that work, my assistant can get my a coffee in seconds, because they're ridiculously fast, powerful, and precise. And over time the work I put in up-front will be paid off pretty quickly because it takes them seconds rather than an hour to get me my coffee, twice a day. I suppose the fact that I sort of enjoy coming up with these ridiculously precise instructions is why I'm a programmer. Of course in practice the OpenDoors library will break, or one of the doors on the way suddenly works differently. The new barista might have a speech impediment, or the items on the menu might change. Or my boss wants coffee too so now I have to teach my assistant to open doors with their elbows. To normal people all of this is purely maddening, but for me it's 50% frustrating, and 50% an excuse to get to come up with new instructions!
- simtel20 8y ago
  Such an amazing book. I hope you are inspired to read the rest of Brin's work.
  - TeMPOraL 8y ago
    I binged "Sundiver" and "Startide Rising" over the last two weeks, and currently I'm well into "The Uplift War", and planning to continue on with the remaining three books. I love the universe so far. Fun fact, in "The Uplift War" (1987!) I found what looks like a reference to cryptocurrencies: "The money inside was GalCoin, untraceable and unquestionable throughout war and turmoil, for it was backed by the contents of the Great Library itself."
bitminer 8y ago
No matter how fast the hardware boys make the machine, the software boys will piss the performance away. Operations is a thing, and it's harder than coding. Especially with a customer on the phone. Your customer's expectations will always exceed the functionality you have provided. Get over it. All the biggest mistakes occur in the first days of a new project. Testing shows the presence of bugs, not their absence. If you think your TDD (test-driven development) method produces correct code, then you will be disappointed. Nobody reads Brooks anymore.
aaron695 8y ago
> 6. You're coding for two audiences: The computer and the future programmer. Favor the latter, because the computer doesn't need help understanding your code. You'll never meet "the future programmer" so I don't see how this is true. They will never know you existed, you'll never know they existed. The tree may or may not have fallen in the forest. Heck most of the stuff you work on never gets seen again. And I've never seen someone punished for not coding for "the future programmer". Do we want real truths?
- SAI_Peregrinus 8y ago
  Funny, I've often been the future programmer. And It's often my own code I'm looking at. Past me has been such an asshole...

TeMPOraL 8y ago

> 2. Programming is a lifelong study of the difference between what you said and what you meant to say. This week I finished reading "Startide Rising", a 1983 (!) novel. There was this gem hidden in it: "You don’t have conversations with microprocessors. You tell them what to do, then helplessly watch the disaster when they take you literally."

mercer 8y ago
I usually try to imagine my computer/code as an extremely dumb superhero personal assistant. If I want my coffee I have to spend quite a bit of time instructing said assistant to open doors along the way rather than just walk into them (thankfully there's an OpenDoorEx library for that!). I'll also have to carefully come up with an exhaustive list of interactions that my assistant might have with the barista (and agonize over the fact that I can never be sure that this external API is fully covered). And that's just some of it. But when I've done all that work, my assistant can get my a coffee in seconds, because they're ridiculously fast, powerful, and precise. And over time the work I put in up-front will be paid off pretty quickly because it takes them seconds rather than an hour to get me my coffee, twice a day. I suppose the fact that I sort of enjoy coming up with these ridiculously precise instructions is why I'm a programmer. Of course in practice the OpenDoors library will break, or one of the doors on the way suddenly works differently. The new barista might have a speech impediment, or the items on the menu might change. Or my boss wants coffee too so now I have to teach my assistant to open doors with their elbows. To normal people all of this is purely maddening, but for me it's 50% frustrating, and 50% an excuse to get to come up with new instructions!
simtel20 8y ago
Such an amazing book. I hope you are inspired to read the rest of Brin's work.
- TeMPOraL 8y ago
  I binged "Sundiver" and "Startide Rising" over the last two weeks, and currently I'm well into "The Uplift War", and planning to continue on with the remaining three books. I love the universe so far. Fun fact, in "The Uplift War" (1987!) I found what looks like a reference to cryptocurrencies: "The money inside was GalCoin, untraceable and unquestionable throughout war and turmoil, for it was backed by the contents of the Great Library itself."

bitminer 8y ago

No matter how fast the hardware boys make the machine, the software boys will piss the performance away. Operations is a thing, and it's harder than coding. Especially with a customer on the phone. Your customer's expectations will always exceed the functionality you have provided. Get over it. All the biggest mistakes occur in the first days of a new project. Testing shows the presence of bugs, not their absence. If you think your TDD (test-driven development) method produces correct code, then you will be disappointed. Nobody reads Brooks anymore.

aaron695 8y ago

> 6. You're coding for two audiences: The computer and the future programmer. Favor the latter, because the computer doesn't need help understanding your code. You'll never meet "the future programmer" so I don't see how this is true. They will never know you existed, you'll never know they existed. The tree may or may not have fallen in the forest. Heck most of the stuff you work on never gets seen again. And I've never seen someone punished for not coding for "the future programmer". Do we want real truths?

SAI_Peregrinus 8y ago
Funny, I've often been the future programmer. And It's often my own code I'm looking at. Past me has been such an asshole...