Live data from Hacker News

The Rule of Three

codinghorror.com

21–30 of 31 posts

Re: The Rule of Three

#21
post #9

Wow what a horrible way to advertise your products. Disguise your advertisements into some substanceless article seemingly useful.

Codinghorror is the personal blog of the founder of Stack Exchange. He left that company and later founded Discourse. Why wouldn't he talk about the things he's built and working on on his blog?

I know, I know who he is. It's just I am not convinced at all that the examples used are the best (or even good for that matter) in the field of code reuse etc. He's clearly just advertising his products which can be done in more honest ways.

Re: The Rule of Three

#22
post #21

Earlier quoted context omitted.

Codinghorror is the personal blog of the founder of Stack Exchange. He left that company and later founded Discourse. Why wouldn't he talk about the things he's built and working on on his blog?

I know, I know who he is. It's just I am not convinced at all that the examples used are the best (or even good for that matter) in the field of code reuse etc. He's clearly just advertising his products which can be done in more honest ways.

I don't understand this at all. This is a personal blog. That means that the people who read it do so for no other reason than that he's interested in what he has to say. A blog is a platform to say whatever you want to say. If that's thinly veiled advertising, then so what? What you consider advertising someone else with a different background might consider insightful. I don't understand the dishonesty charge. There's nothing he's 'supposed' to be doing with it. So how could someone say he's pretending it's something it's not?

Re: The Rule of Three

#23
post #12

I have a problem with the word reusable. A reusable software should be a component in a larger solution. Not a complete solution itself. If I accept that Stack Overflow or Discourse are reusable, because you can run them on different urls with different graphics, topic, moderators and users, then every application, for example Photoshop, is reusable in the same way, because multiple people use it to perform multiple…

Of course a piece of software that you intend to distribute to others must be reusable - that's the whole point. However, there are plenty of software systems that are one-offs. In the case of Stack Overflow, they wanted to see if the overall solution (which is much more than just the underlying code) would be good for different types of users or whether they had built a one-off.

With Discourse they are setting out from the beginning to make a reusable piece of software but that doesn't mean they are guaranteed to do so. Hence the extended development time before they offer it more widely.

Re: The Rule of Three

#24
post #9

Wow what a horrible way to advertise your products. Disguise your advertisements into some substanceless article seemingly useful.

Welcome to 95% of technical blogs.

And I don't fault the authors, because of course they want their creations widely known. But it isn't generally conceived as "I have this great epiphany and I must share it", but rather "I need to get some product pimping out, so what should I write about?" I've done it enough times myself.

Re: The Rule of Three

#25
post #12

I have a problem with the word reusable. A reusable software should be a component in a larger solution. Not a complete solution itself. If I accept that Stack Overflow or Discourse are reusable, because you can run them on different urls with different graphics, topic, moderators and users, then every application, for example Photoshop, is reusable in the same way, because multiple people use it to perform multiple…

Right, I think reusable components (at least in web dev) are the libraries/frameworks that come out of creating a project.

Example: DHH built Basecamp and pulled Rails out of it. He (and now many others) used Rails to create web apps.

Re: The Rule of Three

#26
I have had a similar thought. The multiple of 3 seems to be a nice heuristic to track and tame complexity in many fields. Nature of any problem undergoes fundamental changes when the problem size is tripled and our solutions should be reviewed accordingly.

Here is what I mean. Say your startup has only one employee. You come up with certain processes to make it productive. However, when the team size goes to 3, 9, 27, it would be a good idea to review those processes and rules. Those seem like appropriate milestones to me for future planning. Not too short, nor too long.

Another example: Let's say I want to understand a topic like, say, Relativity. I think an effective approach would be to first read a one paragraph summary which barely describes the big picture of it. Once I've done that, I look for an article 3-times as long (say, a page). Next would be an essay which is about 3 pages. 9 pages, 27 pages and so on.

By not taking a big jump, (say a multiple of 10 or more), I make sure that I have a good foundation based on experience to be able to understand the next stage of complexity. And a jump less than a multiple of 3 would tend to be not the most productive.

Re: The Rule of Three

#27
post #4

At first I thought this might have been a repost of some refactoring advice I heard of long ago. A quick google finds a reference on wikipedia [0]. Essentially it goes like this: The first time you implement something, just do it. The second time you implement the same thing, copy it. The third time, refactor. The OP seems like an interesting variation on the same theme. [0] http://en.wikipedia.org/wiki/Rule_of_three…

Huh, that was the exact rule I adopted the first time I had to work on a "real" project. I wonder if I'd previously read it into my subconscious, or if it's simply kind of obvious. :)

Re: The Rule of Three

#28
post #4

At first I thought this might have been a repost of some refactoring advice I heard of long ago. A quick google finds a reference on wikipedia [0]. Essentially it goes like this: The first time you implement something, just do it. The second time you implement the same thing, copy it. The third time, refactor. The OP seems like an interesting variation on the same theme. [0] http://en.wikipedia.org/wiki/Rule_of_three…

This might be the reason behind "Everything sucks until version three"

Re: The Rule of Three

#30
post #4

At first I thought this might have been a repost of some refactoring advice I heard of long ago. A quick google finds a reference on wikipedia [0]. Essentially it goes like this: The first time you implement something, just do it. The second time you implement the same thing, copy it. The third time, refactor. The OP seems like an interesting variation on the same theme. [0] http://en.wikipedia.org/wiki/Rule_of_three…

This might be the reason behind "Everything sucks until version three"

Awesome. Where did you hear this? A Google search for "Everything sucks until version" returns no results.

I think there might be some truth to this. My first MVP sucked hard. My second version of it was passable, but still left quite a bit to be desired. I have a feeling whenever I ever get to version 3, it will be good.

Post reply on HN