How I Develop Things and Why • Hacker News Board

Re: How I Develop Things and Why

#11

Post by reuser » Sat, Jan 28, 2012, 12:27 AM UTC

There are lots of ways of doing things, and more than a few of them are sensible. Without zeroing in on a specific well-defined problem, you usually won't have any hope of identifying anything like 'optimal' solutions - let alone uniquely optimal solutions.

"user in mind" and "have a real problem" and "get things done" and "responsive design" and "designed for Humans" and "make it happen" and "never compromise the API" are vague platitudes which don't even provide interpretable advice, let alone specific usable information.

It can be slightly obnoxious when a battle-hardened grayhair begins to hold forth on vague general principles in this way - it can still be productive to listen insofar as knowledge is being shared. What information is being shared here, and what experience or reasoning is there to ground it as knowledge?

Re: How I Develop Things and Why

#12

Post by 6ren » Sat, Jan 28, 2012, 12:51 AM UTC

daenz wrote: post #3

> Before I start writing a single line of code, I write the README and fill it with usage examples. I pretend that the module I want to build is already written and available, and I write some code with it. I write the same way. It forces you to think of how intuitive and natural your code should be. I've run into so much code that makes me wonder, "did they even consider how someone will want to use this?" Software…

This is very important, but he's making a deeper point, that the README ties it to the problem it solves. It's possible to make a beautiful, intuitive, natural solution that nobody needs (not even yourself). From the user to the code, it goes:

  problem -> usability -> code

Although intriguingly, pure mathematicians create solutions for their own sake (without reference to a problem), and it sometimes (often?) turns out to have practical application anyway e.g. http://en.wikipedia.org/wiki/G._H._Hardy#Pure_mathematics

BTW: I just noticed you can resize the reply textarea by dragging the bottom right corner. There doesn't seem to be any JS or CSS in the HN source to do this, so I guess it must be in Firefox 9; google says chromium has it too. Seems about 1.5 years old :(

Re: How I Develop Things and Why

#13

Post by bitops » Sat, Jan 28, 2012, 1:54 AM UTC

AznHisoka wrote: post #7

I'm not sure if this principle is a good one for starting a business. Many of us aren't exposed to meaningful problems outside of coding, using the internet, etc.

> Many of us aren't exposed to meaningful problems outside of coding, using the internet, etc.

Are you certain? Unless you live at home 24/7, you're interacting with the world every day. If you're like me, you regularly run into situations that are "sub-optimal" in terms of how much hassle you have to deal with to get things done.

I think the key is to stop thinking that meaning problems only exist in the realm of computers. In fact, most of the meaningful problems in our world are outside of the realm of software precisely because no-one has looked at the problem and thought "hey, software could make this easier".

An example we're all painfully aware of: medical records. There's a TON of paper involved, little co-ordination between doctors, the list goes on. People are working on the problem, but the revolution hasn't arrived yet.

A different way of putting it comes from Paul Graham: "don't think that you're trying to start a startup, instead think that you're trying to solve a problem".

Re: How I Develop Things and Why

#14

Post by gavanwoolery » Sat, Jan 28, 2012, 2:32 AM UTC

Nailed it. I've been very guilty of writing applications and APIs strictly oriented towards my own understanding. Also, I like how you throw a jab at all the BS metrics companies use to try and come up with a useless startup they can flip. ;)

Re: How I Develop Things and Why

#15

Post by AznHisoka » Sat, Jan 28, 2012, 4:14 AM UTC

bitops wrote: post #13

AznHisoka wrote: post #7

I'm not sure if this principle is a good one for starting a business. Many of us aren't exposed to meaningful problems outside of coding, using the internet, etc.

> Many of us aren't exposed to meaningful problems outside of coding, using the internet, etc. Are you certain? Unless you live at home 24/7, you're interacting with the world every day. If you're like me, you regularly run into situations that are "sub-optimal" in terms of how much hassle you have to deal with to get things done. I think the key is to stop thinking that meaning problems only exist in the realm of co…

Well, ok, let's talk about medical records. Not many people have the expertise/knowledge to tackle that issue (they can acquire it). They're not around doctors, and healthcare to experience the pain point and understanding the nuances of tackling that problem.

On the other hand, based on our daily interactions, we're more predisposed to making a better Javascript framework, developer tools, better ways of managing our social contacts, etc.

Re: How I Develop Things and Why

#16

Post by zmonkeyz » Sat, Jan 28, 2012, 4:14 AM UTC

daenz wrote: post #3

> Before I start writing a single line of code, I write the README and fill it with usage examples. I pretend that the module I want to build is already written and available, and I write some code with it. I write the same way. It forces you to think of how intuitive and natural your code should be. I've run into so much code that makes me wonder, "did they even consider how someone will want to use this?" Software…

It kind of reminds me of an interview with Larry Stroman. He was a comic artist that I really liked on X-Factor and someone asked him how he approaches drawing a comic. He stated that he actually starts with the very last page and then goes back to the beginning to work his way there.

Re: How I Develop Things and Why

#17

Post by quanticle » Sat, Jan 28, 2012, 4:34 AM UTC

agentultra wrote: post #4

daenz wrote: post #3

> Before I start writing a single line of code, I write the README and fill it with usage examples. I pretend that the module I want to build is already written and available, and I write some code with it. I write the same way. It forces you to think of how intuitive and natural your code should be. I've run into so much code that makes me wonder, "did they even consider how someone will want to use this?" Software…

I write the tests first which is kind of the same thing except that I can actually execute that API and see if what I wrote actually works. Writing good tests first also helps me constrain my implementations to be as simple as possible as well. Otherwise my tests get hard to write and that's a sign things are probably going in the wrong direction. Often though you can't have your cake and eat it too. There are two sc…

The problem is that the worse is better school usually wins over the long run. Jamie Zawinski has a great essay on this [1].

Unix was a "worse is better" MULTICS. DOS was a "worse is better" CP/M. Windows was a "worse is better" MacOS. The advantage of simple implementations is that you can get them in front of users right now, and then iterate your implementation until you have something that's cheap and adequate. Not perfect. Not even great. But adequate. However, as the essay points out, cheap and adequate today beats pricey and perfect tomorrow every time.

[1]: http://www.jwz.org/doc/worse-is-better.html

Re: How I Develop Things and Why

#18

Post by arundelo » Sat, Jan 28, 2012, 6:22 AM UTC

quanticle wrote: post #17

agentultra wrote: post #4

Earlier quoted context omitted.

I write the tests first which is kind of the same thing except that I can actually execute that API and see if what I wrote actually works. Writing good tests first also helps me constrain my implementations to be as simple as possible as well. Otherwise my tests get hard to write and that's a sign things are probably going in the wrong direction. Often though you can't have your cake and eat it too. There are two sc…

The problem is that the worse is better school usually wins over the long run. Jamie Zawinski has a great essay on this [1]. Unix was a "worse is better" MULTICS. DOS was a "worse is better" CP/M. Windows was a "worse is better" MacOS. The advantage of simple implementations is that you can get them in front of users right now , and then iterate your implementation until you have something that's cheap and adequate.…

It's by Richard Gabriel.

Re: How I Develop Things and Why

#19

Post by tomjen3 » Sat, Jan 28, 2012, 9:02 AM UTC

agentultra wrote: post #4

daenz wrote: post #3

> Before I start writing a single line of code, I write the README and fill it with usage examples. I pretend that the module I want to build is already written and available, and I write some code with it. I write the same way. It forces you to think of how intuitive and natural your code should be. I've run into so much code that makes me wonder, "did they even consider how someone will want to use this?" Software…

I write the tests first which is kind of the same thing except that I can actually execute that API and see if what I wrote actually works. Writing good tests first also helps me constrain my implementations to be as simple as possible as well. Otherwise my tests get hard to write and that's a sign things are probably going in the wrong direction. Often though you can't have your cake and eat it too. There are two sc…

No, written tests first means you make the code easy to test. That may make it easy to use to, but it is not likely. Easily testable tends to mean that the class knows to little. And as a user that you have to tell it too much.

Re: How I Develop Things and Why

#20

Post by adeelk » Sat, Jan 28, 2012, 9:39 AM UTC

6ren wrote: post #12

daenz wrote: post #3

> Before I start writing a single line of code, I write the README and fill it with usage examples. I pretend that the module I want to build is already written and available, and I write some code with it. I write the same way. It forces you to think of how intuitive and natural your code should be. I've run into so much code that makes me wonder, "did they even consider how someone will want to use this?" Software…

This is very important, but he's making a deeper point, that the README ties it to the problem it solves. It's possible to make a beautiful, intuitive, natural solution that nobody needs (not even yourself). From the user to the code, it goes: problem -> usability -> code Although intriguingly, pure mathematicians create solutions for their own sake (without reference to a problem), and it sometimes (often?) turns ou…

Pure mathematicians are always motivated by a problem, even if it isn't a "real world" problem.