DISQUS

Noah's Mark: it should be obvious how to use it

  • Stump · 2 years ago
    I see your point here, and I also believe that code should be intuitive and obvious to the developer using said framework/collection/whatever.

    I also find a good bit of truth in the likening of coding to other arts. I've always thought that, but I couldn't really articulate the thought in the manor that I wanted.

    However.

    I have an issue with this bit of text here (I don't know if HTML tags work here, but I'll try it):

    You can’t always guarantee that, though, especially if you are writing framework code that will be used by millions. You don’t have the luxury of “I’ll just fix it later”, and nor should you. The second corollary here is that you should always take the time to do it right the first time, just as you should always take the time to do it the first time."

    This seems to me that you're saying that people always have the time to do it totally right the first time.

    While this would be ideal, I don't think many developers are given the chance to do it totally right the first time. Deadlines come and go, and sometimes you have to let something sub-par go. It's crappy, and it happens, but I doubt that anyone would do it intentionally.

    Maybe I'm naive and think people as a whole would like to make their projects and work as of high a quality as possible.

    Like you said, the things I code are my craft. I sincerely hate to let anything lacking in any way be released from me. The sad part is, which I'm sure you're familiar with, is that sometimes it's just impossible. Given enough time, I could take most any of my projects (at school or work) and make it better. However, that whole time thing is just so damn elusive.

    I'm sure I'm preaching to the choir on this, and I'm completely sure it's all stuff you've heard and gone through before. I just felt that this should be said.
  • noah · 2 years ago
    You are absolutely correct that occasionally we are forced, via deadlines, to act more quickly than we would like. However, the problem is much more insidious than this, as it really does apply to more than just software.

    We (as humans? as Americans? who knows) are traditionally bad at making cost/benefit analyses that span more than 20 seconds. Most managers get about a factor of 10 past that, not because they are stupid people, but just because they are bad managers (i.e. have not read Peopleware).

    The extra 20 minutes you would spend thinking through an interface the first time will save you plenty of time down the road, plenty of time that you can use to make other decisions correctly. In the long-run, by which I mean a week or longer, you end up taking less time, even on the same product in the same product cycle, because you decided at the outset not to make stupid decisions in the name of short-term gain. We are a culture of immediate result, and it may be hard to escape that, but we, as good designers, must always take the time. Always.