chris · August 9, 2017 22:18
diff --git a/Coders at Work highlights b/Coders at Work highlights
 Yeah. At the end of the day, ship the fucking thing! It's great to rewrite your code and make it cleaner and by the third time it'll actually be pretty. But that's not the point—you're not here to write code; you're here to ship products.
 Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 22, loc. 522

 A lot of programmers have the instinct of, “You've got to present the error message!” No you don't. No one cares about that. That sort of stuff is a lot easier to manage in languages like Java that actually have an exception system. Where, at the top loop of your idle state, you just catch everything and you're done. No need to bother the user with telling them that some value was zero.
 Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 32, loc. 702

 Are you trying to write good software or are you trying to be done by next week? You can't do both.
 Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 34, loc. 743

 you want to arrange for there to be no more than three or four people working really closely
 Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 37, loc. 802

 together on a day-to-day basis. Then that can scale up a lot.
 Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 37, loc. 802

 The idea that everyone should own all the code, I don't think is really practical because there's going to be too much of it. People are going to have to specialize; you need an expert sometimes. It's just always going to work out that way. There's always going to be the code you're familiar with because you happened to write more of that module than some other guy did. Or there's just going to be parts that resonate with you more. It's certainly good for other people to have their hands in it, if only because you're not going to be maintaining it yourself forever. It's going to have to be handed off to someone else for one reason or another. And for that knowledge to be spread around is good. But it's also good to have someone to blame. If everybody is responsible for it then there's no one to put their foot down.
 Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 39, loc. 830

 I think one thing that's really important is to not be afraid of your ignorance. If you don't understand how something works, ask someone who does. A lot of people are skittish about that. And that doesn't help anybody. Not knowing something doesn't mean you're dumb—it just means you don't know it yet.
 Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 40, loc. 855

 Design Patterns—which I just thought was crap. It was just like, programming via cut and paste. Rather than thinking through your task you looked through the recipe book and found something that maybe, kinda, sorta felt like it, and then just aped it. That's not programming; that's a coloring book. But a lot of people seemed to love it. Then in meetings they'd be tossing around all this terminology they got out of that book. Like, the inverse, reverse, double-back-flip pattern—whatever. Oh, you mean a loop? OK.
 Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 44, loc. 918

 But I've always seen much more in common with writing prose than math. It feels like you're writing a story and you're trying to express a concept to a very dumb person—the computer—who has a limited vocabulary. You've got this concept you want to express and limited tools to express it with. What words do you use and what does your introductory and summary statement look like? That sort of thing. The issue of taste really fits in there. You can have a piece of text describing something that describes it correctly or it can describe it well, with some flair. And the same thing's true of programs. It can get the job done or it can also make sense, be put together well.
 Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 45, loc. 947

 tasteful and maintainable are
 Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 46, loc. 955

 similar.
 Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 46, loc. 955

 I think it's really important to know the whole stack even if you don't operate within the whole stack.
 Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 65, loc. 1302

 The projects that I never finish—my friends give me shit that it's a whole bunch—it's because I did the hard part and I learned what I wanted to learn and I never got around to doing the boring stuff.
 Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 69, loc. 1393

 At night I feel like this is my time and I'm stealing this time because everyone else is sleeping. There's no noise and no interruptions, and I can do whatever. I still stay up late sometimes. I did it this weekend; I was up quite a bit working on different things. But that screws me up for days sleepwise.
 Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 75, loc. 1495

 There are probably a lot of schools of thought and I'm probably not educated about what the proper way to do it is.
 Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 80, loc. 1595

 What do you think is the most important skill for a programmer to have? Fitzpatrick: Thinking like a scientist; changing one thing at a time. Patience and trying to understand the root cause of things. Especially when you're debugging something or designing something that's not quite working. I've seen young programmers say, “Oh, shit, it doesn't work,” and then rewrite it all. Stop. Try to figure out what's going on. Learn how to write things incrementally so that at each stage you could verify it.
 Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 86, loc. 1717

 I guess there are the people who just do it for a job but don't really enjoy it. Which is OK. But it's kind of weird to compare those people with people who are hardcore programmers.
 Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 87, loc. 1742

 I think it was a program I wrote to disassemble the runtime of the Fortran system on the timesharing system I was using.
 Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 93, loc. 1816

 There are some languages that I was aware of that I never got a chance to use. I've read a lot about APL and I understand why it lost, but it was really neat and I never
 Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 93, loc. 1826

 spent any time with it and that was unfortunate. There are other languages like that, where I'm aware of them, I've read what I can about them, but I never got a chance to actually think in them.
 Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 93, loc. 1827

 Most of the Adobe applications have JavaScript in them so you can script them locally. And other applications as well.
 Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 97, loc. 1889

 Going back afterwards, developers who had not had that experience all seemed arrogant to me in a way which was completely inexcusable. The lack of respect they had for the people who used our stuff was appalling and it was basically a consequence of their having never met those people.
 Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 123, loc. 2411

 So I would actually rather see people start as English majors than as math majors to get into programming.
 Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 124, loc. 2432
	Yeah. At the end of the day, ship the fucking thing! It's great to rewrite your code and make it cleaner and by the third time it'll actually be pretty. But that's not the point—you're not here to write code; you're here to ship products.
	Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 22, loc. 522

	A lot of programmers have the instinct of, “You've got to present the error message!” No you don't. No one cares about that. That sort of stuff is a lot easier to manage in languages like Java that actually have an exception system. Where, at the top loop of your idle state, you just catch everything and you're done. No need to bother the user with telling them that some value was zero.
	Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 32, loc. 702

	Are you trying to write good software or are you trying to be done by next week? You can't do both.
	Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 34, loc. 743

	you want to arrange for there to be no more than three or four people working really closely
	Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 37, loc. 802

	together on a day-to-day basis. Then that can scale up a lot.
	Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 37, loc. 802

	The idea that everyone should own all the code, I don't think is really practical because there's going to be too much of it. People are going to have to specialize; you need an expert sometimes. It's just always going to work out that way. There's always going to be the code you're familiar with because you happened to write more of that module than some other guy did. Or there's just going to be parts that resonate with you more. It's certainly good for other people to have their hands in it, if only because you're not going to be maintaining it yourself forever. It's going to have to be handed off to someone else for one reason or another. And for that knowledge to be spread around is good. But it's also good to have someone to blame. If everybody is responsible for it then there's no one to put their foot down.
	Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 39, loc. 830

	I think one thing that's really important is to not be afraid of your ignorance. If you don't understand how something works, ask someone who does. A lot of people are skittish about that. And that doesn't help anybody. Not knowing something doesn't mean you're dumb—it just means you don't know it yet.
	Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 40, loc. 855

	Design Patterns—which I just thought was crap. It was just like, programming via cut and paste. Rather than thinking through your task you looked through the recipe book and found something that maybe, kinda, sorta felt like it, and then just aped it. That's not programming; that's a coloring book. But a lot of people seemed to love it. Then in meetings they'd be tossing around all this terminology they got out of that book. Like, the inverse, reverse, double-back-flip pattern—whatever. Oh, you mean a loop? OK.
	Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 44, loc. 918

	But I've always seen much more in common with writing prose than math. It feels like you're writing a story and you're trying to express a concept to a very dumb person—the computer—who has a limited vocabulary. You've got this concept you want to express and limited tools to express it with. What words do you use and what does your introductory and summary statement look like? That sort of thing. The issue of taste really fits in there. You can have a piece of text describing something that describes it correctly or it can describe it well, with some flair. And the same thing's true of programs. It can get the job done or it can also make sense, be put together well.
	Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 45, loc. 947

	tasteful and maintainable are
	Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 46, loc. 955

	similar.
	Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 46, loc. 955

	I think it's really important to know the whole stack even if you don't operate within the whole stack.
	Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 65, loc. 1302

	The projects that I never finish—my friends give me shit that it's a whole bunch—it's because I did the hard part and I learned what I wanted to learn and I never got around to doing the boring stuff.
	Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 69, loc. 1393

	At night I feel like this is my time and I'm stealing this time because everyone else is sleeping. There's no noise and no interruptions, and I can do whatever. I still stay up late sometimes. I did it this weekend; I was up quite a bit working on different things. But that screws me up for days sleepwise.
	Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 75, loc. 1495

	There are probably a lot of schools of thought and I'm probably not educated about what the proper way to do it is.
	Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 80, loc. 1595

	What do you think is the most important skill for a programmer to have? Fitzpatrick: Thinking like a scientist; changing one thing at a time. Patience and trying to understand the root cause of things. Especially when you're debugging something or designing something that's not quite working. I've seen young programmers say, “Oh, shit, it doesn't work,” and then rewrite it all. Stop. Try to figure out what's going on. Learn how to write things incrementally so that at each stage you could verify it.
	Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 86, loc. 1717

	I guess there are the people who just do it for a job but don't really enjoy it. Which is OK. But it's kind of weird to compare those people with people who are hardcore programmers.
	Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 87, loc. 1742

	I think it was a program I wrote to disassemble the runtime of the Fortran system on the timesharing system I was using.
	Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 93, loc. 1816

	There are some languages that I was aware of that I never got a chance to use. I've read a lot about APL and I understand why it lost, but it was really neat and I never
	Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 93, loc. 1826

	spent any time with it and that was unfortunate. There are other languages like that, where I'm aware of them, I've read what I can about them, but I never got a chance to actually think in them.
	Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 93, loc. 1827

	Most of the Adobe applications have JavaScript in them so you can script them locally. And other applications as well.
	Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 97, loc. 1889

	Going back afterwards, developers who had not had that experience all seemed arrogant to me in a way which was completely inexcusable. The lack of respect they had for the people who used our stuff was appalling and it was basically a consequence of their having never met those people.
	Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 123, loc. 2411

	So I would actually rather see people start as English majors than as math majors to get into programming.
	Peter Seibel, Coders at Work: Reflections on the Craft of Programming, pg. 124, loc. 2432