
Take pride or fuck it - jshakes
http://robertheaton.com/2013/03/27/take-pride-or-f----it
======
TheFuture
Having done this stuff for about 15 years now, it is amazing how much of your
work is scrapped in 5 years or less.

If you're writing some deep enterprise level back-end stuff that is going to
be integrated in a large, expensive system, obviously it really is worthwhile
to do it right.

If you're cranking out another piece of shit marketing website, or even
better, anything app or mobile related, no matter how much planning and
testing and pride you put in to it, it is almost always completely worthless
in a couple years.

Everything is changing so fast right now, the platform, device, language,
database, etc, may not even exist in 5 years. 5 years! That's a hell of a
depreciation schedule for a $200k project.

~~~
Roritharr
This resonates so much with me... i really dislike the way how much my work is
depreciated after just months...

I really learned not to invest much time and finesse into those kinds of
projects. When i was younger i was thinking "oh, someone may look at the code,
keep it clean...". Nearly 10 Years later and dozens of projects later: Only 5%
of my code ever got even a second glance or had to be changed...

~~~
michaelochurch
It's a self-fulfilling prophecy. Technology management has given up on the
idea that code can actually be read, so it's write-once. Reading Code is that
ghetto where you put untalented people you want to fire, or young/new people
you don't know what to do with yet. Otherwise, the idea that people can
actually read code has been given up on. That, of course, generates a class of
programmers who never improve and write terrible (illegible) code.

If your attitude is that reading code is a lost cause, you'll create a bunch
of shitty, illegible code.

People forget that outside of the corporate world, there actually is code that
people (a) enjoy reading, and (b) write with the intention of making it
comprehensible.

------
dangrover
I used to get mad at other engineers for this. A lot of them didn't seem to
take much pride in their work.

Then I realized that people take pride in different dimensions of their work.
Perhaps for one person it's well-factored code, for another person it might be
design and user experience and overall polish, for another person it might be
the ultimate effect of the product being built on the customers (or on the
business). And even on each of these there is infinite room to give a shit or
not about different components of them.

All too often, being obsessive about code cleanliness is a type of
bikeshedding among geeks who have gone so far down the rabbit hole that they
can't engage meaningfully with the world through anything _but_ code. Or have
been so disempowered through years of cruddy jobs and sitting at the kids'
table that they haven't reason to try.

It's a hard balance to strike, because there certainly have been projects
where people couldn't move forward or feel pride in anything because the code
was so messy. But in these situations I've found it's best to try to see the
big picture and pick my battles. Code quality is only important in service to
other goals.

~~~
dmiladinov
> _It's a hard balance to strike, because there certainly have been projects
> where people couldn't move forward or feel pride in anything because the
> code was so messy. But in these situations I've found it's best to try to
> see the big picture and pick my battles._

This.

Sometimes it's really hard to tell when you're shaving a yak instead of fixing
broken windows. What are some ways to tell you're doing the wrong one?

~~~
pekk
Yak-shaving isn't necessarily a waste of time. Sometimes you have to spend
time on something locally suboptimal to get something closer to globally
optimal.

With the "weekend project" idea it seems that we easily forget how real jobs
often require time and struggle, even for smart people.

------
edw519
Great post! I've felt this way for years but never put words to it quite like
OP just did. Thank you.

I also work in 2 modes: "1. Make it perfect." and "2. Just get it done and
hope I never see it again."

I used to do everything in Mode 1 and took great pride in my work. Now I use
this logic:

if (LowLevelCode) or (VeryImportantAppForCustomer) mode 1 else mode 2

Funny, the longer we build software, the more we rationalize and the smarter
and lazier we get.

~~~
jrs235
I never put what you just described into words. I follow the same thought and
mode processes. As of late, I feel the company is making (indirectly due to
their priority of constraints) to work in Mode 2 for
(VeryImportantAppForCustomer) and it's a painful internal conflict. How do you
cope or handle such situations?

~~~
edw519
_How do you cope or handle such situations?_

Pay day and beer, ususally on the same day.

(This is _not_ a snarky answer, but the truth, for me and many of my
contemporaries. The internal conflicts caused by the irrationality of others
can eat you alive, but only if you let them. OTOH, whenever I get paid, I
realize how much harder my father and grandfathers worked for so much less and
thank my lucky stars. I'm not saying that this is ideal, but _it works_.
Another great strategy is to go home and build something for myself in Mode
1.)

------
coenhyde
"It's too easy to write something crap, be forced to write several layers of
crap on top of that, shout "LEAN STARTUP" at anyone who questions you and make
a shamble for the exit."

This. I hear "Lean Startup" way too often as an excuse to do something shit.
I'm so over it.

Doing something shit is easy.

Every situation is different but i'm generally of the opinion that you should
do the absolute minimum required to achieve your objective but just do it
well. If your trying to get to market asap so you don't die a horrible death
i'll give you a temporary pass on the quality... unless quality is one of your
core value propositions.

------
eeeeaaii
I would have agreed with this up until about a year ago. But I've recently
discovered a new way of thinking about the development process that IMO is far
superior, and more importantly, far healthier in the long run.

The way I used to think about development was that there were separate phases:
building, debugging, then launching, then you stop working on it because it's
"done." Then, I suppose, you go on vacation and sip Mai Tai's on the beach.

The thing is, once you get rid of the "done" phase, your whole perspective
changes. The other three phases (building, debugging, launching) get mixed
together in a blender. Suddenly, any time you hack something, it's okay
because you're going to fix/change/refactor it later. It's all part of one big
growing, changing, process -- a process that actually fits with the literal
meaning of the term "development."

So it's not about pride anymore for me, it's about humility. These days, when
I build something, I start off hacking something together in the quickest way
possible, no matter how ugly. Then I just keep iterating, refactoring, fixing,
cleaning: improving, improving, improving. So there is never a moment when you
proudly show off a gleaming, fancy product and say "look, I'm done!" There's
always something that works, something that doesn't -- something that needs to
be completely rewritten, something that looks good and you haven't touched in
months (or years).

The great thing about doing this is that it's a good way to keep yourself from
being an "architecture astronaut." If you start with a hack and build
refactoring into your process from the very beginning, you'll never build out
more architecture than you need, because every time you use a design pattern
it will be a direct response to a real need, not an imagined future need.

To conclude, I'll leave you with this quote from Walt Whitman, talking about
the "deathbed edition" of "Leaves of Grass" -- a book he revised nine times
during his life, which grew from 12 poems to 400 during his lifetime.

"L. of G. at last complete—after 33 y'rs of hackling at it, all times & moods
of my life, fair weather & foul, all parts of the land, and peace & war, young
& old"

Not sure what "hackling" means, but it sure sounds a lot like hacking!

------
johnw
All engineering involves trade-offs. Ideally, we'd prefer to have maintainable
code that ships on time, but this usually isn't possible.

So you have to look at how much payoff you're getting from maintainable code
versus shipping late. I would say that how to manage this tradeoff depends on
the type of software being developed - If you're creating throwaway apps for
the app stores then shipping fast is probably a more important consideration
than having a maintainable codebase. If you're writing banking software for
the enterprise the balance probably tips in favor of maintainable code.

You also have to take into account the constantly shifting goalposts in
software development. That class you spent all day refactoring gets thrown out
tomorrow.

------
jcmontalbano
This seems like distorted thinking. Surely there is a balance to be struck
between hyper-rigor and abandoned rigor. This guy seems to have an awareness
of various best practices, but no sense of perspective about their relative
importance.

I'm not a programmer (at least, I'm a very beginning one), so maybe someone
can clue me in: Are all best practices equally destructive if you don't follow
them? Or are there best practices which can be neglected?

I'd expect that the best practices being neglected would be differently
relevant to different projects, types of application, customers, etc. Would it
be productive to modify the discussions of "best practices" by talking about
_under which context_ those practices are necessary or unnecessary?

~~~
rwallace
Your intuition is correct, not all best practices are equally important. e.g.

1\. Business data should be stored in a proper relational database such as
Postgres, with a well-normalized schema. This is critical; if you don't do it
before the first day in production, inconsistent data will accrue and then
it's too late to solve your problems just by fixing your code.

2\. Your code should be well formatted, properly indented, with variable names
that are informative but not too long. This will end up being important, but
if you neglect it initially, you can fix it up later, so it doesn't _have_ to
be right upfront.

3\. Your code should be commented where appropriate. This is good to have, but
if you neglect it initially, you can add comments later, and even if you never
get around to that, you can probably work well enough without them, so if you
find you don't have time to write comments, don't sweat it.

For any practice whatsoever, you can find people who will insist it's do-or-
die critical (I've seen people insist uncommented code needs to die in a fire
along with its authors),so you have to use your judgment to distinguish
between things where you have to make a stand and things you can let slip.

------
unoti
This is a personality preference thing. Some people feel empowered by the open
possibilities of an empty text editor, and their spirits crushed by the boring
grind of polishing existing features to a fine glow.

On the other hand, there are plenty of people out there who are somewhat
paralyzed by the completely open and undefined possibilities of a project not
yet started, whose spirits soar at the opportunity to take something mediocre
and really make it shine.

The trick is to pair with someone of the opposite type, and work together to
make truly awesome stuff, and keep each other honest and not lazy. I've done
this many times over my career.

------
cmdkeen
Very apt given I was just moaning (zombie?) to my colleague about this. The
problem is how you get your pride back though - especially when management
continually gets in the way.

~~~
alexjeffrey
agreed - management is a key problem here. That extra 20 minutes to make your
class readable, multiplied by 20 for all of your classes, is going to be very
difficult to explain when your boss walks over to talk about why your project
is overdue. There's an argument in there for time estimates to include
refactoring, but that's a whole 'nother problem.

~~~
onemorepassword
Management is a lame excuse, and you've just defined why: it's _"going to be
very difficult to explain"_.

Grow up, deal with it. Delivering bad news is part of many jobs, and
programmers shouldn't expect to be exempt.

It's _your_ choice whether or not you compromise your code. Sometimes you'll
agree that it's worth it (shipping means $$$ the company desperately needs),
sometimes saying no (because you know the consequences won't be worth it) will
initially make people unhappy/disappointed/angry.

You can't please everyone all the time, and if you make pleasing your boss
your highest priority, well, that's the price you pay.

~~~
alexjeffrey
That's a very naive viewpoint - if you present your boss with the reality of
the situation, that you put off completing the project to rewrite code you've
already written because you weren't happy with the results and have some vague
idea that some future programmer might struggle to read it, s/he's going to
look for someone who can deliver.

While you and I know that refactoring is the right thing to do, the
customer/manager isn't going to say "by all means, delay completion of the
project in pursuit of improvements to parts of the system that only you have
to deal with". They don't see/understand the code so naturally they don't care
about its state.

[note] Obviously this is a blanket statement but it's been applicable to me
and I'm sure others have experienced similar.

~~~
Evbn
After a few years, you realize that if nobody wants your right thing, it isn't
the right thing for business, and you have to decide if you want to resign and
pursue your art with intellectual integrity, or keep working in the sausage
factory that generates revenue.

If the guy who made my lunch sandwich put as much pride and care into his
product as we all want to, which lasts about as long as the average modern
software application, it would cost $50 and I wouldn't want to buy it.

~~~
bluesnowmonkey
> it would cost $50 and I wouldn't want to buy it.

I think that's a false dichotomy. There's the $6 Subway option and the
hypothetical $50 perfectionist option, but you can also get a really amazing
sandwich near here for $9. They make something they're proud of, and it costs
more than Subway, but it's worth it.

------
cynusx
ship it and write up a janitor card to clean it up. pick up the janitor cards
when you're low energy or waiting on somebody else.

------
marmot1101
I understand the premise of the article, and I think that one should take
pride in creating great work. However, this kind of absolutism makes people
difficult to work with. I've worked with absolutist engineers and things
rarely ship and the team hates themselves by the end. Lighten up, make things
work when the chips are down and move on with life. You have to take pride in
the imperfect because all software is flawed, some of the flaws just haven't
been discovered yet.

------
A1kmm
I think the real problem is when people have an inappropriate model of what
'quality' is. Quality criteria, when used properly, act as surrogates for the
realisation of the benefits that motivated the project in the first place, or
for the management of risks or costs.

What constitutes quality is context dependent - a quality criteria that is
meaningful on a large project that will be used for a long time (for example,
one that improves maintainability) is not necessarily meaningful on a throw
away script that will not conceivably be reused.

Too many people are influenced by fashion when it comes to evaluating quality.
Some things called 'best practices' will provide no organisational benefit,
and might increase the cost without any corresponding gain.

Slogans like 'take pride or fuck it' probably do more harm than good - what
you should do is think rationally about what the appropriate quality criteria
are for a given project, keeping focused on the continuing 'business'
justification for the project and all the criteria, and aim to produce
something that lives up to those quality criteria. By focusing on what is
optimal for your goals, you avoid premature quality optimisation / over-
engineering.

------
bartwe
After several bouts of not programming due to perfectionism driven fear of
failure, making 'crap' beats perfection.

------
taude
One thing the author doesn't really take into account is the team
dynamic...and once you're no longer the sole guy in charge of that
feature/product whatever...it get's vastly more complicated (and tainted) once
five or ten others have gotten their paws on the code.

------
mmv
The funny thing is that memory is a tricky bastard, and you're likely to
remember yourself with no pride on something you did that went wrong, when at
the time you were actually doing it you were very much committed and with a
lot of pride.

The opposite is also true: if your endeavor did succeed, you'll probably
remember the journey with the sense of "of course deep inside I always knew
this was going to be great" even if in fact you didn't believe in what you
were doing.

------
linhmtran168
Agree with the article wholeheartedly.

In my case, sometimes, another team fucks up, they cannot ship the product on
time and I have to join to help them. As I have to deal with bad codes, bad
practices, short deadlines and a product that I don't have any interest in, I
often become a zombie and get it done as fast as possible and hope I would
never have anything to do with it again.

------
gavinflud
Very well put and it hits home. I always find that once I cut the first
corner, I care less and less about each future shortcut or badly coded feature
I implement.

However, if I truly care about the project or have a project that has been
very well designed so far, I always find myself going out of my way to ensure
I will be proud of it when looking back.

------
parnas
side project. side language... I think mine might be ocaml--can't stop looking
at it, though I've tried I know there's no application other than a side
project. Something has to have a bit of soul...

look at softpanorama regarding lots of years, it just gets frustrating.

------
endgame
I have the opposite problem. For personal projects I have to get over my fear
of imperfection or I'll produce nothing at all. For work projects or anything
with a deadline the pressure to make it work means I'll at least have
something to refactor.

------
dave_sid
peer code reviews. I don't they are done often enough. But, as a developer, if
I'm sitting writing a line of code, and I know my peers are soon going to
review it, I'd be less likely to cut corners and make myself look
unprofessional.

~~~
rohitnair
In my experience, even reviews suffer when you're working against a deadline
to ship. Reviewers add comments, but major refactoring is usually marked with
a "can do this post launch" (which, of course, never gets done) or people just
ignore them and check-in any way (unless they comments are related to actual
functionality).

------
seivan
I see this in myself. It hits right at home. Very well put!

There have been occasions I fall in love with a particular solution because it
was so elegant and I just have this urge to tell everyone about it.

But there have also been the opposite...

------
lukethomas
"covered my codebase in bacon" - I got hungry after reading that.

------
ipetepete
"I've unleashed the hounds of hell and covered my codebase in bacon." Best
quote of the week.

------
stevebot
I wish I could do this, but I know I won't make the deadline if I do.

------
michaelochurch
Lions get a better deal: take pride _and_ fuck it.

Ok, to be serious... I perceive a dissonance here.

On one hand, we're essentially a degraded tribe. Most software engineers _work
for managers_. We're not a profession, we don't pick our tools, and most of us
work on uninspiring bullshit and are subjected to Brownian Management that has
one team digging holes and another filling them in.

Management has its place, but in most companies it's a class of intermediate
extortionist thugs who keep talent down: _you support my career goals, or
you're gone yesterday._ Only the most progressive companies (Valve, Github)
trust engineers to work directly for the company. No wonder our industry is so
fucked.

On the other hand, the fact that Yahoo bought a small team of high-schoolers
for $30 million and canned the product means that there _is_ a lot of value in
what we do. As engineers, we have a lot of muscle. We're good at something for
which the world has almost infinite demand (not "programming" only, but the
more abstract talent of solving problems and improving shit.) We're just
terrible, as a class, at negotiation. We need to get better. We also have a
tendency to want to put our heads down and ignore "the boring business stuff",
then we get pissed when non-technical executives drink our autonomy milkshake.
We need to stop that, too.

~~~
benihana
> _Management has its place, but in most companies it's a class of
> intermediate extortionist thugs who keep talent down: you support my career
> goals, or you're gone yesterday. Only the most progressive companies (Valve,
> Github) trust engineers to work directly for the company. No wonder our
> industry is so fucked._

Wow. In three sentences you likened management to the mafia, said they were
only concerned about themselves, complained about lack of trust towards
engineers, then said our industry is fucked, all without a hint of irony. It
sounds like you want everyone to trust you for your genius talent but you
don't feel you should have to extend any trust the other way. That's now how
trust or human interaction works, and the whole statement makes you come off
like an immature prima donna. You're making us look bad and I'm almost
embarrassed to share the same job title as you.

~~~
michaelochurch
Most companies give managers the ability to be extortionists if they want to
be. That doesn't mean that all managers go black hat. Many do not.

I've seen companies where 90% of the managers were decent people, and
companies where _zero_ percent were decent people. It seems to average about
70, but that bad 30 percent can do a lot of harm.

~~~
flogic
In my experience, managers are like programmers. Good managers can be really
effective. Most are semi effective. Some are downright harmful. For the most
part though companies seem to have limited ability to tell which is which. I
went through a major re-org over year ago. Just from the management switch my
stress level went down by a factor of 10.

------
martinced
_"As soon as I lose pride in something, I stop caring about it being good."_

The one quote to deal with that is simple: _"A professional is someone who can
do his best job even when he doesn't feel like it"_

That's what I keep in mind when I have to work in that special Java/C# + ORM /
(N)Hibernate + XML + SQL kind of development hell.

:-/

~~~
mindcrime
_that special Java/C# + ORM / (N)Hibernate + XML + SQL kind of development
hell._

There isn't necessarily anything inherently wrong with Java, C#, ORMs, XML, or
SQL. All are pretty useful ways to solve certain classes of problems, taken on
their own.

That said, there are definitely "development hell" projects that feature all
of those things, but I believe you can have "development hell" in any
language, using any libraries, and any persistence technology.

And anyway, if you think writing C# or Java code is bad, trying writing
RPG/400[1] using SEU[2] on an AS/400[3] sometime. That stuff'll leave you
shuddering and sweating in your sleep, and walking around with a blank stare
on your face, drooling and mumblng "Ia! Cthulhu Fthagn! Ph'nglui mglw'nfah
Cthulhu R'lyeh wgah'nagl fhtagn, %!@ ^^&!@(, (#!^H NOCARRIER".

[1]:
[http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index....](http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=%2Frzahg%2Frzahgrpg400.htm)

[2]:
[http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/index.jsp?t...](http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/index.jsp?topic=%2Fcl%2Fstrseu.htm)

[3]: <http://en.wikipedia.org/wiki/IBM_System_i>

~~~
pjmlp
Only recently I discovered that OS/400 is bytecode based for all userland
software, with a JIT integrated into the kernel.

Which means Android and Windows are kind of following a path similar to a
mainframe OS. Interesting for language geeks.

Anyway I haven't touched one since 1994.

~~~
mindcrime
Oh, yeah, no doubt. It's fun to make fun of mainframes, and IBM, etc., but the
reality is that they invented a ton of ideas that are only just now migrating
into the commodity hardware/software world, and/or consumer devices.

Developers in general would probably be well served to do a better job of
acknowledging our own history and maintaining more awareness/context regarding
what has come before.

------
iTrollFreely
"untitled.txt"? what kind of p.o.s editor is he using to code

~~~
Evbn
It is a program in Textile language, a modern language designed for
multithreaded programming.

