This reminded me of something written by noted surgeon (and Rhodes Scholar and MacArthur Fellow) Atul Gawande [0]:
<blockquote>
If medicine is a craft, then you focus on teaching obstetricians to acquire a set of artisanal skills—the Woods corkscrew maneuver … , the Lovset maneuver …, the feel of a forceps for a baby whose head is too big. … You accept that things will not always work out in everyone’s hands.
But if medicine is an industry, responsible for the safest possible delivery of some four million babies a year in the United States alone, then a new understanding is required. The focus shifts. You seek reliability.
You begin to wonder whether forty-two thousand obstetricians in the Unites [sic] States could really safely master all those techniques. You notice the steady reports of terrible forceps injuries to babies and mothers, despite all the training that clinicians received.
After Apgar, obstetricians decided they needed a simpler, more predictable way to intervene when a laboring mother ran into trouble. They found it in the Cesarean section.
</blockquote>
Atul Gawande, Better: A Surgeon’s Notes on Performance, at 192 (Henry Holt & Co. 2007) (emphasis and extra paragraphing added).
I was expecting an article focussing on how making software is not engineering said to myself, "not this again."
But the article isn't arguing that, the article seems to be arguing we are something more than engineers.
There is a subtle implication that engineers are hyper pragmatic and the only thing that is important is that it works. My wife who is a biomedical engineer and makes robots might disagree. In fact, I don't know many good engineers of any kind that stop at "just working."
I think this artisan argument could also be applied to other types of engineering as well.
However, the title is slightly off, it should probably be "You Are an Artisan, Not JUST an Engineer" --- the two aren't mutually exclusive and the author even acknowledges that in the first paragraph.
> But the article isn't arguing that, the article seems to be arguing we are something more than engineers.
But we are not even engineers, let alone more.
There are some people active in the production of software that would qualify as engineers but that's a tiny fraction and they're not going to be found too far from medical devices and aerospace.
Oh my god this is such pompous article. None of these things are specific to software developers, and 90% of the things it says are platitudes that mean nothing.
There are even some that are just wrong, like the 'throw it away' section.
"It's not the code that is valuable. It's the understanding you've gained from building it."
What? Maybe at some places, but where I work, the software I write is NEEDED.
And this:
"Never be afraid to throw something away and do it again. It will almost always be faster to build and much better the second (or third, or Nth) time around."
This jumped out at me too. This is such a HUGE fallacy. If what you have written is core to or is the product you're selling, you can't just rewrite it! Software evolves over time, and it can become difficult to replace it when it gains features and bug fixes for random edge conditions.
Properly replacing existing software requires having a consistent API against which you are developing and can test to make sure that it continues to work. And then having the ability to potentially dark launch new software next to old to see that it works properly. Even doing all of that, replacement projects often fail, why? Simply because most organizations can't afford to have a team that is not contributing to the bottom line of delivering features to customers.
Doing a replacement project should never be started without a significant amount of thought and attention. Software always takes longer to develop than you think, I even underestimate "Hello World!" most of the time.
My team and I were recently working on a replacement for an old service. One weekend I thought, "I could re-write the whole thing in a way better, clever-er way!" I stayed up way too late hacking on it. It was my masterpiece. Sunday night I uploaded it to our org's GitHub and then on Monday the team lead was like "Um, what's that?" and then I knew that the feelings I'd ignored while writing it were true: it was a waste of time. We weren't going to use my new re-write.
Starting with the title. Yes, I'm an engineer. I studied engineering, including algebra, calculus, and physics for CS students, a common core for all engineering students, regardless their specialty. Don't take that away from me. I saw colleagues leave after 1st and 2nd years because they couldn't stand it. It's my peers' and my achievement.
I'm an engineer also because I solve people's problems through software, applying technology derived from scientific breakthroughs.
Yes, sometimes we need to get creative, as everyone else.
Finishing with this
We are in a very fast-paced industry, and nothing will stand still for long.
That mentality is toxic. I aim for my designs, APIs, routines, scrips, to be as long lived as I can make them. Most of the time I don't achieve it. Sometimes it's my fault, sometimes it's the environment. But I create for the future. For me it would be an enormous achievement to learn some piece of software is still kicking ass 5y/10y/15y after.
I mostly agree. They're selling a development platform. You could look at this at marketing fluff aimed at stroking the egos of their prospective customers.
No, an artisan is an artisan. A developer is developer. That's not to say some developers aren't artisans, but a lot of people are developers because it pays the bills: they build things, and are good at building things, because they see it as a means to an end. Some do it as a means of expression: it is their medium for creation. Both modes of operation, and everything in between, are equally viable and valid.
I guess my point is, it's fine to write code and NOT be an artisan. I'd argue that most people who code are not as interested in the creation aspect of is as much as "doing cool stuff" or making money...and that's fine.
But let's not paint all developers with an artisan brush.
> No, an artisan is an artisan. A developer is developer. That's not to say some developers aren't artisans, but a lot of people are developers because it pays the bills
That's the norm for artisans (which is just a skilled worker in a trade involved in making things, especially by hand), not a distinction. Artists may be a different story, but artists aren't the same thing as artisans.
The term artisan always makes me think of pizza. How about referring to ourselves as smiths instead? Imagine upon being asked what do you do for a living and responding that you're a codesmith!
ar·ti·san
noun: artisan; plural noun: artisans
a worker in a skilled trade, especially one that involves making things by hand.
synonyms: craftsman, craftswoman, craftsperson; skilled worker, technician; smith, wright, journeyman; archaicartificer
"artisans from around North America will demonstrate their crafts"
smith
noun: smith; plural noun: smiths
1. a worker in metal.
short for blacksmith.
While the article may be considered a bit trite, and people argue over the word "artisan", there were a couple of points that brought salient anecdotes to mind.
Own Up to Failure
I've worked in quite a few places where arse covering was a full-time activity. Where, "I don't want to make a decision because then I can't change my mind later," is and actual quote during requirements gathering.
For some reason, I've never been bothered being honest when I've screwed up. I distinctly remember one time when one of the client's staff came to me about a problem, loaded for bear, fully expecting a fight on their hands. About one minute into the discussion, having got my head around the problem I said, "Yeah, that was my stuff up. I'll get that fixed."
There was a palpable sense of shock, followed by delight and relief.
...and that leads in to...
Trust is Earned
Where I was brought into high-level management meeting with the same client about some important issue, and my opening remark was, "That's not a bug, it's a feature," as which point my project manager nearly had kittens on the spot. But I then explained through the details of what was going on, agreed on a couple of minor adjustments that would make things clearer in the future, and everyone came away satisfied.
Don't know if I could have gotten away with that if I hadn't already had the reputation for being straight with people and owning my own mistakes.
I don't think this manifesto adds any kind of value to developers. The word that come to my mind is "shallow". Pretentious, pompous. Of course "coders" will love it.
Perhaps UI and UX design is an art, but at the end software requires engineering.
Our field may be grounded by solid engineering and conceptual foundations, but we have much more in common with the medieval blacksmith than we do a modern machinist.
For example: Given a bog-standard relational database and the requirement to be able to create, read, update, and delete rows in the database, what is the best way to present that via an HTTP API? What language will be used? What will the API look like? What edge cases will be considered? How long will it take?
You'll probably get a unique answer for every dev you ask, even though they'll all consider it to be a trivial task. You'll probably also get fairly unique clarification questions about the spec from each one as well.
I'm not sure, when we can put the same task to 100 people and get 100 unique results (and few (if any) would agree to monetary penalties for failures), that we're strongly positioned within the engineering discipline.
> Writing stable code and being available to fix your bugs, even sometimes after hours.
Nah I'd rather be available during hours to fix my bugs. Call me old fashioned, but does anyone not believe your work should not follow you home? I love what France is doing with the "right to disconnect"
Artisan? As in artisan breads? I'm not so sure that's the best fit. Yes, I rise. But I don't want to be sliced and buttered :)
Ultimately, the issue for me is when people use the wrong title (?) to describe their level of experience, skill and overall sweet spot.
For example, a programmer is not a developer, and a developer is not an engineer. So when a programmer describes themselves as an engineer - to someone who has no idea what the difference is - that just ruins it for everyone. Not to point fingers in a negative way but the WordPress community is notorious for such shenanigans.
The engineering debate aside, I don't even like how programmers fancy themselves as "developers", which is very non descriptive, considering that around half of all human jobs are about "developing" something. People who write programs should just call themselves "programmers" for the sake of clarity.
I'd think reality is more like tradesman or software builder rather than engineer. Most devs aren't doing anything new or different. There are probably guys in the building next door probably doing something similar.
Engineers of any kind usually aren't doing something radically different.
Even if you are building a robot, which is undoubtedly engineering, you probably have a team down the road building something similar.
In fact, most software engineers I know are very interested in the cutting edge and research pieces. You can make a living as a mechanical engineer without using an equation newer than a few hundred years.
[+] [-] dctoedt|8 years ago|reply
<blockquote>
If medicine is a craft, then you focus on teaching obstetricians to acquire a set of artisanal skills—the Woods corkscrew maneuver … , the Lovset maneuver …, the feel of a forceps for a baby whose head is too big. … You accept that things will not always work out in everyone’s hands.
But if medicine is an industry, responsible for the safest possible delivery of some four million babies a year in the United States alone, then a new understanding is required. The focus shifts. You seek reliability.
You begin to wonder whether forty-two thousand obstetricians in the Unites [sic] States could really safely master all those techniques. You notice the steady reports of terrible forceps injuries to babies and mothers, despite all the training that clinicians received.
After Apgar, obstetricians decided they needed a simpler, more predictable way to intervene when a laboring mother ran into trouble. They found it in the Cesarean section.
</blockquote>
Atul Gawande, Better: A Surgeon’s Notes on Performance, at 192 (Henry Holt & Co. 2007) (emphasis and extra paragraphing added).
[0] https://en.wikipedia.org/wiki/Atul_Gawande
[+] [-] jMyles|8 years ago|reply
[+] [-] throwaway2016a|8 years ago|reply
But the article isn't arguing that, the article seems to be arguing we are something more than engineers.
There is a subtle implication that engineers are hyper pragmatic and the only thing that is important is that it works. My wife who is a biomedical engineer and makes robots might disagree. In fact, I don't know many good engineers of any kind that stop at "just working."
I think this artisan argument could also be applied to other types of engineering as well.
However, the title is slightly off, it should probably be "You Are an Artisan, Not JUST an Engineer" --- the two aren't mutually exclusive and the author even acknowledges that in the first paragraph.
[+] [-] jacquesm|8 years ago|reply
But we are not even engineers, let alone more.
There are some people active in the production of software that would qualify as engineers but that's a tiny fraction and they're not going to be found too far from medical devices and aerospace.
[+] [-] cortesoft|8 years ago|reply
There are even some that are just wrong, like the 'throw it away' section.
"It's not the code that is valuable. It's the understanding you've gained from building it."
What? Maybe at some places, but where I work, the software I write is NEEDED.
And this:
"Never be afraid to throw something away and do it again. It will almost always be faster to build and much better the second (or third, or Nth) time around."
Has he never heard of the second system effect?
[+] [-] bluejekyll|8 years ago|reply
This jumped out at me too. This is such a HUGE fallacy. If what you have written is core to or is the product you're selling, you can't just rewrite it! Software evolves over time, and it can become difficult to replace it when it gains features and bug fixes for random edge conditions.
Properly replacing existing software requires having a consistent API against which you are developing and can test to make sure that it continues to work. And then having the ability to potentially dark launch new software next to old to see that it works properly. Even doing all of that, replacement projects often fail, why? Simply because most organizations can't afford to have a team that is not contributing to the bottom line of delivering features to customers.
Doing a replacement project should never be started without a significant amount of thought and attention. Software always takes longer to develop than you think, I even underestimate "Hello World!" most of the time.
[+] [-] spraak|8 years ago|reply
My team and I were recently working on a replacement for an old service. One weekend I thought, "I could re-write the whole thing in a way better, clever-er way!" I stayed up way too late hacking on it. It was my masterpiece. Sunday night I uploaded it to our org's GitHub and then on Monday the team lead was like "Um, what's that?" and then I knew that the feelings I'd ignored while writing it were true: it was a waste of time. We weren't going to use my new re-write.
[+] [-] bassman9000|8 years ago|reply
Starting with the title. Yes, I'm an engineer. I studied engineering, including algebra, calculus, and physics for CS students, a common core for all engineering students, regardless their specialty. Don't take that away from me. I saw colleagues leave after 1st and 2nd years because they couldn't stand it. It's my peers' and my achievement.
I'm an engineer also because I solve people's problems through software, applying technology derived from scientific breakthroughs.
Yes, sometimes we need to get creative, as everyone else.
Finishing with this
We are in a very fast-paced industry, and nothing will stand still for long.
That mentality is toxic. I aim for my designs, APIs, routines, scrips, to be as long lived as I can make them. Most of the time I don't achieve it. Sometimes it's my fault, sometimes it's the environment. But I create for the future. For me it would be an enormous achievement to learn some piece of software is still kicking ass 5y/10y/15y after.
[+] [-] xirdstl|8 years ago|reply
[+] [-] mal808|8 years ago|reply
[+] [-] orthecreedence|8 years ago|reply
I guess my point is, it's fine to write code and NOT be an artisan. I'd argue that most people who code are not as interested in the creation aspect of is as much as "doing cool stuff" or making money...and that's fine.
But let's not paint all developers with an artisan brush.
[+] [-] dragonwriter|8 years ago|reply
That's the norm for artisans (which is just a skilled worker in a trade involved in making things, especially by hand), not a distinction. Artists may be a different story, but artists aren't the same thing as artisans.
[+] [-] taylodl|8 years ago|reply
[+] [-] cwbrandsma|8 years ago|reply
ar·ti·san noun: artisan; plural noun: artisans a worker in a skilled trade, especially one that involves making things by hand. synonyms: craftsman, craftswoman, craftsperson; skilled worker, technician; smith, wright, journeyman; archaicartificer "artisans from around North America will demonstrate their crafts"
smith noun: smith; plural noun: smiths 1. a worker in metal. short for blacksmith.
It seems artisan is more appropriate.
[+] [-] yborg|8 years ago|reply
[+] [-] uberstuber|8 years ago|reply
[+] [-] pcurve|8 years ago|reply
It feels like we are borrowing titles from other professions in effort to legitimize our profession. (or inventing new ones)
Software "Engineer"
Software "Architect"
* "Designer"
Solutions *
Distinguished *
Software "Evangelist"
"Technologists"
* Specialist
[+] [-] technologyvault|8 years ago|reply
Developers tend to be much more creative than that.
[+] [-] anotherevan|8 years ago|reply
Own Up to Failure
I've worked in quite a few places where arse covering was a full-time activity. Where, "I don't want to make a decision because then I can't change my mind later," is and actual quote during requirements gathering.
For some reason, I've never been bothered being honest when I've screwed up. I distinctly remember one time when one of the client's staff came to me about a problem, loaded for bear, fully expecting a fight on their hands. About one minute into the discussion, having got my head around the problem I said, "Yeah, that was my stuff up. I'll get that fixed."
There was a palpable sense of shock, followed by delight and relief.
...and that leads in to...
Trust is Earned
Where I was brought into high-level management meeting with the same client about some important issue, and my opening remark was, "That's not a bug, it's a feature," as which point my project manager nearly had kittens on the spot. But I then explained through the details of what was going on, agreed on a couple of minor adjustments that would make things clearer in the future, and everyone came away satisfied.
Don't know if I could have gotten away with that if I hadn't already had the reputation for being straight with people and owning my own mistakes.
[+] [-] flavio81|8 years ago|reply
Perhaps UI and UX design is an art, but at the end software requires engineering.
The only manifesto i'd recommend is this one:
http://programming-motherfucker.com/
[+] [-] brett40324|8 years ago|reply
[+] [-] falcolas|8 years ago|reply
For example: Given a bog-standard relational database and the requirement to be able to create, read, update, and delete rows in the database, what is the best way to present that via an HTTP API? What language will be used? What will the API look like? What edge cases will be considered? How long will it take?
You'll probably get a unique answer for every dev you ask, even though they'll all consider it to be a trivial task. You'll probably also get fairly unique clarification questions about the spec from each one as well.
I'm not sure, when we can put the same task to 100 people and get 100 unique results (and few (if any) would agree to monetary penalties for failures), that we're strongly positioned within the engineering discipline.
[+] [-] treehau5|8 years ago|reply
Nah I'd rather be available during hours to fix my bugs. Call me old fashioned, but does anyone not believe your work should not follow you home? I love what France is doing with the "right to disconnect"
[+] [-] LeoNatan25|8 years ago|reply
The inabilty of the young folk to disconnect from their work is disasterous.
[+] [-] Splendor|8 years ago|reply
I know the historical reference but I'm not sure I understand what the author is actually talking about here.
[+] [-] cortesoft|8 years ago|reply
[+] [-] jacquesm|8 years ago|reply
[+] [-] 2_listerine_pls|8 years ago|reply
[+] [-] chiefalchemist|8 years ago|reply
Ultimately, the issue for me is when people use the wrong title (?) to describe their level of experience, skill and overall sweet spot.
For example, a programmer is not a developer, and a developer is not an engineer. So when a programmer describes themselves as an engineer - to someone who has no idea what the difference is - that just ruins it for everyone. Not to point fingers in a negative way but the WordPress community is notorious for such shenanigans.
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] alexanderdmitri|8 years ago|reply
if (inputStr == "artisan") { ENV = "MARKETING" };
[+] [-] UK-AL|8 years ago|reply
You may not like it, but engineer is probably the closest match to an existing profession.
[+] [-] em3rgent0rdr|8 years ago|reply
[+] [-] jv22222|8 years ago|reply
https://www.amazon.com/Hackers-Painters-Big-Ideas-Computer/d...
[+] [-] rb808|8 years ago|reply
[+] [-] throwaway2016a|8 years ago|reply
Even if you are building a robot, which is undoubtedly engineering, you probably have a team down the road building something similar.
In fact, most software engineers I know are very interested in the cutting edge and research pieces. You can make a living as a mechanical engineer without using an equation newer than a few hundred years.
[+] [-] danielalmeida|8 years ago|reply
Why not stop at "An engineer makes something work. You are more than that. You are an artisan." and present a reasonable line of argument?