5 ms·

How about recommendation #7 of http://paulgraham.com/head.html http://paulgraham.com/head.html ?

staunch 18y ago
That's my favorite solution. I don't really care if someone else is writing code that makes me vomit as long as the interface I have to it is good enough and that it works reliably.
- azanar 18y ago
  You will if you ever need to maintain or expand it for any reason, and the person you might otherwise call on to do so is unavailable.
  - deleted 18y ago
    [deleted]
  - staunch 18y ago
    We're talking about startups here. If that unavailable person is your co-founder you're probably screwed anyway.
    - azanar 18y ago
      That could be even worse, even if your co-founder is still available. What if your co-founder is stuck on a difficult problem, and needs a second set of eyes on the code to help him out? If he has been writing vomit-code the whole time, will you be able to help? The point behind tip #7 was to advocate having a single person in charge of editing a component, to avoid two people making changes to the design and confusing one another. The point wasn't to suggest a total lack of caring about the other developer's work. This smells very much of political fence building, and an overly zealous drive to strictly segment responsibility.
      - staunch 18y ago
        I think the core idea of #7 is to give a vast amount of freedom to each person in their work so they can let their brain run wild on the problem without restriction. Even if that's not what PG meant, it certainly is what I mean. I think the other great benefit is that each person can afford to become an expert in their areas, rather than each person becoming merely competent at everything. I think 3 people who are each experts at 3 different things is more powerful than 3 people who are merely competent at the same 9 things.
        azanar 18y ago
        No problem with the idea of letting peoples' brains run wild on a problem. I suspect you and I could debate for some time about your latter point; I'd worry about things ranging from bus factors to developers who become expert in some set of things later being confined to those areas of expertise to avoid stretching their knowledge portfolio to thin, whatever that means. Maybe it is worthy of it's own conversation somewhere; maybe such a conversation already happened that I could get more insight from.

That's my favorite solution. I don't really care if someone else is writing code that makes me vomit as long as the interface I have to it is good enough and that it works reliably.

azanar 18y ago
You will if you ever need to maintain or expand it for any reason, and the person you might otherwise call on to do so is unavailable.
- deleted 18y ago
  [deleted]
- staunch 18y ago
  We're talking about startups here. If that unavailable person is your co-founder you're probably screwed anyway.
  - azanar 18y ago
    That could be even worse, even if your co-founder is still available. What if your co-founder is stuck on a difficult problem, and needs a second set of eyes on the code to help him out? If he has been writing vomit-code the whole time, will you be able to help? The point behind tip #7 was to advocate having a single person in charge of editing a component, to avoid two people making changes to the design and confusing one another. The point wasn't to suggest a total lack of caring about the other developer's work. This smells very much of political fence building, and an overly zealous drive to strictly segment responsibility.
    - staunch 18y ago
      I think the core idea of #7 is to give a vast amount of freedom to each person in their work so they can let their brain run wild on the problem without restriction. Even if that's not what PG meant, it certainly is what I mean. I think the other great benefit is that each person can afford to become an expert in their areas, rather than each person becoming merely competent at everything. I think 3 people who are each experts at 3 different things is more powerful than 3 people who are merely competent at the same 9 things.
      - azanar 18y ago
        No problem with the idea of letting peoples' brains run wild on a problem. I suspect you and I could debate for some time about your latter point; I'd worry about things ranging from bus factors to developers who become expert in some set of things later being confined to those areas of expertise to avoid stretching their knowledge portfolio to thin, whatever that means. Maybe it is worthy of it's own conversation somewhere; maybe such a conversation already happened that I could get more insight from.