Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: How best to learn software design principles?

news.ycombinator.com

Post reply on HN
Print view View original

91–100 of 100 posts

Re: Ask HN: How best to learn software design principles?

#91

Post by mattgreenrocks »

simplify wrote: post #50

Learning software design principles is like learning how to draw - you need to study many, many examples before getting a good feel for it. For example, in drawing there are many individual principles, such as shading, perspective, scale, and so on. Studying each individual principle is only useful within the context of a full drawing . Software is the same way. Studying SOLID principles, application boundaries, enca…

The difference between framework and software developer is often glossed over by people, especially on HN. In the position of the former, you're pushed around by your tools. In the latter, you learn how to push back and impose structure that speed development, clarify thinking, and reduce bug counts dramatically.

Re: Ask HN: How best to learn software design principles?

#92

Post by mtdewcmu »

mattgreenrocks wrote: post #90
mtdewcmu wrote: post #89

Earlier quoted context omitted.

Replying to myself/no edit link: The kicker about software architecture is that it gives bad advice about writing software. Now, it's true, the individual bits of advice are all over the map. They don't all agree. But the premise was to prevent bad code from getting written by syntax changes and style conventions, hopefully stopping bad practices in their tracks and encouraging good practices in their place. I think…

Which is why simplicity remains the ultimate sophistication in software architectures. At some point, you cannot continue writing code without structure. Then you slowly and deliberately introduce meaningful abstractions along the necessary dimensions. And no more. Abstractions are also useful to separate the arrangement of work from the actual work itself. These boundaries are useful for dividing up work among colle…

Knuth argues that programming is a form of writing. I agree. Therefore, you should organize code like a book or article, since those are forms of writing that have benefitted from centuries of use and refinement.

Even books and articles on complex subjects are fairly light on structure.

Re: Ask HN: How best to learn software design principles?

#93

Post by kenbot »

pessimizer wrote: post #84
kenbot wrote: post #83

Earlier quoted context omitted.

They have almost nothing in common, and it's accidental when they do. For instance: - Designing software in minute detail beforehand is generally neither necessary nor possible. - It is impossible for someone to be a capable software "architect" unless they are an experienced software "builder". - It is impossible for someone to be a capable software "builder" unless they are also capable of designing it. - Software…

Other than the top 3, these seem to be differences between software and buildings rather than software designers and architects. In addition, I don't think the first three are true. Lastly, these are distinctions without any actual difference in the context of the metaphor, where "architect" could have been replaced by 'novelist' or 'cabinetmaker' and no information would have been lost. edit: to be more specific abo…

The vast differences between software and buildings correspond to the vast differences in designing them.

In context here, "minute detail" is obviously a relative term comparing the requirements of software and architecture design.

You just made up the "specific language" thing. The reason we don't get unicorns to write software for us is they don't exist either.

There are many incompetent software devs out there, but I don't see how anyone can possibly build any amount of software _well_ without having an appreciation of how to design it. This is why I used the word "capable".

The thing is, even if some of these things were similar to architecture, it would be by accident. They are, on the surface, totally different fields. On a deeper level, they're still totally different. The onus is on you to show the linkage, if you believe it to be applicable.

Re: Ask HN: How best to learn software design principles?

#94

Post by theshank »

nikhilalmeida wrote: post #52
pessimizer wrote: post #10

http://www.aosabook.org/en/ "Architects look at thousands of buildings during their training, and study critiques of those buildings written by masters. In contrast, most software developers only ever get to know a handful of large programs well—usually programs they wrote themselves—and never study the great programs of history. As a result, they repeat one another's mistakes rather than building on one another's su…

https://github.com/aosabook/500lines This is a repo of smaller real world applications that are 500 lines or less in length, so as not to be overwhelming to novice / intermediate programmers.

This is really helpful ! Thanks a bunch !

Re: Ask HN: How best to learn software design principles?

#95

Post by iqbaljamsheed »

I'm currently 16 year old, studying in middle school. I want to enter programming, and am already taking Codeacademy courses in Javascript.

I want advice from experienced programmers, on programming, and generally becoming a good programmer and how to think like a programmer.

I also want suggestions for resource that I can use at my absolutely beginner level

Thanks

Re: Ask HN: How best to learn software design principles?

#96

Post by mtdewcmu »

mattgreenrocks wrote: post #90
mtdewcmu wrote: post #89

Earlier quoted context omitted.

Replying to myself/no edit link: The kicker about software architecture is that it gives bad advice about writing software. Now, it's true, the individual bits of advice are all over the map. They don't all agree. But the premise was to prevent bad code from getting written by syntax changes and style conventions, hopefully stopping bad practices in their tracks and encouraging good practices in their place. I think…

Which is why simplicity remains the ultimate sophistication in software architectures. At some point, you cannot continue writing code without structure. Then you slowly and deliberately introduce meaningful abstractions along the necessary dimensions. And no more. Abstractions are also useful to separate the arrangement of work from the actual work itself. These boundaries are useful for dividing up work among colle…

Not sure if you'll come back and read this, but here's my current theory on structure.

In a piece of software, there are many schemes by which you might organize the source code:

- Organize by author of code

- Organize by chronological order of appearance (e.g. what version or patch # this appeared in)

- ... by order of execution (of course, this is only a partial order)

- ... by library

- ... by importance

- ... by some arbitrary property of the code (by algorithm, by what data it touches, etc.)

Each one makes sense in a different context, and you can't have all at once. But you don't want to double-down on one choice at the expense of other, equally-valid choices with excess structure.

Re: Ask HN: How best to learn software design principles?

#97

Post by philrea »

Write a relatively complex system without any external code and, preferably, without any previous training...

It will suck, it will break, and eventually, it will be near impossible to add or change anything at all. But you will have experienced what the patterns n' principles authors (better) have and, I bet, even "accidentally" used a few of them.

In my opinion, design principle = minimize dependency. Oh and, if you do follow my suggestion, use a language that isn't object oriented... at the least you will, like me, wonder why "object-oriented something" isn't explicitly defined by gof elsewhere and, at better, might "accidentally" implement some sort of custom object system

I am gonna go ahead and say it... REINVENTING THE WHEEL IS A GOOD AND NECESSARY THING... if done for the right reasons, in the right circumstances...

Re: Ask HN: How best to learn software design principles?

#98

Post by philrea »

tmsh wrote: post #65
pessimizer wrote: post #10

http://www.aosabook.org/en/ "Architects look at thousands of buildings during their training, and study critiques of those buildings written by masters. In contrast, most software developers only ever get to know a handful of large programs well—usually programs they wrote themselves—and never study the great programs of history. As a result, they repeat one another's mistakes rather than building on one another's su…

I think this is great and look forward to reading these books. Lots of familiar names. But I'd say in my oh 10-15 years of programming I've learned that the way to really learn the importance of a pattern is by deriving why it is really needed. You can't really make shortcuts there. The difference with software is that it's soft. We're not actually creating buildings. Yes we ship products so it's related. But it's mo…

amen

Re: Ask HN: How best to learn software design principles?

#99

Post by collyw »

mattgreenrocks wrote: post #91
simplify wrote: post #50

Learning software design principles is like learning how to draw - you need to study many, many examples before getting a good feel for it. For example, in drawing there are many individual principles, such as shading, perspective, scale, and so on. Studying each individual principle is only useful within the context of a full drawing . Software is the same way. Studying SOLID principles, application boundaries, enca…

The difference between framework and software developer is often glossed over by people, especially on HN. In the position of the former, you're pushed around by your tools. In the latter, you learn how to push back and impose structure that speed development, clarify thinking, and reduce bug counts dramatically.

You are implying that rolling your own will give you faster, less buggy code, more organised code than using a framework?
Post reply on HN