Peter Seibel - Coders at Work - Reflections on the craft of programming

Здесь есть возможность читать онлайн «Peter Seibel - Coders at Work - Reflections on the craft of programming» весь текст электронной книги совершенно бесплатно (целиком полную версию без сокращений). В некоторых случаях можно слушать аудио, скачать через торрент в формате fb2 и присутствует краткое содержание. Жанр: Программирование, на английском языке. Описание произведения, (предисловие) а так же отзывы посетителей доступны на портале библиотеки ЛибКат.

Coders at Work: Reflections on the craft of programming: краткое содержание, описание и аннотация

Предлагаем к чтению аннотацию, описание, краткое содержание или предисловие (зависит от того, что написал сам автор книги «Coders at Work: Reflections on the craft of programming»). Если вы не нашли необходимую информацию о книге — напишите в комментариях, мы постараемся отыскать её.

Peter Seibel
Coders at Work
Founders at Work

Coders at Work: Reflections on the craft of programming — читать онлайн бесплатно полную книгу (весь текст) целиком

Ниже представлен текст книги, разбитый по страницам. Система сохранения места последней прочитанной страницы, позволяет с удобством читать онлайн бесплатно книгу «Coders at Work: Reflections on the craft of programming», без необходимости каждый раз заново искать на чём Вы остановились. Поставьте закладку, и сможете в любой момент перейти на страницу, на которой закончили чтение.

Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать

Fitzpatrick:Google search—which one’s highest? Which one do people tend to like? And knowing people. I got so much more involved in the open source community once I started going to all these conferences because then I would meet people and see who was respected, and who was cool.

Then I would see their code: I remember that guy. He was awesome. He was fun, friendly, and attentive, and he really cared about his code. He was really passionate when people complained about it. I’m going to use that one because if I find any bugs, I know he’ll be crazy about fixing them. As opposed to the grumpy guy who maybe writes great code, but he’s grumpy and not fun to interact with if you have a question or a bug. So you pick maintainers you trust or respect.

Seibel:Then is there any trick to quickly figuring out whether something’s going to suit your needs?

Fitzpatrick:I just start. I don’t plug it right into my code—first I write a test program that uses the couple functions I know I’m going to need, make sure they work. Or write a unit test for just that library on just the data I plan to use with it. A lot of libraries out there don’t even have their own tests. Even if it does, maybe you read the doc and you don’t really trust that it does what it says it does, or the doc wasn’t clear about how it behaves. So I write my own tests for the shit I care about. I figure since I’m going to have to write something to learn the library anyway, my first Hello, World program might as well be a unit test against it.

Seibel:What about the actual tools you use—you’re still an Emacs user, right?

Fitzpatrick:I’m still an Emacs user. I wish I were better at Emacs. But I know all the keystrokes but I don’t really customize it much. I steal other people’s customizations and I can kind of read it. But I find myself getting annoyed by something and saying, “I should go write some Elisp to bind it to a key.” And then I don’t.

Steve Yegge is working on project to basically replace all of Elisp with JavaScript. So I keep saying, I’ll wait for him to do that so I don’t have to learn another language. I’ll just write it in JavaScript. I don’t mind JavaScript as a language. It’s browsers that suck. At Google I write a lot of stuff in JavaScript that I then embed in Java and C++. I figure JavaScript is a good embedding language.

Seibel:Are there any tools that you are forced to use regularly that you just hate? Other than your whole desktop?

Fitzpatrick:Yeah, the whole desktop. There are a whole lot of things on my desktop. All these browsers are always hanging and crashing and using tons of memory. My whole operating system hanging. My coworkers try to tell me—if they see me doing something in Emacs—that Eclipse or IntelliJ does it for them automatically. So every six months I try out one of them, Eclipse or IntelliJ. And the damn thing just sits there spinning forever, consuming memory and maybe crashes in the middle of me typing or can’t keep up with me typing. Come on—syntax-highlight in the background or compile in a different thread. Why are you blocking my typing to do this? OK, I’ll try it again in six months, guys. So I’m glad I’m not forced to use that. I should really get better at Emacs, though.

My learning curve is, I learn something pretty rapidly until I get to this point where I’m pretty productive and good enough. Then I kind of plateau at like maybe 90 percent or 80 percent, where I’m productive and I don’t have to look things up and I’m happy. And then it slowly gets better after that. It’s only after I’m super comfortable with something that I’m like, “I’m going to go dig around the docs for this language—the man pages—and learn every nook and cranny.”

Seibel:Is that maybe wise these days? There are so many things you could learn. You could spend forever just learning how to use your editor, and how much software would you write then?

Fitzpatrick:Yeah, but I’ve always found—at least for your editor—it always pays off. Whenever I learn something, it pays off within, I don’t know, a week or two. Whenever I write a stupid little shell script in my bin directory, or a little Perl script, or something to automate my life, it always pays off.

Seibel:So you’ve never gotten trapped in the pit of endless toolsmithing?

Fitzpatrick:Nah. I tend to do it for a purpose. I definitely know people who are just always working on their personal tools and never get anything done. I can go a little bit more in that direction and be safe, though.

Seibel: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.

Seibel:Is there anything that you did specifically to improve your skill as a programmer?

Fitzpatrick:Sometimes I’ll go out of my way to write something in a language that I would rather not write it in—and I know it’ll take me longer to write in that language—because I know I’ll be better in the end. Like when I got to Google, there were a lot of times where I was writing one-off things and I’d go to write it in Perl. Then I’d be like, “Ah, no, I should write this in Python.” Now I write tons of Python and it doesn’t bother me—I barely have to look things up. Perlbal was originally written in C# just to learn that.

Seibel:And are there skills apart from programming itself that you think would-be programmers should develop?

Fitzpatrick:There’s communication, but I’m not sure that’s something you can really practice. Deal with people on mailing lists a lot. Written communication style goes a long way. But that’s a general life thing, right? There was some study about who was successful after high school. Was it the smart kids or the social kids? It turned out that it was the social kids who ended up making all the money in life, not the people with the good grades. I thought that was interesting.

Seibel:That seems to be a bit of a change from the past. It used to be programmers could be gnomes hiding in an office. These days it’s all mailing lists and collaboration.

Fitzpatrick:Well, at the places I’ve worked, either on open source or at companies, everyone depends on each other. The motivating factor is, “I’m going to write this code because I know you’re going to be needing it in two weeks or I’m going to be needing yours in two weeks.” There’s always a human level.

Seibel:People have claimed that there are orders of magnitude differences in productivity between the best and worst programmers. Has that been your experience?

Fitzpatrick:Yeah, but it’s probably like that in every field. It’s how much experience you have. It’s not often the case where I know of two people who do the same sort of programming and have been doing it the same amount of time, but differ by a factor of ten times. It seems like if you’re not getting better all the time, you’re probably getting frustrated and you drop out.

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. What’s ten times more productive when one person works ten times the hours and thinks about it nonstop and the other person just does it at his job?

Читать дальше
Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать

Похожие книги на «Coders at Work: Reflections on the craft of programming»

Представляем Вашему вниманию похожие книги на «Coders at Work: Reflections on the craft of programming» списком для выбора. Мы отобрали схожую по названию и смыслу литературу в надежде предоставить читателям больше вариантов отыскать новые, интересные, ещё непрочитанные произведения.


Отзывы о книге «Coders at Work: Reflections on the craft of programming»

Обсуждение, отзывы о книге «Coders at Work: Reflections on the craft of programming» и просто собственные мнения читателей. Оставьте ваши комментарии, напишите, что Вы думаете о произведении, его смысле или главных героях. Укажите что конкретно понравилось, а что нет, и почему Вы так считаете.

x