Какие скиллы важны для программистов, и как их улучшить? Насколько важно образование, полученное в учебном заведении? На что собеседники Сибела обращают внимание при поиске и найме программистов? Как разобраться в чужом коде? Как улучшить совместную работу с коллегами? Эти и многие другие темы затронуты в книге. Помимо обсуждения общих вопросов, чуваки рассказывают увлекательные истории о проектах, благодаря которым они стали известными.
Чуть ли не всю книгу хочется цитировать. Я понавыписывал целую кучу цитат, и несколькими из них хочу поделиться с вами (из первых трех интервью с Завински, Фитцпатриком и Крокфордом).
Jamie Zawinski
Author of XEmacs and early Netscape/Mozilla hacker
О работе в компании Netscape
It was really a great environment. I really enjoyed it. Because everyone was so sure they were right, we fought constantly but it allowed us to communicate fast. Someone would lean over your cubicle and say, “What the fuck did you check in; that’s complete bullshit—you can’t do it that way. You’re an idiot.” And you’d say, “Fuck off!” and go look at it and fix it and check it in. We were very abrasive but we communicated fast because you didn’t have to go blow sunshine up someone’s ass and explain to them what you thought was wrong—you could say, “Hey, that’s a load of shit! I can’t use that.” And you’d hash it out very quickly. It was stressful but we got it done pretty quickly.
О запуске первой версии Netscape
That first night when we put up the .96 beta, we were all sitting around the room watching the downloads with sound triggers hooked up to it—that was amazing. A month later two million people were running software I’d written. It was unbelievable. That definitely made it all worthwhile—that we’d had an impact on people’s lives; that their day was more fun or more pleasant or easier because of the work we’d done.
Overengineering и запуск проектов
Zawinski: [...] They were being extremely academic about their project. They were trying to approach it from the DOM/DTD side of things. “Oh, well, what we need to do is add another abstraction layer here and have a delegate for this delegate for this delegate. And eventually a character will show up on the screen.”
Seibel: Overengineering seems to be a pet peeve of yours.
Zawinski: 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.
Seibel: Folks engaged in overengineering usually say, “Well, once I’ve got this framework in place everything will be easy after that. So I’ll actually save time by doing this.”
Zawinski: That is always the theory.
Seibel: And there are times when that theory is true, when someone has good sense and the framework isn’t too elaborate, and it does save time. Is there any way you can tell which side of the line you’re on?
Zawinski: [...] If you spend the time to build the perfect framework that’s going to do what you want and that’s going to carry you from release 1.0 through release 5.0 and everything’s going to be great; well guess what: release 1.0 is going to take you three years to ship and your competitor is going to ship their 1.0 in six months and now you’re out of the game. You never shipped your 1.0 because someone else ate your lunch.
Your competitor’s six-month 1.0 has crap code and they’re going to have to rewrite it in two years but, guess what: they can rewrite it because you don’t have a job anymore.
О сходстве программирования и писательства
Seibel: Do you find that programming and writing are similar intellectual exercises?
Zawinski: In some ways, yeah. Programming is obviously much more rigid. But as far as the overall ability to express a thought, they’re very similar. Not rambling, having an idea in your head of what you’re trying to say, and then being concise about it. I think that kind of thinking is the overlap between programming and writing prose.
О комментариях в коде
I always wish people would comment more, though the thing that makes me cringe is when the comment is the name of the function rephrased. Function’s called push_stack and the comment says, “This pushes to the stack.” Thank you.
You’ve got to say in the comment something that’s not there already. What’s it for? Either a higher-level or a lower-level description, depending on what’s most important. Sometimes the most important thing is, what is this for? Why would I use it? And sometimes the most important thing is, what’s the range of inputs that this expects?
Не нужно стесняться собственного незнания чего-либо (моя любимая цитата)
[...] 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.
О самом главном навыке программистов
Seibel: Is there a key skill programmers must have?
Zawinski: Well, curiosity—taking things apart. Wanting to know what’s going on under the hood. I think that’s really the basis of it. Without that I don’t think you get very far. That’s your primary way of acquiring knowledge. Taking something apart and looking at it is how you learn to build your own. At least for me. I’ve read very few books about computers. My experience has been digging through source code or reference manuals. I’ve got a goal and, alright, to do this I need to know what this thing does and what this thing does. And I’ll just sort of random-walk through that until I find where I’m going.
Снова о сходстве программирования и писательства
Zawinski: [...] So math was never really my forte.
But I wouldn’t go so far as to say you don’t need that to be a programmer. There’s obviously different kinds of programming. Without people who are not like me none of this would exist. 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.
Seibel: And why does that matter? Is that just for the satisfaction of it or is tasteful code also better in some practical way?
Zawinski: To a large degree, tasteful and maintainable are similar. Or very closely related. One of the things that makes a piece of writing tasteful is if it’s structured in a way that’s easy to grasp. Are the facts loaded up at the front or are they scattered around? If you’re referring back—if you’re flipping through a book, can you figure out where in the book is the thing you kind of remember? “This was somewhere near the middle because that’s where he talked about this thing.” Or is it just scattered all through. And that’s the same sort of thing that goes on with programming a lot.
Brad Fitzpatrick
Writer of LiveJournal, OpenID, memcached, and Perlbal
Отличный совет программистам
Seibel: Do you have any advice for self-taught programmers?
Fitzpatrick: Always try to do something a little harder, that’s outside your reach. Read code. I heard this a lot, but it didn’t really sink in until later. There were a number of years when I wrote a lot of code and never read anyone else’s. Then I get on the Internet and there’s all this open source code I could contribute to but I was just scared shitless that if it wasn’t my code and the whole design wasn’t in my head, that I couldn’t dive in and understand it.
О соглашениях по стилю написания кода
Seibel: [...] What are the first warning signs of bad code?
Fitzpatrick: Well, I’m particularly snooty now, having worked at Google with really strict style guidelines in all languages. On our top six or seven languages, there’s a really strict style guide that says, “This is how we lay out our code. This is how we name variables. This is how we do spacing and indentation, and these patterns and conventions you use, and this is how you declare a static field.”
We’ve started putting these online too, just as a reference for external contributors contributing to our projects. We wanted to have a documented policy so we don’t just say, “We don’t like your style.”
Now when I work on projects in C, the first thing I do is add a style guide. Once a project is mature and has a lot of people hacking on it, they’ll have a style guide. It’s not even always written, but the programmer just respect the style of code written already. Maybe they don’t like the brace style, but fuck it, it’s more important to have it consistent within a file, within a project, than to do it your favorite way.
Как устроен процесс рецензирования кода в Гугле
Seibel: What about code ownership? Is it important for people to own code individually or is it better for a team to share ownership?
Fitzpatrick: I don’t think code should be owned. I don’t think anyone really thinks that. The way it works within Google is that it’s one massive source tree, one root, and one unified build system across all of it. And so anyone can go and change anything. But there are code reviews, and directories have owners, always at least two people, just in case some quits or is on vacation.
To check in you need three conditions met: You need someone to review it and say it looks good. You need to be certified in the language—basically you’ve proven you know the style of this language—called “readability.” And then you also need the approval above from somebody in the owner’s file in that directory. So in the case that you already are an owner of that directory and you have readability in that language, you just need someone to say, “Yeah, it looks good.” And it’s a pretty good system, because there tends to be a minimum of two, up to twenty, thirty owners. Once you work on a code base for a while, someone just adds you to owners. I think it’s a great system.
Быть энтузиастом и иметь свои проекты
Seibel: So you’ve hired for your own company, and I assume you’ve been involved in hiring at Google. How do you recognize a great programmer?
Fitzpatrick: I often look for people that have done, like, a lot of stuff on their own that wasn’t asked of them. Not just their school project or just what their previous employer had them do. Somebody who was passionate about something and had some side project. How did they maintain it and how serious did they get with it? Or do they do a lot of quick hacks and abandon them?
Все приложения уйдут в веб
Seibel: Do you have any interest in writing better desktop software?
Fitzpatrick: The problem is, no one uses it. You want to write stuff people use, which comes down to web apps. I lost my laptop the other day and people were like, “Oh, my God, did you lose stuff?” I had no files on there. It was an Internet terminal. And it was an encrypted disk so I’m not worried about my password or cookies or anything like that. People won’t download programs, I don’t think.
Быть общительным
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.
Douglas Crockford
JSON founder, JavaScript architect at Yahoo!
Читаем код (очень понравилось, предложу ребятам в Яндексе)
Seibel: These days you’re a JavaScript architect and evangelist here at Yahoo!, so part of your job, presumably, is to tell Yahoo! JavaScript programmers, “Here’s how you should do it.” Does your job also cover general good design practice and good coding practice?
Crockford: One of the things I’ve been pushing is code reading. I think that is the most useful thing that a community of programmers can do for each other—spend time on a regular basis reading each other’s code. There’s a tendency in project management just to let the programmers go off independently and then we have the big merge and if it builds then we ship it and we’re done and we forget about it.
One of the consequences of that is that if you have weak or confused programmers you’re not aware of their actual situation until much too late. And so the risks to the project, that you’re going to have to build with stuff that’s bad and the delays that that causes, that’s unacceptable. The other thing is that you may have brilliant programmers on the project who are not adequately mentoring the other people on the team. Code reading solves both of those problems.
Seibel: Can you talk a bit about how you conduct a code reading?
Crockford: At each meeting, someone’s responsible for reading their code, and they’ll walk us through everything, and the rest of us will observe. It’s a really good chance for the rest of the team to understand how their stuff is going to have to fit with that stuff.
We get everybody around the table; everybody gets a stack of paper. We also blow it up on the screen. And we all read through it together. And we’re all commenting on the code as we go along. People say, “I don’t understand this comment,” or, “This comment doesn’t seem to describe the code.” That kind of stuff can be so valuable because as a programmer you stop reading your own comments and you’re not aware that you’re misdirecting the reader. Having the people you work with helping to keep your code clean is a huge service—you find defects that you never would’ve found on your own.
I think an hour of code reading is worth two weeks of QA. It’s just a really effective way of removing errors. If you have someone who is strong reading, then the novices around them are going to learn a lot that they wouldn’t be learning otherwise, and if you have a novice reading, he’s going to get a lot of really good advice.
And it shouldn’t be something that we save for the end. Back in the old days, we would schedule a code reading just as we were finishing a project and usually it would be canceled because we were late. I now believe that code reading should be happening all the time throughout the life of the project. That’s something that took me a while to figure out but there are so many benefits that come from that.
For one thing it makes it easier to track the project, because we can actually see what progress people are making. And we can see much sooner if they’re going off the rails or not.
I’ve managed projects where we’re up against a deadline and we had people saying, “Yeah, I’m almost done,” and then you get the code, and there’s nothing there, or it’s crap, or whatever, and they’re nowhere close to done. In management, those are the experiences you hate the most and I think code reading is the best way of not getting trapped like that.
Seibel: So say we’re doing a code reading of some of my code. I bring printouts and we put it up on the screen. Then what? Do I literally read it out loud?
Crockford: Yeah, go through it line by line, and you’ll be doing commentary on it. This is what’s supposed to be happening here. If we have time, we’ll go line by line.
Seibel: Do you find that you have to teach people how to do code readings? I can imagine it’d be hard to find the right balance of being critical enough to be worthwhile without making the code’s author feel personally attacked.
Crockford: Yeah, it requires a lot of trust on the part of the team members so there have to be clear rules as to what’s in bounds and what’s not. If you had a dysfunctional team, you don’t want to be doing this, because they’ll tear themselves apart. And if you have a dysfunctional team and you’re not aware of it, this will reveal it pretty quickly. There’s a lot that you can learn, a lot that’s revealed by this process. It feels unnatural at first, although once you get into the rhythm of it, it feels extremely natural.
Another aspect is writing your code such that it can be read. Neatness counts, as it turns out, and style is important. And all of those things will increase the quality of the code base going forward and increase the competence of the programming community.
Читабельность прежде всего
[...] I think it’s really difficult to write good code in a sloppy manner. By good code, I mean it’s going to be readable. At one level, it doesn’t matter what it does to a machine if I can’t figure out what it does, so it might turn out that the code is amazing in terms of its efficiency, or its compactness, or some other metric which I don’t care about.
Readability of code is now my first priority. It’s more important than being fast, almost as important as being correct, but I think being readable is actually the most likely way of making it correct. So I think it’s probably not good code and they probably made the wrong trade-offs if the code turned out to be in the state that it’s not easily readable.
Собираем программы из готовых блоков
I think the next leap, we don’t know what the name of it is yet, but I think it’s something related to mash-ups where we can casually take bits of program and put them together and immediately make new programs. We’ve been talking for decades about a model of programming in which we snapped programs together like LEGO and make stuff. That hasn’t happened yet. But I think it is starting to happen now and the place it’s happening is in JavaScript, which is the least likely place.
Снова о том, что надо быть общительным
Seibel: When you’re hiring programmers, how do you recognize the good ones?
Crockford: The approach I’ve taken now is to do a code reading. I invite the candidate to bring in a piece of code he’s really proud of and walk us through it.
Seibel: And what are you looking for?
Crockford: I’m looking for quality of presentation. I want to see what he thinks is something he’s proud of. I want to see evidence that in fact he is the author of the thing that he’s defending. I find that is much more effective than asking them to solve puzzles or trivia questions. I see all that kind of stuff as useless. But how effectively they can communicate, that’s a skill that I’m hiring for.
Seibel: What about advice for someone who’s actually getting a C.S. degree who wants to work as a programmer?
Crockford: I would focus on the communication aspect. Learn to write; learn to read.
My advice to everybody is pretty much the same, to read and write. I generally don’t hire for specific skills. Until very recently, you couldn’t hire good JavaScript programmers. They were extremely rare. There are a lot of really good ones out there now, but that’s a fairly recent thing. So until that happened, I would just hire for quality. Are you a good Java programmer, a good C programmer, or whatever? I don’t care. I just want to know that you know how to put an algorithm together, you understand data structures, and you know how to document it. If you can do that, you should be able to figure out JavaScript.
2 комментария:
О, дашь почитать?
Конечно дам, но у меня только в электронном виде есть в PDF. Читаю на ебуке Sony Reader.
Отправить комментарий