[mikekchar]

My advice for design: Design is hard. Good design is so hard that you will almost never see it in the wild. It becomes even harder when you work with other people. Your carefully crafted ideas will be crushed under the foot of the next confident programmer who thinks they have found the holy grail of design. As more and more programmers are added, they pour in their particular favourite flavour of programming sauce. The result is swamp water.

Good design is not about the code. Good design is about the people who are going to work with that code. Understand your audience. Get to know what they like and what they don't like. Write your code in a way that will delight your audience. Give them what they expect to see.

Of course, this is exceptionally shallow advice because no programmer can actually be so selfless. If you write code that pleases your audience you will usually have to do so at the expense of yourself. It is not possible to write good code that you dislike -- at least not long term.

So the trick to good design is always putting a bit of yourself in the code and always putting a bit of your colleagues in the code. It's striking that balance where you are satisfied, but also where they are satisfied. This requires working in small increments, and sharing what you are doing. It requires watching what your colleagues are doing and looking for opportunities to borrow. It requires questioning, evaluating, praising, explaining and coaching.

And if you are working by yourself: do whatever the hell you want. Why are you so worried about what other people think? If you are trying to improve what you are doing, don't do so by reading about the opinions of others. Read code, not blog posts. Write code, not design diagrams. Work slowly, try out ideas you've seen in other code and evaluate their success. When you get the chance, work with others to broaden your horizons.

[sooheon]

I like the way you think, do you write anywhere else?

I'm only in my first year of designing and writing code professionally, much of what you point out about this being 1. difficult, and 2. a social/human endeavor rings true.

[mikekchar]

I have promised to, but have not followed through with that promise. One of these days maybe...

[cleong]

Although pracitcally what you said is true, many teams I've worked in had seniors that would design projects based on their interests. I'd like to say there is a way to design objectively based on trade-offs for the project. If you ever worked in enterprise-like "frameworks" like Magento you will see the design patterns and how they achieve certain goals in a project. E.G EAV, XML module & layout declaration for flexibility, MVVM for single responsibility controllers meant for large enterprise teams working on the same controller at one time.

[mikekchar]

Yeah. I think that kind of thing can work in certain circumstances. Definitely I've seen the dictatorial design approach be quite successful -- at least short term. It's pretty awful for the participants, though. Normally your best talent leaves. I'm less convinced about the framework approach. I've never actually seen it work well. Normally the design is just not flexible enough and something breaks pretty badly. Of course, there is a limit to the number of projects you can see in your lifetime, so I could well be missing something :-)