
The Case for Slow Programming - bufo
http://ventrellathing.wordpress.com/2013/06/18/the-case-for-slow-programming/
======
wellpast
I largely agree w/ the argument here, but "slow" is going to be self-defeating
nomenclature, and is also inaccurate. Business doesn't want slow. So if we're
pitching slow, we're setting ourselves up to lose and the speed-hackers are
going to win.

Our goal is architectural soundness. I believe the biggest fallacy of our
industry is we think the only way to get these is to go "slow". Not true.

What we're really saying is our industry is short on _skill sets_. With
specific skill sets, you can build architecturally sound systems at no extra
cost.

If I were to build a house today it would take me much longer than someone
else because I don't have the necessary skills. I might hurry in which case
the house would be shoddy. Is the shoddiness of the house _necessarily_
because I hurried? No. It's because I didn't acquire the required skill sets
first.

The software industry has no such (practical) concept of the skill sets
required to build architecturally sound systems. We have a bunch of well-
meaning hackers, and as a result shoddy systems that decay into technical
liabilities.

Our industry needs to solve this skill set problem. The challenge is that
academia has a hard time teaching these skill sets, because they are so
removed from the practitioner. And businesses can't teach it b/c it takes
years and special experience to actually teach it. So it's not advantageous to
a business to teach those skill sets.

So how do we do it? And how do we organize an industry around _professionals_
who know how to build architecturally sound systems and code? This is a very
difficult problem for a world that has such high demand for code and such
little understanding of what the professional skill set would afford them.

~~~
Argorak
> I largely agree w/ the argument here, but "slow" is going to be self-
> defeating nomenclature, and is also inaccurate. Business doesn't want slow.
> So if we're pitching slow, we're setting ourselves up to lose and the speed-
> hackers are going to win.

German has a very nice word for that: "zügig". It means "speedy" as well, but
goes a bit towards "stable", "steady" and "friction-free". It's the good kind
of fast, which sometimes needs a step back and a look at things.

So, if I came to work "zügig", I didn't speed, but there was no traffic jam, I
didn't stop for a coffee somewhere, etc.

~~~
barking
Zügig is just so..Germanic! It's exactly how I imagine the stereotype of
German efficiency. In the anglo-saxon world we pride ourselves on how many
hours we work. In Germany they work fewer hours and produce more and of better
quality. At least that's my impression.

~~~
lectrick
Relevant: [http://knote.com/2014/11/10/why-germans-work-fewer-hours-
but...](http://knote.com/2014/11/10/why-germans-work-fewer-hours-but-produce-
more-a-study-in-culture/)

~~~
rapind
I now love german culture. It's like finding my soulmate.

~~~
jsilence
Please note that another german culture is to be overly pedantic in following
rules, no matter if their initial intention applies or whether we just set
them five minutes ago. Rules are followed because.

This culture makes administrative processes bulky and tedious and tiring.

It often fuels my Ungeduld, because I want to get s __t done zügig.

~~~
moconnor
This is true; it's also true that Things Work here. Processes, equipment,
social organizations.

To get your fishing permit you _will_ need to provide all the right bits of
paper and stamps, no exceptions.

The flip side of this is that if you follow a set of precise, unambiguous
instructions _you will get your fishing permit_.

Source: moved from UK to Germany 8 years ago.

~~~
Argorak
My favorite expat quote is: Germans have rules for everything, but with some
though put into them, most of them are quite sane. ;)

------
donatj
I was once a "fast" developer, like thousands of lines a day. I could knock
things out at an amazing pace but they always had problems and were rarely
testable. That actually worked out OK where I was where we basically built
things and ideally never touched them again.

Now, 8 years later I write maybe 50-100 lines a day. I can see all the vectors
of things that would go wrong and take the time to mitigate them. I work with
"hotshot" young developers who write my old maybe a thousand+ a day. I'm the
grumbly old man in code reviews who forces them to break them into multiple
smaller pull requests. The difference is my 100 lines will stay in the
codebase for years, whereas their thousand will likely be rewritten several
times over in the lifetime of my code. There's tradeoffs here, to be certain.

I see so many younger devs thinking just because their code is tested that its
"good". This is certainly not the case. There is so often so little
consideration of how their code fits into the "big picture". We end up with 5+
"widgets" where one general widget would have sufficed if they'd thought
things out ahead of time. _Sigh_. _Shakes Fist_. Get off my lawn. Old man
grumbles... I'm 28.

~~~
Raphmedia
Hotshot here.

Oh, how I wish I could slow down.

But how could I? My task must be done in time for the sprint. Everything I do
must be logged into the right ticket, I need to time everything I do. The
enemy is time, and I must defeat it. I wish I could output better quality
code. Right now, I'm working on a project that was finished at 90% and I need
to finish it. The code is horrible, but I have no time to fix it. So I'm
simply going to hack at it as fast as I can and make my agile manager happy.

~~~
raintrees
This conversation reminds me of an electronic relay assembly line I once
observed over a period of time. The workers hand-soldered relays, their
numbers were being measured/judged, so many cold welds were shipped.

QA sent them to soldering classes, where temperatures and flowing of solder
were discussed/practiced. They came back with nicely soldered joints, and
production numbers dropped to the floor.

Management came back in, exhorting higher numbers, so out came the cold welds
again to make the numbers.

------
Spearchucker
This guy speaks to my _soul_.

A couple years ago I worked on a project that tried to put a 40+ page printed
form online. The form is complex. The form has a lot of intricate guidance and
notes, and sections that must or must not be completed based on previous
sections or fields.

I threw together a form builder by re-purposing old code from a side project
that took me two years to polish. My proof of concept let an admin change
guidance on the fly, without touching HTML. Fields could be re-sequenced, data
types changed. Business rules could be linked to fields dynamically, and
applied to single fields or entire form sections. Data was saved to a SQL
Server (already in wide use in the estate). My proof of concept took 4 weeks,
and on the basis of that I estimated a 6 month project. When I presented the
idea it was viewed as being too complex, and therefore too risky.

So the dev team just started hacking it out, field by field, and saving the
whole form into Mongo as a single, nested document. Guidance was hard-coded
into the HTML. It was fast, and at the start everyone was awed.

Of course soon after the customer decided that the guidance for the printed
form wasn't appropriate for the online version. And of course the customer
wanted to analyse data across all forms. What was a 6 month piece of work took
_3 years_. And still no ability to analyse data nested in Mongo documents. Any
change requires hours of re-work, regression tests and sign-off.

All because agile.

In my 20's I'd have been emotionally destroyed. Ego like an aeroplane into the
side of a mountain. No survivors, call of the search. Happily I'm in my
mid-40's. I know better, and I know better than challenging an inexperienced
project lead that has too much authority. So I move on. There's always a
project that's more suited to my style of work (slow).

~~~
lmm
> I threw together a form builder by re-purposing old code from a side project
> that took me two years to polish. My proof of concept let an admin change
> guidance on the fly, without touching HTML. Fields could be re-sequenced,
> data types changed. Business rules could be linked to fields dynamically,
> and applied to single fields or entire form sections. Data was saved to a
> SQL Server (already in wide use in the estate). My proof of concept took 4
> weeks, and on the basis of that I estimated a 6 month project. When I
> presented the idea it was viewed as being too complex, and therefore too
> risky.

Was your flexibility in the right direction? I could tell you exactly the
opposite horror story, where an enterprise architect built in a bunch of
flexibility that we never used, but we still spent a load of time changing
everything as the customer requirements changed. Only we had to spend twice as
long because we had to change everything in three places because the "flexible
design" required that.

> Of course soon after the customer decided that the guidance for the printed
> form wasn't appropriate for the online version. And of course the customer
> wanted to analyse data across all forms. What was a 6 month piece of work
> took 3 years. And still no ability to analyse data nested in Mongo
> documents. Any change requires hours of re-work, regression tests and sign-
> off.

Why would your way have been different? If you are using the database to store
logic in, it's still logic and still needs the same level of testing as it
does in code. And you don't get existing tools like VCS, release systems,
staging environments to help you with that.

I know we're just comparing anecdotes, but everywhere I've worked the business
effectiveness has been directly proportional to the extent to which they
actually followed the agile principles.

~~~
einhverfr
First, I sympathize with your reaction against building in functionality that
is not required. This typically causes a lot of problems. However, for a
library, that is less of an issue because you aren't maintaining it. It sounds
to me like the guy used what was essentially a library he had previously
developed to do this and that's a step towards having the flexibility in the
right place.

> Why would your way have been different? If you are using the database to
> store logic in, it's still logic and still needs the same level of testing
> as it does in code. And you don't get existing tools like VCS, release
> systems, staging environments to help you with that.

My largest open source project does a lot with database stored procedures. We
use all the tools you mention above, and we have written some of our own
tooling to make that easier. So I don't think there is any reason why those
tools don't work. So you have to spend a little time on tooling? That gets
paid off many times over.

> I know we're just comparing anecdotes, but everywhere I've worked the
> business effectiveness has been directly proportional to the extent to which
> they actually followed the agile principles.

There are many things that agile gets right. As a reaction against the
waterfall engineering model, the emphasis on integrating design into coding is
a welcome advancement. There are many other things as well.

But agile development, because of short release cycles, tends to de-emphasize
design and code contracts because it comes from the assumption of changing
requirements, and here it gets a lot of things wrong. You can't do agile
development if you don't have a stable platform to develop on because
otherwise the ground is always being pulled out from under your feet. That
platform needs to be well designed, and I am not sure you can do that
iteratively without a fair bit of up-front thought. This doesn't mean a
waterfall (except in the area of UX). Rather it means getting the right amount
of design done at each level and having the right person do it.

~~~
lmm
> My largest open source project does a lot with database stored procedures.
> We use all the tools you mention above, and we have written some of our own
> tooling to make that easier. So I don't think there is any reason why those
> tools don't work. So you have to spend a little time on tooling? That gets
> paid off many times over.

Programming logic in the database, or config files, is a huge antipattern I've
seen many times. People seem to have this huge blind spot where you can take
the exact same piece of logic and label it "code" or "not code" and in one
case it will be subject to review and signoff and all that and in the other it
won't be.

You _can_ always write your own programming language and tools, but you're
unlikely to do better than the existing ones. So why not just use one of them?

------
cesarbs
> Fast programmers build hacky tools to get around the hacky tools that they
> built to get around the hacky tools that they built to help them code.

This resonates so much with me. Sometimes I worry that I'm falling behind on
keeping up with technology, but whenever I try to learn something new it seems
like I have to install a package manager, then another package manager inside
the first one, then pull a million other tools and libraries and frameworks
before I can even begin doing something with this stuff I'm trying to learn.
No, thanks.

I love computers, I love computing, I love thinking about solving problems
using computers, but I hate the direction things seem to be taking. I'm
seriously considering a career change in the immediate future because all this
crazy tooling truly burns me out.

~~~
NateDad
Try Go, seriously. There's just the one tool. No package manager, no
dependencies... And the code it produces is the same. Just a binary. "Here,
have this tool, just run it." It's small, simple, and the community actively
searches out simple solutions.

~~~
woah
I found go to be quite cumbersome in comparison to npm. Magic folders in the
filesystem and such. With node you never have to do more than npm install and
everything is ready.

~~~
sysk
<rant>

npm (and the CommonJS module system) is the #1 reason I use Node.js. I don't
care if Javascript is ugly, npm totally makes up for it. I don't get why most
module systems implicitly import symbols in the scope (Python, Ruby) or worse,
those that pollute the global scope (PHP).

Brew (Ruby) is not that bad but Python's package ecosystem is a complete mess
(distutils, setuptools, pip, etc.). Cabal (Haskell) is pretty good too in
comparison to C/C++ (installing dependencies usually involves following
instructions in a README file, that is, if there are available instructions
for your OS). I haven't tried Go.

I believe the language of the future will be built around, and win mainly
because of, its package system/ecosystem.

</rant>

~~~
ploxiln
<rant>

npm is easily the worst. Python is a lot better. I hold the C library model as
the golden standard, so we're not going to see eye-to-eye.

The worst part of npm is the sub-dependencies. Having enabled them, they
proliferate endlessly. Each time I improve the efficiency of deploying a
strictly controlled tree of modules, the front-end devs manage to double the
number in use. 200, 350, 650, over 1000... oh and these improvements come from
realizing that npm-shrinkwrap isn't 100% reliable, and ending up with scripts
comparing npm-ls output and doing full wipe and replace with a tarball for
even the slightest change to the dependency tree.

If some serious bug is discovered in one of these things, there's no way the
20 copies of it at various levels of this tree of 1000 modules are going to
get patched. No one really has a handle on what's in these hundreds of megs of
various versions of modules. This is the true fast code movement - serious
problems can't be fixed in there, they'll just be ignored and replaced with
other bugs in the twice-yearly full rewrite. Don't get me wrong, our frontend
devs are among the best I've seen, but the pressures and environment they're
in make them focus on churning out the latest fad in web design and skimping
on engineering quality everywhere possible.

Python doesn't do implicit import of symbols into a scope if you don't use
"from blah import (star)". Don't use the (star).

Managing, and using, a list of python modules, each at a particular version,
is way simpler, more reliable, and more efficient (than npm style). Pip can
reliably list installed module state (freeze) and install from source tarballs
or git tag checkout.

You need to fully control and understand the versions of all libraries
installed and used on a system in order to have a fully reproducible
deployment state, and be able to reliably roll back to a previous state. Given
that, the Python or C model is much easier to work with.

</rant>

~~~
NateDad
Go's model is pretty good. This is why there's just a single $GOPATH and every
package has exactly one location on disk, so even if 100 dependencies use the
same subdependency... you only have to update one spot if it needs a patch.
And again, this only needs to be done at development time. It's baked in when
you compile, and from there on, deployment is just a file copy of your binary.
No dependencies during deployment.

~~~
notduncansmith
Maybe I'm missing something, but this seems like a bad idea to me. What if
projects are relying on differing versions of the same package? What if two
developers collaborating on the same project have different versions of that
dependency installed?

Sure, it's space-efficient, but disk is cheap, and developer hours are
expensive. I certainly wouldn't want two employees burning man-hours trying to
figure out why some app is behaving differently on their respective machines,
only to fix the problem and unwittingly break another project in the most
expensively subtle of ways.

I'd really like to think I'm missing something though, I certainly don't
presume to be more insightful than the collective Go team.

~~~
NateDad
So, in theory, any particular import path should be stable. There are no
"different versions" of the same import path. A different version would be a
different path.

So, for example, github.com/natefinch/lumberjack is an import path. When I
wanted to change the API, I have to put my project at a different import path
so I don't break projects that use this version. I could just make a new
github repo called lumberjack-v2 and that would work fine.

Of course, reality and theory don't always see eye to eye, and the Go
community realizes this. That's why there are several community-made tools to
help out.

The most well-respected one is godep, which has the ability to pin revisions
on your dependencies. That is, it'll look at the git commit hash (or equiv for
hg/bzr/svn) for every repo that you depend on, and record it in a file in your
repo. It can then reset those dependencies to those specific hashes. Then all
members of your team just need to use godep to make sure they're all using the
exact same git commits for all dependencies. Bam - now you're insulated from
someone updating a dependency with breaking changes, and your team can test
new revisions and decide when they want to start using them.

Godep has a second function that lets you copy all your dependencies into your
repo and renames all import statements to reference the copied paths. This is
an even more extreme version of the above, which not only insulates you from
changes in dependencies, but also insulates you from those dependencies
disappearing entirely.

~~~
notduncansmith
Godep is definitely a good tool. One thing that gives me pause, though, is
that this functionality is not built into `go get`. Failing to put hard
versioning into the canonical package manager seems short-sighted to me. I'd
much prefer that over something like the race detector.

------
err4nt
> My wife often comes out into the yard and asks me: “are you coding?” Often
> my answer is “yes”.

I think I need this quote in my kitchen! My girlfriend often pounces be with
the accusation "YOU'RE NOT WORKING" if she sees me out of my chair moving
around, doing mindless house chores or half-vacantly tossing a cat toy around
the house, or running errands, but the reality of _design_ is that it happens
all day. And when you're done 'work' for the day, ideas and solutions still
happen.

I'm working in the shower, I'm working all evening. I'm working waiting for
the bus. I can either let it pass or write it down, but I can't seem to shut
it off.

But I don't mind. I've been learning to slow down too. I used to be a
perfectionist and when I was billing a client I would only bill my butt-in-
chair-and-head-down time as billable hours, but lately I realize if I sit and
think, plan, and research for 2-4 hours, and spend 2-4 hours implementing the
results of that thinking, I get more done each day than 8 hours of butt-in-
chair-head-down typing.

They key is to approach it as design, and that's where my training as a
graphic designer comes in handy. The Design Process was drilled into out heads
and I've only recently been applying it to my coding :)

~~~
a_e_k
"Sunday: Lay on my back most of the day, reading, sleeping and day-dreaming.
Very literary. Some women, however, resent it, so young writers should choose
their wives with care. Many a promising career has been wrecked by marrying
the wrong sort of woman. The right sort of woman can distinguish between
Creative Lassitude and plain shiftlessness."

\-- Robertson Davies "The Writers Week" (1959)

------
serve_yay
> The casualty of my being a slow programmer among fast programmers was a form
> of dysrhythmia – whereby my coding rhythm got aliased out of existence by
> the pummeling of other coders’ machine gun iterations. My programming style
> is defined by organic arcs of different sizes and timescales...

Boy oh boy. Look, I'm all for coding slow, taking time and understanding what
you're doing. But there is something to be said for "playing well with
others". We're all trying to make things, not be the backdrop for your
exquisitely-crafted sense of craft.

To me that reads a lot like "I would have done something really good if I
weren't surrounded by those philistines". Well, maybe so, but you are
surrounded by them. So choosing a method of working that does not result in
"dysrhythmia" or whatever strikes me as rather prudent.

~~~
jerf
"Everyone around you is building this bridge in clay.... what are you doing
fooling around with this 'steel' crap for?"

Of course you can spin it the other way too, which just goes to show this
isn't a useful comment. Don't do what everybody else is doing just because
they're doing it, do the right thing. If that does happen to be clay, great,
but there's a great deal more people using inappropriately sloppy engineering
than people using inappropriately careful engineering, so I'd expect to hear a
lot more about the former.

The only people in real life that I've met that I would consider saying were
being inappropriately careful were really just masking fundamental
incompetence under a veneer of concern about process. I'm not sure I've ever
seen _anybody_ correctly apply massive overengineering to a programming task
in real life. I'm absolutely sure it has happened, but it is not common enough
to be worth talking about.

~~~
serve_yay
Don't do what everyone else does if you can do something better that leads to
better results. The last part matters -- otherwise you're just crapping on
everyone who can go faster than you and attributing the difference to
"quality" (conveniently left nebulously defined).

Put another way, how do you know what you're working with is steel, and others
clay? What if your "steel" is really just clay that is slower to produce and
more brittle? How do you reassure yourself that this isn't the case? The
answer is, make a big deal about going slower and drink tea and stroke your
beard and say "hmmmm." and lots of other things that connote wisdom but do not
actually bring it to bear.

I am extremely skeptical of all this, not because I am unsympathetic but
rather the contrary. We can get extremely wrapped up in our signifiers of
skill and wisdom, to the point that we mistake the map for the territory.
Instead of cursing the punk kids, try to learn from them and beat them at
their own game.

~~~
jerf
Thank you for repeating my own point back at me and making it sound like
disagreement.

~~~
HCIdivision17
I find this sort of thing _fascinating_. I think it nicely showcases how
perspective matters on this sort of thing. I almost feel like the whole
fast/slow dichotomy is missing the point, since you can have two polar
opposite views agree. What the point it... well, I guess that's why there's
hundreds of replys in this thread.

------
m0nastic
I hesitate to recommend my process to other people, because I don't think I'm
a very good programmer.

But for the past year or so, I find that I program best by actually writing
out my program in a notebook (in my case a quad-ruled lab notebook). I don't
even start typing until I have it laid out pretty much in it's entirety on
paper.

This sounds ridiculous (and I can imagine it's not practical for all types of
programming), but I've found that it's been tremendously helpful in getting me
to understand what all the code that I'm writing does.

Most of the code I've written this past year has been in Haskell, so that
helps somewhat by not having a lot of syntax to write down, but I'm sure I'd
be doing the same thing even if I was writing in Java.

~~~
beat
Paper is my favorite programming tool. The beauty of paper is that it's easy
to find out when you're wrong, when you're pursuing the wrong path, without
going deeply in and getting distracted by the small-scale details of the code.

This gets right back to the design thing.

~~~
jschwartzi
To put it another way, it's far less time-consuming to edit a Word document
than it is to update an entire production system.

~~~
beat
No, I need to get away from the computer completely. Word docs (or any other
computer typing) is still bound by the computer structure and the computer
distractions.

With paper, I can draw graphs of relationships, write tables, add notes to
things I drew earlier, etc. It's far more expressive, and far faster, than any
computer tool I've tried.

------
dansingerman
You get shitty fast programmers and shitty slow programmers. You get good fast
programmers and good slow programmers too.

'Fast' or 'slow' in isolation are not really a measure of anything valuable,
except perhaps how an individual fits into the team culture.

The crucial thing to measure is how long it takes to get to good, robust
software that does what it needs to do.

There are many strategies to achieve that (agile or big design up front or
others) but software engineering as a medium is too immature to have found the
one true way (maybe there will never be a one true way). Up front design and
emergent design have both succeeded and failed on many occasions.

This post reads to me as someone who doesn't like working with younger teams
as the work style often doesn't fit, and therefore concludes the team's
working style is wrong, rather than he just subjectively doesn't like it.

Most of this thread sounds the same to me too.

Maybe the benefit of a fast programmer is it is quicker to find out if they
are shitty?

I'm 42 and consider myself fast-ish FWIW.

~~~
hawleyal
Agreed. I am fast, but refactor constantly, so there really is no "final" code
or "finished" result. The current form is continously honed and refined. My
cycles are very quick, however the design is not rushed but rather well
thought out over many iterations.

------
JackFr
He makes a reasonable point, but this piece is largely a strawman. And

> For the same reason that many neuroscientists now believe that the fluid-
> like flow of neuronal firing throughout the brain has a temporal
> reverberation which has everything to do with thought and consciousness,
> good design takes time.

is just pure nonsense.

~~~
thaumaturgy
> _but this piece is largely a strawman_

In what way?

~~~
JackFr
> As long as everyone makes frequent commits, and doesn’t break anything,
> everything will come out just fine.

He is presenting the arguments and beliefs of his intellectual opponents in a
way they probably have not or would not, and then attacking that argument.

Now in a piece like this there is nothing wrong with that -- but in terms of
the strength of an argument, it is no greater than just enthusiastically
stating his preference.

------
elwell
> "I’m Glad I’m not a Touch-Typist."

Yes, typing speed, when looked at in isolation, does not _cause_ the
production of high-quality code. But there is an argument to be made for
reducing the friction between one's mind and the code on the screen. Insofar
as we can ignore that transference of data from biology to technology, we can
think more fully and clearly. So, emacs commands that are fully ingrained in
one's subconscious may be good, but probably not the C-u 12 C-x TAB; at least
for somebody simple like me.

~~~
hasenj
I used to believe that. It's why I picked up coffee script. I thought, the
less there is to type, the more you can focus on the problem rather than the
code.

I found out I was wrong.

The redundancy actually helps. There's somehow a calming effect in it. I don't
know how to put it into words.

I found out that I never actually think while typing per se. I have to first
jot down my thoughts on paper. Typing out the code becomes almost a mechanical
process. I already know what I'm typing, I've figured it all out and put it in
paper (or some plain text note in another text editor or note taking app).

There's stress in trying to hold it all in your head. That stress is released
when you jot things down. Then you can just mechanically write out code with
less levels of stress.

The explicit syntax means you have more to type but less to think about.

I know it sounds paradoxical. But that's been my personal experience.

~~~
m_mueller
It's not paradoxical at all. I think that the more syntax you have (thus
shortening the code), the less you can reason about what you write _while_
writing it, because the mental overhead of writing itself goes up. Compare
stenography to latin in that regard - stenography is almost never used to
write down ideas, only to transcribe.

------
elwell
Brings to mind Rich Hickey's support of so-called "Hammock Driven
Development":
[https://www.youtube.com/watch?v=f84n5oFoZBc](https://www.youtube.com/watch?v=f84n5oFoZBc)

------
larrys
"I’m Glad I’m not a Touch-Typist."

Have to disagree with this 100%. A touch typist can always hunt and peck if
they want to or need to for some reason (would love to have a reason for this
being a benefit though). Being able to touch type helps greatly with just
about everything when you are using a keyboard. Sending emails, writing
letters, filling out forms, coding, the command line and so on.

Not only that but it's extremely easy for the average person to learn to touch
type (I learned from a book and was proficient after about 3 week).

I really can't think of a good reason (other than taking the time to learn
which as mentioned is easy enough) to not learn to touch type. I think it's
one of the least talked about productivity boosts out there.

~~~
KedarMhaswade
+1. I am a bit sad that the author chose to downplay the (usefulness of) touch
typing.

------
angersock
I'll disagree with a few points here.

First, I think that the key is a mindset, not an age--I'm the youngest person
at my company and yet I'm consistently the one pushing for smarter, smaller,
better-designed solutions to our problems. It seems that a lot of people,
especially those with an academic background, forget one of the three
qualities of a good programmer: extreme laziness.

Developers (often younger ones) that manically hop from framework to framework
and sprint to sprint because design work is "too slow" end up expending more
energy than if they'd just been lazy and really _thought_ about what they
wanted to accomplish before they worked on it. This is especially true in
business, where that mindset is invaluable for skipping work you'd otherwise
do while finding fit.

Second, I disagree that on a good team engineers aren't fungible: the fact is
that, if you have one person who "owns" a part of the code, you are inviting
disaster and bad design. This, and not its converse, has been proven to me
over and over the last decade. Sure, one person might have the domain
expertise or familiarity with something to really nail it, but they should
_never_ be the only one on the team who can do so.

If they _are_ , you slip them pizzas under the door, make them happy and
productive, _and then sack them as soon as you can extract their knowledge for
they are a liability waiting to turn into a problem_.

Third, and perhaps most controversially, the author supposes that good design
is important. For almost any business, sadly, it isn't. Nobody gives a shit
when you have deadlines to meet and bills to pay--and if you're lucky, you can
push that burden up onto the next poor bastard to inherit the codebase after
you've cashed out.

I really, really wanted to believe that good design mattered, that somehow it
had intrinsic value. Sad thing is, it doesn't. BeOS failed. Plan9 failed.
Inferno failed. Transmeta failed. Sun and SGI failed. Smalltalk failed. Lisp
failed. Erlang failed (and cleverly stood back up, but not because the
majority knew or cared about design).

~~~
fsloth
" if you have one person who "owns" a part of the code, you are inviting
disaster and bad design. "

I think we have different definitions of ownership. To me, ownership signifies
that a certain person is aware of the history of a particular area of code, is
responsible for keeping it in good shape and is usually the go-to person for
all modification, or at least code reviews all work done to the code.

This does not mean that they should be the only one who understands it and has
the ability to modify it.

I think we both agree that the understanding of the code should be dispersed,
so that any other employee can get up to speed with the code just in case the
prior owner exits the organization.

I'm working at an organization that some parts of which do development in the
"share all" mentality and some of which try to maintain code ownership in the
way I described. The code ownership strategy seems to work much better, but,
YMMV as always.

When the code ownership is not made explicit, actually there can develop
pockets of "accidental ownership" even in the "share all" codebase. Something
that only one person has ever touched, and who does all the modifications
because all the organization needs is a tiny, quick tweak, and the codebase is
already a hot mess after endless amount of these "quick tweaks".

"I really, really wanted to believe that good design mattered, that somehow it
had intrinsic value. Sad thing is, it doesn't. BeOS failed. Plan9 failed.
Inferno failed. Transmeta failed. Sun and SGI failed. Smalltalk failed. Lisp
failed. Erlang failed"

Those all are large scale systems, so I cannot speak for them.

However, in the scale of day to day coding, I've usually attempted applying
good design to all of my prodcution code and usually the only feedback I've
got from my way of working has been positive. I've shipped on time and the
bugcount (for all I know) has been low.

So, based on my experience, I really cannot concur with you.

Perhaps our experience from software development is from a completely
different business area. Professionally I specialize in performance critical C
and C++, 8 years and counting so perhaps I've not been long enough in the
field just yet to witness the fail of good design.

~~~
angersock
I suspect our experience is indeed different. :)

I've had the good fortune of working with good programmers doing performance
critical C and C++ for a hobby project--the time spent in design has paid off,
and the codebase is a joy to work with. Sadly, the code has yet to see the
light of day, because _reasons_. For the purpose of "get game project
finished", more bad code faster probably would've been better, though we
would've had to rewrite it anyways.

As for the rest, I've been in a few shops now where people who should've known
better (or who didn't!) have written klocs and klocs of unmaintainable poorly-
performing garbage and who subscribe to the "code owner" philosophy. The
result is, of course, that you can't _fix_ or even _organize_ their messy
fiefdoms, and so there is no peace-of-mind to be had that the code works. And
yet, the businesses still trundle along to this day despite what is probably
stage 4 cancer of the IP.

Maybe it's just Stockholm syndrome. I kind of feel like an abused puppy every
time I have to look at that code and fight, for hours and weeks, to do
something as basic as "Hey, maybe we should try both debug _and_ release
targets!"

------
leeber
I probably spend just as much or more time sitting, thinking, and staring at
partially written code, than I do actually writing the code. It's frustrating
when you have superiors who don't understand that time spent _thinking_ is
just as productive as time spent typing.

That's just my personal style, although I've never worked in "large" teams on
a single codebase so can't comment on what styles work best in those
situations.

~~~
mVChr
The best analogy I heard for communicating this to superiors is that
programming is like doing a crossword puzzle. 95% of the time you're doing a
crossword you're not writing but that doesn't mean you're not intensely
working on solving the puzzle.

~~~
GFK_of_xmaspast
You need to get better at crosswords.

~~~
mVChr
I'm talking NYTimes Sunday crossword here, not your in-flight magazine.

------
BhavdeepSethi
And yet, most coding rounds in interviews are rigorously timed. Almost always,
the importance is given to code completeness rather than code design/elegance.
I'm sure a lot of talented engineers lose out here.

~~~
Swizec
> most coding rounds in interviews are rigorously timed

In the real world you will have to work against a deadline. As much as code
gardening is fun and does produce better software, in the real world _shipped_
software always wins over well designed software.

Can you get it done, is a more important question to answer than can you make
it beautiful.

~~~
BhavdeepSethi
In the real world, you'll be spending more time on code design than typing it
out. The race against a deadline mostly affects design choices. eg. Whether
implementing a certain feature yourself with rigorous testing, or introducing
a new technology which has been tested before. There are pros and cons of
each. You go ahead based on the constraints involved (time, cost, expertise,
etc.). I'm not talking about making the code beautiful. I'm talking about the
/right/ way to do it.

------
cxseven
John Draper, AKA Cap'n Crunch, made a great case for it: "It was a perfect
coding environment, coding in jail. [...] Those long nights without the
computer really got my smarts in top gear, as I really focused in getting the
code perfect and bug free. Not having a computer some of the time, got me to
thinking more about writing good code, and less time debugging. During this
time, I wrote a really cool FORTH debugger that allowed single stepping
through FORTH code (Totally unheard of in those days).

I also write a De-compiler that would take the compiled FORTH code and re-
generate source code. This was invaluable in tracing down some gnarly compiler
problems in FORTH. You see, I was not only writing a word processor, but I was
also developing the language on the fly as well. Modifying the compiler,
interpreter, and I even write a DOS (In forth) to manage the easyWriter text
files, because EasyWriter didn't need DOS. So I implemented one, using a FAT
(File allocation table) and all that other Gnarly Disk Operating system low
level code. I found out that FORTH allowed me total flexibility. If the
language didn't have a feature, I implemented it. Simple as that.

The day finally came when I was to be released from jail, and Matt had already
rented a fully furnished apartment in West Berkeley for me, and met me at the
jail when I was released. That evening, we met at the IHOP on University Ave
to sign the contract YAY!! and the incorporation papers YAY! Now we can call
ourselves Cap'n Software Inc. We rented office space on Telegraph avenue a
block from the UC Berkeley campus and called it our "Corporate Headquarters".

Soon we got our first royalty check of $3500, and I gave Matt $1000 of it and
put him on a salary. Michelle, Matt's roommate and holistic friend was hired
on as our Secretary, and handled all of our bookkeeping. WOW!! I get out of
jail and in 24 hours, am president of my very own software company. SUPER
COOL!!"
[http://www.webcrunchers.com/crunch/Play/ibmstory/](http://www.webcrunchers.com/crunch/Play/ibmstory/)

------
PythonicAlpha
The best solutions don't come from hacking, but by grasping the problem and
it's full scope, the chance raises that you find a solution that can not only
be used for the current problem, but also for similar other problems. A good
programmer always tries to find similarities and to reuse old solutions in as
many other areas as possible, but not more.

Such a behavior also boosts the maintainability of the solution. On the other
hand, when it is ignored, a solution quickly can become unmaintainable and the
solution that was implemented so "quickly" can become a black hole of man
power.

I personally experienced more than one project, where the source code has
become in very short time so complex and so bug ridden, that development times
literally exploded.

------
ludoo
Very well put. I have a similar (slightly younger) age, and often pose myself
the same set of questions on speed, tooling, typing. Needless to say, my
answers are very similar to yours.

As for the Design Process, it works in the exact same way you describe in
other fields like Architecture, which I studied and practiced ages ago at a
more than decent level.

Money (VCs'), the myth of the young billionaire, and a few other things are
probably what make developing different.

------
bko
This article reminded me of something I read in the Vanity Fair article about
Sergey Aleynikov, the Goldman programmer[0].

>He’d been surprised to find that in at least one way he fit in: more than
half the programmers at Goldman were Russians. Russians had a reputation for
being the best programmers on Wall Street, and Serge thought he knew why: they
had been forced to learn programming without the luxury of endless computer
time. “In Russia, time on the computer was measured in minutes,” he says.
“When you write a program, you are given a tiny time slot to make it work.
Consequently we learned to write the code in a way that minimized the amount
of debugging. And so you had to think about it a lot before you committed it
to paper. . . . The ready availability of computer time creates this mode of
working where you just have an idea and type it and maybe erase it 10 times.
Good Russian programmers, they tend to have had that one experience at some
time in the past: the experience of limited access to computer time.”

Even while he was in prison he managed to code:

> A few months into Serge’s jail term Masha received a thick envelope from
> him. It contained roughly a hundred pages covered on both sides in Serge’s
> meticulous eight-point script. It was computer code—a solution to some high-
> frequency-trading problem. Serge was afraid if the guards found it they
> would deem it suspicious, and confiscate it.

That kind of discipline and meticulous thought is very hard to build in to
someone who has never had these kinds of constraints but it is certainly an
admirable goal.

[0] [http://www.vanityfair.com/business/2013/09/michael-lewis-
gol...](http://www.vanityfair.com/business/2013/09/michael-lewis-goldman-
sachs-programmer)

~~~
logicalmind
This is a good point. I am not Russian but I learned programming in the same
way because I started out doing embedded work. Where a build/deploy/test cycle
could take hours to an emulator and debugging was very unfriendly. If you did
not do rigorous thinking about your program and what you were doing, you could
waste huge amounts of time. I no longer do embedded work, but the mentality
has stuck. When I commit my work, it tends to have fewer bugs than what my co-
workers produce.

------
overgard
I kind of disagree with the premise here, from my own experience, it's much
better to work fast but ruthlessly refactor and never be afraid to delete your
own code. I find I rarely nail things on my first attempt, but by being quick
and failing fast, I learn more about the problem domain and I end up with a
nicer end result than the person that agonized about their decisions rather
than trying things out. (Of course, the corollary is that I usually do these
things on a branch so I'm not inflicting it on my coworkers)

The problem with doing a big design up front is that you're generally going to
run into _something_ that's surprising, that you didn't account for (unless
what you're doing isn't novel -- but then, why are you writing code rather
than reusing it?) I think when people get all ponderous about these things,
they're not really learning about the problem, they're just procrastinating.
We're not building bridges here, if your first attempt isn't brilliant you're
not out a million dollars of concrete.

~~~
cgearhart
It depends a lot on the problem domain. Sometimes rapid prototyping is a
useful tool, but the benefits rapidly diminish in the face of complexity. In
my experience with moderately complicated scientific and mathematical
software, there isn't anything to prototype - either it works, or it doesn't.
If you aren't deliberate about design choices, the bugs can be really devious
to find and squash.

~~~
overgard
I think the implication of this article is that fast = reckless, but I
disagree with that. Sometimes you recognize that you need more data points,
and writing _something_ that works will move you closer to the correct
solution, even if the first version isn't perfect.

But yeah, it depends on the problem domain. If you're asking me how to build a
website, I can probably have a pretty solid idea of what that code should look
like. It's not a novel problem, usually. If you're asking me to build, I don't
know, a voxel renderer and you're trying to figure out if an octree is the
right way to go for representing the data, or you need to do something more
exotic, I'm gonna have to play around a bit.

------
keithnoizu
The Author lost me at "I'm glad I'm not a touch typist". Coding isn't about
typing at the same time when programming you should be writing code not
thinking about where the semicolon is. I type and interact with my IDE
incredibly rapidly. Generally my ability to type quickly is not the bottle
neck. Sometimes it is. When it is I'm glad I can do it as rapidly as I can.

Meanwhile I agree with other comments that slow programming is the wrong word.
You can rapidly write quite a bit of code with out needing to resort to
hacking or avoiding best practices. It depends on your familiarity with the
space and ability to properly construct the problem in terms of implementation
quickly.

The point here is that you work at the appropriate pace and put some sense of
craftsmanship into your work. I doubt that over the course of a sizeable
project the approach of being diligent versus hasty is going to result in the
diligent programmer tacking longer to get the same amount of work done.

------
maerF0x0
You have decades on me and I still wish to work your way. It maybe anecdotal,
but the more timepressure a codebase has been under the less i've liked it,
roughly speaking.

------
n3t
Speaking of touch typing, there's a must-read [1] which made me learn and
practice this skill.

[1] [http://steve-yegge.blogspot.com/2008/09/programmings-
dirties...](http://steve-yegge.blogspot.com/2008/09/programmings-dirtiest-
little-secret.html)

~~~
cesarbs
I usually really enjoy reading Steve's posts, but I have a hard time with this
one. Many great programmers admit to being clumsy typers (IIRC Joe Armstrong
mentions he's a poor typer in his interview in Coders At Work).

------
ThomaszKrueger
A lot depends on who you are programming _for_. Usually it is for a company
that places more importance on a deadline than anything else, including
quality. Other "ilities" are even less relevant. So you just hunker down, and
produces something that "works" very fast. For, say, a small dataset.

Then either the project finishes (abandoned sometimes), or it grows
(exponentially sometimes), and what was created fast no longer is usable. So
you do it once again, now to support the new requirements. And so on.

We are constantly rewriting systems, as we continuously copy data from
different media. It keeps us employed. It is much easier to be remembered for
doing something fast than for creating something that lasts.

------
realrocker
Only few businesses want a well-crafted software. Today's startups are
endeavors of treasure hunts. You build a ship just good enough to hit the
island. If it doesn't work out(which in all probability it won't) you dump the
ship. If it does, you still dump the ship. There is a element of expected
failure in the current enterprise of writing software which calls for and
pushes people to knowingly write bad fast software. As the author says it will
be faster to write slowly if the goal is to write good software. But the goal
is rarely that.

------
Adam89
How does typing speed affect the design of software?

Thinking about your design has not got a lot to do with the speed you type at.

Secondly as programmers we should be able to work on the same code base.

~~~
swalsh
As women we should be able to birth the same babies?

After the baby is born anyone can raise the child, some better than others,
but its easy. We call that adoption. Until its born though, the baby, and it's
mother are symbiotically connected to each other.

I think this is similar to the process of programming. Break down an
interface, and work on a team at that level. Behind the interface though, keep
it small. one or two people max if possible, and those people have to be on
exactly the same brain wave as each other. Even well planned code takes some
time to stabilize, and it's hard to even find that if other people are
actively changing interfaces etc.

~~~
Adam89
I really like that analogy but am not sure if that's what the author was
alluding to.

Besides the one thing I strongly disagree with is how typing slow can help you
produce better software.

Taking time and thinking about your design certainly does help but typing
slowly and taking your time designing are not the same thing.

------
markbnj
Also in the largely-agreed camp, and probably unsurprisingly I'm about the
same age. But unlike some I don't have a problem with the word "slow." Yeah,
it has negative connotations, but it's clearly meant as an ironic counterpoint
to the culture of speed. Whatever, as long as it will get the young guys I
work with to figure out what the problem is before trying out a solution, I'll
be happy.

------
lyudmil
In general I think there is a case to be made for "slow" programming, but this
article falls short for me. I happen to think that software development is a
knowable discipline, that we're in the process of figuring out how to build
the kinds of systems we need and struggling with a new kind of engineering
where there are no physical constraints.

Therefore, I think we have a lot of exploring to do in order to come up with
practices that reliably lead to better software and certainly the speed of the
development process and the number of iterations is an important thing to
experiment with.

However, the post is too wishy-washy to teach anything meaningful. What does
"dot my i's and cross my t's" mean in the context of software development?
What does "something like implementation-ready code" mean and why is it
useful? How do I, as a person separate from the OP, get from where I am today
as a developer to the super effective zen-master you're telling me I could be?
I'd love to read that post, because the one I just read makes it seem like I
should wait to get older and take up gardening.

------
jroseattle
IMHO....

This can be appropriate in certain scenarios. It royally sucks for other
scenarios, though. Measure-twice, cut-once is a great development strategy.
However, iterative-fast can have as many benefits as slow-and-steady.

Are you certain about your feature set? Must the feature be everything we can
imagine when it's released for the very first time? Are there umpteen other
things that also need to be addressed in the allotted amount of time? Are you
sure you're not over-engineering a solution?

The biggest issue with slow-and-steady: cost and time-to-market. Of course one
can argue "but cost is actually lower" and "time-to-market for a solid product
will be the same or less", but (for me) that equates to _any_ iteration having
zero value along the way. And for us, that's just not true.

I'm default-wired to well-thought systems and architecturally sound
operations. I would certainly like to deep-dive into our codebase and bring it
to a beautiful state of robustful bliss. The only problem is -- I can't afford
it right now. Maybe later, but early in our lifecycle, speed is more valuable.

------
ncphillips
This is exactly how I work. It can seem a slower when you tell your boss you
just scraped everything to start over, but it's actually super efficient. It
never takes nearly as long to rewrite an application. On my latest proejct for
example, I took 1 week to think about the problem and play around with
different data schemas, then I spent 3 weeks writing the program. It worked
well enough, but there were a lot of holes, and it was a god damn mess to
read.

I rewrote the entire project in two days. That's right, what took me 3 weeks
of playing around only took me 2 days the second time around, and it was well
worth the effort. The refactoring increased security tremendously, and made
many parts of the code so much cleaner and readable it brings a tear to my
eye.

What's even more important is that I was able to easily add new functionality
which would have taken a lot of effort to implement because of the way things
were written before. Had I left things the way they were, or tried to refactor
without a complete rewrite, I would have just introduced more bugs and got
really frustrated.

------
beat
"There's never time to do it right, but there's always time to do it over".

This reminds me of something I've been saying for a while. I'm a practitioner
of TDD - Test Driven _Development_ , not Test Driven Design. I like test-first
coding not because it's faster, as many proponents claim, but because it's
more comfortable and thoughtful. It forces me to slow down and think about
what I'm actually doing. I don't think I'm any faster when I'm coding to
tests. I do, however, feel much safer. I hate that feeling of cranking out a
bunch of code, then it breaks, and I don't know what broke or why.

But good design is absolutely _not_ an emergent property of the process of
coding! Thoughtless coding leads to poorly structured spaghetti. Well-tested
spaghetti is still spaghetti! Good design is always a matter of compromises.
You can either make those compromises in a conscious and thoughtful way, or
you can close your eyes and hope for the best. Good luck with that.

~~~
diltonm
>> But good design is absolutely not an emergent property of the process of
coding!

>> Good design is always a matter of compromises.

You need to have coded something to have shined the flashlight into the
darkness so you can put a few dots on the wall and start envisioning a path. I
have small scrap projects to let me shine the light and see what reflects
back.

------
sytelus
It's not about being fast or slow but being in a flow. You don't want to go
faster than you can or intently slow down. Unnecessarily long design cycles
inhibits experimentation and may cause you to loose touch with reality.
Artificial push for speed up is probably even more harmful. So I would vote
for "flow movement".

------
EdSharkey
Lack of design in software nowadays was cited as a problem in the post. I
agree, and I think there's a lot of not-classically educated hands out there
that wouldn't know a good design document from bad. Nor would they have any
practical knowledge of a combination of: how to structure code in large code
bases, test their code, converse about/apply software patterns, document their
API's for public consumption, RAII, SOLID, TDD, etc. So, I think there's
little hope for improvement in software quality/design/success metrics/etc.

Big up-front design only satisfies document weight tests and typically does
not stay up to date with the software. So, just simply saying "we need more
design" is not going to get us anywhere but hell.

Self-documenting code is a nice idea, but scales only so much in a large
codebase. UML is a bear to produce and maintain, and I only really like it in
whiteboard discussions, not actually drawn in a tool.

Wikis devolve into a mess of disconnected ideas.

Successful teams I've been on tend to rally and organize designs around the
already generated documentation (like JSDoc or JavaDoc), but those docs often
only focus on the user-facing API's and leave the internals as a partially
documented wasteland.

A few teams I've been on had a scribe, which was sweet, but not usually.

What patterns of design and documentation actually work well for you in real-
world, large project/team scenarios?

Regarding needing an aged "adult in the room" to guide the fledgling
developers to glory, as I think the OP suggests is an answer to the problems
... Well, in my many experiences where imparting wisdom from on-high was the
goal, that has been a miserable failure. It was all because said "senior
architect" or whatever the title was invariably only cared about blessing
random big decisions randomly/destructively and had otherwise checked out to
walk his dog after lunch and otherwise coast during his pre-retirement. All I
can say is, God bless 'em.

I do NOT count on age as a factor, only that a developer has reached a certain
point of experience in their career. What I DO count on is one person who can
enforce a clear vision with passion. Who holds the torch for your team? Is
their grip shaky or firm? Where are we headed? Are we headed there with
conviction? Does the end goal still seem plausible to all hands after every
step we take? If you have proven you've got the chops and can back up all your
assertions with creditable past successes and/or literature, you can rule your
team and demand excellence - YOUR excellence! Pick a darn direction and let's
go! I have total respect for that someone that has a coherent vision AND can
communicate it.

Agile methodologies sound plausible to address design and software
productivity issues, but I have yet to see exceptional results from an agile
project vs waterfall. This is probably just because software is a hard thing
to do well in any case, and is subject to political winds, funding,
ineffective product owner, etc.

~~~
einhverfr
I would agree but I would also say that good design takes a lot of time and
practice to get right. You don't want to design too much up front, but you
don't want to design too little. The top-level design really shouldn't be that
detailed. The component design should get progressively more detailed.

One of the best things programmers can do is to learn software design and I
don't mean UX design but rather API design. Be conscious of what you expose to
the world. Be conscious of your interfaces. Design your interfaces. Think
through error conditions etc. This allows you to push a lot of component
design down to the people actually doing the work.

I have been instrumental in pushing my largest client at the moment from a
fast programming mentality to a contract-oriented design mentality. The goal
is to speed up the development of those components that need to be developed
in a more agile manner by providing greater stability in a platform they can
rest upon. You can't program fast if the ground changes under your feet (or
rather you can but you will never get anywhere).

------
tobyc
I definitely see the value in taking the time to design things correctly and
making sure you're evaluating all angles — I'm not sure if it's 100% necessary
to say that to do that you always need to be slow though.

I think the difference between a fast programmer and a slow programmer often
isn't that the slow one is methodically designing and making everything
perfect, it's that the slow one has so many more inefficiencies in their
workflow.

A good and fast programmer generally knows their tools inside and out, and
they're willing to learn new tools when they need to (and not dismiss them
because their current setup works good enough and it's what they know).

Speed isn't an indicator of good or bad quality. I would say that both mastery
and improvement of tool is more of an indicator.

------
oldpond
One of the key points in the article is that the OP had lots of experience
with Bay area startups. This could be part of their culture. If you use agile
you can achieve a code velocity a touch higher than standard, and if you
really want to push the limits you can. I agree, however, that good design
takes time. I was at a conference in Sweden last year, and the conference App
was a bit problematic. The poor dev team was chained to their keyboards right
in the middle of the breakout area trying to fix it in real time. I felt like
saying, "Guys, it failed, go enjoy the conference."

My experience lately in "normal" shops (non startup) is that the skills sets
are just plain missing. It's hard to find anyone that can code at all, let
alone code fast.

Good post. Thanks for this.

------
kentpalmer
Software Craftsmanship Vision See
[http://kp0.me/SoftCraft](http://kp0.me/SoftCraft)

The problem is that Software is in fact a new kind of object, i.e. it has a
different ontology from most other objects which is defined by what is called
Hyper Being by Merleau-Ponty and Differance by Derrida. This is in
contradistinction to most objects which are either Pure Being (present-at-
hand) or Process Being (ready-to-hand). Hyper Being objects are defined by
Derrida in terms of differing and deferring, but we can talk about instead
decoherence and delocalization of Software. Delocalization has to do with the
fact that design elements are spread out within programs and in spite of
object oriented design are not self-contained at the program level.
Decoherence has to do with the fact that programs lack internal coherence
intrinsically due to the nature of general purpose programming languages and
their multi-paradigm nature and the solution to this is aspect oriented
programming which attempts to render coherent elements that are non-
localizable. But neither aspect oriented programming nor object oriented
programming completely solve the problem of the intrinsic quantum like
properties that occur in software. Software designs are like classical physics
in relation to the quantum like nature of software. See my original paper on
this called Software Ontology at
[http://kp0.me/SoftOntos](http://kp0.me/SoftOntos). There are in fact various
ontological levels identified in Continental Philosophy and beyond Hyper Being
is Wild Being and Ultra Being which both have implications for our
understanding of Software.

Also I don't see any reference to Fast and Slow Thinking by Daniel Kahneman.
There is some basis for understanding the difference between Fast Thinking and
Slow Thinking in his work. Fast Thinking makes up narratives on the fly while
Slow Thinking creates arguments more ponderously. Actually in Software
Craftsmanship we need both and we need to balance these two forces in the
patterning of our development processes.

Kent Palmer [http://kdp.me](http://kdp.me)

------
paul7986
To all the web agencies who expect jobs (design, code it & WordPress it with
custom post types) a mid-size website; 20 to 40 pages) that take 60 hours to
be completed in two to three days (pay you for 24 hours of work only) you can
go take a flying leap.

This industry especially in the web agency world has me burnt out. The
agencies all are in competition with each other .. lowering costs and thus
expect their people to get things done in manner where their employees have no
life but getting their work done. It's exhausting and the work is not very
fulfilling.

Now I have done the same work at Fortune 500 companies and for someone with a
family and who wants a balance work & family/social life that is where you
want to be!

------
Arzh
> And the latest clever development tools, no matter how clever, cannot
> replace the best practices and real-life collaboration that built
> cathedrals, railroads, and feature-length films

There is really one design process with all of the great cathedrals, railroads
and films. One person is designing and running the show. It really just reads
like this guys doesn't like to work with people who like to work by committing
a lot. I work with a programmer that is in his late 50s and he likes to work
as the writer does. I can get his same level of results with my method, which
is much 'faster.' It's not that I am much smarter than him we just have
different ways of doing it and we get the same success rate.

------
pauldprice
Glad he doesn't touch type? What a lame excuse for not mastering the tools of
his trade! That's like a carpenter saying he's glad he never properly learned
to use a hammer. There is a time and place for a steady pace and thorough
design process, but not in the early stages of a startup. If you can't keep up
with your user's feedback and market demands then you'll lose to a scrappy
team that can, no matter how beautiful and elegant your code. 95% of software
startups that become wildly successful were built on an initial base of
excrutiatingly ugly code. Gold plating code for a business that is bound to
change directions is a great way to ensure failure.

~~~
shizzy0
Yeah, who needs entering code to be a challenging "mini-game" instead of an
automatic, non-thinking skill of typing?

------
chillingeffect
Great intent, but modulating speed is only one of several important vectors
toward good code architecture.

I would add planning out on paper, in (small) groups. Also, reviewing designs,
objects, protocols, schema, etc., before writing code. The author mentions
thinking while gardening, but that doesn't share with others. Also, planning
for the future, for maintenance, debugability, verification, validation, for
re-use, for modularity, for upgraded hardware and in some cases regulatory,
etc. And developing documentation before, during and after coding.

So yeah, sneaky trick to get us all to talk about our best practices by
hyperfocusing on speed :)

------
pzxc
I recently disregarded the competence of a coworker (who is in a programmer
position) because I took a class with them and saw that they could not type.
They were hunting and pecking. (This guy is 50 years old so has had plenty of
time to learn)

Is that wrong? Does being bad at typing force you to be more thoughtful and
actually make you a better programmer? Or does it just mean it takes you
longer?

My thinking is that you are not doing much thinking while you are actually
typing, so not being able to type proficiently just means you're slower and
that's it. So all else being equal, a programmer that can't type well is a red
flag.

~~~
georgemcbay
I type about 105 wpm using four fingers (my index fingers and my thumbs); I
don't touch type at all but I also don't look at the keyboard, I just know
where the keys are from muscle memory (when switching to a keyboard that is
unfamiliar to me it takes me a minute or two to adjust if the keys are
particularly different in shape/size from ones I usually use). I'm not sure
what that says about me as a programmer.

In any case I don't think it makes sense to use typing speed as a measure of
programming competence because typing speed is never the bottleneck in
producing real, useful code.

~~~
owtM
> I type about 105 wpm using four fingers

> I also don't look at the keyboard

> I just know where the keys are from muscle memory

You _are_ touch typing though. You may have an unconventional style, but that
is irrelevant.

~~~
georgemcbay
I guess it is touch typing if you define touch typing as any kind of typing
without looking, but it isn't what most people think of touch typing, I don't
have any sort of "rest" or "home" position.

~~~
alxndr
I never really considered a "home" position, but I think my fingers do tend to
end up around roughly the same keys between thoughts: [L-shift]SDF / KL;'

------
kendallpark
I feel like "agile" has come to mean "get shit done fast" in today's
programmer culture. But just as "agility" and "speed" are not the same, agile
development does not necessitate a race to the finish and similarly is not the
antithesis of the slow programming style (as some commenters seem to be
suggesting).

I think people have wrongly used agile as an excuse to implement first,
reflect later, refactor never. In the original agile movement, there is a lot
of time devoted to refactoring. You hack something together that accomplishes
your goal. You get to see how it's working, get user testing up and running,
and then reflect. But underneath the hood the program is a complete mess. This
is the time for an agile developer to go back and majorly refactor the program
into a neat, well-organized system. Maybe even rewrite. The problem is people
on the business side of things see a near-complete project that they want to
launch ASAP. It may even feel that way to the developers. I think the refactor
part of the process gets cut short because of the desire to push the product
out the door or work on new feature sets. You're only doing half the agile
process in this case.

I'm definitely not in the "plan first, build later" vein of thought. It's not
how I program or do artwork (I'm a hobby artist as well). I need time to play
around and experiment with different ideas in real-life implementations before
settling on my plan of attack. There are so many ideas that may seem great in
your head, but don't do well IRL. Additionally, you may stumble upon a new
idea in the process of experimenting.

The thing I long for the most as a programmer is more time to refactor. Time
to refine my code. There is something to be said about craftsmanship as
opposed to mere production. One thing I've enjoyed about my own personal
programming projects outside of work is that I have time to sit back and
reflect. Is this the best way of modeling X? Is there a more simple way of
expressing X? And then I can do major refactors/rewrites that would never fit
into a sprint at my workplace. But I do believe the investment will pay off in
the future when it comes to maintenance. And extra day refactoring now could
save weeks of debugging later on.

------
aoakenfo
A flurry of hacks tends to beat the "correctly designed" way:
[http://www.jwz.org/doc/worse-is-better.html](http://www.jwz.org/doc/worse-is-
better.html)

~~~
the_why_of_y
"A flurry of hacks" indicates you did not understand worse-is-better:

[http://www.dreamsongs.com/Files/worse-is-
worse.pdf](http://www.dreamsongs.com/Files/worse-is-worse.pdf)

"This advice is corrosive. It warps the minds of youth. It is never a good
idea to intentionally aim for anything less than the best, though one might
have to compromise in order to succeed"

------
UK-AL
The main issue are not the developers. In my experience its the pressure the
company puts developers under. Most developers would love to take time develop
well designed software. But most companies push, push, push for more features
in x time. The first thing that gets cut is design discusion and the ability
to go back and improve old code.

The older the developer, the harder they are to push around(They've seen it
all before, probably been a manager before) and probably why we have a agist
industry because companies like developers they are easy to manipulate.

------
jaunkst
Speed, is a constant demand. The rate that we are creating new frameworks,
languages and platforms is an all time high. We toss them away as quick as we
build them, by the time its reaching mainstream adoption we are refactoring
the core, and expecting developers to adopt the changes before they master the
first mature iteration. Born to die software is here and its going to cause a
massive fracturing. If we adopt reverse compatiblity maybe we can offset the
repercussions. I expect my code to start to deprecate in atleast 6 months in
some manner.

------
danenania
While it's true that most nontechnical managers over-prioritize speed and
underestimate the dangers of technical debt, it's also true that many
otherwise great engineers are inclined toward premature optimization and tend
to lose track of business goals.

In most contexts, an engineer that understands both when solid, thoughtful,
slow engineering is appropriate and when it's NOT is worth immeasurably more
than an engineer whose only gear is extreme rigor.

------
lonelybug
I don't understand why so many software developers/engineers believe
engineering without design is a good practice.

Maybe you should read this article
[http://martinfowler.com/articles/designDead.html](http://martinfowler.com/articles/designDead.html).

Martin fowler is one of the people draft the manifesto for agile software
development.

If you still call yourself software engineer, then, remember agile != no
design.

------
talles
He uses a picture from here in the article:
[http://designapplause.com/2012/infographics-the-variables-
wi...](http://designapplause.com/2012/infographics-the-variables-within-
design-process/31329/)

It's such a beautiful infographic, but I couldn't interpret it... anyone knows
it those are based on real data?

------
chandankumar
IMHO, writing a good program goes through lot of thought process. You keep
thinking about the solution of same problem till you get the best solution (or
at least you are satisfied with it). So it is going to take some time. But I
guess after having some experience, you will find a way to create well
designed code more quickly than before.

------
scelerat
One of the first things I learned about programming was to write the problem
down on paper. Diagram it. Don't even start coding until you have a good map
of where you're going, at least at couple levels of detail.

Most of the problems I've encountered myself or seen with others is directly
related to coding too soon.

------
meesterdude
wow, this is great! I definitely have always fallen into the "slow" camp.
Though I've always considered it more a matter of being careful and with
purpose, and not being haphazard.

Quality over quantity. Painting a wall is easy, painting a painting takes much
more precision and care, especially when you have to exercise your design
skills as a developer.

Though often, a lot of the time goes into understanding what it's supposed to
be doing in the first place, and from there it's a matter of making it more
resilient, isolated and friendlier to work with.

I'm the slowest dev on my team, but I squash the bugs that nobody could figure
out, or knew were there. Taking things apart takes time and patience, but when
you're done you know how it all works and can refactor it to be
clearer/simpler, and appropriately comment on what it does and how.

------
seanconaty
I like iterative development but I also really like the author's "cauldron of
soup" metaphor. I've definitely worked on projects where I feel like I'm
rebasing/updating more than I'm actually doing work to add any type of new
value.

------
mattxxx
I'm all for programming slowly, but how many pieces of code are built slowly,
and, in the end, turn out to be built wrong or cumbersomely?

It seems like, if you write slowly, you gotta have legitimate deliverables and
tests at every step.

~~~
shizzy0
Excuse me, are you asking for data? for evidence? We're here to assert our
opinions, speculate on what's best, and cite an anecdote—sadly.

------
atjoslin
My thoughts on this article:

"Yes, new software and new businesses need to grow. But to be sustainable,
they need to grow slowly and with loving care. Like good wine. Like a baby."

Why can't I grow quickly "and with loving care"? :-)

------
edpichler
Really liked this part: " And the latest clever development tools, no matter
how clever, cannot replace the best practices and real-life collaboration that
built cathedrals, railroads, and feature-length films."

~~~
GFK_of_xmaspast
Historically, cathedrals might stand unfinished for decades at a time. Also
the early days railroads were famous for brutally exploiting labor in order to
get built as soon as possible. Haven't you heard of John Henry?

~~~
edpichler
I haven't heard of him. I did not understand you. It seems you believe there
isn't collaboration to build cathedrals, railroads, and feature-length films.

~~~
GFK_of_xmaspast
Of course not. What I'm saying is that these are very much not examples of
well-run projects that aren't exploitative of labor.

------
monokrome
This is a good article, and the constant need to code bigger bowls of
spaghetti faster is definitely a problem. However, I think that it's a stretch
to imply that only older engineers do this.

------
ThinkBeat
I think it is sad that so much of the discussion here is about the name. The
focus is upon marketing not on the substance of the article / blog post.

------
lifeisstillgood
Thank god - there are others out there speaking my language. The ideas of
dysrythmia are spot on.

Totally fantastic - an insight well put. Thank you

------
msolujic
here is one little pearl

The sooner you start to code, the longer the program will take. Roy Carlson
Anon. University of Wisconsin

Taken from BUMPER-STICKER CS
[http://www.bowdoin.edu/~ltoma/teaching/cs340/spring05/course...](http://www.bowdoin.edu/~ltoma/teaching/cs340/spring05/coursestuff/Bentley_BumperSticker.pdf)

------
crispweed
'Slow programming' has too many syllables, and you end up having to say it
fast. Let's call it slooowgramming.

------
aabeshou
What's with describing his friend as a "mature, female software engineer"?
That strike anyone else as weird?

------
bitwize
Here are my Reddit comments on this story:

I've always programmed thus:

* Try to assimilate a mental model of the bit I'm working on, and as much of that bit's dependencies as is practical, into my head. This may involve fiddling with the code and seeing how it breaks when I do certain things to it, or hammering at it inside a REPL or similar. The bit that I'm concerned about could be a single method, but is usually larger.

* Try to develop a mental model of the bit as it _should_ be. Do a diff between the 'is' and 'ought', make code changes as necessary, fiddle with the new code to make sure the shape of its function is roughly the 'ought' shape.

* Update the unit tests with specific tests for the 'ought' case, run tests, fix failures.

* Check in or submit code for review.

This is not how software is written now. How software is written now is a
hill-climbing algorithm where each cycle is one "red-green-refactor" sequence.
Write a tiny failing test which no matter how small or trivial still has a few
lines of setup/teardown boilerplate, make the smallest possible code change to
make the tiny test pass (change minus sign to plus sign?), run the ENTIRE test
suite to make sure that your sign flip didn't break anything anywhere else, if
the code needs to be refactored do so and run the entire test suite again,
fucking repeat. There are a number of theoretical advantages to this from a
management perspective:

* Developers produce working code quickly in the early stages of the lifecycle, whereas with the slow approach you do a lot of sittin' and thinkin' up front without much to show for it -- maybe some design documents or UI mockups, I dunno.

* Development no longer relies on developers' internal mental models of the code. Developers now code against a model which is incarnate in the test suite -- itself a deliverable, documentable artifact.

* Because programmers no longer work from internal mental models but the single-bit state of "do the tests as written pass or fail?", the concept of "code ownership" \-- along with related management problems of coders waxing territorial over the pet modules they've spent days or weeks ruminating over in order to understand deeply enough to change -- evaporates.

* Programmers look busy all the time, because they are constantly typing out test code to exercise even the most trivial of changes.

* Thanks to pair programming, you no longer need worry about the "guy in a room" problem. Your dev team is always seen to be interacting with one another.

But I hate it because it is incompatible with my temperament. I like to think
about _what_ it is I intend to write, before hammering out test cases to
exercise it.

~~~
pandler
This rings true with me. Some of my best work has been done laying on my bed
(working from home) staring at the ceiling.

On one project, we initially gave ourselves a ridiculous deadline and
subsequently made a lot of ad-hoc "fuck it" decisions without properly
thinking out the consequences. The system is sufficiently complex that we
ended up with something that _barely_ did what it said on the box (if it
worked at all). I dreaded even adding the simplest of features, because I
could just feel how fragile the whole thing was.

We ultimately made the decision to scrap the project (and piss off or outright
lose some customers waiting to pay us money) and restart from scratch, and I
spent a few months part-time just building up a mental model of the system and
stress-testing it against all of the different requirements and scenarios we
had to handle. I went through a couple of notebooks in that time, but I didn't
write a single line of code.

For me, it was a lesson in the importance of deliberation and knowing what you
_should be_ building before building. As my uncle liked to say when we built
houses together, "measure twice, cut once."

------
kevin_thibedeau
It seems like most of his problems would be alleviated by working on a non-
volatile version of the code in a private branch. The kids these days tend to
favor a VCS that has this feature.

------
Mobiu5
Bruce Lee say: Code like water ^_^

------
afar
I wonder what pg thinks of this?

------
4ydx
This is why golang.

------
dschiptsov
> You can’t wish away Design Process.

 _Furious activity is no substitute for understanding._

 _Before you start to writing the code, YOU HAVE SPEND A LOT OF TIME STUDYING
YOUR PROBLEM._ (Brian Harvey, CS61A)

 _If you can’t write it down in English, you can’t code it._

 _Programs must be written for people to read, and only incidentally for
machines to execute._ Immortal classic.)

 _The sooner you start to code, the longer the program will take._

 _Details count. (Devil is in the details)._

 _Get your data structures correct first, and the rest of the program will
write itself. (Data structures suggest algorithms)._

 _Premature optimization it the root of all evil._

There is nothing new, of course. In "old times", even if "old programmers"
didn't have such marvels like Java or Javascript, being mostly scientists,
they have figured out "how their minds work" and in what kind of processes
they are mere parts.

An one sentence summary could go like this - "Programming is an engineering
discipline, Coding is a translation skill". To write down quickly one has to
spent a life-time thinking and doing.

~~~
aercolino
Yes, someone in another thread is discussing about skill sets to be learned to
engineer software, but I think academy already does a decent job.

To engineer a good architecture you need time to thoroughly think and explore
alternatives. Coupled with deep field knowledge and an even deeper know how,
gained by means of experience. And to build the best is impossible by
definition: you can only hope to build a better one.

I didn't know what a fast programmer was until I had to work with one. The
king of copy and paste. All his neurons on his fingertips. He showed to me
that thinking with their hands wasn't limited to manual workers. Luckily for
me, his awesome speed allowed me to become his "boss" a couple of months after
being hired. And I'm not being sarcastic here. The manager saw he was better
left typing and me better left thinking.

~~~
dschiptsov
That's why, perhaps, in pre-Java era, in good schools they taught "big ideas
in CS" instead of Java syntax and how to OO everything.

Algorithms, Data Structures and reasoning behind them, Scheme courses of CS
basics (based on SICP) and Operating Systems, so a student could understand
the principles and design decisions.

Then such student could code in any language, because syntax and common idioms
are much less important than appropriate data structures and processes. Then,
perhaps, they will use a modern file-system as a database (like this very site
back-end does) instead of bullshitting each other about what re-implementation
of optimized in-kernel routines in Java is more popular, etc.

I know syntax of about dozen languages, but I am inferior programmer due to
lack of appropriate theoretical background. I could spent days trying to
figure out, should a request be a closure or an assoc or this fancy but costly
"persistent-map", and these nuances like aliasing and locality in Clojure and
CL.

Of course, one could always Ctrl-C/Ctrl-V from millions of online tutorials
and "get shit done", but I cannot write anything without understanding why
this instead of that, not because they say so in some narcissistic, over-
confident blog-post. Thank god programming is my hobby, not my job.

So, it is not about syntax or how pointers were arranged (in structures and
ADTs or in classes and objects) it is about _whats_ and _whys_ instead of
_hows_. Coding is easy. Programming is difficult.

~~~
klibertp
> I know syntax of about dozen languages, but I am inferior programmer due to
> lack of appropriate theoretical background. I could spent days trying to
> figure out, should a request be a closure or an assoc or this fancy but
> costly "persistent-map", and these nuances like aliasing and locality in
> Clojure and CL.

I have a deep understanding of various areas of CS and maths and I never
resort to "Ctrl-C/Ctrl-V" to get things I don't understand done. I rather
spend enough time to understand them. Every. Single. Time. Ah, and I didn't
attend a university almost at all.

You could do the same, you know? If I could learn all of this, without any
help from friends or from lecturers or from senior programmers (until very
late in my learning), basically with books alone (from a library - that was
before the Internet!), then you could have done this easily. But you didn't
and now you're whining and shifting the blame and making others responsible
for your personal failure to learn.

Really, stop that and start learning for yourself, it's not too late!

------
benihana
>This is why I believe that we need older people, women, educators, and
artists

Remember, if you're a young man, or you don't have the _title_ of artist or
educator, you're obviously not a people person and you're fucking up software,
shitlord.

------
wslh
I posted the same article 1 day ago... but used the https address...
[https://news.ycombinator.com/item?id=8678439](https://news.ycombinator.com/item?id=8678439)

~~~
dang
The dupe detector is left porous on purpose to allow good stories multiple
cracks at the bat. A small number of reposts is ok.

It's true that who ends up getting the karma on a multiply-posted story is
just a roll of the dice. On the other hand, you can stack your long-run odds
as high as you want by submitting more and better stories. So it tends to even
out in the end.

~~~
glurgh
You're not really stacking your long-run odds any more than you're stacking
your odds by playing the lottery a lot. The odds are stacked in favour of
anyone who submits a lot and submits early rather than in favour of someone
who submits well.

~~~
dang
I'm not sure what you mean by submitting "early", or what experience you're
drawing on here (your account has submitted zero stories!), but am pretty sure
that the odds favour a user who submits a lot that is good [1] and that the
latter is where the emphasis should be. We're also working on systems to
amplify this effect, so it is going to get more true with time. The point as
far as karma goes is not to be attached to any one post, but rather to play
for the long run.

1\. What counts as good on HN: stories of intellectual substance that many
good hackers would find interesting.

~~~
glurgh
I guess I just found the response "submit more, it evens out in the end" a bit
glib (as is, 'your account has submitted zero stories'). I do have some
experience submitting stories as well as plenty of just reading and commenting
on the site. It seems to me the current system amplifies negative tendencies
like being 'first to post' or reposting variants of the same story.

I'm perfectly happy to take your word that you're working on something better.

------
idibidiart
Has anyone read this book and for those who have is there a correspondence
here?

[http://www.amazon.com/Thinking-Fast-Slow-Daniel-
Kahneman/dp/...](http://www.amazon.com/Thinking-Fast-Slow-Daniel-
Kahneman/dp/0374533555)

~~~
duncanawoods
I don't think it has a direct correspondence in terms as you might be implying
i.e. the fast in this context is mostly still the slow Type II reflective
thinking DK refers to. The "fast" coders are making small iterative changes
but that doesn't mean the thinking is automatic, just localised and frequent.

The deeper analytical and design oriented thinking where someone takes
extended time to identify goals, prototype and review different
implementations is an important variation of Type II but not really addressed
in TFAS. There might be plenty of Type I micro-decisions involved in that
process too.

I'm pretty interested in how cognitive biases do rear their heads in design
problems. I'm scared silly by framing effects where given options A and B, an
individual chooses A but adding a third option C and now they would choose B.
There are so many decisions that crop up during design/development that are
vulnerable to those issues.

------
GFK_of_xmaspast
I've worked with slow programmers, including someone a lot like the poster,
and in my experience they never produce anything that was worth the wait.

