People are still trying to figure out programming. It's been around as a profession for, what, 50 years or so? And has changed a lot since its inception. And has economics that are a lot different from something like building a bridge or even an airplane.
So it's natural that people are still attempting to define it in ways that make sense to them in terms of 'known' things.
Stop trying to compare it to engineering and fine art.
Could you elaborate on how programming is different from engineering? I feel like if programming seems that different from an engineering discipline, you're probably doing it wrong.
Engineering is actually getting more like programming, with CAD and simulation testing taking the place of coding and testing. And some types of engineering (circuit design in VHDL/Verilog) is programming.
I've never engineered, but from what I've gathered, the main difference is that in engineering, you have to be really careful about writing down a design, because once you design a car or an airplane or even a shoe, it takes a lot of human effort to build the actual car/airplane/shoe, and you really want to make sure it won't crash before you test it. It's costly to reiterate a design before release, if that iteration involves a full design-manufacture-test cycle. Whereas in programming, we can build the actual program whenever we want (compilers are fast and cheap) so we usually start from an initial design that's completely broken and incrementally refine it. Even the largest scale programming, done right, has a "nightly build", the engineering equivalent of changing your airplane design in the afternoon, manufacturing it at night, having a test pilot fly it in the morning, and discovering that afternoon why the test pilot and your new airplane are now in hundreds of pieces spattered across the Nevada desert.
I hear you, but to me that's a difference of scale, albeit one that allows you a greater tolerance for risk during the engineering process.
I wouldn't argue that chip design is not an engineering process because because the risk/build profile differs from that of a bridge, nor would I make a similar argument for bridges versus cars or dams or spaceships. To me, engineering is a really broad term that encompasses software just as easily as it does physical components.
It's a massive difference though. A single software project might go through a few thousand iterations of a complete build, test, development cycle. Some projects probably go through that a week. That's completely different to the average engineering project.
I hate being called a 'software engineer', as it's pretty much nothing like what I do.
The only similarity is that we both "Build stuff".
I hate being called a 'software engineer', as it's pretty much nothing like what I do.
Ironically, having studied several engineering disciplines, I feel precisely opposite of this. I want people to understand that building reliable software is an engineering effort.
In my work, I try to balance competing forces and constraints to design reliable, elegant, modular, well-tested components at low cost. Just like practically every other kind of engineering I've ever seen.
And that's one way of doing it that resembles engineering.
Just as engineering can resemble programming, programming can resemble engineering. But trying to imitate what engineers do limits what you can do as a programmer. Programmers also work on multiple levels of abstraction in a way that I imagine to be somewhat different from engineers.
Abstract concepts are imperfect. Chip design isn't exactly programming because the final product requires fabrication, no matter how well you can fake it with simulators or FPGA's. (In situations where FPGA's are useful in deployment, I guess "chip design" would become "programming an FPGA" and you would get the benefits of quick building that programming gives you.) Likewise, we can design an airplane in CAD and put it through a computer simulator, which might allow a more programming-like design experience. But "engineering" implies that it's a separate step from manufacturing or assembly, whereas a programmer goes from idea to built parts within hours (not the whole system but definitely a subset of it).
If you want someone "waxing lyrically about beautiful code and its sensibilities", get a poet-in-residence at your software company.
If you want art and engineering in programming, think of the way architects bring art to the world's most impressive buildings and bridges. It doesn't count if the bridge falls down.
Similarly, your program can't ignore "memory and runtime".
If you want art and engineering in programming, think of the way architects bring art to the world's most impressive buildings and bridges. It doesn't count if the bridge falls down.
Interestingly, the architects have structural engineers and all sorts of other engineering professionals to help them make sure the building, bridge or whatever will not fall down.
Perhaps that's the problem with software development. We still want the coolest fancy looking bridges that span miles, but we haven't quite figured out how to get the artist-programmers and the engineer-programmers working together.
"we haven't quite figured out how to get the artist-programmers and the engineer-programmers working together"
Pair programming.
Alternatively, I would say that we actually have. I believe that the Artist-programmer is most concerned with the expressiveness of the code, wheras the engineer-programmer is concerned with the efficiency and stability (of course there is overlap/cross-pollination.) The artist-programmers work at the problem domain level, and the engineer-programmers work at the systems/implementation level. Apache/MySQL/Sphinx written by engineer-programmers, Sinatra apps written by artist-programmers.
And yet as a profession Architecture seems to reward art more than engineering. The phenomenon of an award-winning building with a leaky roof is a cliché for good reason.
Interestingly, the work of many highly regarded "artistic" architects fails the basic test of keeping water from leaking on the inhabitants - Wright, Gehry, etc.
Maybe best not to look at contemporary architecture as a model.
How are we exactly defining the term artist here? This term varies so much in scope that it can quickly become misleading.
If I try to conceive of an artistic programmer the first thing that comes to mind is not the language or the platform it's running on, but the result of the work. . .programming is just a means to an end like many of may already know.
It is projects like http://processingjs.org/ and video-games like http://tinyurl.com/sotc4ps2 that don't appear to solve anything in particular, but are merely an implementation of some [one's/one else's] artistic vision.
The title here is a little misleading - it sounds to me like the term 'artists' is being used to describe professionals who are simply more laid-back and friendly than the traditional uptight, nose-to-the-grindstone ideal of a working stiff.
> People willing to trade the hard scientific measurements such as memory footprint and runtime speed for something so ephemeral as programmer happiness.
I'm sorry, but I just can't take this seriously. Runtime speed and memory footprint are not important anymore?
How will you justify to your customers why the software you just delivered takes several hours to perform simple operations? I'm sure they don't care about programmer happiness one single bit.
(I don't have anything against the guy who wrote this. I'm glad he found something he loves doing.)
No, what he's saying is that there is a tradeoff involved, and that for many things, it's better to optimize for programmer time/productivity, rather than for machine time. This has been true for 50 some odd years:
Clearly, that's not true in all cases, and some code has to be fast. However, it's often best to avoid premature optimization - write the code, explore the problem domain, and then speed up the bits that need it.
I think we've reached the point where it shouldn't take "several hours to perform simple operations" on any modern compiler/platform. Instead, it shouldn't take several hours of a programmers time to develop simple operations.
I would change the phrasing - we need professionals in programming. People who approach their work with serious craftsmanship, own their work (both the good and the bad), and do the last 5% that distinguishes good stuff from the rest of the lot.
Do we always have time to do this? No. Is it always appropriate to do this? No. But when it is mission critical work, deliver the goods.
Perhaps it's because of the way you phrased it, but it appears to me that you completely missed the point of the article. It sounds like you're disagreeing with DHH but agreeing with Uncle Bob. Do you care to try rephrasing it again?
No, I think even though it was early in the morning I said what I wanted to say. We need professionals, not amateurs, in the programming biz. Whether they're professional engineers, artists or whatever, we need people who approach the problem seriously, do the best work they can and make sure to finish the odds and ends that make good code. There's far too much "slap it together" code dragging down both the user's experience and our collective reputation.
One can be a professional artist as well as a professional engineer. I prefer the former generating visualizations and the latter doing operating systems. But I really want the #!~!&@$~! to work.
There's far too much "slap it together" code dragging down both the user's experience and our collective reputation.
I have absolutely ZERO experience with slap-it-together code coming frompeople who think programming is an art form.
All, and I repeat my n=1 anecdote at the top of my voice, ALL, of the shit code I have seen was written by people who viewed programming as a profession, namely something to be done for money using processes that valued delivery over quality.
Which is not to say that other programmers who view themselves as professionals have not written terrific code. But I vigorously dispute the notion that there is a correlation between slap-it-together fecality and someone's self-images as an artist.
Fine, if all you want is software that works, i'm sure you can find some bored engineers to write software that just works.
Meanwhile, the rest of us will continue to have fun with software that does amazing stuff and sometimes breaks.
There's a not-so-old saying: "Brilliant people are often hard to work with, but if I've got to choose between working with a brilliant person that is hard to work with, or a stupid person that is easy to work with, I'll always choose the former."
The same is true of software. When you're pushing the envelope, things break. Learn to live with it, or stop bothering with computers until those of us who are more passionate about doing extraordinary things have left the field. We should be done in about 50 years.
Note: this is not a defense of cowboy programming. It's a defense of genius cowboy programming. If someone like Linus Torvalds, as an amateur student programmer, wants to write something as awesome as Linux, who are you to suggest that he shouldn't?
You're (aggressively?) missing the point. If you're doing research, pushing the envelop, then by all means have a go! If, however, you're writing stuff to sell, that people will depend on, then do it well. Calling somebody a professional != calling them an engineer. Slowhand's certainly a professional guitar player, and I think there's general agreement he's not an engineer...
When Linus did his groundbreaking work, that was pure creativity. Redhat, however, better be a little more grounded.
So then we arrive at exactly the point that the article made: you need both.
You need the "artists", i.e. the extraordinary, unprofessional people who do something crazy that no professional would ever attempt, and come up with something that pushes the envelope in new and unexpected ways.
And you need the "engineers", the professionals who will convert that (or other things) into something steady, reliable, rock-solid.
I don't think that your rephrasing helped, personally. It made a point which was in agreement with the article look like it was a disagreement.
"There's far too much "slap it together" code dragging down both the user's experience and our collective reputation."
This, perhaps, is most true in those who term themselves user interface developers. They probably started with HTML and CSS, and started learning Javascript from snippets pasted across the net in the early 00's. Unfortunately, most never took the time to actually learn the language, so these days they just slap together jQuery plugins and call it a day... crossing their fingers that it works, and having no idea what to do -- other than an ugly hack. Like user agent sniffing (something about jQuery not being fully compatible with IE6. If you've run into these issues, you know what I mean. Prototype is even worse -- hell, it doesn't realize that you can actually determine what the rendered CSS of an element is...).
