robin2's comments

"Influential" can be tricky to pin down, but a couple of books that made a big impact on me at a certain age were "Prometheus Rising" by Robert Anton Wilson and "The Muse in the Machine: computers and creative thought" by David Gelernter. (The latter arguably counts as a technology book, since it's supposed to be about AI, but it's more to do with psychology and literature.)

More recent sorta/kinda philosophy: "The Craftsman" by Richard Sennett; "From Novice to Expert: excellence and power in clinical nursing practice" by Patricia Benner; "The Craft of Thought: meditation, rhetoric, and the making of images, 400-1200" by Mary Carruthers.

I also like to think that "Asterix in Britain" by Goscinny and Uderzo had a formative influence on me...

My guess is that this might be cycling related; that an area where there's likely to be public-spirited cyclists with GPS devices is well placed to get good OSM coverage.

In support of my theory, I point to Cambridge being a little bit of a hotspot in the southeast of England. (Not so much as Clacton though ... hmmm ... maybe the theory needs some work.)

Are you implying that if your only proverb is the one about hammers and nails then everything looks like a problem of misapplied technology?

I can't quite make up my mind whether its irony, or the other half of the same phenomenon, that humanities are feeling pressure to become more business-like whilst businesses are being drawn towards methods from the humanities.

An example of the latter would be the work of ReD Associates. (See, e.g., http://www.theatlantic.com/magazine/archive/2013/03/anthropo..., http://rdn32.com/2014/04/03/the-moment-of-clarity/)

> What makes you say that this was the "original intent" of patents?

The original meaning of the word "patent" might be a bit of a clue here.

The problem that patents tried to solve was of people keeping their innovations secret (in order to maintain an edge on their competitors), and that when they died their secrets died with them. Encouraging people to make public work they were doing anyway way, in the first instance, the way the patent system promoted progress.

Slightly off topic, but Peter Seibel's take on the idea of code reading groups, and the idea of code as literature, is interesting: http://www.gigamonkeys.com/code-reading/

"Code is not literature and we are not readers. Rather, interesting pieces of code are specimens and we are naturalists. So instead of trying to pick out a piece of code and reading it and then discussing it like a bunch of Comp Lit. grad students, I think a better model is for one of us to play the role of a 19th century naturalist returning from a trip to some exotic island to present to the local scientific society a discussion of the crazy beetles they found."

The reason this is off topic is that it sounds like you were after interesting specimens anyway. I don't have any code examples as such, although if algorithms count I'm particularly fond of Tarjan's algorithm for finding strongly connected components in a directed graph, and the Burrows-Wheeler transform (as used in bzip).

TL;DR? See http://www.slideshare.net/vgururao/usc-annenberg (slide 7 in particular)

On a related point, am I the only one who notices the language coming out of the Silicon Valley ecosystem (the war for talent, the need to identify star performers) and is reminded of Malcolm Gladwell's assessment of Enron's corporate culture (http://gladwell.com/the-talent-myth/)?

"Pragmatic Thinking and Learning" was Andy Hunt, but as he and Dave Thomas are kind of a double act I can see why you'd get mixed up.

As to your point about whether they wrote any books on 'agile' I think it could be argued either way. More specifically, whether or not "The Pragmatic Programmer" (the book they made their name with) counts as a book about 'agile' is an interesting question, and one that throws some light on the wider debate.

Although they sometimes talk about "pragmatic programming" as if it were a thing, in the same way as XP and Scrum, their approach was more one of giving a smorgasbord of potentially useful techniques and practices rather than codifying a tightly defined set of best practices.

There was a time when LinkedIn would often require you to re-enter you login details, seemingly at random. Login details consist, of course, of your email address plus a password, and so if you used the site much you kind of got used to entering them in every time they were requested.

The login form, unsurprisingly, looked very similar to the one suggesting that you give LinkedIn your email address plus you email account password. When I first noticed this, I thought that, for people who re-use passwords, this was an accident waiting to happen. I'm sure people must have been caught out by this.

I was very tempted to submit this to darkpatterns.org, but the first part of the pattern (frequent re-authentication) doesn't happen any more.

An odd thing about Alexander's work on pattern languages is that, despite people's enthusiasm, Alexander himself considered it to be a failure. There's a chapter in Richard Gabriel's "Patterns of Software" (http://dreamsongs.org/Files/PatternsOfSoftware.pdf) that has an interesting discussion on this.

It's possibly worth mentioning that the original moon shots were - in a sense - exercises in publicity. OK, that's putting it a bit crudely, but if you read Kennedy's speech announcing the goal of putting a man on the moon (http://www.space.com/11772-president-kennedy-historic-speech...) he emphasizes how impressive a feat this would be, and he frames the whole enterprise in terms of a battle with the Soviets for hearts and minds of mankind.

While I can't say that I'm personally very keen on the whole idea of Google Glass, and I don't know how genuinely innovative these "moon shots" are. But even if they are not particularly innovative at all, I don't think there's anything inherently dubious about Google engaging in publicity for their vision of what the future could be.

[Lightweight comment] The main thing that puts me off from learning Clojure is the name. I mean, why not go the whole hog and call it funargs4j?

For a different take, read Steve Albini's "The Problem with Music" (http://www.negativland.com/news/?page_id=17) in which he does a financial breakdown of what he considered a representative scenario (back whenever it was written):

"The band [...] has made the music industry more than 3 million dollars richer, but is in the hole $14,000 on royalties. The band members have each earned about 1/3 as much as they would working at a 7-11, but they got to ride in a tour bus for a month."

Edit: In light of tptacek's third paragraph, perhaps it's more like a variation on the same take.

I'd have thought http://zedshaw.com/essays/c2i2_hypothesis.html would be more relevant here.

Projects can be canned for all sorts of reasons, but from what I recall the people involved in C3 blamed the Chrysler management. Perhaps the latter were more interested in having a working payroll system than inventing the future of software development.

One of the criticisms I remember some people making of XP when it first came to prominence was that it shifted a lot of the hard work of software development onto the customer, or rather the customer representative; certainly, ever since I heard about what happened to the first XP customer representative (see http://www.coldewey.com/publikationen/conferences/oopsla2001...) I've taken comments about XP being a humane methodology with a pinch of salt.

OK. Here goes nothing.

I had a conversation with someone I know about what I wrote, and why I wrote it. Their comment was that without giving any explanation as to why I wrote what I did, the whole thing just comes across as arrogant and mean spirited. I think it's worse than that: the cumulative effect of a number of different remarks, that I had thought of as distinct, is one of a sustained, vindictive attack on the whole Martin clan and the horse they rode in on. Now, I could say "that wasn't my intention", but it doesn't matter very much what my intention was: how it comes across is how it comes across, and for that I can only apologize.

More specifically, I have absolutely no reason to doubt that both Martins have lots of genuinely satisfied customers. Also, with regard to the thread I linked to, now that I've done a spot of freelance consulting myself (even introducing the concept of unit testing to a client) I'd say that "consultancy" is a fairly broad concept. I'm still uncomfortable about the "hired gun" aspect of it, but I now know enough about that world to know that I know very little, and so shouldn't be making sweeping statements about it.

I'm aware that what I wrote shows me in a bad light. I could trying to clarify points badly explained, dispel unintended implications, and backtrack on exaggerations and plain mistakes. But I won't. The light is going to get worse in two paragraphs' time.

[Incidentally, you know when someone says "I'm sorry, but..." and you think to yourself "That's not really an apology"? I'm about to do something like that. I'm sorry. But I'll try to redeem myself in some other way later on.]

Mr Martin said that my tone was virulent. Even allowing for my not having explained myself very well (or at all) this is certainly true. I didn't notice at first how much anger there was behind it. It took me by surprise. What's behind the anger? What's always behind anger: pain. For some reason, something hit me in a really, really sore spot. Even though on the internet no-one can hear you scream, they can read the stupid things you write in the heat of the moment. So, yeah, there's a large element of lashing out here: but if I elaborate a little bit, perhaps some relevance to the matter in hand might become apparent.

Here's a key bit of context: the other year I was on a project in which I may have made mistakes that put lives in danger.

When I say "may" I don't doubt that I made mistakes. The nature of the work, the poor usability of the tools being used, meant that even a momentary lapse in concentration could easily result in a slip which would either go undetected or necessitate time-consuming rework. Problems tended to snowball. It would have been difficult work, even if it weren't being done in a noisy office. My uncertainty regards the extent to which the data we were dealing with was safety critical, and how much further scrutiny it would be subject to: I heard different things from different people, and don't know who to believe. (The truth can be a complex thing to unravel, even without people acting to cover their backs or to save face.)

The real mistake I made, however, came long before, and isn't one that can be easily blamed on circumstances. For a long period before I had become fatalist, and for the sake of a quiet life I'd been too cowardly to push back against things that I could see were wrong. It got to the point where it just seemed par for the course that I ended up with a computer that seized up on a daily basis.

Extreme stress is an interesting experience, although one that's probably best enjoyed when you're not doing anything important at the time. (Mind you, the warnings you get on packs of beta blockers are scary, especially for an asthmatic like me.) A complicating factor at this time was a bout of naive optimism: that if everyone were less coy about problems at work then it would be possible to tackle the root causes, that one should be the change one wishes to see, etc. Crazy, I know. Anyway, I fear I'm digressing.

I'm trying to bring this around to my first beef with Mr Martin, which isn't really a beef with Mr Martin so much as the habit of devaluing "home grown" knowledge in favour of that which is "bought in" (books, training courses, certification, even blog posts). The thing is that, as far as I can work out, some lessons have to be learned the hard way: even when a piece of second-hand wisdom is true, it does no good without a visceral understanding as to why it is true. There's not much point in a company being well informed about good practice if it then says, in effect: "none of the software for this project is being delivered to the customer, therefore the normal principles of software engineering don't apply."

The other thing I wanted to say about bought in knowledge is that there is always more to be had, and always someone trying to sell it. (At times it can seem akin to the situation with theories in social psychology, as described by Michael Billig when he said that "psychologists treat theories like toothbrushes: no one would wish to use someone else's.") In my experience, constantly chopping and changing the ways things are done, in pursuit of some best way, can be enormously destructive. Much better to have a reasonably good way, and stick to it, perhaps tweaking it now and again in the light of experience. Apart from anything else, tacit knowledge gets embedded in the way things are done, and can only really be picked up through doing: its "knowing how" rather than "knowing that", skill rather than information.

This sort of brings me on to why I didn't address Mr Martin's essay. The reason was that it seemed rather lightweight: the diagnosis was, as far as I could see, that if people didn't sufficiently value software development expertise then it was because no-one had pointed out to them that software development is a skilled activity and that the skills can't be acquired instantly. Surely, I thought, it is too obvious to be worth saying. Moreover, when someone says something to obvious to be worth saying, surely they must have an ulterior motive. Hence, in my ire, I assumed Mr Martin must be trotting out easy pieces as a form of self-promotion.

The are a number of grounds for saying that this was stupid of me, but one of them is that what Mr Martin said wasn't, in fact, too obvious to be worth saying. Sometimes things are worth saying even when they are obvious: what is obvious to one person isn't obvious to others. Moreover, I should have known this from my own experience. (There is a software company I know where the - now retired - HR manager said that "technical competencies" were relatively unimportant, as anything technical could be picked up on a short training course.)

Hmmm... I had a bunch more stuff to say, addressing various other aspects of what I said, going into stuff like the nature of reputation, disappointment as a function of exception, and whatnot. But I've rather run out of steam - which is probably for the best. Perhaps at this point I should attempt to make good on my promise to redeem myself by making a more substantive contribution to the debate. (Yes, I know no-one's going to read it, so it doesn't really count as a contribution. Humour me.)

Oh, hang on. I've just discovered the limit on comment length.

[Part II]

In another comment, Mr Martin suggests that something like a guild system might be an appropriate for software development, and I'm assuming that 8th Light's interest in apprenticeship reflects this line of thinking. This sort of talk is interesting, but runs the risk of sliding toward sub William Morris sentimentality, which would be a shame. As it happens, I know a small amount of economic history that might possibly be helpful.

It's fairly obvious that the sort of industrial capitalism exemplified by, say, a 19th Century Lancashire cotton mill doesn't apply very well to software development. The capital costs involved in doing software development can, in extreme, be merely those of a laptop computer and an internet connection. This, I suspect, is what encourages the "rock star" model, which says that if you have some modicum of programming skill, the right idea, the right attitude and a bit of luck, then you too could become rich beyond the dreams of avarice. (See also http://quantumprogress.files.wordpress.com/2011/06/screen-sh...) Whilst I don't personally find this terribly attractive, is has a certain amount of logic to it.

Similarly, if we are to look to an earlier model - master craftsmen and apprentices - then we should look at the forces at play, rather than just the image.

One thing to understand about a traditional apprenticeship is that it was a serious commitment. As I recall, a typical period of indenture was seven years. Some of the reasons were economic; I'll give a couple of them.

One reason not to rush towards the status of master craftsman was that obtaining that obtaining the tools of ones trade could itself take a very long time. As I recall, the most extreme example of this was with blacksmiths, who would typically have to wait to inherit the equipment they needed.

Another reason for the length of indenture was to do with the fact that an apprentice wasn't an employee, and wasn't paid for his labour, but that the master had an obligation to house and feed him. So the cost of the apprentice's labour stayed the same, even though the value of the labour increased as the apprentice gained in experience. Hence it was, in this respect, in the masters' self-interest to have the indenture last a long time.

Both the points I've just mentioned suggest a disanalogy more than anything else, and don't really do much to illuminate the contemporary situation. I've got a final point which I think is more telling.

As I said, an apprentice wasn't an employee, and an indenture agreement was a mutual bond that carried obligations quite unlike those of a modern employer/employee relation. One of these was that a master couldn't let apprentices go when there wasn't sufficient revenue-generating work to keep them occupied. Even in lean years, a master was still responsible for the apprentices' keep, and they might be kept busy with, e.g., building up inventory in anticipation of future need. (This is, incidentally, one reason given for the decline of this system: masters preferred the flexibility of having hired hands that they only paid for when they needed them.)

This contrasts very strongly with a modern corporation that has an obsession with every quarter's bottom line, and a hire-and-fire attitude towards its employees. Quite apart from the effect of this on morale, it potentially impacts skill acquisition: it is a dicey proposition for an employee to invest in skills that tie them to their current employers since they never know when they might have to look for something new.

I don't how the tension between the requirements of craft and commercial reality can best be resolved. I don't know if it can be resolved at all. That's OK. Open questions are the interesting ones.

Anyway, I've said my thing now. Over and out.

OK, challenge accepted. I've only just noticed that this thread continued, and to be honest I doubt anyone will read this - but seeing as Mr Martin's responses aren't unreasonable I think they deserve an answer. I'll have to collect my thoughts, so more later...

That's why they don't need to slander you - writing a lukewarm reference does the same job.

Well, ObjectMentor got paid, someone at the company got to tick a box to say that developers had been given appropriate training, and we got a break from real work.

Corporate training is an odd business, it has to be said.