Pipe hidden behind the wall still has to be beautiful in relative to how the plumber have to work with it. If some plumber hide pipe behind the wall in a way that makes any maintenance impossible, then it's probably "ugly" for plumber standard.
Even if he is, to continue the analogy, people will care how well arranged and maintained those pipes are as soon as they have a problem with the plumbing and have to call a plumber.
A messy unfathomable array of pipes will cause the plumber to spend more time fixing the problem and will cost the customer more.
A well arranged, "documented" set of plumbing will help a good plumber spend less time performing the maintenance lowering the long-term cost of ownership of the plumbing. Not only that, it's more likely to work correctly the first time. Instead of spending weeks calling out plumbers to figure out why no hot water is coming from the bathroom taps, etc.
Of course they care, but they are also willing to compromise with an over bent towards getting the job done. At least observing my dad and grandfather who have been in the plumbing industry their entire adult lives.
Software Craftsman, on average, trend towards the code is the ultimate goal and/or product. The job WILL NOT get done if they don't like how the code will be written. They've swung the pendulum too far in the opposite direction.
Ultimately, its a give and take between the business and software. In fact, this holds true FOR ANY DEPARTMENT in a business. Marketing I'm sure feels some of the same feelings development do, as does UX, as does finance, as does sales, etc.
I am truly disgusted by the "on average" behavior and attitude that accompanies most "software craftsman".
My grandfather, who is a master by rank in the union, always told me, "there is no 'right' way. It's a matter of communicating and balancing the trade-offs".
Also, I would prefer to employ a plumber who runs a nice clean length of piping in the loft and fastens it down properly, or who explains that they'd recommend an approach that's a bit more expensive because it's more long term reliable, and so on. This kind of thing is a sign that they actually care about what they're doing, and suggests that they're less likely to, for instance, forget to actually properly complete a connection so that the next person who bangs into that pipe causes it to break apart and flood the place. [That last happened to my parents the other month.]
He is analogizing the fact that pipes are usually inaccessible behind walls, much like code is inaccessible from the executable standpoint. People running programs don't know what is going on underneath, generally. The same holds true for the average person turning on the hot water at their sink.
I hear ya. It's all about balancing short term vs long term.
My general reaction to Craftsmanship is they pull toward an equally unhealthy end of the spectrum. Only focusing on quality is equally as bad as never focusing on quality.
I don't think we admire good engineering because it has some "aesthetic" merits. It's beautiful because it fits its purpose.
Planes are beautiful, but if they looked differently, they wouldn't be able to fly. Cheetahs are beautiful, but every feature in their body has been designed by nature to make the fastest animal on earth.
I think it's the same with software engineering. We don't think a program is "beautiful" because the author decided to use that particular algorithm or fancy data structure, it's because this algorithm or data structure allows them to solve the problem at hand correctly and within imposed limitations on resources. It fits nicely with the overall purpose.
My remarks here: http://news.ycombinator.com/item?id=4906217 probably should have been posted as a reply to this comment, which is what inspired it. The rest of the remarks here make mine seem out of context, but there were a lot fewer remarks at the time I started my reply.
I remember seeing a shift in CS student populations, say around 1999, from people who already had a self-developed interest in computing to people who wanted to learn programming as a trade to make money. The first group had probably taught themselves programming and had already been tinkering with system internals and hardware. They were programming because they were drawn to it for whatever reasons.
I think the author of this piece is from the latter group. To that group, software as craft just doesn't fit into their world. Whereas I think the first group has an understanding that beauty on the inside of a program shows on the outside too, especially over time.
It's the same in a lot of technical fields. In my mechanical engineering courses there was a minority who truly loved everything to do with machines. The people who work on their car at weekends or build projects in their spare time. They were truly excited just to be able to do what they loved and get paid for it.
The majority though are people who have some affinity for maths and sciences and have made a career choice to study engineering. They put in the hours to do the coursework, but if it's not proscribed in the course they simply won't do it. They go home and don't think about engineering at all. Big companies are full of these people, chugging away at their job but not particularly interested in spending their spare time honing their skills or working on other stuff because it's actually pretty awesome.
I'd also argue that it's also art, just with a smaller target audience. Open source software is a great example of this. A lot of open source projects are really just experiments in expressing an idea in a new way, or basically saying, "hey guys, check out this cool thing I did." _why was the trademark example of taking this concept and constructing an entire persona around it, but art is about expression, and programming allows for some interesting forms of expression.
Just like it takes a little training to appreciate the intricacies involved in the construction of a piece of literature, classical music, painting, or other work, it takes training to appreciate beautiful software.
Code is just a much newer canvas for ideas, so it's not as mature.
Art is a poor metaphor for software. A bad painting just looks ugly. It doesn't hurt anyone.
A better metaphor is a block of Legos, but where none of the pieces fit together well and 2/3 of them are of such poor quality as to make them almost worthless and, worse yet, you can't choose not to use them because the people setting requirements don't know or care about block quality and "just want it to work".
I'm experienced both in software and creative writing. I've read (and written) some awful short stories and poems. Bad writing is embarrassing. Bad software is a much higher dimension of evil. Bad code kills businesses.
So the question could be rephrased to a better analogy: is architecture art? A faulty building can kill people, but buildings can be expressions of ideas. In other words, there is a utilitarian form of architecture, which involves making the most efficient/simple/effective solution to a problem. But there's also the side that produces iconic and truly beautiful buildings for no other purpose than beauty.
Software is just a medium. A small subset can be thought of as art, just like a small subset of paint jobs, constructions (in the broadest sense possible), and sounds sound can.
Hackety.org is for artful computer hacking. Mind expanding code.
Hobbyists & amateurs welcome. Business trends and language wars?
None for us, thankyou!
[More](http://viewsourcecode.org/why/hackety.org/about/)
You're falling on the same mistake as the original author, that craft implies art.
Craft is about applying creativity and skill and produce some product. Art is about expression, it doesn't have to solve a problem, and can come to life using any medium, software included.
So we could said while all software is craft, some software is art.
I think a lot of these discussions -- Programming is/isn't Engineering/Math/Science/Craft/etc... -- suffer from what I call "the moon is like an onion" problem. The moon is like an onion. This is obvious! After all, both are whitish, more or less spherical, have layers, and on occasion, drive men to tears. And yet, of course, the moon is not exactly an onion. It differs from onions in other obvious characteristics.
You can play this game with anything. Programming is like engineering. It's like math. And yet it's not exactly engineering, or math, or a craft or a trade or anything. People find one attribute where the metaphor fails and go "Aha! Programming is not X!" Let's step away from the "find the perfect metaphor" game for a second and ask, which word works in daily discourse? Like you, I'd agree that "craft" works pretty well. It's not perfect, but I'd argue that if you want the perfect word, just use "programming."
Additionally, I find the author's argument that "with a craft, the product has an intrinsic beauty in its own right," rather uncompelling. Aside from the fact in aesthetics, the notion of "intrinsic beauty" is suspect, software can certainly have aesthetic qualities. Their audience (other programmers) may be small, and aesthetics may sometimes[1] be hidden from customers, but that doesn't mean code can't be beautiful.
[1] Sometimes, because poorly crafted software tends to have bugs or other problems that annoy customers or otherwise visibly manifest themselves.
And then the TLDR basically says: "Non-programmers just want programs to work". As if the two are mutually exclusive... as if craftsmanship forbids pragmatism.
I find it interesting that the two examples he gives of "proper professions" are highly regulated guild-like professions whose values are artificially inflated, at least to some degree.
I'm only a very new programmer, but I'm reading Martin Fowler's Refactoring and, even from my limited experience I'm finding that one of the differences between software and other products is that software must be maintainable. So the end user isn't the only end user. Software has to be read and worked on by other programmers in future, and most of the craft involved is not in making a program simply work as it's supposed to, but making the code easy to read, easy to maintain, and easy to modify.
So the aesthetic quality of the code and the craftsmanship involved is very important, for pragmatic and eventually end-user-facing reasons.
But hey, what do I know? I haven't gone to programmer's school or gotten a programmer's license or anything.
> Software craftsmen should be egoless, humble, with a focus on the outcome rather than the code or the process.
That sounds good. But developers aren't like that. We are concerned about getting the job done in a way that promotes our career and/or keeps us from getting fired, well- most of the time.
> I also think there should be a way for passionate, skilled programmers to differentiate themselves from the mainstream commodity bodies, and also to recognise one another, and demonstrate their value to potential employers. What could that be, and how could we make it work?
These are called certifications, and their value has diminished. Here's why:
Many of us survive by Google searching, using stackoverflow and better documented frameworks. And, there still aren't enough of us. Many of us feel we are overpaid, but most would never admit it.
By deciding on a way to determine who is proficient and who isn't, you risk a lot of people not being able to find work, and for what goal? Right now programming is an art. If you make it into a trade with the federal, state, or county regulations saying that the developer must be qualified in X, and they have tests for X (that become irrelevant daily), then you are going to (1) eliminate a lot of developers from the workforce and (2) stagnate the art because right now it develops at a faster pace than any of us can keep up with.
"Many of us feel we are overpaid, but most would never admit it."
Really? I've always felt underpaid. Most business owners don't understand software or deadlines and me (and my developer co-workers) have always had to suffer as a result of this by working insane hours for weeks at a time to get things done.
But keep thinking this way. It will only help me when I need to hire developers for my own business.
I look out for myself. My salary is a lot better than my experience level for what I do.
I'm talking about guilt. I have done this for many years now and I see people that work harder than I do each day with more skill to make much less salarywise. And it isn't just me.
I think a lot of what we get paid for is the ability to adapt and endure not knowing how to do what we do when it changes all the time.
BTW- those running their own business often are in the lower income bracket, which is why I haven't made that jump yet. More power to ya.
I think the sentence before the one you quoted clears things up:
>> Many of us survive by Google searching, using stackoverflow and better documented frameworks. And, there still aren't enough of us. Many of us feel we are overpaid, but most would never admit it.
If you're shipping real software for real businesses that weaves a half-dozen technologies together in a way that none of the business guys knew was even possible, and you proposed and executed on the idea.
If you're in a large corporation working 40 hours a week, always clocking out at five, and there are no consequences for dates slipping, then yeah, I could maybe understand feeling overpaid.
But if I'm building the systems that make the business? The business could not operate without this software? About to make 5 salaried employees 1.4x productive? Yes, I'll charge a lot, and yes, I'm worth every penny.
That timer is long expired. This article (which uses "craft" as a synonym for "art") directly opposes Knuth's [1] from 1974 -- I'll let you guess which one carries more weight.
Does he really think this sort of invisibility just happens?
A road goes over a bridge so smoothly that drivers don't notice the bridge. The result of the bridge-builder refraining from decoration? Mostly the result of the bridge-builder very, very carefully lining things up. With a level of planning-time rarely seen in the software world.
Non-craftedness is just a style, one that only the most skilled craftspeople can achieve.
I think of it like this, Craftsmanship is about having the discipline to dot 'i's and cross 't's. It's about scrubbing out the pans after your done cooking a meal, because while you might be able to keep reusing a skillet without cleaning it to produce delicious meal after delicious meal quickly, eventually, you're going to send a customer to the hospital.
Keeping code in small readable chunks that have automated tests makes it easier to maintain and if this hasn't been your experience then I would say you haven't been doing it correctly.
The cathedral example does not work. The author clearly explains how the aesthetic of a cathedral helps put people in the right reverent frame of mind to worship, which is the action they are there to perform, then dismisses that beauty as not functional, as mere aesthetic. It seems clear to me if the design helps them get in the right frame if mind, it is functional. Furthermore, historically, the point of stained glass windows was to share some of the stories of the bible with a largely illiterate population. Again, it was beautiful but not merely decorative. The art of the cathedral had purpose and function.
I have a Certifucate in GIS. The mapmaking class I took emphasized the fact that a good map -- one well designed for its intended purpose of efficiently conveying information -- will be perceived as "beautiful" in much the same way that good engineering is typically perceived as aesthetically appealling but a beautiful map is not necessarily a good map. In organizations where GIS is not well integrated, you wind up with "map shops" who are not involved in any really important part of collecting the data or using it. Their only role is to make maps for the people who do use the data. Map shops inevitably become obsessed with making beautiful maps, to the point where embellishment may well interfere with effective use of the map.
I have come to believe that beauty (of all kinds) is valued because it is a qick and dirty proxy for real value since things which are well designed seem to universally have visual appeal. Therefore, if it is not aesthetically appealling, it probably is not really all that good in terms of quality. I think beauty then also gets routinely maligned because it can be a quick and dirty means to fake value, to falsely signal value, when it doesn't really exist. I think this conflict will never be resolved because both things will remain true. We will continue to remark with awe and wonder on the "beauty" of high quality work and continue to deride low quality work which tries to cover up its defects by slathering it in prettiness.
For those adequately in the know to understand the code, there will continue to be people who talk about programming in terms of "beauty". For those not in the know, it is too abstract to "see" the beauty of it.
This is a fantastic title, right up there with 'Dynamic typing is 1000x better than static typing' and 'Tabs vs Spaces: winner spaces'.
It really just leaves us arguing the finer points of what the definition of craft is. Could you argue that knitting isn't really a craft as most people just want sweaters that work over sweaters that show some amount of professional craftsmanship quality? What about coffee tables since Wal-Mart sells cheap coffee tables and people generally own cheap coffee tables that must mean that woodworking isn't a craft.
ugh... we may as well argue the merits of calling something 'Art' with one side holding firmly to the position of since I consider it art it therefore becomes art because art becomes art once someone identifies it as art.
As for the artistic nature of code I'm reminded of reading someone's quote years ago "On a whim one afternoon I decided to browse the source-code for Nethack. I looked at it, and it looked back at me, and I was afraid"
Code beauty is different from aesthetic beauty (e.g. cathedral). Code should be straightforward and almost boring. You don't need to start complex; it will come to you. Complexity should come from the problem being solved. Self-modifying code is "fun" and also completely unmaintainable. Same with code that uses a lot of inheritance (except in GUIs, where inheritance is a natural fit). It might be "fun" to write but it's hideous to maintain. It's better to point that creativity in the direction of clean code that teaches other people how to use it and how the problem is solved.
Code aesthetics cannot be compromised, but code beauty doesn't mean complexity or adornment. It means functional simplicity and ease of learning. It should trigger the, "Why didn't I see this problem so simply?" reflex.
A really great programmer (and I’ve been lucky enough to work with a handful over the years) can out-perform a doing-it-for-the-money programmer by orders of literally hundreds, delivering in hours or days what would take an average developer weeks or months.
True, if that great programmer doesn't have meetings or interruptions, get to choose her tools, and has full autonomy in how she does her work.
I used to think that mediocre "day-jobbers" (to borrow a word from the OP) made the crappy corporate software environment and bad software. I now am pretty sure that it's the reverse. The corporate world limits people and turns them into day-jobbers. You have to be constitutionally insubordinate in order protect your creativity through the grunt-work 20s and not a lot of people have the nerve to deal with the result of that (e.g. frequent job changes).
This is compounded by the fact that the people who climb the corporate ladder tend rarely to be of that insubordinate type. After 15-25 years, they're finally in positions that would use that creativity... and don't have it anymore; it's gone forever.
Carpentry craftsmanship risks putting the furniture at the centre rather than the benefit the furniture is supposed to deliver, mostly because we are romantics with big egos. Carpentry is about having a place to sit, a place to put your coffee cup, and a place to store things that fits in with the client's desired style and other requirements.
Non-carpenters don’t care about the aesthetics of joinery in the same way non-plumbers don’t care about the aesthetics of plumbing – they just want their furniture to support their weight and drawers to not stick.
End of parody. If software isn't craftsmanship, then the only reasonable alternative is that it's a branch of engineering, but most software is developed in an environment and via a process that is much more like a customer furniture maker's shop than a proper engineer.
It looks like what he actually wanted to argue was something more like "we should learn lessons from other more developed craft professions" but I didn't read beyond the link bait title and inflammatory introduction.
>It would be great if programming were a proper profession, but it isn’t. A profession has a structured model for advancing [...] We need some sort of apprenticeship model, and a way to identify masters, both to apprentices and other masters.
Bullshit. It is precisely because programming is not straitjacketed in such medieval rigidities that it can create so much value these days. Forcing today's youngsters, who may be like Gates, Zuckerberg or the Collison brothers, into an X-years long "apprenticeship" program before anyone takes their code seriously is a spectacularly bad idea.
1. Anyone can write code. 14 years old? No school? Fine. Doesn't matter. If it's good, people will voluntarily use it. Absolutely anyone can write code, and if it's good, people will use and pay for it.
2. No manager can make me read your code as a requirement of my job unless you've proven (by certification) yourself to be at a level where less than 5% of professional programmers currently are.
>No manager can make me read your code as a requirement of my job unless you've proven (by certification) yourself to be at a level where less than 5% of professional programmers currently are
You mean if you were hired by Facebook in '04 you'd have refused to read their source code?
Well, that certification that I'm talking about doesn't exist right now, so... we kind of have to guess. No one can get away with saying, "I won't read crap code" and remain employed, but that problem is exactly what I'd like to see some professionalism to fix. I am fucking sick of bad code.
To answer more directly, I'm not good at picking startups (0 for 2) and I doubt I would have foreseen Facebook's success. I didn't, although maybe if I knew the company better I'd have been more of a believer. My general answer is: No, I wouldn't take a startup job where the bulk of my time would be spent reading other peoples' code, unless the code quality were extremely high.
I don't think a cert is the answer to your problem. Because then a large % of people would study and pay just to get the cert and continue to write crap code anyway. Meanwhile a certain % of other people who can't/don't want to get the cert will continue writing beautiful code.
If you're concerned about filtering out people who write ugly, hard-to-maintain code, how about more portfolio-based hiring? Want a programming job? Show me an impressive piece of source code you've written, and explain what design patterns you employed and how it is an elegant and maintainable solution to the problem it was written to solve.
No manager can make you read code as it is. There is said to be an unprecedented shortage of developers. It is easy to walk to another company who has code that aligns with your beliefs.
I don't see anything wrong with companies that want to have bad code. They'll probably suffer for it, but that's not your or my problem.
I'm not talking about "me" here, except rhetorically. Yes, I can walk away from bad code (although I might be walking into worse code). I don't think a junior developer in Iowa City can.
What I'd like is a world where as few people as possible deal with bad code, and no one is stuck with no other options, because bad code tends to beget more bad code, and because it's wasting time that could be spent writing a bunch of new good code.
The evil of bad code isn't that unskillful code exists. The problem is that there are plenty of managers out there who don't know any better and will insist that people use it, and who never learned the processes that lead to good code (most important: keep program size small.)
Also, my experience is that over 90% of corporate code is absolutely terrible-- unusably, mind-stoppingly awful. Rolling the dice doesn't have the best odds.
> Also, my experience is that over 90% of corporate code is absolutely terrible-
Which is kind of funny because those are the businesses who rely most heavily on vetting done through colleges and universities. They have, on paper, the very best programers available. I guess that goes to show how poorly credentialing actually works in the real world.
+1. You win this one. At least, we haven't shown that we have the machinery to build a useful credentialing system for software quality.
I think the pain of what we do in the software industry, from the low respect to the bad code, goes back to the fact that our work is extremely difficult to measure, although the importance of quality could not be higher. Corporations have traditionally responded with a 3-4 year bug-fixing evaluative spell, but that's now leading to adverse selection because people like us (as you noted) won't stand for it.
It really strongly depends on what you're writing. There's a world of difference between hacking together a social networking web app and building software for a flight guidance system.
Professional accreditation and training may well be wasted on social web app coders, but I sure wouldn't want to fly in an airplane that was controlled by a weekend hacking project written by someone who just learned their first programming language the day before...
Programming is one of the few fields left where measures of productivity, utility, and value have not yet been fully usurped by the more arbitrary measures of popularity and seniority. You can judge a programmer by the quality and quantity of the product he/she produces, so you don't need to do it by arbitrary social rank.
In other professions where an individual's marginal product of labor is much more difficult to measure or is averaged together with that of everyone else in the organization, ranking people based on these extraneous social factors becomes necessary, but with programmers it is unnecessary and even harmful because the incentive structure becomes biased toward factors other than programming productivity.
Anyone who chooses to use "TL;DR" at the start of an article where professionals put "Abstract" or "Synopsis" (or, God forbid, "Introduction") is, whilst not necessarily a posing hipster, at least subverting their own credibility.
Although it's true that people want programs for their functionality, not their beauty, there is a reason why it's a good idea to focus on the "beauty" of the program that lies beneath the functionality, and that's because unlike bridges, which rarely need to change once they are built, programs often do need to be improved and modified after the 1.0 release.
More importantly, other people will need to be able to revise and extend upon your work, and if it is easy for other programmers to understand your code, and be able to work on your code, this makes your code far more valuable in a way that might not be visible to a customer who is only interested in the functionality.
Now, there may be cases where this doesn't matter. If it's a startup where it's not even clear whether you're going to get the next round of funding, maybe taking the time to invest in making your software more maintainable doesn't matter; letting technical debt build up might be acceptable.
But there is a reason why open source projects care very much about the underlying quality of the code from an aesthetics point of view, and that's because we need to worry about the long-term maintainability of the code after we accept a code contribution. Even if the startup goes belly up, you can reuse open source code. Proprietary code is much less likely to be reused, and besides, once the startup fails and you are fired and the assets get sold off, why would you care about how maintainable the code will be? It's very unlikely you'll ever get the chance to work on it again....
But in the case of open source code, caring about the craft of writing good, maintainable, elegant, easy-to-understand code is important. And in that way, I do respect programmers who respect their work as if it were a craft.
There are two kind of "technical" people. The "Science" kind, and the "engineering" kind. If you appreciate the "beauty" of an mathematical equation, or the "elegance" of a proof, you are the "Science" kind. If you appreciate the preciseness of a tool, or speed to achieve a task, you are the "Engineering" kind. Science provide the backbone behind engineering, but engineering re-invigorates science.
Unfortunately, programming can fall into either categories. Argument like this is mostly pointless without a specific context. As a programmer, it is a life long effort to find the "zen" of the two.
> So here’s my concern with the idea of Software Craftsmanship. It’s at risk of letting programmers’ egos run riot. And when that happens… well, the last time they went really nuts we got Web Services, before that J2EE.
I'm pretty sure it wasn't programming craftsman that created J2EE, but rather the programming tradesmen that this guy seems to be glorifying.
There is an internal property of a software system wherein it is better suited to accomodate the future (new requirements, change). Better suited means it can accomodate the future more efficiently and stably.
Two software systems may delight the customer, for example, but one could be far better positioned to evolve, grow, delight future customers and more customers.
The ability to create such systems lies with some not all and usually comes with experience.
60 comments
[ 3.7 ms ] story [ 136 ms ] threadOf course they do. Nobody wants crooked pipes in their house, or pipes visible where they need not be.
A messy unfathomable array of pipes will cause the plumber to spend more time fixing the problem and will cost the customer more.
A well arranged, "documented" set of plumbing will help a good plumber spend less time performing the maintenance lowering the long-term cost of ownership of the plumbing. Not only that, it's more likely to work correctly the first time. Instead of spending weeks calling out plumbers to figure out why no hot water is coming from the bathroom taps, etc.
Software Craftsman, on average, trend towards the code is the ultimate goal and/or product. The job WILL NOT get done if they don't like how the code will be written. They've swung the pendulum too far in the opposite direction.
Ultimately, its a give and take between the business and software. In fact, this holds true FOR ANY DEPARTMENT in a business. Marketing I'm sure feels some of the same feelings development do, as does UX, as does finance, as does sales, etc.
I am truly disgusted by the "on average" behavior and attitude that accompanies most "software craftsman".
Amazingly, software development is basically in constant renovation mode until the program is put out to pasture.
My general reaction to Craftsmanship is they pull toward an equally unhealthy end of the spectrum. Only focusing on quality is equally as bad as never focusing on quality.
Planes are beautiful, but if they looked differently, they wouldn't be able to fly. Cheetahs are beautiful, but every feature in their body has been designed by nature to make the fastest animal on earth.
I think it's the same with software engineering. We don't think a program is "beautiful" because the author decided to use that particular algorithm or fancy data structure, it's because this algorithm or data structure allows them to solve the problem at hand correctly and within imposed limitations on resources. It fits nicely with the overall purpose.
So, basically, I was agreeing with you.
Thanks
I think the author of this piece is from the latter group. To that group, software as craft just doesn't fit into their world. Whereas I think the first group has an understanding that beauty on the inside of a program shows on the outside too, especially over time.
The majority though are people who have some affinity for maths and sciences and have made a career choice to study engineering. They put in the hours to do the coursework, but if it's not proscribed in the course they simply won't do it. They go home and don't think about engineering at all. Big companies are full of these people, chugging away at their job but not particularly interested in spending their spare time honing their skills or working on other stuff because it's actually pretty awesome.
- It is labor-intensive
- It is creativity taxing
- It produces better results the more skilled the craftsman is
- It can only be learned by practicing
That extends to all professions that can't be automated and benefit from highly-skilled labor. They are all crafts.
The author is just confusing craft and art.
Just like it takes a little training to appreciate the intricacies involved in the construction of a piece of literature, classical music, painting, or other work, it takes training to appreciate beautiful software.
Code is just a much newer canvas for ideas, so it's not as mature.
A better metaphor is a block of Legos, but where none of the pieces fit together well and 2/3 of them are of such poor quality as to make them almost worthless and, worse yet, you can't choose not to use them because the people setting requirements don't know or care about block quality and "just want it to work".
I'm experienced both in software and creative writing. I've read (and written) some awful short stories and poems. Bad writing is embarrassing. Bad software is a much higher dimension of evil. Bad code kills businesses.
http://viewsourcecode.org/why/redhanded/images/hpricot-aby.p...
http://viewsourcecode.org/why/redhanded/images/a-personal-ex...
http://viewsourcecode.org/why/redhanded/images/aside-from-th...
http://viewsourcecode.org/why/redhanded/images/gem-mirror-on...
/!\ /!\ Epilepsy warning: /!\ /!\ http://viewsourcecode.org/why/redhanded/images/irb-lex.gif
Ditto, to a lesser extent: http://viewsourcecode.org/why/hackety.org/images/goa-trance-...
And then, of course, Hackety.org:
http://viewsourcecode.org/why/hackety.org/Craft is about applying creativity and skill and produce some product. Art is about expression, it doesn't have to solve a problem, and can come to life using any medium, software included.
So we could said while all software is craft, some software is art.
You can play this game with anything. Programming is like engineering. It's like math. And yet it's not exactly engineering, or math, or a craft or a trade or anything. People find one attribute where the metaphor fails and go "Aha! Programming is not X!" Let's step away from the "find the perfect metaphor" game for a second and ask, which word works in daily discourse? Like you, I'd agree that "craft" works pretty well. It's not perfect, but I'd argue that if you want the perfect word, just use "programming."
Additionally, I find the author's argument that "with a craft, the product has an intrinsic beauty in its own right," rather uncompelling. Aside from the fact in aesthetics, the notion of "intrinsic beauty" is suspect, software can certainly have aesthetic qualities. Their audience (other programmers) may be small, and aesthetics may sometimes[1] be hidden from customers, but that doesn't mean code can't be beautiful.
[1] Sometimes, because poorly crafted software tends to have bugs or other problems that annoy customers or otherwise visibly manifest themselves.
And then the TLDR basically says: "Non-programmers just want programs to work". As if the two are mutually exclusive... as if craftsmanship forbids pragmatism.
No, just no.
I'm only a very new programmer, but I'm reading Martin Fowler's Refactoring and, even from my limited experience I'm finding that one of the differences between software and other products is that software must be maintainable. So the end user isn't the only end user. Software has to be read and worked on by other programmers in future, and most of the craft involved is not in making a program simply work as it's supposed to, but making the code easy to read, easy to maintain, and easy to modify.
So the aesthetic quality of the code and the craftsmanship involved is very important, for pragmatic and eventually end-user-facing reasons.
But hey, what do I know? I haven't gone to programmer's school or gotten a programmer's license or anything.
That sounds good. But developers aren't like that. We are concerned about getting the job done in a way that promotes our career and/or keeps us from getting fired, well- most of the time.
> I also think there should be a way for passionate, skilled programmers to differentiate themselves from the mainstream commodity bodies, and also to recognise one another, and demonstrate their value to potential employers. What could that be, and how could we make it work?
These are called certifications, and their value has diminished. Here's why:
Many of us survive by Google searching, using stackoverflow and better documented frameworks. And, there still aren't enough of us. Many of us feel we are overpaid, but most would never admit it.
By deciding on a way to determine who is proficient and who isn't, you risk a lot of people not being able to find work, and for what goal? Right now programming is an art. If you make it into a trade with the federal, state, or county regulations saying that the developer must be qualified in X, and they have tests for X (that become irrelevant daily), then you are going to (1) eliminate a lot of developers from the workforce and (2) stagnate the art because right now it develops at a faster pace than any of us can keep up with.
Really? I've always felt underpaid. Most business owners don't understand software or deadlines and me (and my developer co-workers) have always had to suffer as a result of this by working insane hours for weeks at a time to get things done.
But keep thinking this way. It will only help me when I need to hire developers for my own business.
I'm talking about guilt. I have done this for many years now and I see people that work harder than I do each day with more skill to make much less salarywise. And it isn't just me.
I think a lot of what we get paid for is the ability to adapt and endure not knowing how to do what we do when it changes all the time.
BTW- those running their own business often are in the lower income bracket, which is why I haven't made that jump yet. More power to ya.
I think the sentence before the one you quoted clears things up:
>> Many of us survive by Google searching, using stackoverflow and better documented frameworks. And, there still aren't enough of us. Many of us feel we are overpaid, but most would never admit it.
If you're shipping real software for real businesses that weaves a half-dozen technologies together in a way that none of the business guys knew was even possible, and you proposed and executed on the idea.
If you're in a large corporation working 40 hours a week, always clocking out at five, and there are no consequences for dates slipping, then yeah, I could maybe understand feeling overpaid.
But if I'm building the systems that make the business? The business could not operate without this software? About to make 5 salaried employees 1.4x productive? Yes, I'll charge a lot, and yes, I'm worth every penny.
[1] http://www.paulgraham.com/knuth.html
https://www.google.com/search?q=market+cap+apple
A road goes over a bridge so smoothly that drivers don't notice the bridge. The result of the bridge-builder refraining from decoration? Mostly the result of the bridge-builder very, very carefully lining things up. With a level of planning-time rarely seen in the software world.
Non-craftedness is just a style, one that only the most skilled craftspeople can achieve.
Keeping code in small readable chunks that have automated tests makes it easier to maintain and if this hasn't been your experience then I would say you haven't been doing it correctly.
I have a Certifucate in GIS. The mapmaking class I took emphasized the fact that a good map -- one well designed for its intended purpose of efficiently conveying information -- will be perceived as "beautiful" in much the same way that good engineering is typically perceived as aesthetically appealling but a beautiful map is not necessarily a good map. In organizations where GIS is not well integrated, you wind up with "map shops" who are not involved in any really important part of collecting the data or using it. Their only role is to make maps for the people who do use the data. Map shops inevitably become obsessed with making beautiful maps, to the point where embellishment may well interfere with effective use of the map.
I have come to believe that beauty (of all kinds) is valued because it is a qick and dirty proxy for real value since things which are well designed seem to universally have visual appeal. Therefore, if it is not aesthetically appealling, it probably is not really all that good in terms of quality. I think beauty then also gets routinely maligned because it can be a quick and dirty means to fake value, to falsely signal value, when it doesn't really exist. I think this conflict will never be resolved because both things will remain true. We will continue to remark with awe and wonder on the "beauty" of high quality work and continue to deride low quality work which tries to cover up its defects by slathering it in prettiness.
For those adequately in the know to understand the code, there will continue to be people who talk about programming in terms of "beauty". For those not in the know, it is too abstract to "see" the beauty of it.
It really just leaves us arguing the finer points of what the definition of craft is. Could you argue that knitting isn't really a craft as most people just want sweaters that work over sweaters that show some amount of professional craftsmanship quality? What about coffee tables since Wal-Mart sells cheap coffee tables and people generally own cheap coffee tables that must mean that woodworking isn't a craft.
ugh... we may as well argue the merits of calling something 'Art' with one side holding firmly to the position of since I consider it art it therefore becomes art because art becomes art once someone identifies it as art.
As for the artistic nature of code I'm reminded of reading someone's quote years ago "On a whim one afternoon I decided to browse the source-code for Nethack. I looked at it, and it looked back at me, and I was afraid"
Code aesthetics cannot be compromised, but code beauty doesn't mean complexity or adornment. It means functional simplicity and ease of learning. It should trigger the, "Why didn't I see this problem so simply?" reflex.
A really great programmer (and I’ve been lucky enough to work with a handful over the years) can out-perform a doing-it-for-the-money programmer by orders of literally hundreds, delivering in hours or days what would take an average developer weeks or months.
True, if that great programmer doesn't have meetings or interruptions, get to choose her tools, and has full autonomy in how she does her work.
I used to think that mediocre "day-jobbers" (to borrow a word from the OP) made the crappy corporate software environment and bad software. I now am pretty sure that it's the reverse. The corporate world limits people and turns them into day-jobbers. You have to be constitutionally insubordinate in order protect your creativity through the grunt-work 20s and not a lot of people have the nerve to deal with the result of that (e.g. frequent job changes).
This is compounded by the fact that the people who climb the corporate ladder tend rarely to be of that insubordinate type. After 15-25 years, they're finally in positions that would use that creativity... and don't have it anymore; it's gone forever.
Non-carpenters don’t care about the aesthetics of joinery in the same way non-plumbers don’t care about the aesthetics of plumbing – they just want their furniture to support their weight and drawers to not stick.
End of parody. If software isn't craftsmanship, then the only reasonable alternative is that it's a branch of engineering, but most software is developed in an environment and via a process that is much more like a customer furniture maker's shop than a proper engineer.
It looks like what he actually wanted to argue was something more like "we should learn lessons from other more developed craft professions" but I didn't read beyond the link bait title and inflammatory introduction.
Bullshit. It is precisely because programming is not straitjacketed in such medieval rigidities that it can create so much value these days. Forcing today's youngsters, who may be like Gates, Zuckerberg or the Collison brothers, into an X-years long "apprenticeship" program before anyone takes their code seriously is a spectacularly bad idea.
1. Anyone can write code. 14 years old? No school? Fine. Doesn't matter. If it's good, people will voluntarily use it. Absolutely anyone can write code, and if it's good, people will use and pay for it.
2. No manager can make me read your code as a requirement of my job unless you've proven (by certification) yourself to be at a level where less than 5% of professional programmers currently are.
This would work for me.
You mean if you were hired by Facebook in '04 you'd have refused to read their source code?
To answer more directly, I'm not good at picking startups (0 for 2) and I doubt I would have foreseen Facebook's success. I didn't, although maybe if I knew the company better I'd have been more of a believer. My general answer is: No, I wouldn't take a startup job where the bulk of my time would be spent reading other peoples' code, unless the code quality were extremely high.
If you're concerned about filtering out people who write ugly, hard-to-maintain code, how about more portfolio-based hiring? Want a programming job? Show me an impressive piece of source code you've written, and explain what design patterns you employed and how it is an elegant and maintainable solution to the problem it was written to solve.
I don't see anything wrong with companies that want to have bad code. They'll probably suffer for it, but that's not your or my problem.
What I'd like is a world where as few people as possible deal with bad code, and no one is stuck with no other options, because bad code tends to beget more bad code, and because it's wasting time that could be spent writing a bunch of new good code.
The evil of bad code isn't that unskillful code exists. The problem is that there are plenty of managers out there who don't know any better and will insist that people use it, and who never learned the processes that lead to good code (most important: keep program size small.)
Also, my experience is that over 90% of corporate code is absolutely terrible-- unusably, mind-stoppingly awful. Rolling the dice doesn't have the best odds.
Which is kind of funny because those are the businesses who rely most heavily on vetting done through colleges and universities. They have, on paper, the very best programers available. I guess that goes to show how poorly credentialing actually works in the real world.
I think the pain of what we do in the software industry, from the low respect to the bad code, goes back to the fact that our work is extremely difficult to measure, although the importance of quality could not be higher. Corporations have traditionally responded with a 3-4 year bug-fixing evaluative spell, but that's now leading to adverse selection because people like us (as you noted) won't stand for it.
Professional accreditation and training may well be wasted on social web app coders, but I sure wouldn't want to fly in an airplane that was controlled by a weekend hacking project written by someone who just learned their first programming language the day before...
Programming is one of the few fields left where measures of productivity, utility, and value have not yet been fully usurped by the more arbitrary measures of popularity and seniority. You can judge a programmer by the quality and quantity of the product he/she produces, so you don't need to do it by arbitrary social rank.
In other professions where an individual's marginal product of labor is much more difficult to measure or is averaged together with that of everyone else in the organization, ranking people based on these extraneous social factors becomes necessary, but with programmers it is unnecessary and even harmful because the incentive structure becomes biased toward factors other than programming productivity.
More importantly, other people will need to be able to revise and extend upon your work, and if it is easy for other programmers to understand your code, and be able to work on your code, this makes your code far more valuable in a way that might not be visible to a customer who is only interested in the functionality.
Now, there may be cases where this doesn't matter. If it's a startup where it's not even clear whether you're going to get the next round of funding, maybe taking the time to invest in making your software more maintainable doesn't matter; letting technical debt build up might be acceptable.
But there is a reason why open source projects care very much about the underlying quality of the code from an aesthetics point of view, and that's because we need to worry about the long-term maintainability of the code after we accept a code contribution. Even if the startup goes belly up, you can reuse open source code. Proprietary code is much less likely to be reused, and besides, once the startup fails and you are fired and the assets get sold off, why would you care about how maintainable the code will be? It's very unlikely you'll ever get the chance to work on it again....
But in the case of open source code, caring about the craft of writing good, maintainable, elegant, easy-to-understand code is important. And in that way, I do respect programmers who respect their work as if it were a craft.
I'm pretty sure it wasn't programming craftsman that created J2EE, but rather the programming tradesmen that this guy seems to be glorifying.
Repeat after me: you are a computer programmer.
Two software systems may delight the customer, for example, but one could be far better positioned to evolve, grow, delight future customers and more customers.
The ability to create such systems lies with some not all and usually comes with experience.
What is this ability called, if not craftmanship?