

We need both engineers and artists in programming - joao
http://loudthinking.com/posts/42-we-need-both-engineers-and-artists-in-programming

======
kiba
Stop trying to compare it to engineering and fine art. Programming is a
discipline that stand on its own and incorporate elements from other field.

~~~
_pius
_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.

~~~
philwelch
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.

~~~
_pius
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.

~~~
axod
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".

~~~
_pius
_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.

~~~
philwelch
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.

------
dxjones
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".

~~~
swombat
_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.

~~~
aaronblohowiak
"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.

------
mlLK
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.

------
PhilChristensen
He's right about there being two kinds of programmers, and we might as well
use 'engineer' vs. 'artist' even though it's not entirely accurate.

However, _all_ programmers need to be professionals, at least if they have any
intention of interacting with non-programmers.

------
pie
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.

------
GeneralMaximus
> 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.)

~~~
davidw
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:

[http://journal.dedasys.com/2008/12/04/the-economics-of-
progr...](http://journal.dedasys.com/2008/12/04/the-economics-of-programming-
languages-in-the-1950s)

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.

------
jleyank
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.

~~~
swombat
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?

~~~
jleyank
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.

~~~
swombat
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?

~~~
jleyank
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.

~~~
swombat
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.

------
ErrantX
how can he suggest engineering and artistry are mutually exclusive..... some
of the most beautiful code is engineered.

