5 ms·

This is pretty good advice overall. One small change I suggest is to take it easy on Design Patterns and the like. I’ve seen people in OPs position (general sma

This is pretty good advice overall. One small change I suggest is to take it easy on Design Patterns and the like. I’ve seen people in OPs position (general smarts but limited production experience) turn into architecture astronauts and start overengineering everything. It can be useful if you’re working on a legacy codebase and need to understand the jargon that can appear in [possibly overengineered] existing codebases.

perfmode 8y ago
as a middle ground: my advice would be to learn and internalize design patterns. and then “forget them.” let experience show you when to break the rules. keep things simple. this level of the craft is subtle, intuitive, and often inaccessible to the conscious intellect.
briandear 8y ago
I agree. I would like to add, doing something like The Rails Tutorial from Michael Hartl would be a great place to start. It takes you through a reasonably real world application including testing and how to think about the constituent parts. A PhD is like being an expert in materials science while lacking in craft-level skills such as running a vertical mill.
fsloth 8y ago
I've written software over a decade and I loath the design patterns book. I would not give it to a beginner as it would corrupt their mind with useless drivel . It's authors exhibit themselves as morons who celebrate renaming existing computer science concepts while occasionally mixing and matching them. I would not be this uncharitable towards it if it was not such a famous (and hence harmfull) book. It's harmfull because software engineering is really hard, and they just add up to the load by trying to have the reader memoize their junk instead of doing something that would actually make them a better programmer. And, if you try to use their concepts while programming - shudders, oh god help you. I'm not going to iterate over every pattern. Here's an example: Flywheight? You assholes, just tell memoization for what it is. Why don't you rename existing data structures as well? Good thing those come out of the box, otherwise you would have began the book by renaming array, linked list and dictionary. Maybe you would have called linked list "the chaingang" or something. You don't simplify things by giving things cuddlier names. You stunt peoples growth that way. Gang of four book is a malignant offshoot of the practice of attempting to make software engineering better by legalizing and dogmatizing it by decomposition into trivial details that hurt your brain. It's a branch of 'consultancy driven software development' where people attempt to aquire a halo of professionalism by calling things by fancy names and over-complex descriptions (while skipping the practical things with equally complex names but at least those weren't made up by a bunch of idiots).
- voltooid 8y ago
  Your comment is very interesting. I recently took a course on Design Patterns. I sat squirming during the lectures because I didn't like what was being said, but couldn't put my finger on what exactly I disliked. What I understand from your comment is that you dislike the Gang of four book because it renames concepts that don't need the cutesy names that they give them. Do you have a problem with the _concept_ of design patterns? Or just the names they are given? Are the concepts themselves sound and worth paying attention to?
  - reacweb 8y ago
    I do not like the GOF book. Some of the patterns appears sometimes in my code, but the book has never helped me to program better or helped me to think about my code. The single benefit I got from this book is that it gaves me words to explain my code to other people.
  - fsloth 8y ago
    I wrote a long rant as a response to another comment above. To quote myself: "It reads like it was written by a clever, verbose, and 'over-eager novice." Design patterns are a really usefull concept. The GoF book just totally botches up that concept by dwelving deep in trivial language details while missing the big picture. Christopher Alexander's "A timeless way of building", and "Notes on the Synthesis of Form" are the books in architecture that prompted a lot of dicussion in software design circles, and from which I presume GoF got their idea of software design patterns. What are good design patterns in software? IMO they are composed from the programming models exposed in a basic CS book like Aho and Ullman's "Foundations of Computer Science" and further developed in a books like Structure And Intrepretation of Computer Programs. GoF is an ok anecdotal reference after those, but it really is not suitable as a didactic resource. Peter Norvig wryly commented that 16 of the 23 pattern are either invisible or non-existent in lisp Lisp[0]. [0] http://www.norvig.com/design-patterns/design-patterns.pdf http://www.norvig.com/design-patterns/design-patterns.pdf
  - beaconstudios 8y ago
    your instinctual reaction against design patterns because you may have realised that design patterns are patches over flaws in the programming language's design - they're a terrible basis to build an architecture on. There's some discussion on this idea at the C2 wiki: http://wiki.c2.com/?AreDesignPatternsMissingLanguageFeatures http://wiki.c2.com/?AreDesignPatternsMissingLanguageFeatures
DeathRabbit 8y ago
To all readers who've never experienced it, working on a large Java (and other) codebases where the original developers completely overused patterns, your life will be hell in my opinion, just as much as a codebase written totally without thought or patterns. Patterns can be useful but only in moderation and only with reason. They're spice. A contrived example, but: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... FizzBuzz Enterprise Edition. It's enterprisey!

perfmode 8y ago

as a middle ground: my advice would be to learn and internalize design patterns. and then “forget them.” let experience show you when to break the rules. keep things simple. this level of the craft is subtle, intuitive, and often inaccessible to the conscious intellect.

briandear 8y ago

I agree. I would like to add, doing something like The Rails Tutorial from Michael Hartl would be a great place to start. It takes you through a reasonably real world application including testing and how to think about the constituent parts. A PhD is like being an expert in materials science while lacking in craft-level skills such as running a vertical mill.

fsloth 8y ago

I've written software over a decade and I loath the design patterns book. I would not give it to a beginner as it would corrupt their mind with useless drivel . It's authors exhibit themselves as morons who celebrate renaming existing computer science concepts while occasionally mixing and matching them. I would not be this uncharitable towards it if it was not such a famous (and hence harmfull) book. It's harmfull because software engineering is really hard, and they just add up to the load by trying to have the reader memoize their junk instead of doing something that would actually make them a better programmer. And, if you try to use their concepts while programming - shudders, oh god help you. I'm not going to iterate over every pattern. Here's an example: Flywheight? You assholes, just tell memoization for what it is. Why don't you rename existing data structures as well? Good thing those come out of the box, otherwise you would have began the book by renaming array, linked list and dictionary. Maybe you would have called linked list "the chaingang" or something. You don't simplify things by giving things cuddlier names. You stunt peoples growth that way. Gang of four book is a malignant offshoot of the practice of attempting to make software engineering better by legalizing and dogmatizing it by decomposition into trivial details that hurt your brain. It's a branch of 'consultancy driven software development' where people attempt to aquire a halo of professionalism by calling things by fancy names and over-complex descriptions (while skipping the practical things with equally complex names but at least those weren't made up by a bunch of idiots).

voltooid 8y ago
Your comment is very interesting. I recently took a course on Design Patterns. I sat squirming during the lectures because I didn't like what was being said, but couldn't put my finger on what exactly I disliked. What I understand from your comment is that you dislike the Gang of four book because it renames concepts that don't need the cutesy names that they give them. Do you have a problem with the _concept_ of design patterns? Or just the names they are given? Are the concepts themselves sound and worth paying attention to?
- reacweb 8y ago
  I do not like the GOF book. Some of the patterns appears sometimes in my code, but the book has never helped me to program better or helped me to think about my code. The single benefit I got from this book is that it gaves me words to explain my code to other people.
- fsloth 8y ago
  I wrote a long rant as a response to another comment above. To quote myself: "It reads like it was written by a clever, verbose, and 'over-eager novice." Design patterns are a really usefull concept. The GoF book just totally botches up that concept by dwelving deep in trivial language details while missing the big picture. Christopher Alexander's "A timeless way of building", and "Notes on the Synthesis of Form" are the books in architecture that prompted a lot of dicussion in software design circles, and from which I presume GoF got their idea of software design patterns. What are good design patterns in software? IMO they are composed from the programming models exposed in a basic CS book like Aho and Ullman's "Foundations of Computer Science" and further developed in a books like Structure And Intrepretation of Computer Programs. GoF is an ok anecdotal reference after those, but it really is not suitable as a didactic resource. Peter Norvig wryly commented that 16 of the 23 pattern are either invisible or non-existent in lisp Lisp[0]. [0] http://www.norvig.com/design-patterns/design-patterns.pdf http://www.norvig.com/design-patterns/design-patterns.pdf
- beaconstudios 8y ago
  your instinctual reaction against design patterns because you may have realised that design patterns are patches over flaws in the programming language's design - they're a terrible basis to build an architecture on. There's some discussion on this idea at the C2 wiki: http://wiki.c2.com/?AreDesignPatternsMissingLanguageFeatures http://wiki.c2.com/?AreDesignPatternsMissingLanguageFeatures

DeathRabbit 8y ago

To all readers who've never experienced it, working on a large Java (and other) codebases where the original developers completely overused patterns, your life will be hell in my opinion, just as much as a codebase written totally without thought or patterns. Patterns can be useful but only in moderation and only with reason. They're spice. A contrived example, but: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... FizzBuzz Enterprise Edition. It's enterprisey!