4 ms·

God don't read anything about patterns or refactoring. That'll sap all of your creativity and cover you in a tight fitting straight jacket. Read a language spec

God don't read anything about patterns or refactoring. That'll sap all of your creativity and cover you in a tight fitting straight jacket. Read a language spec. That gives you the building blocks. Then go away and play with them.

asciilifeform 17y ago
> don't read anything about patterns or refactoring Actually, I wish I had done so. Then, after dumping it in disgust, I wouldn't have allowed programming to burn my youth, and would perhaps now be in an honest and not yet intellectually-stunted field like chemistry - where cube farms are unknown and the subject has some actual (vs. accidental) depth (see: http://tinyurl.com/lfzb58 http://tinyurl.com/lfzb58)
fizx 17y ago
I read the Gang of Four Design Patterns book straight out of college when I had a job as a dev lead at a small lifestyle software startup. Man, I tried to make every problem fit into that mindset. I'd do things like hand-roll my own XML parser in PHP (never mind LibXML bindings, etc) while trying to make sure I was observing the Visitor and Command patterns, oblivious to the silliness of the situation. I also missed the understanding of dependency injection (or just management in general) that would have made that hellishly large Flash project so much easier to test and assemble. Somehow I still managed to get a lot done. I feel in retrospect, that the Design Patterns are good to know about, but I don't know about whether anyone should intend to implement them.
- fizx 17y ago
  Also, I remember interviewing with an early Bubble2.0 startup, and spouting tons of Design Pattern rhetoric to a Smalltalk guru. Also I tried to make small talk about wife and kids, when in retrospect, it should have been obvious that in SF, that isn't always the way people are wired.
- ovi256 17y ago
  The CTO at a startup I worked at read some book about patterns sometime before I got there. Guess what ? They HAD to start on a new version of their VoIP client right away, and it HAD to be architected using patterns. Right. The v1 is still the best.
- akeefer 17y ago
  Patterns are primarily useful when you refactor to a pattern once you've gotten through the implementation to the point where you realize that applying the pattern would improve the code you've already written and make it clearer/more flexible/easier to extend. Starting with the intention of implementing a given pattern is almost always the wrong thing; recognizing when you've inconsistently half-implemented something very similar to a well-established pattern can actually help improve your code. Unfortunately, people do often attempt to start from the pattern, which gives the whole idea of patterns a bad name, since most people's primary exposure to them comes from Some Guy In The Office Who Just Read The Gang Of Four Book And Now Tries To Use Patterns For Everything He Does. And everyone, rightly, hates working with that guy or his code. The same thing happens with XP/Agile/TDD, where most people's exposure to them is from some annoying zealot rather than someone a little more experienced and pragmatic.

asciilifeform 17y ago

> don't read anything about patterns or refactoring Actually, I wish I had done so. Then, after dumping it in disgust, I wouldn't have allowed programming to burn my youth, and would perhaps now be in an honest and not yet intellectually-stunted field like chemistry - where cube farms are unknown and the subject has some actual (vs. accidental) depth (see: http://tinyurl.com/lfzb58 http://tinyurl.com/lfzb58)

fizx 17y ago

I read the Gang of Four Design Patterns book straight out of college when I had a job as a dev lead at a small lifestyle software startup. Man, I tried to make every problem fit into that mindset. I'd do things like hand-roll my own XML parser in PHP (never mind LibXML bindings, etc) while trying to make sure I was observing the Visitor and Command patterns, oblivious to the silliness of the situation. I also missed the understanding of dependency injection (or just management in general) that would have made that hellishly large Flash project so much easier to test and assemble. Somehow I still managed to get a lot done. I feel in retrospect, that the Design Patterns are good to know about, but I don't know about whether anyone should intend to implement them.

fizx 17y ago
Also, I remember interviewing with an early Bubble2.0 startup, and spouting tons of Design Pattern rhetoric to a Smalltalk guru. Also I tried to make small talk about wife and kids, when in retrospect, it should have been obvious that in SF, that isn't always the way people are wired.
ovi256 17y ago
The CTO at a startup I worked at read some book about patterns sometime before I got there. Guess what ? They HAD to start on a new version of their VoIP client right away, and it HAD to be architected using patterns. Right. The v1 is still the best.
akeefer 17y ago
Patterns are primarily useful when you refactor to a pattern once you've gotten through the implementation to the point where you realize that applying the pattern would improve the code you've already written and make it clearer/more flexible/easier to extend. Starting with the intention of implementing a given pattern is almost always the wrong thing; recognizing when you've inconsistently half-implemented something very similar to a well-established pattern can actually help improve your code. Unfortunately, people do often attempt to start from the pattern, which gives the whole idea of patterns a bad name, since most people's primary exposure to them comes from Some Guy In The Office Who Just Read The Gang Of Four Book And Now Tries To Use Patterns For Everything He Does. And everyone, rightly, hates working with that guy or his code. The same thing happens with XP/Agile/TDD, where most people's exposure to them is from some annoying zealot rather than someone a little more experienced and pragmatic.