5 ms·
1. Start with the answer, then work back. 2. Don't repeat yourself. (DRY) 3. Normalize the data. The process will follow. 4. Isolate. Isolate. Isolate.
by edw519 12y ago
1. Start with the answer, then work back.
2. Don't repeat yourself. (DRY)
3. Normalize the data. The process will follow.
4. Isolate. Isolate. Isolate.
5. It worked. You touched it. It doesn't work. It was you.
6. Write for the next programmer, not the machine.
7. If you don't hate your old code, you haven't grown enough.
8. The first A/B test is your own.
9. Focus on the microseconds & the nanaseconds take care of themselves.
10. The fastest code is the code you don't write.
11. The 2nd worst programmer is who wrote what you're maintaining.
12. The worst programmer is the one who changes your code.
13. Comments don't execute.
14. The best technical co-founder is a code generator.
15. The user never knows what they want until UAT.
16. Fast. Cheap. Right. Choose 2.
17. Perfect specs or rapid iterations. Choose 1.
18. Start with "Hello World", then amend.
19. Never deploy on Friday.
20. Forget to unit test? That's a paddlin'.
- sp332 12y agoWhat does #8 mean?
- shangxiao 12y agoI take it to mean that you'll be the first person to smoke test changes
- shangxiao 12y agoThese are quite good, source? I've heard of most of in one form or another from different people.
- V-2 12y agoAd. 7. True, but if you get to hate your old code all the time, you must be doing something wrong and you probably don't actually progress.
- SideburnsOfDoom 12y ago> Don't repeat yourself. (DRY) Beware the Share: http://programmer.97things.oreilly.com/wiki/index.php/Beware_the_Share http://programmer.97things.oreilly.com/wiki/index.php/Beware... It can bite you just as hard as DRY.
- lmm 12y agoReally? I've never seen that happen in today's days of, well, maven.
- SideburnsOfDoom 12y agoI don't know your language's tooling, but I don't think that the decision of when to share code or not - (i.e. if it actually represents the same concept) is something that is solved by a specific tool, or is limited to a specific language.
- lmm 12y agoI've never seen a problem that comes from code being shared, and I think that comes from maven getting the rules right: * Releases are immutable * Releases can only depend on releases * Releases can only be made when all tests pass. Twice. * The transitive dependency graph is a deterministic function of the config file; upstream changes cannot affect it * Dependency versions are only updated by an explicit manual step You never worry about "synchronizing" changes because other components can perfectly well depend on an old version of the library. You never accidentally break a downstream project, because everything's explicit. I have genuinely never seen the problems described in your link.
- SideburnsOfDoom 12y agoYou are talking about binary compatibility and immutable dependencies. That's nice, but it's a different topic to the conversation that jerf and I are having about the semantics of shared code. I'm sure maven is good at what it does, but it's not completely relevant.
- lmm 12y agoFine, then let me put it this way: your initial claim in no way matches my experience. "Beware the Share" is bad advice; that wiki page is simply wrong. Factoring out common code is a good thing and will not bite you.
- btbuildem 12y agoAmen to #19!