Coders at Work: Reflections on the Craft of Programming

Oct 14, 2011

Jamie Zawinski e Douglas Crockford

_"Personally I have never believed that it is possible to be a good coder without being a good programmer nor a good programmer without being a good designer, communicator, and thinker."_ - Jamie Zawinski

Como Joel e Atwood disseram, a leitura de Coders At Work é tão útil quanto ler o código dos outros, só que em um estilo mais condensado, que se aproveita das décadas de experiência dessa gente para aprimorarmos nossos processos de desenvolvimento e, muitas vezes, a forma de pensarmos sobre software.

[caption id=“attachment_1202” align=“aligncenter” width=“203” caption=“Coders at Work: Programadores no Hall da Fama”][/caption]

No meu estilo de leitura circular, adaptada do brilhante (maluco?) método de Dmitry Vostokov, as coisas vão mais devagar, e estou apenas no início do livro, tendo passado por Jamie Zawinski (desenvolvedor da equipe original do Netscape), Brad Fitzpatrick (criador do Live Journal) e terminado recentemente Douglas Crockford. O artigo de Joel sobre Zawinski demonstra seu apreço pelo codificador pensante, ou aquele que faz as coisas acontecerem e não fica preso eternamente na armadilha da arquitetura. Eu acredito que as seguintes passagens do livro demonstram seu pensamento melhor do que se eu fosse tentar traduzi-los.

Jamie Zawinski

[caption id=“attachment_1217” align=“aligncenter” width=“186” caption=“Jamie Zawinski”][/caption]

“Personally I have never believed that it is possible to be a good coder without being a good programmer nor a good programmer without being a good designer, communicator, and thinker. (…) Start converting it into the bad one until it stops working. That¿s primary tool of reverse engineering. (…) 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. (…) The design process is definitely an ongoing thing; you never know what the design is until the program is done. So I prefer to get my feet wet as early as possible; get something on the screen so I can look at it sideways.(…) I¿ve noticed that one thing that separates good programmers from bad programmers is that good programmers are more facile at jumping between layers of abstraction¿they can keep the layers distinct while making changes and choose the right layer to make changes in. (…) I think one of the most important things, for me anyway, when building something from the ground up like that is, as quickly as possible, getting the program to a state that you, the programmer, can use it. Even a little bit. Because that tells you where to go next in a really visceral way. (…) I don¿t want to be a mathematician but I¿m not going to criticize someone who is a mathematician. It¿s weird that people often confuse those two pursuits. People who are into very theoretical computer science are thought of in this same way as people who are shipping desktop applications. And they don¿t really have a lot to do with each other. (…) Then there was another book that everybody thought was the greatest thing ever in that same period¿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. (…)”

Douglas Crockford

De certa forma, o mesmo pragmatismo pode ser observado em Douglas Crockford, que utiliza o método de leitura de código tanto na entrevista por candidatos (“traga-me o código que tem orgulho de ter escrito e explique-o pra mim”) quanto no dia-a-dia do projeto, para que todos entendam e aproveitem a evolução do projeto como um todo, além de constituir, na minha visão, uma das melhores dicas de auto-management que uma equipe de programadores poderia ter.

[caption id=“attachment_1218” align=“aligncenter” width=“300” caption=“Douglas Crockford”][/caption]

“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 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 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?

“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.”

Seibel: So if you don¿t clean up every seventh cycle you may be faced with the choice of whether or not to do a big rewrite. How do you know when, if ever, it¿s time for a big rewrite?

“Generally the team knows when it¿s time. Management finds out a lot later. The team is getting beat up pretty regularly, making too many pretty regularly, making too many bugs; the code¿s too big, it¿s too slow; we¿re falling behind. They know why. It¿s not because they became stupider or lazier. It¿s because the code base is no longer serving the purpose that it needs to.”

Brendan Eich, threads e depuração

_"Proofs are hard. Most people are lazy. Larry Wall is right. Laziness should be a virtue. So that¿s why I prefer automation. Proofs are something that academics love and most programmers hate." - _Brendan Eich

[caption id=“attachment_1211” align=“aligncenter” width=“150” caption=“Brendan Eich, Pai do JavaScript”][/caption]

Esse pequeno trecho da entrevista de Brendan Eich, de Coders at Work, revela parte das frustações que os programadores de linha de frente sofrem com os ambientes de depuração, muitas vezes aquém dos desafios atuais. Sinceramente, não sinto isso em meu dia-a-dia, e acho o Visual Studio um excelente depurador com interface (mas que perde feio para o WinDbg em casos mais hardcore). Porém, fica a percepção curiosa do criador do JavaScript.

Sobre SGI

“Diagnosing it was hard because it was timing-sensitive. It had to do with these machines being abused by terminal concentrators. People were hooking up a bunch of PTYs to real terminals. Students in a lab or a bunch of people in a mining software company in Brisbane, Australia in this sort of ¿70s sea of cubes with a glass wall at ¿70s sea of cubes with a glass wall at the end, behind which was a bunch of machines including the SGI two-processor machine. That was hard and I¿m glad we found it. These bugs generally don¿t linger for years but they are really hard to find. And you have to sort of suspend your life and think about them all the time and dream about them and so on. You end up doing very basic stuff, though. It¿s like a lot of other bugs. You end up bisecting¿you know ¿wolf fence.¿ You try to figure out by monitoring execution and the state of memory and try to bound the extent of the bug and control flow and data that can be addressed. If it¿s a wild pointer store then you¿re kinda screwed and you have to really start looking at harder-to-use tools, which have only come to the fore recently, thanks to those gigahertz processors, like Valgrind and Purify.”

Ferramentas de Depuração Avançadas

[caption id=“attachment_1212” align=“aligncenter” width=“129” caption=“Logo da Valgrind”][/caption]

“Instrumenting and having a checked model of the entire memory hierarchy is big. Robert O¿Callahan, our big brain in New Zealand, did his own debugger based on the Valgrind framework, which efficiently logs every instruction so he can re-create the entire program state at any point. It¿s not just a time-traveling debugger. It¿s a full database so you see a data structure and there¿s a field with a scrogged value and you can say, ¿Who wrote to that last?¿ and you get the full stack. You can reason from effects back to causes. Which is the whole game in debugging. So it¿s very slow. It¿s like a hundred times slower than real time, but there¿s hope.”

“Or you can use one of these faster recording VMs¿they checkpoint only at system call and I/O boundaries. They can re-create corrupt program states at any boundary but to go in between those is harder. But if you use that you can probably close in quickly at near real time and then once you get to that stage you can transfer it into Rob¿s Chronomancer and run it much slower and get all the program states and find the bug.”

Depuradores da Indústria

“Debugging technology has been sadly underresearched. That¿s another example where there¿s a big gulf between industry and academia: the academics are doing proofs, sometimes by hand, more and more mechanized thanks to the POPLmark challenge and things like that. But in the real world we¿re all in debuggers and they¿re pieces of shit from the ¿70s like GDB.”

[caption id=“attachment_1213” align=“aligncenter” width=“200” caption=“Mascote do GDB”][/caption]

_"In the real world one big split is between people who use symbolic debuggers and people who use print statements."_ - Peter Seibel

“Yeah. So I use GDB, and I¿m glad GDB, at least on the Mac, has a watch-point facility that mostly works. So I can watch an address and I can catch it changing from good bits to bad bits. That¿s pretty helpful. Otherwise I¿m using printfs to bisect. Once I get close enough usually I can just try things inside GDB or use some amount of command scripting. But it¿s incredibly weak. The scripting language itself is weak. I think Van Jacobson added loops and I don¿t even know if those made it into the real GDB, past the FSF hall monitors.”

Multithreading

“But there¿s so much more debugging can do for you and these attempts, like Chronomancer and Replay, are good. They certainly changed the game for me recently. But I don¿t know about multithreading. There¿s The multithreaded stuff, frankly, scares me because before I was married and had kids it took a lot of my life. And not everybody was ready to think about concurrency and all the possible combinations of orders that are out there for even small scenarios. Once you combine code with other people¿s code it just gets out of control. You can¿t possibly model the state space in your head. Most people aren¿t up to it. I could be like one of these chestthumpers on Slashdot¿when I blogged about ¿Threads suck¿ someone was saying, ¿Oh he doesn¿t know anything. He¿s not a real man.¿ Come on, you idiot. I got a trip to New Zealand and Australia. I got some perks. But it was definitely painful and it takes too long. As Oscar Wilde said of socialism, ¿It takes too many evenings.¿

Coders at Work: Reflections on the Craft of Programming, by Wanderley Caloni. 2011-10-14.