Dave: Ok, I will give the idealist point of view. If you were wildly optimistic, a software craftsman would emulate or be somewhat analogous to what you used to see in the Renaissance. So you go into a studio and you see someone like Leonardo or someone of that ilk who are masters of a discipline or in some cases several related disciplines. But they are also masters of the tools that they use in those disciplines. They are masters of the technology or inventors of the technology that they use in those disciplines and to a very large extent they are temporal polymaths, they know everything that there is to know about the world at that point in time. So someone that exhibited those kinds of traits or characteristics would be my definition of a craftsman.
Brian: I think the kind of people build things that people admire as great code. And there are people who are unfortunately fewer and farther between than they should be. I think it is something like Xerox Smalltalk image. There are people like Dan Ingalls running around at this conference here, in Orlando 2009 and people who could build such a thing as that artifact something that you can spelunk around in for months, as the greatest apprenticeship in software engineering design you can possibly ever have. Those are the kind of people I think of as craftsman, people who look at something and cultivate it, who live with it, make it part of how they live and breathe day to day. Code for me is a place; it's this place where we spent the better part of our lives, most of the work week and a whole lot of it other times. And we don't treat it as a kind of place that should be sustained, cultivated and admired and improved in a way that we are to, and the kind of people who do that, the kind of people who are committed to that about making this place where we live but we can't see we work here all time, those are the kind of people that I admire, those are the craftsmen.
Dave: It's interesting that you are following the trend of the craftsmen movement, the nascent craftsman movement, in focusing on programming, the craft is programming, with Dan Ingalls as an exemplar, (certainly a good exemplar). Is there a more general sense of craftsmanship? Can you see craftsmanship in software development? Or systems design: as opposed to just narrowing in on programming?
Brian: I'll bet you could, but that is not my department. I simply am thinking about code, that's where I live and I wake up in the morning and I see something on television and I wonder if there is some analogy I could draw between that and code. To paraphrase Karl Wallenda "The code is life, everything else is just standing around". There are people who are good at process there are people who are good at these other things but, the place where I live is this place where that is the focus. I want the code to talk to me, I want the code to be something that I know will be better tomorrow than it was today. I live down Urbana Illinois and we have a large Amish community and they found this niche whereby most of the world wants pressed board but they found a way to be able to find a place in the world where they can produce things, with dove tail joints and cherry wood, and they are not just rubes or rustics they are able to command a price for this and there is an niche for it, they are able to spend their lives doing that, they get to do it without electricity, it's like they are building great software and oh, yes they use vi because an IDE is an offence to God or something. Fascinating kind of way looking at life, and there is a place for that, and I wish there was more of a place for that. Sometimes it just seems that there isn't.
Dave: So Ikea doesn't have craftsmen, but the Amish community does.
Dave: The current interest or the current resurgence in craftsmanship, talking about craftsmanship probably was prompted by the publication of a book with that title by Pete McBreen in 2002 or 2004 (somewhere around there) so the current interest seems like it's new, it's an interesting idea. I think Pete's idea was much more general kind of like the ideal that I laid out earlier, but the people who have adopted it have been far more like Brian they are coders, so they adopted in terms of their own discipline, their own specialization. In the background there are other influences like Agility, so the entire Agile movement has this focus on the responsibility of the team which implies that you have to be better than the average or better than you are. So that takes a slightly different direction and then there is the original historical roots the whole idea that software is an art. So that is still a third direction. So you have people like Richard Gabriel running around trying to do an MFA in software a master in fine arts software with studios and all kind of things you would see in art school, and that's a craftsmanship. So, there is at least three different origins at least that I see.
Brian: I think that it has been this current that has been running through - I have been running around this [OOPSLA] community for maybe longer than is fit for a person, and starting with the Smalltalk world and through the 90s and the XP and the development of Java there has always been this cultural here that seamed to encourage this idea that software shouldn't be built in waterfall, "ship that shit," sweatshops; like zillions and zillions of people. But that we are better served by having small commandos teams small teams of guys who are really good who could aspire to workmanship, to know how to do work, they master different skills, know how to keep a code base healthy and it's the same current that inspired the emergence of the pattern movement, and XP and then the Agile movement, in this century and I think at the root of that was a belief that a dedicated team of people who were passionate about quality, who know what iterative incremental design development is, could build things faster and more effectively than it was being done in the industry at that time.
And I think what we see with the Agile movement is that a lot of the organizations have tried to lower their cost by engaging in IQ point arbitrage. They figured Waterfall isn't working for us so we can cut the budget by taking advantage by the exchange rates and get our IQ points elsewhere because they are abundant. So they tried doing the same thing they couldn't afford to do here, and didn't get the results they wanted - because that is not the kind of way that is needed. Good software doesn't come from a process like that, it's organic it's grown and it needs to be cultivated by people who care about it, it's like a bonsai garden.
And that is what this model seems to encourage so a lot of people who got burned by trying to scale Waterfall with their wallets that way have turned around and said "Ok maybe we can come up with a cultural of sustainable development, by using smaller teams. That sounds cheaper even if the people are expensive on a per head basis and we then have to solve this problem of getting the rest of the organization out of the way and I think that is one of the big impulses driving Agile right now, figuring now how people can become these liaisons, between the big organizations and these teams that focus on their development jobs - there is a role in the Agile management community as well and I think it's all focused on this idea I think that at least from the developers prospective that kind of hyper-topia is possible. And there are other variants on it I think that some people just wanted to get stuff cheap and fast and there is a certain flip side quality to that particular perversion of the vision. And that is out there too all those things are out there.
Dave: An analogy or a parallel kind of idea to that you see a lot of people in a craftsmanship community using the vocabulary of martial arts. So the idea is that you go thorugh a Dojo and become a black belt in whatever it is that you are doing, and so the analogy there is, one Samurai is worth a hundred ordinary warriors, (as long as they don't have gunds) and there is definitely that kind of market force out there - "Well gee, maybe I can get what I want with 10% or 90% less people less whatever if they are Samurai". But that analogy breaks down really fast, because a samurai might be a really really skilled swordsman, but what makes them a samurai is a larger cultural context a software context which takes a lot longer to master and I don't see the Agile community being particularly interested in that.
Brian: It's interesting you ask "Why doesn't everybody do this?" Craftsmanship, quality code that sounds like a courageous and iconoclastic stand. Like, who is gonna be against that? It seems like most of the world is against it. The default seems to be a school of architecture that we call "Big Ball Mud", Joe Yoder and I wrote a paper twelve years ago now, that had as its focus this idea that, if there is all these high minded notions of software architecture out there, (they were being published in droves in journals those days), why is it that when we turn around and look at real people code that the architecture that seems to be dominant in practice is something called a big ball of mud, which is duct tape and bailing wire spaghetti code jungle.
We all know what they are. And we contended that that's the architecture most dominantly deployed out there in the real world we have been running around it for several years. The thing that amazes me is no one has ever disputed that point people just nod their head and say "Oh yes, yes, that's just how it is". We kind of wish it was better, and it's fair to ask the question if that is so, why is it so? What are they doing right? There is one thing if you ask them why is it that it is persistent? And there are reasons for that, there are reasons why that kind of people are cheaper. You get anyone to write bad code, if you want good code, you have to pay for it, people don't like to pay for it.
Maybe if you have ever had surgery your doctor knows if your internal organs are elegant, but people who run software companies one level above your manager and they never looked at a line of code in their life. They don't care what is in there, it's like the craftsman in Europe who carve the gargoyles on the big cathedrals, on the back - on the side only visible to God -anyway for the sake of their art but code is the same way. Most of us write things, reproduce these cathedrals for elegance, that no one has ever seen. Basically there has been no audience for them. Open source has changed that a little bit but that is one of the issues. In the meantime there are people out there who have this horror of mud that's out there that we are producing at an incredible rate. We are producing at an incredible rate, producing this inscrutable code at a faster rate that people can re-cultivate it and re-factor it.
And there is no end in sight for that. And it persists because it works and people can produce something that kind-of works, they bring in people, it's like World War I though, fighting mud in the trenches it's an awful fate. Banishing it on humanitarian grounds or something that might make sense. The other direction that you can go by analogy there is that you can move faster if the code is actually something that people can comprehend. If it's scrutable, if its a place that you can recognize. We are in the middle of swamps here in Florida, we are surrounded by this stuff that could only be charitably called land. A lot of code feels that way; it's a trackless waste. You look in every direction there is no visible sign of any structure or human habitation maybe a lot of it shouldn't have been inhabited in the first place.
But when code is like that: you are stuck in the mud, you're knee deep in Big Muddy - it's World War I. With tools and skilled people code development done by people who know what they are doing would be more like World War II. You move quickly you got re-factoring that allows you to keep the code in good shape, you don't get bugged down in one place and you don't have the kind of human tragedy that working in ball of mud sweat shops put you in and on humanitarian grounds alone I think you can make a case for a move away from that style of development, and into something that is correct. Maybe on the same kind of occupational safety grounds that people got rid of tobacco in the workplace you could say "Sanity would be maintained if people didn't have to work on this garbage". But none the less people get to market quicker with some of that stuff and the competition maybe trying to do something a little better and maybe later they can refactor. All those possibilities all those variants are out there and that's why it's still there.
Dave: The whole idea of software craftsmanship opens a metaphorical door where you start looking for a bunch of other interesting referents. Let me be fanciful for a minute: starting with a question I used to ask when I would teach, particularly at a big university, I would ask my students at some point or another when talking about art and I would ask them: "Who would you pay, or do you know anybody that you would pay to go into a big theatre they would be sitting up on the stage with a projector and they would write code.
And you would pay twenty dollars to go and spend an evening watching somebody write code". And unsurprisingly I never got an answer, nobody ever said "Oh, I would go and see so and so" in part because they were ignorant of people like Dan Ingalls and what he could do, except for the University of New Mexico where everybody, it was universal among the entire student body would go and see Dan Ackley, who is professor there, who they would pay to watch him write code. People come from all over the world, to go to Pennsylvania to buy furniture from the Amish. There is somehow an esthetic or a common sense worth the value in other kinds of crafts that we don't see in software. Have you ever written a block of code that should be hung on the wall of the Louvre? Has anyone in our profession written a block of code that should be hang on a wall in a museum like that or are we just whistling in the dark because craftsmanship doesn't really mean the same thing.
Brian: Maybe, I never had surgery and knock on something I hope I never do, but if I do, I necessarily don't want the guy who has been doing this for a few weeks, who doesn't know how to suture and doesn't give a damn whether the arteries are reconnected in the right place, you kind of want to go for the Babe Ruth when the stakes are high. And I don't know if the most famous surgeon in the world's best work could be hung on the wall in the Louvre either but you kind of want to know that when he is having a good day that's the day you want him on your case so probably they go to conferences and look at pictures like that and then go home and that guy's liver, what a job.
Dave: Probably not the Louvre but maybe in those Body Works traveling exhibitions
Brian: I would pay to see Ward and Kent pair again, they are like Simon and Garfunkel; they keep getting together and breaking up but that would be something I would show up. I would go and take a master discount though.
Dave: That's actually true - and maybe it's a two-fold thing: maybe there are and have been, I am sure there have been lots of software are being hung in the museum but we are totally oblivious to it. People say that our world is too young, that we are only 50-60 years old profession, so we don't have a history yet, but if you look at computer time, it's this kind of compressed and accelerated time driven by Moore's Law all this kind of stuff, then we have got several hundred years, official history or equivalent history and so it's far past time to have their museums and you hear the old guys and maybe this is just their ego saying "Hey, don't forget what I did, fifty years ago". But that is one of the biggest laments of the people retiring from the profession now that invented it, is that nobody remembers what they did or they are constantly just reinventing things. Maybe it's also a low point of entry. I mean you see fourteen years old in our profession and they haven't had the time to assimilate any history about their profession.
Brian: I think that a museum is too small is not a grand enough vision of how good some of the stuff that was done in the 70s and 80s was. And maybe if we thought like the original Smalltalk images like a world heritage cultural cyberspace site that you could visit like the Serengeti or something, spelunk around in it for a few days, explore it, the scope of some of these things is really kind of amazing, people haven't seen it. I think one of the problems with code is that it's easier to do it over than it is to read other people's stuff. Years ago I found the dirty little secret of our discipline is that it is easier to write stuff than it is to read it.
And I think one of the reasons people keep reinventing stuff is that it is more fun to do it again. That is because they have to go back and figure out how other people do it; because it is way more work to read other people's code and more fun to write your own. It's a lot more fun to do it yourself because then you know how it works. Re-inferring what other people did that is a difficult chore. Our pal Dick Gabriel said once that reading other people's code for him is like being blindfolded and hearing a shotgun cocked in a dark room. You are looking for the land mines everywhere and ball mud code has that character, you feel like you are crawling blindfolded through a mined field, anything you touch might break it. And so you have got this problem if you want to recycle stuff you have got to go through a lot of work to clear the mines and figure out how it is that you can live there. Doing another generation is probably an easier cut.
And yet every time this stuff is re-developed it gets a little better, there is a reason why there is mortality in the genome, some species are long-lived, some live shorter lives, and then take another cut in the next generation and evolution is a field where you see that kind of model, for the most part.
Dave: Is Donald Knuth a software craftsman, a programming craftsman? ofI raise that point because he is the first person I know of that was really famous for advocating readable code. And in fact writing code that was addressed to a human being instead of to a machine. And I don't think that went very far and influenced much of programming.
Brian: I don't think it would be The hallmark of a craftsman, the most important thing. One of the themes of the keynote address this week that came across was that readability is the great unachieved goal of a lot of what we have been doing for the last twenty-five thirty years. We are really good about writing stuff and really bad at writing something we can make sense of subsequently. And I think readability is a hallmark of a craftsman, I think it's a most important thing and we have come no where near close enough to achieving that on a regular basis that's why the majority of stuff out there would probably be construed by most readers as Mud. It may just be a fundamental problem about this medium.
For me there's a spatial sense about spelunking around in code, getting to work – there is this place. And if the place is a shambles if the place is a toxic waste site, it's a depressing place to be and you don't necessarily put a lot of effort into getting it better sometimes if you are just the maintainer that is the kind of thing that leads to a cycle of despair the code just gets worse and worse, and you have to employ increasing numbers of IQ points just to have any chance of even keeping it on the air. You got to be really smart to spelunk around that stuff and be able to keep it going if it's in a horrible state like that.
That's one of the problems you can avoid if you do systematic cultivation. Another observation on that previous theme is the software industries always had the manifest destiny, a kind of slash and burn, mentality about it. You keep wearing out hackers in their twenties by exhausting their detail capacity and dealing with garbage and then you move on to the next generation of them. If you burn out one continent's worth, you go out find another continent. The mentality that you do sustainable development that you are a sod buster instead of a rancher that you set down in one place, live with a piece of code and actually make it better. I think an important part of a craftsman and I think it's something we haven't seen a lot of. It's all out there, there are example of all of these things but I think the old slash and burn mentalities still dominates to a greater extend than it should.
Dave: Weekend, hotel starving artists arts sales, of development.
Brian: I have seen incredible stuff done in Assembly language in my day and I have seen people do ingenious things with every language you can possibly think of. I have seen people do masterpieces in C++. I think it's easier when you don't have to contend to some of the ancillary concerns, and things like automatic garbage collection helps you out with that, so in languages like Java it's easier to focus on the stuff that is really important. But I don't think any language prevents you from paying attention to good design and active communication. The computer can execute garbage but humans have a hard time reading the big balls of mud, and spending the time that you need putting the attention into making sure that person who comes after you has any idea of what you were doing I think it's what coding is about, what craft is about.
The artifact is being produced for the next human being here, if I am doing it, to be able to make sense of. If I do a crummy job of that, then I have failed. Now technology isn't as much the solution to this in some ways, that I thought it's gonna be when I got into this racket. When I first got into objects I thought frameworks were going to save the world. If we could distill some of the cleverness into the frameworks I could build these things other people could use, and they would worship at the altar of cleverness they have these naïve youthful visions of what can be done and it turns out frameworks are useful in a few areas: they are successful for GUI's, they are good for doing persistence stuff, dependencies injection frameworks.
But they weren't as effective in getting code better as the next thing that came along, and that kind of surprised me and that was the patterns movement, we are here at OOPSLA this is the fifteenth anniversary of the publication of the "Gang of Four" book. And it turned out that the thing that worked in terms of being able to keep ideas alive, was not to do it at the level of reusable artifacts like frameworks, it was to actually look at what programmers were doing right, and then turn those ideas into literary descriptions of those moves, so that real press people could look into a problem and go "You know I have seen that thing where this dove-tail joint lasted for a hundred years, I am using it in this piece of furniture".
That turned out to be the level of reuse, it turned out to be a more important way of keeping ideas alive and getting them properly integrated in the software then just to focus on objects or even on languages and that's a big surprise. I suppose a pleasant one. I think I would rather have a world where we are not building everything out of Legos, that we got from the reusable components store, I think I like the idea that you don't stack up double-wide trailers when you want to build a nice house you actually have people design something and make decisions about the wall boards and where the rooms are, that are crafted, that are specifically designed to serve the requirements at hand. And having patterns in your quiver and using them in that way has turned out to be a more effective way of achieving that kind of result than trying to make the components reusable.
Dave: I would answer it by challenging the assumption in your question, or the assertion in your question that X languages have a higher order of abstraction that Y languages, I do not believe that at all. All programming languages that you see out there are abstractions of the exact same thing, the computer and so they aren't higher or lower, they are different prospective of the same thing, different ways of thinking about the machine. A higher order abstraction language for me would be one that goes beyond the machine and starts encompassing an application so an application programming language or a system's programming language. The only really serious attempt that I am aware of doing that was the original Simula which was supposed to be an abstraction of a general scientific system.
And it was supposed to be written so that people who were really expert in that domain could think about that domain and express their thoughts in this language. The machine was next to irrelevant. And they didn't really have machines then, they had these old toys but they didn't care about how efficient the machine run or anything of this sort but what they wanted was a system description language. That would be a high order of abstraction. You saw a little bit of that in Smalltalk, where Smalltalk self consciously emulated Simula, and tried to come up with this verisimilitude to the real world to make it match the user illusion and be something that kids could grasp and comprehend and then describe. In both cases, both in Simula and Smalltalk, they got seduced by the dark side and wanted to produce a programming language that had all the power of C, all the power of Assembler, and so they didn't have the right idea, they didn't go on the right direction.
Brian: There is this old story of the medusa, and there is a Star Trek episode where they strip mined the idea, something that when you look at it is so horrible you are completely driven insane. Code can be like that sometimes that's a characteristic of balls of mud. And I think the episode's pretext was something like "I can not show you my real form because you would immediately be driven insane and so I come to you in this form that looks like an actor we can hire for cheap because otherwise the special effects would be really expensive", that's what they used to do in SciFi movies.
Sometimes I wonder if we could find different ways to present code that would not drive us insane the way the current medium does, better ways of visualizing the glory and the intricacy and the cleverness of the connections, if we lived in the space and had night vision devices that may keep us feeling like we are stumbling blind through a mine field, something better than this goofy punch card based, syntactic Unicode, basically Fortran warmed over syntactic tradition. Maybe things will get better and you see bits and pieces of things starting to happen. There is other ways of discerning what this space looks like if people are talking about, I am not talking about going back to the whole ideas of just doing visualization, in a way that, what's the name of those languages? It's blocked out, too bad it as a good point.
Dave: I don't remember those. I remember Jaron Lanier working on a music notation based visual language.
Brian: It's visual languages, the term I was looking for. That went nowhere because the whole idea of pushing things that looked like flowcharts or UML diagrams turned out to be a damaged way to actually code because it doesn't properly express behavior but other ways of visualizing the space, of letting us embrace the intricacy rather than going off on these attempts to be simple tangents where we tried to say "The world is complicated, why isn't our code?" maybe the problem is we need to have better ways of really navigating the intricacy of some of these things people have succeeded in building but that are really difficult to read than just wallow in this notion that if we were just better at crafting it, it would just be simple. Some things just aren't simple. It's a gift to be simple but it's not necessarily a duty or always possible.
Dave: What about the hybrids like Parts with Smalltalk or IBM's Visual Age where you had visual programming environment and then you could drop after the base level code, do they do a better job?
B: I guess those were better but it could be just that intricacy is one of those things where the best we can do pushes the horizon beyond which a person's detail capacity exhausts and you go from World War II from World War I - out a little bit further. And that is probably a good thing, but those had that feel for me, it was a little bit of progress but there were still all these dangling ends of intricacy that seamed to keep you from getting the major improvement that you expected to get out of those in practice.
Dave: At the very beginning I mentioned one of the trends in software craftsmanship actually comes out of work by Ken Auer He was the first person I know that seriously developed an apprenticeship program. He was taking kids that came out of home school environments and apprenticing them into Agile and object oriented programming. And the conference that I went to this summer that was the only really strong thing was that apprenticeship is essential and oh by the way we are doing apprentice ships and that makes us cool. I think clearly becoming a craftsman is a result of experience and developing a personal history I do not think that if you take the blue pill or the red pill and all of a sudden it's there. I am a professor, at least part of the time, so somehow I have the solution that I can nurture people in this direction but only again at the expense of turning the education into experience you are never going to do it in a lecture exam format. You have to put people in a lab and have to do it over and over and over again.
Brian: I remember Charlie Parker once said of learning to be a master in a different discipline "Learn the patterns and then forget them", and I always used that in our patterns courses, being the gang of four missionary, carrying around the bible of Joshua Kerievsky and Johnson's re-factoring for the last two years. And if you want to get good look at other people that are good, steal the best stuff you can possibly find, be like the guy you really like than find another one and be like that, look at other people's stuff and start to turn that into a style of your own. That is what you got to do.
And to do that you got to get up and play – you got to get out an blow -you got to watch what the next guy is doing, you got to figure out what he is doing right, you got to say "That's cool, I want to be like that". Some of the currents that have run to this community for the last twenty years have encouraged that. Pairing is one of the things that does that, it has the same advantage that sexual reproduction does in the genome, best practices are rapidly disseminated, figuratively because I see him working on something and say "God that is good, what the hell is he doing with this IDE? I didn't want to admit that I didn't know how to do it" because working with them it's "Oh, yes".
Pairing has been one of the surprises for me, when I first heard about it I thought it was totally insane I used to tell people there are two things I absolutely do not want to do in public and one of them was programming because you don't want to screw up in front of people who could be smarter than you it could be a total humiliation. It turns out it doesn't have to be like that but the thing about it is you realize everybody makes the kind of screw ups you do and in the meantime you can say "Dave is good" that's one of the benefits. The other thing a craftsman should master his tools.
And we have got better tools these days. When you write a line of code is not for life anymore because we now have the technology that will allow me to say "Dave put a dumb name on one of those variables let's just replace it all over the place". Re- factoring tools have been one of the things that have enabled people to look seriously at the problem of gentrifying code, of getting it to be better because doing it by hand is possible is much harder work but having the power tools to be able to have that stuff handled quickly and be able to take it to the bank, that's been a major boon. That is another thing that has been a great persistence to this notion of becoming a craftsman. Why don't you pick one?
Dave: There is a corollary idea here that most recently been popularized by Gladwell, with Outliers - and that is the ten thousand hours rule, that you are not a master of anything until you have put in ten thousand hours of practice in doing it. You don't go out and buy a pair of Air Jordan's and all of a sudden do a four-minute hang-time, And that is why he got cut [in high school], he hadn't hit his ten thousand hours in high school or college or whatever it was. And that is ten thousand hours of doing it, not reading about it, listening to it, observing it, it's doing it.
Brian: The nice thing about that book is it makes anyone who has been doing anything for over ten thousand hours feel really good about themselves.
Dave: Let me ask one last, kind of goading, question. Going back to some of the stuff at the beginning about programming being the focus of craft, the profession itself has very little regard for programming. The idea is that we for fifty some years the goal has been to automate the programmer out of programming. Because it seems like a very mechanical kind of thing which it offers zero room for art. There is another school of thought that, while it doesn't denigrate programming, it doesn't see it as being king of the world. That idea is that if you do your design right and I don't mean the big waterfall architecture kind of design, but if you conceptualize your object in the right way, and the community of objects that are doing a task in the right way, then the programming part, the actual writing of methods and variable names becomes trivial.
That instead of having to write this really complicated and grand and masterful and absolutely beautiful, ten thousand lines of code program I can write a hundred lines of code and do the same thing, if I had the right design concept. So I said early when I described my ideal designer, that my ideal craftsman was much more focused on this design. That I can come up with this conceptualization of Mona Lisa and at that point mixing the paints is trivial task. How wrong am I?
Brian: That which a culture glorifies will flourish and I think you are absolutely right, that the culture for some reason doesn't glorify programming. Even in the popular culture we are depicted as the people who bite the heads of chickens, circus performers, that's where that term geek came from, Ozzy Osborne was a geek but no programmer I know bits the heads of chickens, but there is this perception, there is this quirky thing that people who are a little peculiar do. We should probably try to do more to dispel that if people want to persist in thinking about us that way, they should all go back to high school. But beyond that, code when it's good is a literally artifact.
People focus on metrics, but if computer scientists wanted to figure out whether a writer was great they would do something like the importance of Hemingway and they would find out how long his sentences were and what kind of word size did he use, and things of that nature. And if your writing had exactly the same qualities as Hemingway, computer science will call you a good writer and that's all totally beside the point. Our job as programmers is to create literally artifacts that other people like us can consume and be able to cultivate and maintain. All this wondering about that kind of analysis is beside the point. The real test of craftsmanship is "Do you want to live there?" If I built something that looks like a space that you want to come in and inhabit and improve that you want to sustainably develop. And all the rest of this stuff is just people wishing they were back in grad school.
Dave: Is there any Mecca that we would go to, to observe programming craft or software craft? Is there any center of excellence?
Brian: Let's see, I would refer the gentlemen form New Mexico to my previous response regarding the world heritage site, that is the old Xerox Parc. Beyond that there are lots of people out there who are good at it. The closer you can get to them if you get the opportunity to pair with someone that is a little better than you, they may not be household word but just in general that Mecca is around us everywhere really. There are people who are good at this, just seek them out.
Dave: So if Ward would be there we could all trek up to the Rogue River.
Brian: Something like that.