Permanence and Programming as a "craft"

[Hero Zzyzzx]

So, I was recently in a meeting, trying to convince the advisory committee for a set of sites I manage that we should move off of Domino and into mod_perl/MySQL for our web sites. These people are non-technical, and luckily I had one influential person there who understood my vision and was a strong proponent of it.

One thing this proponent said that resonated with me was that I was a “craftsman,” meaning I created sites, cared about them, and understood them. I was flattered, of course, but that also go me thinking: that’s a pretty good description of many perlmonks, I’d say.

When I think craftsman, I think someone who enjoys their craft, is proud of their work, derives satisfaction from it, and someone for whom “work” doesn’t always feel like work. It’s a craft.

I guess I like historical precedents for things: I kind of think of myself as a furniture maker or something.

The only thing that doesn’t carry over is the idea of permanence: you make a table, and it’s there forever.

However, you make a perl script and who knows how long it will last. I guess I’m wondering what effect this lack of permanence behind my “craft” is going to have.

I feel like I’m kind of at a crossroads: do I want to take the perlmonk fork? Will I be satisfied with it ten years from now? I don’t work for money, I work for satisfaction (hence all my jobs have been with non-profits, of course it’s nice to have both, though).

I’m certainly satisfied now, but down the road, will I feel I’ve made a permanent contribution? This may be a question for the older monks here.

[footpad]

Answer Hazy. Ask Again Later

A little more than ten years ago, I had a somewhat similar choice. Fresh out of college, I was vying for entry-level (support) positions with two companies. Company A was local, a market leader in many categories. Company B was one of their fiercest competitors in certain areas and located some place I'd never been before.

I received an offer from Company B while Company A was still dithering about. I had to decide between taking the offer in hand or hoping that a second one would appear. I took it, partly because it existed and partly because it would involve a number of new experiences. (The second offer did come through as I was packing the U-Haul to move to the new location.)

I did well at Company B, moving quickly through the ranks until I had another choice. Accept a promotion into R&D to help develop the product we were working or one into Product Management to help lead that development. I chose the latter. A month later, I was laid off as Company B restructured, in part because they'd not been able to sucessfully compete with Company A. (None of the developers were laid off at that time.)

I was devastated, in part because I'd allowed a lot of my personal sense of self to be wrapped up in the successes I'd enjoyed at Company B.

If I'd waited for and accepted Company A's offer, I would likely have far more money than I do now, for their stock has performed admirably and they've only recently run into certain, well-publicized problems.

In looking back, I stand by my original decision for two main reasons:

1. As many of you know, I have a love for live theatre. While working at Company B, I was able to heavily participate in the local community theatre, doing some thirty shows in 3-1/2 years. I do not believe I would have been allowed to indulge my avocation as heavily had I waited for Company A.

2. Through a bizarre series of coincidences (which I'll spare you the details of) related to Company B and the product I was working on, I met the woman who would later consent to be my wife.

   Without getting overly mushy, I believe she was the right person for me and I do not believe I would have met her if I'd joined Company A. Similarly, I don't believe that I'd have the pleasure of our daughter's presence in my life.

I believe that, as developers, we should take pride in our work and should strive to use craftsmanship as a guiding principle. That said, I also believe that:

• There are more important things in life. In another ten years, some of my work may still exist and some of my code may still be in use, however, what will matter most is how my wife and I raise our child and the difference we make in other people's lives.

• You cannot predict the future. Judge carefully, and make informed decisions, but don't invest a lot of time fretting about possibilities and what might be.

• Unplanned and unexpected things will happen. Do your best to roll with those unplanned surprises. Hope for the best, but prepare for the worst.

• Have backup and restoration strategies, but work on the tasks before you.

• The most enjoyable journeys are those that you allow yourself to enjoy while getting to the destination.

• If you make a mistake; don't stress it. You may be surprised at what happens later.

• Learn from the past; don't dwell on or in it.

In short, be a Monk: Take pride in your work and your accomplishments, but not to the detriment of what really matters.

--f

[michellem]

I'm a younger monk, but I really related to your question. I don't have an answer, but I have my own perspective of this issue.

One thing I have realized is that I have a drive to be creative. I've generally found this fulfilled outside of work, like writing poetry, drumming, and other pursuits. I spent 10 years as an academic, teaching biology, and doing research - a little creative, but not much, which is why I needed the non-work outlets.

I've now spent 2 years doing a lot of programming - primarily in Perl. I'm hoping to move to working 3/4 time as a programmer. I find that I am really happy coding - that I find it a great creative outlet.

Now to the permanence issue. Maybe this is too philosophical, but my perspective is that nothing is permanent. I'm happy if a database I design, or a script I write, gets used by some folks for a while and does some good in the world. (I too, work for non-profits, primarily) That, and the creative juices that get flowing in the process of making the product is enough for me.

[Albannach]

While I agree that we won't be seeing early 21st century CGI scripts on the Antiques Roadshow (though maybe if merlyn would write a column in longhand and sign it... nah!), I certainly like the idea of "craft" (as does the Monastery). To me it implies a blend of utility and art, which seems to me to make best use of all the human abilities. Thought I certainly ridiculed the "artsies" with the rest of my engineering class when I was in school, I now think it is when we apply art to whatever we are doing that we derive maximum personal satisfaction, and as an unintended side-effect we also produce the best work.

As for a permanent contribution, I think you're better to look at the benefits you've given to your employers and society rather than specific cool bits of code. I think many of us (and certainly me) may be destined to be cogs in a great machine, but however depressing I might find that, it is still important to have sturdy and precise cogs if the machine is to achieve its design goals.

Even so, I'm still striving for more, and will be until I die!.

--
I'd like to be able to assign to an luser

[Hero Zzyzzx]

I love the antiques roadshow idea! What about a "code museum?" Does this already exist somewhere? A google search didn't turn up a whole lot.

Could anything be geekier than a code museum? I'd kind of like to look at older code, just to see how far we've come.

[clemburg]

Well, there is The Retrocomputing Museum.

Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com

[Masem]

Well, tables (as furniture) aren't permanent as well; as soon as it starts to show age or wear, it will be replaced, just as perl scripts that don't scale well or keep up with current technologies. It's just that Internet time is much faster than real time, thus, an unchanged perl script might be outdated within 5 years, while a table may take 20.

Another point to consider, to continue your analogy; most furniture makers tend to put their heart into making their table or whatever, and thus while the table may never be used or sold, they feel they've done a good job. With perl scripts, you can also put your heart into making it as good and effective as possible; even if no one but yourself uses it, you've at least tried to offer something.

While 10 years might be questionable (will the Internet be as we know it now?), there is certainly nothing wrong with crafting web sites and script as long as you continue to derive both benefit and enjoyment from it. You just need to keep an open mind and continue to watch as the web continues to evolve, grasping new technologies and experimenting with them, as maybe within 10 years, you'll find yourself not only a perlmonk, but an XMLmonk, an UNIXmonk, and the-next-big-thingmonk. Its' not knowing perl (or any one language) to the point of quoting the standard that will get you a paying job, but knowing how to use one language effectively with other standards or languages. As perl is quite well adapted to staying with the current computer technology, this is an added benefit of using perl compared to other languages.

---

Dr. Michael K. Neylon - [e-mail] || "You've left the lens cap of your mind on again, Pinky" - The Brain

[Fengor]

---

Masem said:
Another point to consider, to continue your analogy; most furniture makers tend to put their heart into making their table or whatever, and thus while the table may never be used or sold, they feel they've done a good job. With perl scripts, you can also put your heart into making it as good and effective as possible; even if no one but yourself uses it, you've at least tried to offer something.

---


and its always a good feeling if u get a programm to work even if its just a little one :)
--
"WHAT CAN THE HARVEST HOPE FOR IF NOT THE CARE OF THE REAPER MAN"
-- Terry Pratchett, "Reaper Man"

[koolade]

Well, tables (as furniture) aren't permanent as well; as soon as it starts to show age or wear, it will be replaced, just as perl scripts that don't scale well or keep up with current technologies.

Even though software is less permanent than other creations (furniture, art, music, etc.) there's another difference--you can continually imporove software. To me, that's even more appealing than permanence. If a carpenter creates a table and looks at it decades from now, there still may be things he/she would change. Furniture styles change, tables get sturdier, etc. (Yeah, you get the drift. The analogy is starting to wear down).

I love working on a piece of software, finishing it, looking at it proudly, then start hacking at it again a while later to make it better. The sky's the limit, and sometimes that's frustrating if you just focus on what you could do, but overall it forces you to continually work at mastering your craft and producing better and better quality work. And you also have the benefit of building on top of an existing work, not always having to start from scratch.

[dws]

One thing this proponent said that resonated with me was that I was a “craftsman,” meaning I created sites, cared about them, and understood them. I was flattered, of course, but that also go me thinking: that’s a pretty good description of many perlmonks, I’d say.

There's a risk to being known as a "Craftsman".

Among peers, being known as a Craftsman is a Very Good Thing. We like to work with people who care about what they do, and who produce good, solid, well-crafted code. Those are the people I want on my team.

Outside of our circle of peers, however, the term can carry very different, sometimes negative, connotations. To the person up the food chain who is funding a project, "craftsman" can be heard as "Oh, no. They're going to burn through cash endlessly polishing instead of delivering a product." This isn't entirely unfair. Lots of projects have been burned one or two programmers who couldn't seem to finish anything, and often times they waived the banner of craftsmanship as a defense. To a higher-up who doesn't have the time or attention span to sort the situation out, this leaves the term "craftsman" tainted.

In my experience, calling oneself a "pragmatic craftsman" defuses the taint. Higher-ups hear "pragmatic" and like it. To them it means good things, like maybe that you can actually finish and ship without running way over budget.

But more than calling yourself pragmatic, you have to be pragmatic, at least when taking someone else's money. It's part of the inner game of Craftsmanship.

[Fengor]

Some others may say that programming is the black art of our time, but in my eyes its a craft. You have so much wonderful possibilitys as a programmer today. But the important part is not how long a programm lasts it is it's inner beauty. The purity of the source the elegant flow of the code, its what good programming is made of.
Personally i'm not yet really good at programming. Most things i do are quick and dirty hacks but i try to learn and while i learn my programs will get more complex and hopefully will once be under the cathedrals of programming ;-)
--
"WHAT CAN THE HARVEST HOPE FOR IF NOT THE CARE OF THE REAPER MAN"
-- Terry Pratchett, "Reaper Man"

[deprecated]

Hi, I wanted to chime in here (though most of the responses thus far have been spot-on with what I am about to say).

First, I currently work for a non profit organization. The difference in the people is pretty significant. One of the things I always disliked about working for commercial entities is the pressure. I have worked for so many companies that have gone under or been bought or been downsized, that an NPO is really where its at if you ask me. It allows me to focus more on what I see are the important things in work, my craft and my co-workers (as friends).

That having been said, I've been in the workforce as an IT guy for six years now. Thats been mostly Unix adminning, with some Mac stuff thrown in. The more perl I learn I find that more people want me to program for them. I recently took the plunge, with ACS, and I am officially (for the first time in my career), a "programmer/analyst" instead of a "senior unix administrator" (or similar). So, Wow!, I get to focus on what is important to me -- my work. I get the same feeling from Unix adminning because I leave quite a legacy. I conceive and implement new servers, I name new machines, I leave shell scripts and config files, and all manner of things all over the place. It is my responsibility to see that those reflect well on me, and that other users (perhaps even those without my skills) are able to use and learn from them.

You don't mention what you're forking from. Presumably since you were in there making that sort of decision, it was also some sort of shoot-from-the-hip programmer/admin type guy. I cant tell you whether you'll be satisfied in ten years. I can tell you, however, that if you take pride in your work, and work for something being done right rather than just being "done", you will be satisfied in ten years.

My father has been a unix admin for 25 years. He, too, works for satisfaction, and he is still satisfied. Funny thing is he was originally a programmer and moved into adminning. But I digress.

I wanted to also let you know that your perception of the programmer as a craftsman is an accurate assessment. There is a book available which makes this very correlary, The Pragmatic Programmer: From Journeyman to Master. Furthermore, before I began work in IT, my life goal was to work in automotive mechanics and engineering. I never stopped looking at myself as somebody who had a craft. I transitioned very easily from somebody who was rebuilding engines to somebody who writes code. Because I can still see and feel my work. I can look at it at the end of the day, or in a month, and take pride in it -- and strive to be better.

At the risk of sounding trite, THAT is why we're all here, when it comes down to it. And that is what makes us craftsmen/masters/whatever. That we strive to be better.</saccharin>

Brother Dep.

--
Laziness, Impatience, Hubris, and Generosity.

[petral]

With software, you "ship the blueprint".

p