
You Are Not Paid to Write Code - tylertreat
http://bravenewgeek.com/you-are-not-paid-to-write-code/
======
simula67
My working theory about this is that the industry is driven by resume-driven
development. Recruiters filter resumes with a keyword based search : 'Do you
have React experience ?', 'What about docker ?', 'Do you do Ruby on Rails ?'.
If you cannot show experience in the current hotness, your chances in the job
market diminishes. So people pick up the new hotness and implement their next
solution with that technology whether or not it is the right tool for the job.
If we fix the job market, this problem might automatically disappear.

Another solution could be encouraging personal projects. Many companies over-
work their employees to the point that they cannot do anything in their spare
time. Give employees free time and encourage them to play with new technology
in their personal projects. The curious ones will have an outlet to channel
their energies and you will get a rock solid stack. Also, they will be
knowledgeable to take you forward when a problem that requires their newfound
knowledge arises in your organization.

~~~
tapan_k
> Another solution could be encouraging personal projects.

Agree. This is necessary to encourage learning, which helps keep people sharp,
which in turn benefits the projects that they are working on in the day job.
Even if the technology is the "same old".

A couple of decades ago, many software developers were content using the tools
they had and knew. Few demonstrated the eagerness and openness to try
something new. These few were also the ones who were better at coming up with
out of the box solutions because they were willing to try something new --
both tools and/or approaches. Now, we have reached a point where the bare
minimum required of a software developer is familiarity and comfort with the
new and shiny, leading to the reverse problem we had early on. Now, people can
spend way too much time and energy learning and trying out new tech that they
miss out on the opportunity of staying long enough with a technology to learn
from experience.

In other words, today we spend way too much time on accidental complexity than
on essential complexity.

~~~
clifanatic
> encourage learning

Hell, I'd settle for just not discouraging it so damned hard.

------
clifanatic
> You are not paid to write code

Well, actually yes, yes I am. You can make a compelling case that this
shouldn't be the case, or that they people paying me are shooting themselves
in the foot running things the way they're running things, but the fact
remains that in today's daily standup/weekly status report/what have you done
for me lately "agile" corporate environment, I am absolutely paid to write
code and if I don't write code, they'll stop paying me.

~~~
marrs
Well, actually no, the author is right. You are paid to deliver results, be it
adding new features, processing data, making widgets or whatever. The business
really doesn't care how you do that.

Obviously you _do_ write code in the course of providing those results, and
all of the author's examples of what you should be doing are still examples of
writing code, but they are the minimum code required to deliver results.

Another example of how you're not paid to write code is the frown you receive
from stakeholders every time you say you are going to refactor something, or
that you are going to rewrite the API to be RESTful.

They don't care, and they shouldn't

~~~
JamesBarney
I think a thought experiment illuminates the difference. Two different but
identical companies with unlimited vacation gets too people to do the same
project.

Workaholic Walter shows up to work 7 days a week, works 10 hours days for 3
months busting his butt to write a piece of software that ultimately fails
because he spends so much time working he misses the big picture.

Smart Steve does some research decides the project already exists in open
source downloads it, sets it up in a week. Then decides to take a 10 weeks
vacation because he just saved the company so much money.

In these two situations Steve objectively did far better, but I bet your sweet
butt that he gets fired, and Walter gets promoted. The problem is no one ever
really knows how much value you added, or how much work you did.

I've been on projects that were incredibly successful from a technical
perspective. Objectively the product performed exactly like the stake holders
wanted, the performance was great, it could run for months at the time, even
while actively being configured by people completely unfamiliar with the
software and not crash. It was still a failure because no one wanted to buy
it. We spent a year kicking butt and still added 0 value to the business. But
I will still paid. And I wouldn't have been paid any more if the project had
instead resulted in an extra $12 million in revenue.

You pay a hair stylist to cut your hair, not for the business deal you may or
may not get because of it. Why someone pays you is different from what you are
paid to do.

~~~
user5994461
> In these two situations Steve objectively did far better, but I bet your
> sweet butt that he gets fired, and Walter gets promoted.

I wouldn't bet on that.

Noone is aware that Walter overworked because noone saw him. Plus, he didn't
delivered anything in the end.

~~~
clifanatic
> Noone is aware that Walter overworked because noone saw him

I know Walter. He made a big point of sending e-mails at 2 AM, CC-ing the
recipient's boss, and then following up at 8:00 the next morning asking why
you hadn't responded yet.

~~~
user5994461
This behavior is seriously wrong. It's insane that it could go on for months
without feedback or blame.

The question is whether it comes from Walter or from the company. Either let
him go or move to a better environment.

------
sebringj
I'm coming from learning all about toothpicks and glue, then seeing every
problem solved as building things with toothpicks and glue. It was quick and
fun at first but my creations were brittle and sometimes were dangerous even.
Gradually I became aware of ductape, saws, plywood, nails, hammers, steel,
etc, then pre-fabricated parts. Eventually, I ended up buying some from
vendors even that had compatible standards so I could make things quicker
piecing them together. In the end, just having to try to come up with things
that were already made seemed stupid and a waste of my time but unfortunately,
that idea only seems to make sense to people that have gone through the same.

But it ain't all bad, see. I hear some young folks are coming up with brand
new types of toothpicks and glue, hell some of em' I hear put themselves
together.

~~~
Retric
I had a new developer decided to make their own charting library. It seemed
like the best idea was to let him try and learn why that was a bad idea. Which
looking back I think many other people had the same idea with me.

Honestly, I think programming is at the point where apprenticeships are a good
idea. Thirty years ago the tools where changing to fast, and eventually we can
codify the correct body of knowledge to have useful formal education. But,
education seems to default to handing people a bunch of tools and getting them
to learn it own their own.

~~~
greydius
> It seemed like the best idea was to let him try and learn why that was a bad
> idea

This is exactly why it's a good idea to try your own implementations. You get
intimately familiar with the problem. You understand the trade-offs, corner
cases, api design, etc. far better that way. And there might be a slight
chance that you come up with a better solution.

I've heard that Feynman had a motta something like "If I can't build it, I
can't claim to understand it."

Also, I like the idea of apprenticeships. At some point our academic culture
seems to have shifted from liberal education to some kind of quasi-vocational
preparation. This is probably in response to the death of apprenticeships when
we started requiring a bachelor's degree for entry level professional jobs.

~~~
aaronchall
"What I cannot create I do not understand."

------
alkonaut
Not sure what the articles point is? That you shouldn't write an application
if you can use an off the shelf tool? Who does that?

I'm paid to write code because someone wanted an application. I don't think I
could tell the customers who buy our application that they should learn some
bash or excel and solve their business problems?

I assume under some rare circumstances a developer isn't faced with writing an
app (site, CAD program, OS, ...) but instead to solve some business problem
internal to a business - _then_ you have the option of not writing code.

~~~
Swizec
> solve their business problems

Your job is to solve business problems. You happen to use code as the tool to
do so because it lends itself to building better, more reliable, more scalable
solutions.

Nobody pays for a lump of code, they pay for _a tool that solves a problem
they have_.

~~~
blub
Depends really. A surprisingly large number of organisations don't seem to be
equipped to handle business input from the development staff or any kind of
"productivity multiplier" contributions. E.g: making the team more efficient,
reducing signup friction, fixing UX annoyances, inventing a new feature or
product, improving security practices, reducing defect rates by introducing
CI/static analysis/whatever.

In this case the job of the developer _will_ be to write code and it doesn't
make sense to pay high salaries because the ROI is not there.

This leads to the situation where very good developers aren't paid good
salaries because in such a company they are _literally_ not worth the money.

------
white-flame
The major problem of bringing in external technologies is that they take over
your architecture, not that they might introduce bugs.

There is no catch-all architecture, so there is guaranteed to be some
impedance mismatch between the expectations of your project, and the
provisions of the 3rd party tool. Heaven help you if you need the facilities
of multiple architectures, and try to marshal and connect disparate datatypes
and calling/threading assumptions together.

As programmers, we work with general purpose programming languages. Many
project-specific problems are not difficult to solve in a custom manner, given
somebody with enough experience and hindsight to know how to write such a
forward-looking thing robustly. It is a serious consideration whether or not
to defer your architecture to generic external sources that were not written
with your unique needs in mind. And even if you do, it is by far a best
practice to ensure that such things live behind an application-specific
abstraction separating out your project-specific code from entangling 3rd
party code, allowing you to perform the inevitable migration to a different
platform later.

~~~
davidgerard
This is an issue we're grappling with at present, as we move all our sites out
to AWS: do we build our apps to use the incredibly tempting AWS services, or
do it ourselves?

Our present approach is "hell yeah, if it can be outsourced it should be" and
that applies to services too. We do keep an awareness of what it would take to
do each thing by hand again though.

~~~
white-flame
With AWS, I think cost becomes a significant issue in selecting which services
to use, more so than development issues.

But then again I've also always found that once you start coding to it, AWS
gets you 90% of what you want, and you spend the other 90% of the time
fleshing out the exact retry, migration, and error-handling behaviors you need
manually on top of it. :-P

------
binalpatel
This is employer-centric in my opinion - sure you're not paid to write code,
and sure you can reuse existing code base in new and exciting ways.

But - there's also value in learning new things, in new skills, in new
toolsets. Maybe it's not best for the employer, but for you the employee it
can help quite a bit.

There's a fine balance - ideally your employer encourages you to learn things
on the job, and to try new things that may not necessarily make it to
production, but improve your skillset overall.

~~~
drvdevd
That's an interesting take. I think it's important to also remember there's a
fine line in breadth vs depth learning in this field as well. So called 'Taco
Bell' programming _does_ encourage you, in a way, to learn the basic tools in
greater depth than perhaps you would if you weren't forced to.

~~~
binalpatel
I completely agree on that - it's exactly like math, the only way to truly
learn it is to practice, over and over again, until you've mastered the
concept.

This is something I'm coming to terms with in my career right now (~3 years
in) - do I learn something to a mastery level, even if it's not the most
marketable thing, or do I focus on breadth first and shoot for depth later.

------
agentultra
> In fact, code is a nasty byproduct of being a software engineer.

This is the core of the matter.

This is something Dijkstra, Edward Cohen, Jayadev Misra, and others in and
around the formal methods camp have been saying for decades. It is more
worthwhile to solve the problem than to guess your program into existence and
patch the errors later. To dismiss them is to say you do not appreciate the
true difficulty of programming and designing systems.

In practice I don't write formal proofs for every line of code -- how
exhausting! But I do often write high-level specifications in tandem with the
software I'm using to implement it and often one informs the other to the true
nature of the problem I'm trying to solve. And I find that as I improve in
different logics and predicate calculus I can find and spot the design errors
in the structures formed by code that you don't see if all you're doing is
trying to "solve the puzzle."

The whole approach to guessing your program and patching the bugs later is far
too addictive. It saddens me when otherwise good programmers fall into this
trap. It creates work for oneself but it keeps you from solving the real
problem at hand!

Nice article. Not sure about the allure of "Taco Bell," but the spirit is in
the right place.

~~~
rpazyaquian
Where can I read more about this? "Formal methods"? Being able to write proofs
and tests/frameworking around things that I need to write would help me be
more confident in what I do and also help me keep myself on track/not end up
going down rabbit holes.

~~~
nickpsecurity
There's several, different kinds you might use. One group are designed for
formal specification rather than verification where you're mainly making it
easier to understand for people with some tool checking. Another type is
designed to help a formal logic prove specific things about your software.
Then, there's lighter versions like model checkers that explore abstract
models of the system to prove properties about it but operate on constrained
problems.

Here's an introduction to Z specification language that illustrates how it
uses simple formalism to precisely specify requirements and design going from
abstract to concrete:

[https://people.csail.mit.edu/dnj/teaching/6898/papers/spivey...](https://people.csail.mit.edu/dnj/teaching/6898/papers/spivey-
intro-to-z.pdf)

Alloy is a model-checker in a similar vein as Z that's designed for easier use
and automation:

[https://www.doc.ic.ac.uk/project/examples/2007/271j/suprema_...](https://www.doc.ic.ac.uk/project/examples/2007/271j/suprema_on_alloy/Final%20Report/LaTeX/report.pdf)

Although TLA+ is popular now, SPIN was the goto model-checker for analyzing
software for concurrency errors:

[http://www2.imm.dtu.dk/courses/02152/CP/spin.pdf](http://www2.imm.dtu.dk/courses/02152/CP/spin.pdf)

Software Foundations teaches you formal verification of the kind that is used
in cutting-edge academic projects like CompCert compiler or seL4 kernel:

[https://www.cis.upenn.edu/~bcpierce/sf/current/index.html](https://www.cis.upenn.edu/~bcpierce/sf/current/index.html)

Language designers can also include lightweight, formal methods into their
type systems like Design by Contract which helps knock out
interface/integration errors:

[https://www.eiffel.com/values/design-by-
contract/introductio...](https://www.eiffel.com/values/design-by-
contract/introduction/)

Finally, since logic programming is so fast these days, one can even translate
logical specs into logical programs to straight-up execute the specification:

[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.34....](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.34.6816&rep=rep1&type=pdf)

Note: The Z, Allow, SPIN, and Coq tools referenced above all have websites
with FOSS software, tutorials, etc. Just Google them.

~~~
agentultra
Eiffel, I hear, was (is?) quite cool. I've read some of Bertrand Meyer's work
and have learned a lot from it.

One area that is becoming really interesting to me is in dependently typed
languages and their ability to encode at least some of the properties of the
formal specification in the type system.

I haven't had much time to take a deep dive into Agda but what I have
challenged myself with gives me hope that this may be the way we write
programs in the future (even if it's not Agda _per se_ ).

~~~
nickpsecurity
Re meyer

The neat thing is his method was adopted commercially with years of success
despite never showing up on Hacker News, etc. It combined efficiency, OOP,
basic safety, and concurrency safety (SCOOP). Most talk about adoption of
formal specs in theory but he got it done in practice with DbC in industry.
Now, tools like SPARK, Ada 2012, and Perfect Developer are using it. You can
do it in C, C# and Java, too.

Btw, in case you missed it, his Theory of Programs defines most aspects of
programming in an elegant, precise way using set theory:

[https://arxiv.org/pdf/1507.00723v3](https://arxiv.org/pdf/1507.00723v3)

Re dependent

Learn from the master:

[http://adam.chlipala.net/cpdt/](http://adam.chlipala.net/cpdt/)

Far as whether they're good, Im not sure as formal methodists have endless
arguments on it. The critics basically say you have to put in enough spec and
proving work that you might as well do the real thing in a prover then extract
it. Chlipala actually does something like that called Programs as Proofs I
think. Memory gettimg fuzzy. Just remember dependent types vs proving is in
dispute at the moment.

------
DanielBMarkham
Every now and then we'll see an HN thread that asks something like: what do
you know now that you wish you would have known when you started programming?

This. This is the thing that took the longest to sink in and had the biggest
impact. There were a lot of cool languages, tools, platforms, and systems
along the way, and I was stoked picking up each one and coding -- but after
decades of that, I realized I was focusing on the wrong thing.

I think the thing that convinced me was when I got to start watching lots of
technology teams in the wild across multiple organizations. So many times I
would see conversations and tons of problem-solving effort being spent on the
tools to solve the problem instead of the problem itself.

A couple of years ago I was teaching tech practices to a team that was
deploying on iOS, Droid, and the web. After we went over TDD, ATDD, and the
CI/CD pipeline, I emphasized how crucial it was not to silo. When I finished,
a young developer took me aside.

"You don't understand. We have coders here who just want to do Java. They want
to be the best Java programmers they possibly can be."

I told him that he didn't understand. Nobody gave a rat's ass about people
wanting to program Java. They cared about whether the team had both the people
and technical skills to solve a problem they have. It would be as if a
carpenter refused to work on a cabinet because it wouldn't involve using his
favorite hammer. You're focusing on the wrong thing.

Sadly, once you get this, the industry is all too happy to punish you for it.
That's because the resume/interview/recruitment world is interested in
buzzwords and coolkids tech, not actually whether or not you can make things
people want. This means sadly, in a way, if you continue growing, it's
entirely possible to "grow out of" programming.

~~~
NobleLie
> I think the thing that convinced me was when I got to start watching lots of
> technology teams in the wild across multiple organizations. So many times I
> would see conversations and tons of problem-solving effort being spent on
> the tools to solve the problem instead of the problem itself

Your insight really hit home. Especially since I've been on a new software dev
position for about a month now. This is the overwhelming issue that is already
reared its ugly head, is massively frustrating and I feel (nearly) powerless
to stop it.

------
scotty79
Actually I'm paid to do this:
[http://devhumor.com/content/uploads/images/November2016/mode...](http://devhumor.com/content/uploads/images/November2016/modern-
software-development-animation.gif)

Writing code is just the only way to do the above since all attempts at making
it less text file driven have failed so far.

------
Const-me
That only applies to web dev and to a subset of user-mode PC, server and
mobile software. While I understand that represents the majority of the
software being developed, that article is IMO an incorrect generalization.

Some of us do CAD/CAM/CAE, the proven tools either don’t exist, or are
targeted towards companies like Boeing and GM and cost a fortune.

Some of us work on console games. The environment is pretty close to the bare
metal/hypervisor, and typically, there’re significant costs involved in
integrating any third-party stuff.

Some of us program embedded firmware. Only recently the hardware became fast
enough to reuse those proven tools ported from PC, you can’t use those on a
PIC16, just not enough resources.

That’s just what I personally did/doing over my 16 years in the industry. I’m
sure there’re other fields where the proposed approach is inapplicable for
various reasons.

------
charlieflowers
This is a good article, and the quote in the middle is absolutely amazing --
it belongs up there with some of the most insightful quotes about software
ever (and it was not even directly about software).

I sum the quote up as, "Systems are sentient beings like the One True Ring,
and they will absorb you. Soon, though you believe you are thinking freely,
you will actually be merely a part of the System, thinking what it wants you
to think." So true!

But ... Taco Bell programming _still creates a new system_. That's a flaw in
the article's premise.

If you solve a problem by stringing together 11 tools, then yes, you should
get some benefits from reusing preexisting tools. But now, you have a system
with some rube goldberg characteristics, plus you've written a bunch of "glue
code" (which is "new code") in the process.

Those systems can often turn out to be more complex.

------
aswerty
It's pretty amusing when you have to keep repeating to a client that the off-
the-shelf tool is better, cheaper, and is immediately available to them. Yet
they still argue for the development of a new system. So I don't think this
push towards custom builds only comes from the developers side of things.

And another thing worth pointing out is: most employers hire you to write
code. That's the job spec. So don't be surprised that that's what we end up
doing.

~~~
gonzo41
The worst is when people buy off the shelf and its close to what they want.
Then they ask for changes.

~~~
clifanatic
> they ask for changes

And expect those changes to take an hour (maybe two).

------
logicallee
Wake me up the next time a 5-line shell script in Bash that uses only standard
tools and runs off of any default Debian sells with a license cost of $20
(only) -- you know, for the 5 lines, not anything else -- and anyone pays it.

Doesn't matter what it does. It is literally impossible to sell even $20 worth
of the solution the person advocates. Go ahead: link me to anywhere in the web
selling a 5-line bash file without anything else. I'm waiting.

You can do a lot in 5 lines, too. lalalala. waiting. While I wait I think I'll
make some money coding something people actually pay for. /s

Seriously though, while the author's point might stand in many sys admin and
even systems integration roles - most of the software world actually pays for
deliverables: the clearest example of which is consumers doing so. People
would rather spend 20 hours cursing, and then give up, rather than pay for a
systems integration script that generalizes and solves their problem. It's
what the market _demands_. This article really would make sense if it came
from the person paying -- but it doesn't. nobody who is paying actually says
the words the article chose for the title. Yes, you are paid to code.

~~~
clifanatic
> Wake me up the next time a 5-line shell script in Bash

Or when somebody can write a 5-line shell script in Bash that:

a) typical non-programmers can and will use b) produces enough diagnostic
information that anybody (programmer or not) can use to troubleshoot when
something inevitably goes wrong - whether it's user input, network
connectivity, a missing dependency...

I get what he's saying, but he's talking about a pretty small subset of what
we really do.

------
alrs
I was paid pretty well yesterday to judiciously delete a lot of code, and I
had a blast.

~~~
mrweasel
I love deleting code. It's probably when deleting code I feel most productive.
And of cause: deleted code is debugged code.

~~~
trprog
People get weirdly apologetic when they have to tell you that code you have
written isn't getting released/merged.

I think its great. My future support burden just decreased. That is a big
piece of code that will result in zero bug reports.

------
bluetwo
I don't know about you, but I'm paid to solve problems.

~~~
randomdata
Me, I'm paid to translate someone's idea from one language to another. The
value to the business is already understood by the one conveying the original
idea. My only job is to ensure that the entity on the other side fully
understands what was originally communicated without hinderance through
language barriers.

~~~
bluetwo
That sounds great, but I never see clients who actually understand what they
need.

------
golergka
You know these occasioanl threads about engineer burnouts we see and post on
HN? Well, I actually feel that when you are "burned out" and don't feel like
writing complex systems is "fun" anymore, you actually become a better
engineer - exactly for the reason described in this post.

~~~
lisivka
Exactly. After burnout, I spending a lot of time trying to kill code and make
simpler designs. However, my outsource firm does not like that.

------
libeclipse
I can't emphasise how true this is. I've written tonnes of temporary scripts
that parse some files or rename some directories, and then later discovered
that I could have done it with a single UNIX command.

I'm not employed as a professional software developer, so I still don't
actually use the helpful UNIX commands. Takes all the fun out of it. :P

~~~
z3t4
The other day I had problems with grep, so I rewrote it in JavaScript ... I
could have used awk, but at least my script is more then double as fast as
awk. I think it's some sort of procrastination and being self managed. Reminds
me that I should get off HN and start working.

~~~
travv0
What problem did you have that the easiest way to solve it was by rewriting
grep?

~~~
z3t4
I was investigating an e-mail problem, searching log files across several
e-mail servers ... Did it go through this server, or that server ? After a lot
of frustration I found out grep didn't show all matches ... I does report the
right amount with the -c argument though.

------
hpaavola
If you see yourself as a software developer instead of problem solver, you
tend to solve all your problems by writing code. In many cases problems can be
solved by adjusting processes, improving culture, education or just by
learning to use the current tools in more efficient ways.

~~~
davidgerard
"Developer" rather than mere "coder" _should_ mean you're aware of the full
import of the system from requirement to end user deployment and production.
Sometimes it does.

~~~
TeMPOraL
Enter the insane notion of separating developers from end users. You have
sales and managers talking to customers, then writing you a half-assed
specification that's broken and illogical because they're not trained in
noticing general ideas behind specific points. _sigh_.

~~~
davidgerard
To be fair, extracting coherent requirements has pretty much always been the
problem.

~~~
TeMPOraL
True, but it's good to at least have someone deeply technical on the
discussion too, just for the ability to come up with generalizations and -
after presenting them to the customer - to confirm whether they're sound, or
whether the customer has a completely different model in their head.

It's easier to do that with the customer than with the spec - specifications
can't talk back to you.

------
weego
I'm paid to turn a business requirement into software. I create products.
Coding is an unfortunately complex step in that process.

~~~
Walkman
No, you are paid to turn a business requirement into a SOLUTION. Yes,
unfortunately most of the time you have to write software to reach that.

~~~
crpatino
If the business requirement is to produce something to _sell_ to other
companies, more likely than not you will end up writing software. You simply
cannot build enough entry barriers and protectable IP by glueing together a
bunch of standard components in a clever way.

------
lolc
Good read. Reminded me of "Why I Strive to be a 0.1x Engineer"

[http://benjiweber.co.uk/blog/2016/01/25/why-i-strive-to-
be-a...](http://benjiweber.co.uk/blog/2016/01/25/why-i-strive-to-
be-a-0-1x-engineer/)

------
mynegation
It is all about efficiency.

Can you dig a canal with a tried and true shovel? Yes, you can, but you will
need a lot of time and many shovels.

Can you cook up bioinformatics analysis in Shell and Awk. Yes, you can, but
you if you want a large scale analysis to be done in a reasonable amount of
time, you roll up your sleeves and reach for compiled languages, distributed
systems and so on.

There are downsides in introducing new systems, but it should be weighed
against the upside of suitability and efficiency.

~~~
chadgeidel
It's interesting that you use the analogy "can you dig a canal with a tried
and true shovel". The attempts at building the Panama Canal [1] were basically
just this, and failed. It's a great point though, and on-topic. I think a lot
of times large-scale software projects are approached in exactly this way.
"Let's just hire a bunch of mid-level developers (shovelers) and get them
writing. We can always add more developers." It seems to be the prevailaing
attitude with outsourcing as well.

[1]
[https://en.wikipedia.org/wiki/History_of_the_Panama_Canal](https://en.wikipedia.org/wiki/History_of_the_Panama_Canal)

------
Illotus
I sorta get the idea of the article. Working smart etc. However the incentives
in organizations run often counter to that. Gluing together existing pieces to
do some grunt work is rarely good for your career. Building new glorious
systems is much more likely to do that.

Also for orgs that do the developing for other orgs it isn't really optimal to
offer the quick and efficient solutions unless competitors are doing the same.

------
Paul_S
In my current job I get paid for writing emails, reports and filling out
forms. Programming is just something I sneak in when no one's watching.

The company I work for is super successful so there must be something to it.

------
JoeAltmaier
Advice for the 99%. Some of us do embedded, where you need an actual driver or
app. Can't dispatch interrupts in bash.

------
khedoros1
I'm paid to keep software systems up and resolve issues. Sometimes this means
adding, removing, or modifying code. A lot of the time, it just means clicking
the right buttons at the right time. Really, I'm paid to know which of those
actions is appropriate in various circumstances, and to get it done when it
needs to be.

~~~
jetpks
Hello fellow Operator.

------
cerrelio
My current team suffers from disgust of Taco Bell programming. I love it, and
I push hard to use it for the projects I lead. I've even had other leads scoff
at my use of Python because "the GIL will throttle your application!"
Possibly, but I understand the performance requirements of my systems and GIL
is the last thing I'm worrying about. I'm not going to write my own
programming language, or use one that doesn't have a good ecosystem, because
an existing language is deficient in some negligible aspect.

Engineers who build things from scratch do not understand a very profound fact
about software engineering: a computer performs menial, repetitive tasks so
you don't have to. Be lazy and use someone else's solution.

When I was 14 I remember writing bubble sort from scratch dozens of times, as
well as input scrubbing methods and binary search trees. I didn't know about
the concept of libraries. Granted the internet (sourceforge, github, etc)
wasn't around and I was writing everything in BASIC or Pascal. By the time I
graduated high school I understood that writing code was painful.

Consequently, it's sometimes alarming that most systems I build rely on
thousands of lines of code that I didn't write and rarely ever inspect. But I
have to trust other developers in order to get my work done in a reasonable
amount of time. I don't even consider myself a good programmer, mostly because
I hate writing code. Nevertheless I do deliver useful, valuable systems. I
know my problem has already been solved by someone else. I like being lazy.
It's my best quality.

This isn't addressed in the article, but avoidance of Taco Bell programming is
a symptom of a disease. The disease is ignorance; mostly in managers who are
out of touch with the technical landscape in which their teams work. Any time
I hear of a team building their own tools or doing significant amounts of de-
novo work, I try to limit my dependencies on that team. You're never going to
ship that shit, buddy, but I solemnly admire you for trying.

------
didibus
I fail to see the point of the article. What's the proposed alternative? To
become an admin?

I also doubt most people write software from scratch. We use a well proven
language, ide, compiler and deployment tool. We use existing libraries,
frameworks, databases, caches and services.

Why doesn't that count as Taco bell programming? When's the last time you
wrote code for all these things instead of just assembling all of it together?

This article is forgetting the lesson learned, highly configurable generic
software that doesn't need a code change to adapt has actually failed us, and
is the source of failure. That's why Domain Driven Design was born. Write
simple software that target a single domain only. Write one of those for every
domain. Do not try to use the same software with multiple tweaks and config
hacks for all your domains.

~~~
OpenDrapery
I guess generic-ware like Microsoft Dynamics CRM is putting this to the test.
Written once, configured for whatever domain you wish.

------
sundvor
"You may not be paid to write code, but when being hired we're going to throw
every convoluted or esoteric brain scratching coding test at you for you to
pass, which you'll then never have to do again. Until you apply for your next
job, that is."

------
ensiferum
The Basic premise is true. Every line of code that you write is a liability.
Best line of code is the one that you don't write. So the corollary is that
the less code you use to solve your problem the better.

~~~
nickpsecurity
That's how I read it. We also no the cost of software, from fixes to
extensions, multiplies in the maintenance phase. Many organizations are stuck
on huge piles of software too complicated to change. Better to not have huge
piles then unless one absolutely has to.

------
titzer
FTA:

> Gall’s Fundamental Theorem of Systems is that new systems mean new problems.
> I think the same can safely be said of code—more code, more problems. _Do it
> without a new system if you can._

I agree with the basic idea here, yes. But I would have to disagree strongly
with the last part.

The problem with _Do it without a new system if you can_ is that we need
judgment to decide when to make a new system and when not. Sometimes just
writing a small piece from scratch instead of using (and repurposing!) a
poorly-matched prior system is a hell of a lot simpler.

~~~
Hoasi
Right, sometimes a new system happens to be the best solution.

------
caffodian
This is a great post. I think the "paid to write code" is often a byproduct of
environment - whether it's poor engineering leadership, bad productivity
measurement, etc.

------
bryanrasmussen
no, but job adverts are written asking for people to write code and often take
tests to show they can write code.

Resumes and interviews seem to be heavily focused on if yu can write code. And
there will be lots of talk about how much code you have written in the past.

which I guess is what the article is really railing against - but what it
comes down to is in theory you're not paid to write code, in practice you are.

------
ImTalking
Agreed. I have always felt that technical people approach their jobs from the
wrong side. They cram every technical acronym on the CV in the hope that
something will stick. They don't understand business. Business wants value.
The CV should concentrate on the value created in your past. If it doesn't get
past the recruiters then the job wasn't meant for you anyway. Most techies are
programmers who happen to make money at coding, whereas you should be a
businessperson who programs; with the difference in attitudes being night/day.

Some time ago, I went for a architect role at a telco which was the largest
Progress shop in the southern hemisphere. The interviewer asked if I knew
Progress and I said "No but that is only knowledge" and talked about
successful projects and later found out I was hired because of that sentence.
But I knew 15 languages at the time so what's another language, and sure
enough, 3 months later I was reviewing Progress code. You have to convince
them to hire you because of your perceived value. I have interviewed a lot and
it always cracks-me-up when I ask if they know some technical thing and the
job-seeker goes "No, but I've heard of it" meaning they are unwilling to admit
that they don't know one of the million of technical languages/platforms/etc.
We aren't Leonardo daVinci, who was probably the last person on Earth to know
pretty much everything. It's OK to say No. So say No and explain why that
doesn't matter.

Regarding the tools we use, I agree again. I have used the same DBMS for 15
years. I know it, I feel safe using it, I know what it likes and dislikes. The
majority of all my coding is in stored procedures in the DBMS and I don't
really care what the front-end is, whether it's C or some new-fangled hot
platform. The lower level your coding the better. Find something that works at
a low level and stick with it.

------
jonkiddy
I'm paid to kill jobs. I meet with a group of internal customers to
ask/watch/learn what they do. Then automate the business tasks so that one
person can do the job of the entire group more effectively than before. Then
provide pretty charts to the managers as they "downsize" their groups.

------
ap22213
Meta question: do software developers typically enjoy these types of
officious, bossy article that state what is and what must / must not be done?

The tone of these types of posts always make me chuckle. And, I see similar
types of articles on here often. When I read these, I feel like Dad is mad at
me for being a bad programmer.

~~~
bluefox
Nowadays it pays well to be a programmer (oh wait, developer; engineer;
whatever title helps you rationalize), programming-qua-profession has exploded
(it even draws the feminists... why aren't they into carpentary? draws
governments, America Codes!), and articles are written with the assumption
that everyone wants to be a good cog (oh, employee) and consider business
needs above all, play good by the team, understand why company interests are
always more important. If you don't do (think) this or that, well, you're just
not being a professional! Why would BigImportantEntity, or anyone for that
matter, hire you?

It's much easier for many people to come up with these articles than it is to
write something technical.

I write code since forever, addicted to it. I happen to be in a field that
pays good money for my addiction. So far, despite the stupidity of the
profession, things turn out mostly OK. Why does someone pay me? Don't care. As
long as the relationship is beneficial to me, it's OK. I feel I have more in
common with starving artists in other fields, than some corporate official
looking out for business interests. So I'd be a starving programmer in a
parallel world where programming is not a hot profession. Now, if I had my own
business, then I brought all these nontechnical issues upon myself. But then,
I'll pay myself for whatever reason I want.

~~~
TeMPOraL
I am a programming addict since early teenage years. I like writing code. But
I also like that code to do something fun or useful.

One time, it came the day I was supposed to enter the job market. So I looked
at what companies - around me and worldwide - are doing, I read the stuff
about "solving business problems" instead of "just writing code"... and I
realized that if I were to _really_ care about this, I would be
_unemployable_. Because most of the "business needs" in our industry are
trivial bullshit stuff that's at best neutral (more often harmful) to society,
and only exists to make money for some entrepreneur. _I don 't give a shit,
and will never give a shit about those problems_. So - through many years of
depression and burnout - I learned to _ignore_ most of the business goals and
focus on doing my part the best I can.

For example, right now I'm paid for developing an application that shouldn't
really exist in the first place, and makes little sense to anyone - not to
developers, not to people who will end up uing it - except the management. But
well, management decides. So if I'm making this application _anyway_ , I'm
focusing on making it as useful as possible. Management asks for features. I
do the ones that make sense and politely suggest changes in the ones that are
idiotic. They're happy. I'm paid. When they're not looking, I'm venting out on
HackerNews.

\--

So yeah, to people constantly writing about focusing on delivering business
values: please tell me how to look for values worth delivering, in the sea of
moral bankrupcy the current job market is.

------
mobiuscog
And people wonder why software quality is going downhill.

Of course a Software engineer is paid to write code - if they're not, you
probably want a different person.

Maybe we need a new job title: "Business Value Expander"

Requirements: Glue together everything else that's already been written by
other people, and make the business rich.

What could possibly go wrong.

~~~
ThalesX
I'm not really sure what they are paying me for anymore.

I do analysis, planning, testing, development, client presentations and when I
raise this concern with my TL I always get the 'cross-functional team'
argument.

~~~
mobiuscog
It seems that Software Engineer (or Analyst Programmer, etc.) are being lost
as professions, and becoming 'careers'.

You just do everything you're asked to, in order that the business makes money
- code ? Meh, anyone can do that.

How many other professions suffer the need to be 'cross-functional' ?

------
carapace
"Somebody else has had this problem."

(I'm gearing up to build a big distributed "fabric" and reading the SaltStack
docs; it's a weird feeling of mixed happiness and disappointment as I discover
all the problems they've already solved for me.)

------
tudorw
love this, much of my client handling is explaining why they don't want what
they thought they wanted, how simpler is easier for them and their users, how
functionality driven by need is more powerful than grand all inclusive visions
and how as I am seeking a long term relationship, we are here to adapt to
change, not to implement a 'final solution'. At the end they more often than
not appreciate the honesty and I get the work, when I do the work I'm not
questioned on decisions as often as the trust is there. It's a win win
scenario.

------
lloda
I was in the UK a few months ago for a meeting and they had a plate of sorts
in the room with a list of company guidelines. One of them was ‘Everybody
sells’.

It seems obvious but I'd never seen it put so starkly.

~~~
davidgerard
My beep-boop sysadmin job is _at least_ 50% internal public relations, in one
form or another. Pretty much any job interacting with humans is, I think,
which is basically all of them.

------
iLemming
Yes, we are paid to write code. The final goal is to create a product, and
solve problems, yes. However, as a coder you should think about the code, you
have to breath the code, you need to feel the code. Quality of the code should
become your obsession. Succinct, nice, readable and reasonable code is more
likely to lead to a better product. On the other hand - failing, shitty
software, often is a downright result of badly written code.

------
sickbeard
I'm pretty sure I am paid to write code that solves problems the business
needs. What's this you're not paid to write code meta bullshit?

------
Ericson2314
Yes code reuse is important, but most of our current abstractions suck. It's
good to rewrite old junk so you never need to rewrite it again.

------
otabdeveloper1
> a million other people have probably done the same thing

If this were true than 99% of software wouldn't be such crap.

~~~
TeMPOraL
Of course they did! Especially in the web world. It's just that this million
other solutions are all crap you can't reuse even if you wanted to, so you too
have to do the same CRUD thing everyone else is doing, only in a slightly
different way.

~~~
zepolen
Now there are 1,000,001 crap solutions.

------
cdevs
I think I have the opposite issue at my current job as the person in charge
wants to put every site, every db, every cron job ,every filesystem on one
server and then wonder why we have a io problem...

1 instance on aws...sure hope our availability zone stays up next year.

~~~
riskable
To be fair, running everything on the same host _is_ very efficient. It's just
risky in terms of (lack of) redundancy and unpredictable loads.

When hardware was expensive the idea was to make everything as tiny and
efficient as possible. Now that hardware is cheap the idea is to make
everything as _scalable_ as possible so as to take advantage of all that extra
hardware you can now afford.

The next phase of this evolution is to go back to making everything tiny and
efficient again as we reach the theoretical limits of horizontal scalability.
A good way to "force" such practices is to make your developers use single (or
just limited) hardware for everything.

I doubt your boss is coming from this angle but I've actually witnessed this
put into practice by forcing a small development team to run their code on
Raspberry Pis. It really brings home the idea that, "No, really: Your code is
slow and inefficient."

It makes people re-think their architectures and often forces them to divide
tasks up into smaller pieces that can be written efficiently. Also, nothing
says, "ditch your ridiculously complicated and slow build process" than
forcing it to run on embedded hardware.

If your _build_ forces a multi-core embedded system with a gig of RAM to
thrash and crash you need to re-think things a bit =)

------
ChuckMcM
I agree with the insight, the one that says you are trying to solve problems,
not write code. But I don't think we're just mixing the same 8 ingredients.

------
slantaclaus
It would be nice if he provided a list of unix tools deemed essential
knowledge to any programmer. Anyone care to provide a list of their own
essentials?

~~~
orly_bookz
I'm no expert but have always found the O'Reilly books helpful.

Also... well I'm not sure what HN's policy is on sources/linking but let's
just say that you could search right now for "Classic Shell Scripting pdf" or
"Learning the Bash Shell pdf" and find those fairly quickly online...

------
gaius
Bill Gates said measuring software progress by lines of code is like measuring
progress on designing a new aircraft by weight

------
japanese_donald
"We’re not paid to write code, we’re paid to add value (or reduce cost) to the
business"

I'm curious to know how many companies Brian has worked for as a software
engineer. The majority of the places where I've worked just want you to code.
They don't really care about adding value and just want the job done as
quickly as possible so customers aren't upset (usually because the sales team
promised a feature that should take 2 months in 2 weeks).

It's the main reason I quit and started my own company. I was tired of getting
into battles with management over the well-being of their own code base and I
was tried of being forced to write terrible and hacky code.

~~~
clifanatic
> They don't really care about adding value

They also want you _doing_ something every hour of every day - and
learning/studying/researching/prototyping/experimenting/refactoring/migrating
doesn't count as _doing_ anything, because there's no "business driver" behind
it. So you have to invent things to do because there's going to be a daily
standup at 8 AM tomorrow morning where management engages in the daily "who
can I fire because _I_ have to _do_ something, and firing somebody is
something" ritual.

