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

Jason Fried - 10 Things We've Learned at 37Signals

krisjordan.com

Post reply on HN
Print view View original

21–29 of 29 posts

Re: Jason Fried - 10 Things We've Learned at 37Signals

#21

Post by unalone »

aschobel wrote: post #13
unalone wrote: post #10

Earlier quoted context omitted.

They're more fun, BUT they result in more work being done for less of a benefit. Look at the sites that have succeeded the most and you'll see that they all solve basic problems, and that's resulted in most of them making tons of money. More specialized sites are more fascinating, but they attract fewer people and tend to be much less successful in absolute terms.

It also depends on what kind of hard problems you are tackling. YouTube solved the video codec Gordian knot, Google did the same with relevant search. Not easy problems, but they have huge benefits.

Exactly. Those are resultant problems from a fairly simple opening idea. YouTube: how can we put video online? Google: how can we make searches relevant?

And, while the details are usually tricky, I find that Google's solutions to problems tend to always be brilliantly simple. Like their translate features: they figure out a basic problem and they solve it simply and often unexpectedly. Calling it a Gordion knot is actually the perfect description, yeah.

Re: Jason Fried - 10 Things We've Learned at 37Signals

#22

Post by BrandonM »

edw519 wrote: post #18
fendale wrote: post #14

Earlier quoted context omitted.

Here here - In our project, its packed with generic features - most of them haven't be used ever and were released ages ago. Often they really complicate the application with lookup tables and weird logic that never sees the light of day, 'just incase'!

Good example but not what I was referring to. I just finished an app with 51 separate modules, every one hard coded in infinite detail, and much of the code duplicated, 4000 LOC in all. Crazy, right? I used to think so, too. I could have written one very flexible parameter driven module in a few hundred LOC. But guess what? Even though I bitched and moaned the whole time I wrote the monster, I was able to refactor an…

This seems like a great idea if you are committed to immediately refactoring. The problem is that most people move onto something else as soon as they have something that works. In this case, the code becomes a maintenance nightmare until someone actually takes the time to refactor it.

When immediate refactoring is unlikely (either due to laziness, lack of focus, or feature deadlines), some kind of balance has to be reached on what should be more general and reusable and what should be hard-coded and specific. And then we're right back where we started.

But reading and thinking about your posts has been very insightful. On my next project, I will try your approach. I agree that in the long run, it is likely to be a more efficient use of time. I imagine, though, that someone coding in this style will either have to have a great memory or take good notes in order to know where similar code is located. Especially consider the case of generalizing the code from one project to another project.

Re: Jason Fried - 10 Things We've Learned at 37Signals

#23

Post by davidw »

njharman wrote: post #20

> Not afraid that people will take their ideas and build a restaurant right beside of them. Really? Then how come all the bitcheness around HuddleChat How disingenuous. (the lesson is correct, too bad they don't live by it) I quote "We're flattered Google thinks Campfire is a great product, we're just disappointed that they stooped so low to basically copy it feature for feature, layout for layout," said 37Signals fo…

I think there's a lot of independent thinking here. The important thing is to keep it civil - to say things that you'd feel comfortable saying directly to the people involved.

Personally, I am kind of skeptical of 37S in that they talk a good talk, but... I have a sneaking suspicion that their true scarcity power comes from things like Rails and their blog. Or maybe not; it's hard to tell without doing some very in depth research.

Re: Jason Fried - 10 Things We've Learned at 37Signals

#24

Post by fendale »

pc wrote: post #16
fendale wrote: post #14

Earlier quoted context omitted.

Here here - In our project, its packed with generic features - most of them haven't be used ever and were released ages ago. Often they really complicate the application with lookup tables and weird logic that never sees the light of day, 'just incase'!

I think you mean "Hear, hear".

Hear, hear indeed - It was 11pm after a long day when I wrote that, but I won't make the same mistake again, lol!

Re: Jason Fried - 10 Things We've Learned at 37Signals

#25

Post by thalur »

edw519 wrote: post #19
aschobel wrote: post #9

"13. Give up on hard problems - there is nothing wrong with being lazy. There is an abundance of easy problems that need to be solved. The really hard problems are probably better left to your competitors. Solve a bunch of simple things. Most people’s problems are simple and you can probably solve 10 in a month over 1 in 10 months." Hard problems are a lot more fun to solve. How do you attract top talent if you are o…

How do you attract top talent if you are only solving easy things? A hard problem is just a bunch of easy problems tangled up together.

One of the hardest bits can be working out what the easy problems are in the first place.

Re: Jason Fried - 10 Things We've Learned at 37Signals

#26

Post by edw519 »

BrandonM wrote: post #22
edw519 wrote: post #18

Earlier quoted context omitted.

Good example but not what I was referring to. I just finished an app with 51 separate modules, every one hard coded in infinite detail, and much of the code duplicated, 4000 LOC in all. Crazy, right? I used to think so, too. I could have written one very flexible parameter driven module in a few hundred LOC. But guess what? Even though I bitched and moaned the whole time I wrote the monster, I was able to refactor an…

This seems like a great idea if you are committed to immediately refactoring. The problem is that most people move onto something else as soon as they have something that works. In this case, the code becomes a maintenance nightmare until someone actually takes the time to refactor it. When immediate refactoring is unlikely (either due to laziness, lack of focus, or feature deadlines), some kind of balance has to be…

Like I said, it wasn't easy doing it this way. Every bone in my body screamed, "What's wrong with you? Stop replicating code! Write flexible functions!" But I struggled on until everything worked perfectly.

Here's the good news: I couldn't wait to refactor. I was "in the zone" the whole day. And it felt great. I finally got to clean up the mess that I made, and best of all, I didn't have to struggle trying to figure out how to handle that strange outlying case: it was all already there!

I don't know if I'd try this in someone else's shop. You're right; they'd probably pull me off before I got to refactor, leaving a mess for someone else with nothing learned.

Re: Jason Fried - 10 Things We've Learned at 37Signals

#28

Post by 13ren »

newmediaclay wrote: post #3

I'm a huge fan of 37 signals' products and company philosophy. I bet this presentation is going to be the total opposite of most people speaking at the conference - I mean who else is going to get up there and talk about "Planning is vastly overrated" and "Underdoing." Most presenters are going to focus on all of the amazing features their products offer...however, 37 signals is still more successful than 95% of thos…

Underdoing - if you forget about all those details that people tell you that you must have, and instead make a really useful product, people will find ways around those details, and buy it.

Re: Jason Fried - 10 Things We've Learned at 37Signals

#29

Post by axod »

njharman wrote: post #20

> Not afraid that people will take their ideas and build a restaurant right beside of them. Really? Then how come all the bitcheness around HuddleChat How disingenuous. (the lesson is correct, too bad they don't live by it) I quote "We're flattered Google thinks Campfire is a great product, we're just disappointed that they stooped so low to basically copy it feature for feature, layout for layout," said 37Signals fo…

The funniest thing for me was that campfire and huddlechat didn't really have any features or layout. It's a chatroom!

Google lost so much credibility taking huddlechat down IMHO.

Post reply on HN