

Your Job is Not to Code - Daishiman
http://www.andresosinski.com/you-job-is-not-to-code.html

======
credo
"Your job is not to Code"...."Your job is to solve problems" says the post

Now that it is #1 on the front page, I look forward to the sequel "Your job is
not to solve problems, _your job is to prevent problems from happening in the
first place_ "

Anyway, on a more serious note, my job is to code, my job also includes
numerous other things. None of these things are necessarily an end to
themselves, but semantic games aside, it is my job to do all of these things.

------
IvyMike
I guess I'm the only one so far who kinda agrees with the author.

One thing not explicitly spelled out in the article: you should avoid doing
coding that is not actually solving anyone's problem.

I've seen a lot of engineers, and worse yet managers, who fall into the trap
of "more typing = more productivity".

~~~
gitah
Sometimes it's very hard to justify why a project needs to be done especially
if it involves back-end refactoring. Additionally, there are many ways to
implement a project; the fastest ways usually involves a lot of un-maintanable
hacks. However, your project stakeholders won't care how terrible your code is
as long as the project works

If it was up to business, they would have developers crank out features non-
stop without time to go back and clean up technical debt.

The root cause is management not understanding how software development works.

~~~
austinz
Absolutely. I can't agree with this more.

A long time ago I worked on a codebase where (among other problems) developers
who wanted to extend a particular feature needed to modify five or six
different methods spread across a number of files. (This feature was basically
a pipeline that took in JSON from our servers and translated it into views to
display to the end user.) Forgetting to modify even one of these files would
lead to code that compiled but would throw cryptic errors at runtime.

Developers from outside our team who wanted to work on the codebase and extend
the feature would reliably lose several days to either the problem I described
above, or hunting around the code trying to piece together how the feature
worked from the disparate implementation details.

Eventually, I took some time off and refactored part of the feature so that
only a single source of truth needed to be modified in order to extend it. As
a bonus, this refactoring made the mapping between data models and views in
our application explicit, making the behavior of the feature significantly
easier to understand. I didn't ask management or submit any sort of formal
proposal; I did this on my own time because I had become fed up with the
limitations of the existing approach.

After the refactor entered the codebase, the aforementioned bugs vanished, as
did many of the questions from outside developers about what models
corresponded to which views, or how the feature worked, or how to extend the
feature in general.

I tell this intentionally vague (and honestly quite pedestrian) anecdote not
to brag (the refactor was reasonably straightforward), but rather because I
wanted to emphasize the difference between feature work and technical-debt-
payoff work. The refactor almost certainly saved a considerable amount of
developer effort and increased code reliability. But how much so is not
something that can be easily measured (if at all), unlike the impact of a
user-facing feature. Not only this, some combination of apathy and political
pressure from external stakeholders tends to lead management to deprioritize
paying off technical debt. Proposals to management to formally set aside time
to address other issues of similar scope were pushed back repeatedly or
dropped.

PMs and product people can A/B test, gather analytics, get concrete data on
hypothesis A versus hypothesis B when it comes to features. But it's rare that
engineers get asked how much more quickly they could get their work done if
they hadn't had to hack around unmaintainable hacks, or how much more reliable
their code would be if bad design didn't muddy up the codebase or provide
hiding spots for weird corner cases. Given how expensive software engineers
are and how supposedly scarce they are, I'm honestly surprised that this isn't
something management thinks about more.

~~~
Joeri
Managers who don't know how to measure what they want settle for wanting what
they can measure. Feature delivery is easy to measure, technical debt is hard
to measure. Ofcourse, in the long run technical debt affects feature delivery,
but people tend to look for causality relationships in the short term. That a
decision not to allow refactoring slows down a set of features 6 months later
won't be linked in a causality relationship unless proper root cause analysis
is done.

------
moistgorilla
I read this article twice and really don't understand what it was trying to
say.

From what little I gathered the author believes that it is more important to
educate the customer about what software developers do than to code? Or that
our job is solving problems, not coding? (which if you are a software
engineer, solving problems and coding go hand in hand). But then he conflates
software engineering with IT.

Can someone explain this to me?

~~~
dm2
Some blog posts are just written because the author wanted an article to
attract people to their site.

I'm not necessarily saying that was the case with this article, but I do agree
that it lacks substance, purpose, and a clear message.

Some people are code monkeys, but many software developers (especially
consultants) are fortunate enough to be primarily problem solvers. There is
certainly a degree of creativity required for programming, you have to be able
to think outside of the box, approach the problem from several prospectives,
and it requires a wide range of skills and experience to produce a good
solution. Sometimes it's even necessary to throw everything away and start
over, just like an artist. Many professionals are problem solvers, lawyers,
engineers, architects, soldiers, etc.

Also, "How to Rant your Way Into the Front Page" by the same blog author and
HN user,
[http://www.andresosinski.com.ar/blog_view_entry?id=4](http://www.andresosinski.com.ar/blog_view_entry?id=4)

The problem is not that people are submitting these articles, it's that a huge
number of people upvote it to #1 just because of the title (speculation on my
part).

------
narsil
The title is just linkbait. Coding is as much a means to solving a problem as
walking is to getting to a destination.

~~~
dkural
Likewise, if someone is paying you to reach a destination, it is natural
they'd care more that you reach the destination & on time, not so much about
various aspects of walking style, quality of walking, how your walking gives
you meaning in life, etc.

------
girvo
I'm 23 years old, and I'm a decent developer. Not the best by far, and have so
much more to learn... but I command a very respectable salary for my
experience, age, and location. I can do that because prior (and parallel) to
being a software developer, I was a very very good salesperson (#1 for a
company across their 250 stores, selling mobile phone contracts, retail not
telesales). I'm super thankful for having done that (although the reasons I
ended up doing that instead of development was not so nice), and I find it
helps me every single day as a developer; dealing with clients, working with
project managers, heck even negotiating my salary: all of these were made
easier by my learning how to _sell_. I highly recommend learning it, sure it's
not glamorous, but it is intellectually stimulating, albeit in a very
different way to software engineering. That's my $0.02AUD anyway

------
barosl
"Your job is to solve problems" \- This statement may be useful as a reminder,
but most of the case - it is too obvious to gain something from it. What on
earth are the jobs without solving problems? Of course understanding the
problem is important, but still our primary goal is to code efficiently.

------
kyllo
Code is for humans. The machines only understand pulses of electrons. Your job
is not to code, your job is to make machines do things. Code is just your
means of communication with the machines. It's the tool, not the job itself.

~~~
gmjosack
Though the job description certainly has requirements for how to code. And
knowing a common language allows quick and efficient collaboration among your
team members. So I'd say it is your job to know how to code in order to solve
a problem that the business has.

~~~
kyllo
Yes, but details like common language, coding style, etc are all rules that
humans have made up in order to aid communication with other humans. They are
part of the job only insofar as you need to work together with other humans.
The machine does not know or care about those things at all.

------
wittgenstein
It looks like the job of this article's writer is to create lots of bullshit.

------
re_todd
> Pitch shamelessly

And link-bait shamelessly as well.

------
mantrax9
Yeah yeah yeah, as a garbage man, my job isn't to mop the floor and throw
garbage out, it's to interact with people, educate them about proper
recycling, tell them about the layout of the trash bins and how to locate the
nearest one in case of emergency. Throwing garbage is not what we're being
paid for. Garbage men are thought leaders, influencers, communicators and
teachers.

