
Give A Damn - 10char
http://clayallsopp.com/posts/give-a-damn/
======
klibertp
I have different problem - I just can't code like The Kid anymore. I know I
could in the past, I have the code to confirm this. Not anymore, I'm not able
to.

And often I'm required to. My boss says: "just hack it quickly" or "it's one-
shot script, just write it" and wants it done in an hour or so. And I can't do
this.

I don't even know why I can't. I tried many times to "just code" and there's
something in my mind that seems to be opposed to this. This "something"
refuses to use unknown or not fully understood tools. It refuses to let ugly
line of code be. I feel like I'm refactoring my "one-shot" scripts
reflexively, without me noticing. And the worst thing is I do it continuosly -
not when the script is finished and somehow works, but during writing it for
the first time. I know exactly when was the last time I wrote more than twenty
(Python) lines of code without breaking the code into functions and classes,
caring about names and comments: in 2004. Tests came later, but now they are a
reflex too.

And now what my boss wants done in an hour I write in three or four. Then he's
getting angry and tells me to go clean and document some code or to implement
something else, and I do, and it more often than not works and - I hear -
could even be a pleasure to read. But then, few days later, he wants me to
quickly convert something or export something or something like that and I
just can't do it, unless I have previous script ready. Then he's angry
again...

TL;DR - giving a damn is certainly a good thing, sometimes, but taken to the
extreme can disturb your career.

~~~
ChuckMcM
Welcome to experience. Have you ever tried walking along the outline of a
balance beam drawn on the floor? Jumping along it? Now move the balance beam
1' off the ground, still easy? try 5' and take away the mats. The difference
between walking the outline and walking the beam is that you can 'see' the
consequences of failure and you know they hurt.

Not surprisingly this happens in engineering as well. You start "just trying
to get it done" and when you didn't know better you just wrote it. But now
that you know better, perhaps you've been bitten by an unchecked return value
or a fixed length array, so now you reflexively look for those things, you fix
them, you refactor them. This slows you down, and your fresh graduate peers
start thinking "the old guy is slowin' down."

The only way I've found to move past this to let go of the responsibility when
your manager asks you to. The conversation you have is "Boss, I can crank this
out quickly but the faster its written the more likely it will have some
future problem in it." then write that into the comment "Boss asked me to hack
this out, said he would take responsibility date - time" and then just write
it and move on. Later if it screws up you don't worry about it.

But you can't just go all irresponsible on them, you also need to think about
the kinds of things your doing and step up your game in terms of what some
folks called 'design patterns' make an effort to capture the way you write the
things you write all the time and train your fingers to spit out an 'ok'
version from the start.

Good luck.

~~~
barefoot
> The conversation you have is "Boss, I can crank this out quickly but the
> faster its written the more likely it will have some future problem in it."

Not entirely sure if this is satire or not but it's a genuine conversation
that I've had with a few clients.

I call it "the spectrum of quality" conversation. I can write beautiful unit
tested code that will not explode unexpectedly at 3am on a Sunday several
years later...but it won't be (relatively) quick to get there.

Alternatively, I can rush through something that will have to be rewritten
later and it'll only take me a few hours. Part of me dies writing that type of
code but there's a time and a place for it.

You want to hit the afterburner? No problem, but there are consequences.

~~~
edu
Technical debt. There's a time and place for it, but as financial debt you'll
have to pay it back, with interests.

The best thing about the term, is that not technical people know and
understand how debt works, so they can make a more or less informed decision
and don't get that much surprised in the future when something need a big
refactoring :)

~~~
ChuckMcM
That is exactly right. One the most interesting things I heard from a
departing Google engineer was that he was declaring 'technical bankruptcy.' He
was so fed up with hacking things together to make them work and not doing
them 'right' that he just couldn't take it any more. So much of the way we
work as engineers has analogs in finance that it stuns me some times.

------
Zarel
On the other hand, I'm reminded of this passage from HPMoR:

"But Father had once told her that the trouble with passing up opportunities
was that it was habit-forming. If you told yourself you were waiting for a
better opportunity next time, why, next time you'd probably tell yourself the
same thing. Father had said that most people spent their whole lives waiting
for an opportunity that was good enough, and then they died. Father had said
that while seizing opportunities would mean that all sorts of things went
wrong, it wasn't nearly as bad as being a hopeless lump. Father had said that
after she got into the habit of seizing opportunities, then it was time to
start being picky about them."

Or, in context: You can't skip directly to writing quality code. First, you
have to get used to writing code, and to do that, you have to write a lot of
it. You have to get used to getting things done. Only after you have a good
grasp of getting things done, of seeing a project to completion, should you
start worrying about code quality.

I have a lot of unfinished projects, and a lot of smaller projects that I have
finished. I'm sure all of us do. But once, I decided not to worry so much and
just start writing, and I started and shipped an incredibly ambitious project.
It wasn't my best code, but it taught me a lot about not sitting at a blank
screen trying to plan everything to be perfect before starting.

~~~
10char
Totally agree, and this applies to almost every creative endeavor I can think
of. If you want to write a book, throw words on a page. If you want to start a
company, launch an MVP and iterate fast. All things being equal, doing is
better than not doing, and doing well is better than doing poorly.

If you're interested in this topic w.r.t software engineering, check out
Michael Lopp's article in The Magazine about Stables and Volatiles[1]. Really
good piece on how companies are composed of and need both Volatiles like The
Kid who move fast and innovate, and Stables who clean up the mess and move the
company towards profitability.

[1]: <http://the-magazine.org/1/stables-and-volatiles>

------
DanielRibeiro
Kent Beck, the guy who created Extreme Programming, Test Driven Development,
and the first Unit Test Library ever, made a very similar point about this a
few years ago, in his "The Flight of the Startup"[1]

 _In the taxi phase, breadth, speed, and, above all, cost of experimentation
is the key. Try out ideas related to lots of different needs. Precision of
feedback during the taxi phase is less important than trying out lots of
different kind of ideas. The risk during the taxi phase is that you won’t find
a genuine need. Address this by reducing the cost of experiments and running
many of them._

After working for a while for Facebook ( _the move fast and break things_
company) he described how deployment speed dramatically affects how you work
on his "Software G Forces: The Effects of Acceleration"[2].

So, it is not a secret that _discovering_ "something people want" is more
important than working code[4], because failure if the great equalizer of
code: all good code and all bad code is equally thrown away[5].

[1] <http://www.threeriversinstitute.org/blog/?p=251>

[2] <http://www.youtube.com/watch?v=KIkUWG5ACFY> which was seconded by Mary
Poppendiek on her "How Cadence Predicts Process"[3]

[3] [http://www.leanessays.com/2011/07/how-cadence-determines-
pro...](http://www.leanessays.com/2011/07/how-cadence-determines-process.html)

[4]
[http://swik.net/Eclipse/Planet+Eclipse/Julius+Shaw:+Kent+Bec...](http://swik.net/Eclipse/Planet+Eclipse/Julius+Shaw:+Kent+Beck+Revises+the+Agile+Manifesto+%28for+startups%29/d056n)

[5]
[http://www.universalsubtitles.org/en/videos/6FfAAXK00nWB/en/...](http://www.universalsubtitles.org/en/videos/6FfAAXK00nWB/en/182318/)

------
imechura
I'm gonna go out on a limb and say that this "kid" was not utilized correctly.

He had a valuable "1 in a million" skill and instead of finding a way leverage
that skill in a new and innovative way the team pigeon holed him into a
vanilla software engineer role. Perhaps he should have been responsible for
building alpha releases for new customer features, understanding that the more
detail-oriented software engineers would come in afterward and make the code
production ready.

I see these two types in my job every day. One type can put something
amazingly valuable out there in no time flat. The other type is meticulously
detailed oriented and can perceive every possible permutation of a use case
and ensure that the system is coded to handle them. Unfortunately the streams
rarely cross, however we expect both types to do the same job due to our close
minded view on roles and responsibilities.

In short, possibly, it was not the kid who did not "Give a Damn". Instead it
was a rigid team who probably did not realize the value he could provide.

~~~
mvanveen
I strongly disagree with this sentiment. I see a lot of The Kid in myself in
many ways, and I don't think that this individual is striving for some local
optimization point which is going to make them extremely valuable, but is
instead headed for mastery of his or her discipline. This might be
presumptuous and even a little pretentious (apologies!), but I honestly don't
think simply sticking to one side of the fence is the path to mastery.

Giving a damn is mostly about pursuing the end goal, which is pretty much just
to ship incredibly high quality software which meets the demands that that
piece of software is responsible for meeting.

Sometimes that means applying formal verification techniques or running
nightly static analysis runs over your build. Other times, just enforcing code
review is enough. On the other hand, in those insane, crucible, diffuse-bomb-
with-paperclip moments, all you really have time for is the awful hack.
There's a huge spectrum, but the point is context is everything.

Having experienced both ends of the scale spectrum, from the ivory tower of
spaceflight software verification into the heart of a fast-paced, scrappy
startup, I've only really realized how much more experience I need practicing
software engineering principles to master my craft and profession.

------
greatzebu
> "Code is more than just a tool," I heard he said. "It's our craft. It's our
> muscle. And we need to train it. Chop wood. Carry water. Code."

I seem to hear this comparison between skilled manual labor (especially
carpentry) and coding come up all the time. Yet I never hear writers or
mathematicians making that comparison, and I rarely hear engineers or
scientists in other disciplines make it. Maybe that's just because I listen
more to programmers, but I think there's an actual difference, and I wonder
why that is.

I also wonder whether or not there's any connection between writing better
code and using "best practices" in all your google searches. I suspect not.

~~~
kwekly
I can't tell if you're kidding or not...

Is your question, do writers and mathematicians also speak of elegance and
aesthetic in their work? Do writers engage and practice free writing and side-
projects to hone their skills, beside whatever they have to do to pay the
bills?

Expand your world man, there's so much more out there.

~~~
greatzebu
Obviously elegance, aesthetics, and a desire for personal improvement are
common factors between these professions. But I've spent a lot of time with
writers, scientists, and mathematicians, and I've very rarely heard any of
them analogize the process of improving at their work to carpentry or other
skilled physical labor. But I hear this analogy from programmers all the time.
Programmers talk about sharpening their saw instead of talking about writing
another draft, even though to my mind programming is much closer to writing
than it is to carpentry. That's what I wonder about.

------
jiggy2011
Did anybody else end up with the voice of the narrator from the game "Bastion"
in their head dictating this?

I have to say that my standard practice now is to write all my code twice. I
write it the first time and just do "whatever" until it appears to work. Then
go back and refector, add tests etc.

That second time I always find an astonishing number of bugs that I hadn't
even considered.

------
greenyoda
It sounds like the all too common story of an inexperienced programmer being
overwhelmed by technical debt[1] as their code grows larger and more complex.
I'm sure it's a lesson that many programmers learn the hard way at some point
in their careers (like I did).

[1] <https://en.wikipedia.org/wiki/Technical_debt>

------
afterburner
I'm sure there's great programmers out there who can do things fast _and_
well, so hopefully people won't be too quick to judge any fast workers because
of this story. Tempting to think there's a quality cost to speed; could be the
true cost is just a high salary.

------
joelmichael
Why not just work out the bugs in his redesign? You said he got it done
extremely quickly. It didn't seem like he was presenting it as a final
version, but rather as a demo. Instead you throw it all out? How long did the
replacement version take to finish? How many people worked on it? Was it
feature-complete and free of bugs?

This reads like someone getting their spirit broken.

~~~
Peaker
In my experience, very quick and dirty code becomes correct faster with a
rewrite than with incremental fixes.

------
danbmil99
There is a place in the ecosystem for programmers like this. There are times
when a quick demo can have a huge effect on business prospects. The key is to
understand that the whole thing needs to be recoded, by engineers who
understand process and architecture. Then just put "the kid" on the next
flashy demo.

------
simonbarker87
I've had a side project on the go for 18 months now and am about to complete
the third version. Each time I've started from scratch but the difference is
each time I have cared just a bit more about the quality of the code and
planned things more in advanced. It's still not perfect (by a long way at
that) but if I had't just dived in on the first version I fear I would never
have shipped the first version let alone be on to launching the 3 do over.
This one, should (fingers crossed) be the one that I stick with, hopefully it
is extendable and I actually cared about database design and normalisation
this time around so that should work well for a while too.

------
jyap
I think that more experienced programmers can achieve the same results as The
Kid. In a larger organization, you may have separation of programming roles so
you may not have a 'Kid' at your disposal.

If you have a method for rapid prototyping or something which allows you to
bash out a quick proof of concept. Sometimes management needs that as the
visual impact goes a long way to getting projects approved.

So long as you then convey to others that there are bigger long term concerns
and proper design to look into when making the full version you can take it
from there.

------
elliottkember
At first I didn't like this story. It sounded too much as though The Kid got
stuck in an inappropriate role.

But on reflection, it's more interesting. He was doing fine, then his
situation changed. So he changed along with it.

I think that's what I like most about The Kid. He didn't quit, or blame
anybody - he altered himself to better suit his environment.

------
iopq
My boss wants me to be The Kid. "The users won't know the difference!" Sure,
you can just hack together everything and the users won't know, but at what
cost in the long term?

------
BungleBob
Lesson 1) The Kid is unemployable Lesson 2) That's why The Kid is The Boss.

Be The Kid (or get a job).

