Developer Manifesto – You Are an Artisan, Not an Engineer
content.nanobox.io
content.nanobox.io
<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).
There is a cost to the mother - major surgery - to the benefit of children. Modern society considers this a worthwhile trade, but it would have meant the death of the mother not even a century ago.
I have no real way to tie this back to programming; other than perhaps to note that we're likely still in the dark ages of programming; the programming equivalent of a cesarean section is likely still years away.
One facet of the tie-in is the age-old question of what to optimize for: Programmer time? Execution speed? Code compactness? Code maintainability? Cf. The Story of Mel [0].
Look at HTTP, WebSockets, NodeJS, JS! Docker!
Churning out "apps" and delivering deliverables is the focus, not engineering. Ticking off boxes for enterprise is more important than product feel and user satisfaction. And so on.
And once you got hooked on docker and nodejs (with typescript and VS Code) why would you go back to hacking perl scripts that invoke long forgotten binaries written in the darkest C dialects, darker than void* itself, even if that damn docker image is 600MB, the runtime memory cost is not much less, and it's managed by kubernetes which needs gigabytes of RAM just to run an apiserver and scheduler and a kubelet (node/server manager).
Besides elected c-sections, the prevalence has been increasing, where a labor shows the slightest risk and suddenly it requires a c-section.
But I think that the part that most rubbed me wrong was the realization that it Apgar (a rather crude system for summarizing neonatal health, IMO) that, in part, caused the C-section to rise in popularity.
That's gross. It's like using `free` to measure RAM usage on your server, and then determining that every app with usage over n needs tighter JPG compression, reducing image quality. In other words: you measured the wrong thing, implemented the wrong fix, reduced the quality of the outcome, and then made the above standard practice.
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 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.
I feel perfectly content to deem my work as "engineering". I can understand why someone quickly whipping up a small web application (which is not to imply that all web applications are quickly whipped up, nor that all web applications are small) might reasonably feel that their work is not engineering.
So since I've also done quick little web applications, what do I think the difference is?
The aerospace work includes precise operational requirements. It includes formal verification tests which demonstrate that the requirements are met. Code is reviewed; documents are reviewed; reviews are reviewed (not joking, though typically only a sampling subset). Code is subject to formal coding standards; code repositories are subject to formal standards; tools for testing software are subject for formal standards (and documented/reviewed/etc. in their own right). Software that goes onto aircraft is tested in simulations; tested in limited on-ground hardware scenarios; tested in extensive on-ground hardware scenarios; tested on board flying aircraft. The entire process (and the following of process) is reviewed. The end product is signed off on, and, for example, in the case of U.S. commercial aerospace, certified by FAA representatives.
Sounds nothing at all like developing web applications!
Or does it?
A consumer-facing startup web application might have little or no requirements. Testing may be ad hoc. Nothing is reviewed. Coding standards don't exist. Does the software seem to do what is intended? Ship it!
But what about web applications for banking? I've never worked in banking, but I suspect the requirements are fairly robust. (And if in fact they are not, they easily could be.) I suspect that tests are comprehensives, traced back to the requirements. (And if in fact they are not, they easily could be.) I suspect that the software goes through several rounds of testing, that code is reviewed, that coding standards are adhered to. Maybe not to the same level as aerospace, but probably pretty solid.
So what?
Is financial software engineered? I would imagine so. Maybe not as strictly as aerospace -- or maybe stricter! I honestly don't know. But I can easily imagine comparable scenarios.
So if we can engineer financial software, can we not engineer productivity software? We sure could! How about social media software? You bet! Even games? Why not?
I think that all software could be engineered. But in fact it probably shouldn't be. If you want to make a change on software on an aircraft, it might be five minutes editing code in Emacs, surrounded by a year of paperwork and process. That'd be ridiculous for an iPhone game. It'd probably be excessive for a financial application, but maybe some measure of that would be appropriate.
Perhaps there is (or should be) a spectrum of software engineering. At one end, we take extreme measures to ensure quality and process, because (literally) lives depend on it. At the other end, we can hack out whatever we want and it doesn't matter. Most software lies somewhere in between. Maybe some of it should consider moving more toward one end or the other. :-)
[Incidentally, it's common to repeat the phrase, "never roll your own cryptography software". I think it would be totally fair to say "never roll your own flight control software" too. But the people actually writing flight control software aren't necessarily top-tier 0.000000001% brilliant developers. They are, though, surrounded by sufficient process and review that their work is nearly guaranteed to be solid by the time it takes to the air. We could probably do something similar with cryptography software, if there were a model in place (and, I reckon, funding in place) for all of the surrounding infrastructure to engineer it properly.]
I think a lot of "software engineers" fall under what in another industry would be called a "technician" which muddies the discussion.
Although I'm not sure I'd even put the bar as high as medical, financial, and military.
A sufficiently large web application can indeed require a level of discipline often associated with engineering. The amount of process and control when you have 50 people working on a project and millions of users is very different than the lone hacker in their garage.
You also implied that in engineering making a tiny change can be a year worth of paperwork. While not as extreme as that, if your handling credit card data for instance there is a lot of paperwork, documentation, and verification that goes into pushing a change live.
One might posit that "software engineering" is not very much about developing the actual software at all, but just ensuring that it is done correctly?
Do you think that it should be?
https://c3.nasa.gov/dashlink/static/media/other/ObservedFail...
I also don't really consider myself an engineer: I'm self taught, I don't have a degree, I've never had to formally prove my software, and the most failures in my software can cause is some potential loss in revenue.
https://c3.nasa.gov/dashlink/static/media/other/ObservedFail...
Aerospace development is not categorically harder or more skillful than any other sort of software development. Some areas are math-heavy, but that's true elsewhere too. The biggest difference is the process overhead.
Thanks for responding. Yes that's my question. I assume that domain knowledge in embedded systems, as well as aerospace science are minimum requirements?
Lots of people are hired into aerospace straight out of college, with degrees in non-aerospace things like computer science and electrical engineering. A lot of the domain knowledge is hard to come by outside of working in the field, and it's generally not expected for an entry-level role.
But even if not strictly required, some related domain knowledge would sure make you shine as a job candidate. Specifically:
- Lots of software is written in C, C++, or (less often today) Ada. I would suggest focusing on being skillful with C first and C++ second. It would be nice bonus points to at least have some familiarity with Ada, even if the most you ever do with it on the job is read old code. Verification test frameworks will likely be in some high level scripting language; I've seen Python and Lua used, myself. Model-based development tools (like Simulink) are used sometimes too.
- Understanding of real time embedded systems would be great. There are a variety of such systems out there; real-time Linux would be a good option to become familiar with.
- Knowledge of low-level networking concepts. I.e., the bytes that make up UDP packets, TCP packets, packet headers. Whether if you work directly with networking or not, you'll likely encounter "one box sending data to another box" all over in aerospace. Good ol' Ethernet is used, but so are other more obscure protocols like ARINC 429, ARINC 664, MIL-STD 1553, etc. While most of these specs are not available free of charge, they are available to the general public. They're not exactly light reading, though, and I've learned more with the spec in one hand and a packet sniffer on a running system in the other, than trying to comprehend the spec by itself. But Ethernet / TCP / UDP is easy to learn about, so start there.
- Aerospace science? If you went out and got a degree in aerospace science, especially a combination of aerospace and CS, I can imagine companies tripping over themselves to hire you. Do you need it to do the job? Depends on the job. You could have a successful career developing software in aerospace without actually knowing much about aerospace, because there's just so much to do. One developer does the aerospace calculations, and another one tackles making the code thread-safe, and so on. But a solid understanding of aerospace science concepts would make you quite desirable as a candidate, and would open doors for you to work on things that other "CS-only" people don't know how to do. [There are some aerospace classes on edx.org -- if you like online courses, could be a good way to start. The University of Kansas has an extensive program, though I don't think they offer it online.]
- Related, and maybe easier (or maybe harder), would be to learn about flying. A ground school class would be a good start, and can be done online. Holding a private pilot certificate would be some great resume fodder, and would also give you good knowledge for the job. You would have better understanding of another facet of aerospace knowledge, and would also have more of an "end user" kind of perspective. [Look at http://www.kingschools.com/ for some online materials, or try a local flight school. Quick start: try X-Plane.]
Any or all of that would be good material for being a more attractive job candidate. But again, many people get their start without knowing much or even any of that, and pick up what they need on the job, so it's not strictly required. It would just be helpful. And, depending on the job market at the time, it could be extremely helpful.
And to restate my opening remark, there is immense breadth in this seemingly tiny niche field. Due to the very nature of the work, no one person does everything. You would almost certainly not do the aerospace calculations, and do the network programming, and do the verification testing, and do the graphical displays, and do the air-to-ground communication system, and do the ... And that's just for the software! Someone designs the nose cone, and the wings, and the fuel system, and the passenger seating, and the ...
As always, beware career advice from random people on the internet. But I hope you found something helpful here!
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?
'Come, write your code on this artisanal platform, carefully crafted by Tibetan monks in their 5th year of a 10 year vow of silence'
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.
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.
But yeah, I kinda have a feeling I know where he is coming from with some of his thoughts... my first few jobs were at startups that never went anywhere. We made great software, but never gained any customers because there was no real market for what we made.
After a while, you get REALLY focused on the craft of your code, because it is all you have. You can throw out old stuff and rewrite it, because it doesn't matter, you don't have customers depending on you. You already made what is needed by the business, the problem is there IS no business.
My current job is with a large CDN, serving a huge number of actual real customers with real demands. I don't have time to treat every piece of code I write as a piece of art. It is simply a tool to further the business.
Personally, I much prefer my current job. I would rather create things that actually matter, rather than amazing art that no one uses.
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 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.
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.
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.
Developers tend to be much more creative than that.
It also emphasizes the fact that coding is an iterative process. Sometimes you have to strip the whole thing down, make your codebase malleable again, and pound away to refashion it a different way.
"Thetis of the silver feet came to the house of Hephaistos, imperishable, starry, and shining among the immortals, built in bronze for himself by the god of the dragging footsteps. She found him sweating as he turned here and there to his bellows busily, since he was working on twenty tripods which were to stand against the wall of his strong-founded dwelling. And he had set golden wheels underneath the base of each one so that of their own motion they could wheel into the immortal gathering, and return to his house: a wonder to look at. These were so far finished, but the elaborate ear handles were not yet on. He was forging these, and beating the chains out."
- The Iliad
https://en.wikipedia.org/wiki/Hephaestus
Probably we should choose Hephaestans over Vulcans, to avoid confusion.
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
“Engineer” and “architect” are much more nuanced and hard to distinguish.
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.
Perhaps UI and UX design is an art, but at the end software requires engineering.
The only manifesto i'd recommend is this one:
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.
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"
The inabilty of the young folk to disconnect from their work is disasterous.
I know the historical reference but I'm not sure I understand what the author is actually talking about here.
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.
if (inputStr == "artisan") { ENV = "MARKETING" };
You may not like it, but engineer is probably the closest match to an existing profession.
https://www.amazon.com/Hackers-Painters-Big-Ideas-Computer/d...
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.
Have you seen what's happened to control theory in the last 15 years? There's so much new math that new PhDs are having trouble deciding which parts to learn. Control theory has imported much of machine learning in addition to all the classic control theory, and they want bounds so they know the machine learning parts won't do something stupid.
I am absolutely not implying that there have been no advancements in mechanical engineering. Just that it is possible to find a job where you will not encounter them. I am confident you are right that PhDs are doing great cutting edge stuff.
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?