
The Code You Don't Write - menacingly
http://improbabletruths.com/the-code-you-dont-write
======
btilly
Let me turn this around.

Most feature requests arrive from a user telling you how they think you should
solve some other problem. If you can figure out the real problem and solve it
better, that will be an improvement over delivering the exact request as
given. (If you can't solve the real problem, though, or you misunderstand it,
that's worse.)

For example at one company I was asked to speed up a report. The problem was
that it was running too slowly and was timing out in the browser. Instead of
tackling that fun optimization challenge, I built a feature that would cause
any report that took more than a minute to run to be emailed to the current
user. My manager said that he received more thank yous for that feature than
for everything else the team had done in the previous 6 months.

At another company I received a request to add a feature that would prioritize
pushing specific pieces of data to the website. (We'd had some stability
problems, and they had no visibility into what was happening.) I knew that
adding this prioritization feature would further destabilize the data transfer
logic that I was trying to make more robust, talked to my manager, and refused
the request. The senior executive requesting the feature tried to get another
co-worker to do it instead, that one asked me innocently how to go about it, I
got him to push back. Several months later I got enough of a break from other
projects to consider the prioritization feature and asked the executive
whether he still needed it. His response? "It has been months since data took
more than 5 minutes to get to the website, I'm fine."

Also it can help to generalize your solution. At a third company I built a
reporting system where instead of just plugging inputs, every form field could
template the SQL that was being used. So a report could also generate
drilldowns of itself, and you could combine these in a very flexible way.
After a while over 2/3 of the special report requests that I got could be
immediately resolved by showing that it was available if you combined two
features that had been added for other users doing something else. (My
turnaround time for other requests tended to be under 2 hours - and the
features, documented, were available for anyone who needed them.)

Programmers do not provide value by writing code. We provide value by solving
problems more quickly and cheaply than the alternative. The better you solve
problems, the more value you provide.

~~~
incision
So true.

All kinds of work would benefit from being restated in terms of goals rather
than specific tasks.

~~~
CodeMage
And that's something that frequently ends up being overlooked in discussions
like this. Software development isn't special because you need to state it in
terms of goals. Yet you don't see people telling surgeons "you should avoid
operating on people" or architects "you should avoid putting unnecessary stuff
in and on your buildings".

What makes software development special is the perceived comparative ease of
doing the work: you just sit down and code. There's no risk someone's blood
will get septic just because you sat down to code. One of the consequences of
this is that eager, novice coders will churn out code they could avoid,
because it's cool.

Cautioning coders to avoid unnecessary coding is good, as long as you don't
start forgetting that there's necessary coding, too and that writing that code
does, indeed, add value.

~~~
skmurphy
I am not sure about your two non-coding examples.

There is a lot of effort expended to find non-surgical alternatives to many
health conditions. Insurance companies in effect tell surgeons "you should
avoid operating on people for this condition unless these other approaches
have been tried first" in their reimbursement guidelines.

And the architect Mies van Der Rohe is famous for his precept that "less is
more."

~~~
btilly
_There is a lot of effort expended to find non-surgical alternatives to many
health conditions. Insurance companies in effect tell surgeons "you should
avoid operating on people for this condition unless these other approaches
have been tried first" in their reimbursement guidelines._

As far as I can tell, not true in practice. For example see
[http://www.washingtonmonthly.com/features/2007/0710.brownlee...](http://www.washingtonmonthly.com/features/2007/0710.brownlee.html)
for some of the history of the attempts to bring sanity to back surgery.

As for insurance companies, they have some interesting perverse incentives
going forward. Obama's health care plan says that they have to spend most of
the money they bring in on medical care. This is intended to keep them from
causing too much overhead. However the flip side is that the potential profit
the company and top executives make is directly tied to how much medical care
they get people to have, with the costs passed on to companies and consumers
who are now legally required to buy insurance.

They will be very interested in making sure that the cost of medical care
grows at a known rate. The growth being so that they can make more money. The
known rate being so that they actually can make money. They will give public
lip service to cost saving measures. But privately that isn't their incentive,
and they are smart enough to know it.

------
wonnage
It's amusing how quickly programmers-turned-managers forget their roots. Look
here:

    
    
      I used to get a huge feeling of satisfaction from a weekend  
      spent working on a clever hack. I would spend serious
      effort making something run twice as quickly, even when
      there wasn't a problem with how quickly it was running in
      the first place. Meeting those types of challenges was my
      primary motivator.
    

This is how you were motivated before they gave you a manager hat. This is how
the people you manage think. And I wager that this mindset isn't _wrong_ by
any stretch of the imagination - as a programmer, I love working around people
who program for the sake of programming, who find fun and satisfaction in
writing code.

I don't mean to suggest the perception of code as just one of many means to an
end is wrong either; it actually makes perfect business sense. It's something
managers need to understand. But in your "enlightenment" you've forgotten what
made you tick in the first place - how do you translate your new business-
value-driven mindset to something the people under you (who don't have that
mindset) can appreciate? Hint: it's not by telling them their cool hacks are
useless. And we wonder why programmers distrust management.

~~~
beat
Actually, let me put this another way... back in the original dotcom era, I
worked at a startup that decided to write a BIOS. With the amount of hardware
we'd be selling, it'd save a million dollars! Well worth six man-months or so
of work, right? WRONG. That was six man-months of critical programmer time
when the time and money was running out, and all we learned was that we
couldn't do it in a 512k PROM (not with our design anyway), and upgrading to a
1mb PROM would have cost more than a license from Phoenix for their BIOS.

That's what happens when you let the inmates run the asylum.

Programmers are fools, for the most part. They don't understand what problem
they're really trying to solve. We thought we were solving a cost-of-
production problem for a fully scaled business. That wasn't the problem. The
PROBLEM was NOT DYING. And that meant getting a working product out the door
as quickly as possible, even if it cost more.

~~~
lemming
_Programmers are fools, for the most part. They don 't understand what problem
they're really trying to solve._

That's a little harsh. I think it's fairer to say that they often don't have
insight into the wider strategic objectives of the company, and that's as much
a company failing as anything. I'm now a firm believer in sharing e.g. revenue
numbers with everyone in the company and explaining why they're important -
people are much more willing to accept things when they understand the wider
picture.

------
gngeal
_" The cheapest, fastest and most reliable components are those that aren’t
there."_

\-- Gordon Bell

~~~
pjmorris
I first read this in the 'Bumper-Sticker Computer Science' column/chapter of
More Programming Pearls, Jon Bentley. Great aphorism, great book.

------
rmcastil
I've come to a similar conclusion but I tend to think of it as solving little
problems with the simplest solution possible. Don't pre optimize and don't pre
abstract.

This is a thought process I think you arrive at when you're running your own
business or in some sort of managerial role. You start realizing the
constraints (time, budget, resources, etc) involved in building software.

When we first come into the world of software we just want to write awesome
code. But to truly evolve as a developer you need to start asking real
questions regarding what you are building.

Are we making the budget bleed by spending 3 weeks on making the most
beautiful piece of code possible for a feature when it was originally
estimated to take two days? Can an open source library be used instead of us
trying to build something from the ground up? How does this feature add real
value to the users of this product?

------
JDGM
I enjoyed this but on the surface reading didn't like his "it makes me think
an octave higher" line, and on reading the context from Sivers (an excellent
article that, btw) I even more didn't like it. The analogy just didn't seem
appropriate.

However, after some thought I felt the paragraph after with the bulletpoints
does actually line up quite nicely (albeit rather obliquely) with what Sivers
was talking about and I think I get it now, the finer points just weren't
immediately obvious. This a minor niggle but I think that he could have
explained that part better, and without requiring a whole other article for
context (no matter how good that article is!).

~~~
menacingly
OP here. That's really valid feedback and I'll keep it in mind in the future.

------
prayag
Sometimes you have to write software to make all the other option much more
efficient. Let give an example, we at MobileWorks
([https://premier.mobileworks.com](https://premier.mobileworks.com)) are in
business of providing virtual temps to businesses. Since we are built to
scale, the entire team has virtually unlimited supply of temporary labor and
we use it A LOT.

However, in a lot of cases a little bit of code actually makes the temps much
more efficient. That's the real value of code. Making the mundane much more
efficient.

------
danso
I think this is more about "feature creep" than specifically about code,
though the OP's point is well taken. But the distinction matters: the dilemma
I find myself facing is: do I write that extra library or test to make sure
things work? Do I take the time to refactor? Is it worth the time?

In those situations, it isn't at all an easy question, unless you know the
problem you face requires a one-off software solution with little liability
for maintenance.

~~~
cdmo
Yes, I think the point of the story was about being business minded rather
than indulging your own programming interests and prowess. Or in other words,
the feature creep that you add yourself. This is advice is well timed for me
;)

------
QEDturtles
This is a really cool article in that it shows the transition of one developer
into an architect. I think the grief the author is taking in some of the
comments has more to do with presentation than content.

The weekends of clever hacks that he mentioned were essential to his
development as they are for all of us. The weekend is a good time for clever
hacks. If they have useful business implications all the better. Exciting,
innovated packages often sprout from a developer's desire for a more elegant,
stable, focused, or powerful solution for a problem or a problemset. These
innovations should be abstracted into reusable packages and reused.

However, in a business environment, developers need to be focused on solving
problems for users. They need to do so in the most stable and sane possible
manner. That means that code should be a last resort when a solution has not
already been written. If you miss your weekend hackathon, contribute back to
the packages that you found helpful. This way, you can get your kicks from
clever new hacks and improve several of your existing projects in one fell
swoop!

Writing code (and lots of it) is essential to growing as a developer.
Unfortunately, it's often a detriment to software projects.

------
mgerals
Strictly relying on 3rd-party code without understanding the algorithms and
complexities can lead to just as many problems. In my opinion you still better
be a very good coder when relying on libraries, just plug and play will fail
you sooner than later. I have seen my fair share of this.

When requirements slightly change and you have to adapt a library, suddenly
you have to deal with 20k (or more) lines of code and have no idea where to
even start. You may just need to use a tiny part of that library but the code
is so tightly bundled and abstracted (for good reason) that you have to dig
through layers and layers just to make a simple change.

You should at least understand the complexities when relying on 3rd-party
code, the Go dependency hell of the game "Haunts" comes to mind (but I don't
remember the details, so probably not the best example).

A few additional thoughts:

1\. I said "plug and play will fail you sooner than later" \-- for most
startups that "later" never happens or is not of concern. How often has a
startup's code-base made into an acquiring company's production systems
without a complete rewrite?

2\. Also, when reading some of these posts, I tend to look at the author's
motivation/background. This is a somewhat controversial claim (on HN) -- so it
is bound to stir up some interest/pubilicty. And also, this is probably not
the worst way to court some new clients ("hey, we write less code and waste
less of your money"). But I do believe that the re-use approach would be well-
suited for short-lived marketing campaigns, as opposed to some other software
-- think limited scope and fixed requirements. I'd do the same if I had to
work on several campaigns that are probably all similar to a degree.

~~~
chn
I think there can be good reasons to choose mature library that solves complex
problem (even if you don't understand the code) instead of writing your own
code. I find writing a simple wrapper around big libraries a good practice, it
should limit the external library features to what you really need, give you
more control on how it's used and allow to switch to other library or even
write your own code with much less effort.

------
captn3m0
This is my constant advice to my startup-hungry-friends. I constantly tell
them: "Coding it should be the last item on your list."

------
salmonellaeater
This is spot on. Every time you solve a problem without writing code, you
avoid possible bugs, future maintenance, and legal issues, and you don't spend
time. The second-best code, after code you avoided writing, is code you can
delete and as a side effect solve a problem. The less code, the better.

~~~
j-kidd
Those are certainly valid points, but I can't help but feel like the OP is
going down a slippery slope, and will soon start contracting out coding work
to 3rd party, which would then comes back full of bugs and doesn't mesh nicely
with existing architecture, thus requiring full-time maintenance from internal
staffs anyway.

~~~
menacingly
I can see how you would have come away with that impression.

We produce a lot of code, so much in fact that it didn't even occur to me to
state the value in doing so. We definitely do and will continue to keep a
talented team busy.

------
richkuo
Every non-technical entrepreneur or co-founder needs to read this. Twice.

You would not believe how many non-technical people think that programming is
a critical component to the problems they are trying to solve.

------
0xdeadbeefbabe
After fiddling with gnunet for too long I'm wondering if the code you don't
write will or will not solve the NSA spying problem. I'm in the will not camp
so far because gnunet isn't working, and even if it connected to some peers I
wouldn't know how to verify my anonimity. They also say something like you
might be protected from the law if you click Y here. But I don't want a not
guilty verdict, I don't even want to go to trial.

------
tsm
Working as one of two programmers at a startup has really reinforced this for
me. As a student and even when I worked at BigCo, I loved taking the time to
do things myself, do things Right (with the capital R), and so forth. Now,
since I'm surrounded by business people, I'm thinking more in terms of value-
provided, not cool-hacks-provided. It's made me ship better things a lot
faster and make more people happy. And, really, that's the end goal.

------
6d0debc071
I don't think that too many people like the feeling that their work is going
to be useless. On the other hand, if you don't have a larger overview of a
problem domain it can be difficult to feel that you're making progress doing
anything other than optimising and abstracting.

On the other hand there are reasons why the Linux kernel runs dramatically
better designed than Windows.

~~~
ams6110
The NT kernel is well designed. Windows is full of a lot of other cruft
though, a lot of which isn't.

------
jacob019
This really resonates with me. I'm having a terrible time getting high quality
code from my team. Software is expensive to develop, and as a tech company we
always try to solve every problem with code first. I'm going to make more of
an effort to think about our problems beyond the lens of code, thanks!

------
Mithaldu
It took him becoming a manager to figure out what the Programmer's Virtues*
are about?

* [http://threevirtues.com/](http://threevirtues.com/)

------
themckman

        It gets me closer to adding value directly, instead of shoehorning my preferred 
        solution onto a problem.
    

But shoehorning my elaborate solution onto the problem is the funnest part.
Providing value is easy and boring...

------
beat
Code is not an end in itself, only a means to an end.

