3 ms·

Great find, thanks! My favorite quote from this was: "If you make the engineers answer e-mails and phone calls from the customers, the second or third time the

Great find, thanks! My favorite quote from this was: "If you make the engineers answer e-mails and phone calls from the customers, the second or third time they get the same question, they'll actually stop what they're doing and fix the code. Then we don't have those questions anymore."

aditya 17y ago
It requires a very fine balance, however. When building a big system you need uninterrupted hacking time to make sure you can keep all that state in your head. That won't happen if there's a loud ringing phone or your CEO bouncing around having loud conversations in the office. That's why Joel has private offices, and pg differentiates a maker's schedule with that of a manager.
- anonjon 17y ago
  "When building a big system you need uninterrupted hacking time to make sure you can keep all that state in your head." I think that this is wrong. Or at least it should be wrong. I used to think it was true. State is another way of saying 'Number of things I have to hold in my head'. So what you are saying is that because you have a too many things to hold in your head at one time, you need uninterrupted hacking time. Otherwise something gets forced out and you make mistakes. But another option here would be to increase the amount of abstraction within the code. If you increase abstraction, you reduce the amount of state, and reduce the chances of something important getting pushed out. A side benefit of this would be to increase the readability of the code. If it is very well abstracted, it will be easy to understand when you come back to it.
vaksel 17y ago
that works as long as the company encourages this. i.e. at my mom's job(she is also a programmer) she used to do these little fixes for the users, and they all loved it. Then new management came in, and now to do a little fix a user has to send in a request, which the programmer needs to get signed off by 3 bosses. And here is the funny part, the fix takes literally 5 minutes to do, boss #1 will say..."better tell the next boss it takes a few hours to give us some breathing room', boss #2 will say..."better tell the next boss it takes a few days, to make it seem like we are doing a lot of work" and boss #3 will say "better tell the user it'll take a week, we want them to know that we are doing major code for them" So this tiny 5 minute code fix, that literally just required a change in a few lines of code that used to be done in 5 minutes, now gets expanded into a 2 week "project" THAT's the difference between a startup and corporate culture
- DenisM 17y ago
  Fascinating story, short, descriptive, vivid.
- icey 17y ago
  It's a two-way street. Bosses demand sign-offs because someone at some time deployed something that didn't work. Signoff processes are there as a pain avoidance technique. If you are positive about the quality that goes out, you can have a corporate culture that encourages this sort of thing. If you're in a company that feels like it has to fill seats you get a combination of people who are good at their job who have to deal with bureaucracy and people who aren't good at their jobs who are saved by it.

aditya 17y ago

It requires a very fine balance, however. When building a big system you need uninterrupted hacking time to make sure you can keep all that state in your head. That won't happen if there's a loud ringing phone or your CEO bouncing around having loud conversations in the office. That's why Joel has private offices, and pg differentiates a maker's schedule with that of a manager.

anonjon 17y ago
"When building a big system you need uninterrupted hacking time to make sure you can keep all that state in your head." I think that this is wrong. Or at least it should be wrong. I used to think it was true. State is another way of saying 'Number of things I have to hold in my head'. So what you are saying is that because you have a too many things to hold in your head at one time, you need uninterrupted hacking time. Otherwise something gets forced out and you make mistakes. But another option here would be to increase the amount of abstraction within the code. If you increase abstraction, you reduce the amount of state, and reduce the chances of something important getting pushed out. A side benefit of this would be to increase the readability of the code. If it is very well abstracted, it will be easy to understand when you come back to it.

vaksel 17y ago

that works as long as the company encourages this. i.e. at my mom's job(she is also a programmer) she used to do these little fixes for the users, and they all loved it. Then new management came in, and now to do a little fix a user has to send in a request, which the programmer needs to get signed off by 3 bosses. And here is the funny part, the fix takes literally 5 minutes to do, boss #1 will say..."better tell the next boss it takes a few hours to give us some breathing room', boss #2 will say..."better tell the next boss it takes a few days, to make it seem like we are doing a lot of work" and boss #3 will say "better tell the user it'll take a week, we want them to know that we are doing major code for them" So this tiny 5 minute code fix, that literally just required a change in a few lines of code that used to be done in 5 minutes, now gets expanded into a 2 week "project" THAT's the difference between a startup and corporate culture

DenisM 17y ago
Fascinating story, short, descriptive, vivid.
icey 17y ago
It's a two-way street. Bosses demand sign-offs because someone at some time deployed something that didn't work. Signoff processes are there as a pain avoidance technique. If you are positive about the quality that goes out, you can have a corporate culture that encourages this sort of thing. If you're in a company that feels like it has to fill seats you get a combination of people who are good at their job who have to deal with bureaucracy and people who aren't good at their jobs who are saved by it.