
Why Programming is Difficult - krosaen
http://joearms.github.io/2014/02/07/why-programming-is-difficult.html
======
buckbova
Most difficult part for me is letting go.

I am compelled to febreeze every bit of code smell I come across. I often
rewrite large sections of working code into better structures, more
readable/concise syntax, better naming of variables/functions, etc. and In the
process I have at times introduced bugs.

But that isn't enough to deter me.

I feel like I've accomplished something but in reality I have done nothing.
It's kinda like cleaning behind the refrigerator. You know it's dirty back
there, but it's not stopping the fridge from keeping your food cold.

~~~
jrs235
I agree.

However, "You know it's dirty back there, but it's not stopping the fridge
from keeping your food cold."

If you don't properly maintain your fridge and allow too much dust to build up
you could end up burning out the compressor.

Everything needs to be done thoughtfully, in moderation, and with purpose.

~~~
justinsteele
Yup, if we want to beat the analogy further, I would say the constant
attention to code "smells" and such is like cleaning behind the refrigerator
daily when you see dust has landed. I think there is a great middle ground,
where you actually consider the possibility that the improvement to the code
will be a net loss (time investment to improve code and time it saves in the
future). Lots of books about this, many people don't get the full theories,
and instead take the talking points (x lines of code per method, don't do Y,
do Z, etc).

~~~
humanrebar
The analogy falls apart when you consider that:

1\. Fridge dust compounds linearly with time. Technical debt compounds faster
the more technical debt you have.

2\. Most of us aren't in the fridge business. The downside of a burnt out
fridge is probably a lot lower than the downside of a terrible code base.

~~~
DougWebb
Technical debt only compounds if you're building on top of it. A module that
is written once and never needs to be modified doesn't get any worse over
time. Therefore, once it is working correctly, there is no point in wasting
effort to clean it up until it needs to be touched again.

Note that I assume basic documentation, proper naming conventions, and
adequate testing are part of "working correctly". Those are the things you do
as you write the code initially. It's the refactoring/rework/gold plating that
you leave for later, only if you need it.

------
tenpoundhammer
Good Article, I have found the hardest part of software to be the team work.
It's hard to agreement on what's right, to write code that other people
understand, to understand other peoples code, and generally just to get a good
productive team working.

In fact a lot of software design is just for making things easier for humans.
Otherwise we could have files that are 14,000 lines long.... The hardest part
of software is the people.

~~~
Mikeb85
> Good Article, I have found the hardest part of software to be the team work.

This... I'm trying to work with someone whose only programming experience is
with IDEs on Windows that hand-hold every step of the way. Something as simple
as creating a file, compiling it and running it in a terminal is something
he's never done.

I've spent more time trying to explain incredibly basic concepts than actually
getting anything done.

~~~
mattmanser
Taking a day to teach someone an entirely new (and arguably extremely
backward) workflow is exasperating to you?

~~~
Mikeb85
It's not about the workflow - it's about the fact that things like compiling
files, linking libraries, are kind of basic concepts.

For his prior apps (flash) he created objects using only a graphical interface
(never wrote a single class), and the 'program' was a single 9000 line file
where everything (all vars, functions, etc...) was in the global namespace
with absolutely no organization, encapsulation, etc...

Anyhow, for someone who claims to have been programming for 10+ years, I'd
expect some understanding of how the underlying technology works, how
languages and compilers work, etc...

I mean, I like convenience as much as anyone (my Vim setup behaves like an IDE
with code completion, automatic compiling, etc...), but knowing the command
line is a good thing when the app you want to build involves a Unix-y
server...

~~~
mattmanser
Look, "someone only using IDEs with windows" is nothing like what you just
described. You gave us all the wrong facts in the initial comment. You've
identified all the wrong facts as important.

Your fellow is abnormal to the extreme. That he's never met anyone in 10 years
to tell him drag & dropping is not programming is one thing.

Making your description match a good proportion of C# developers or even Java
developers just shows your irrational bias against types of programmer you
obviously view as inferior.

The problem is not that he's using an IDE, the problem is he's not a
programmer.

Bloody luddites clinging to their consoles.

~~~
Mikeb85
> That he's never met anyone in 10 years to tell him drag & dropping is not
> programming is one thing.

It's not drag and dropping, it's using a 'visual programming' tool that the
environment encourages.

> The problem is not that he's using an IDE, the problem is he's not a
> programmer.

I wouldn't disagree, I like IDEs myself. I even use automatic completion in my
word processor. The problem is that he never learned the basics.

> Bloody luddites clinging to their consoles.

It's funny how things always come full circle - search is the big thing now,
everyone has an interface based on search. Windows 8, Linux, OSX, Android,
iOS, everyone.

We enter http addresses into our browser, and search for things using (gasp)
text, but using the command line makes one a luddite. Great logic that...

------
danso
Here's why I think programming will never get much simpler than it is now...as
our stacks and applications become more sophisticated and powerful, so do the
relations between the systems...Apple has managed to make things simpler on
iOS by clamping down on what developers and users can do, which is one
possibility for a "simpler" future. But for those who do want to be developers
and have flexibility...complexity will just have to be a way of life.

As an example, I recently tried my hand at making a Chrome extension using the
Yeoman build tool. It was a simple plugin to allow you, on Reddit IAMA pages,
to hide all comments except those from the IAMA subject and their direct
questioners, and to also auto-load all comments:

[https://github.com/dannguyen/iama-highlights-chrome-
extensio...](https://github.com/dannguyen/iama-highlights-chrome-extension)

Figuring out how to use the yeoman build tool took about 30 minutes (it's not
quite fully developed)...it took about 30 minutes to browse through the Chrome
extension documentation and then think of what I wanted to do. About 10
minutes to write the actual jQuery.

...And then about 3 - 4 hours figuring out why the comment auto-loader wasn't
working. I thought I could simply just have my jquery activate the "click"
event on all "load more comments" links...but a recent Chrome upgrade clamped
down on security, effectively sandboxing all extension code and preventing it
from executing existing inline JavaScript.

IMHO, this is a good security measure. But it just goes to show you that when
things are made "easier" (the scaffolding of the extension, the jQuery to do
DOM/AJAX work), there are still intractable tradeoffs and details that have to
be dealt with...in this case, security.

~~~
philosophus
I had a similar experience with a very basic Android app I did for a Coursera
class. It took me about an hour to finish it, and then 3-4 hours to figure out
that the test cases would only run successfully using one particular Android
virtual device at a particular API version. It didn't work on any other AVD's
or on my phone. This was an exercise designed by a compsci professor at a
major university. Who knows how many additional hours would be necessary to
determine the exact reason for the error?

------
sdegutis
I think "bad environment" is the worst of all the problems.

At first we had no environment, so we had to make it ourselves. A few
companies did this, and turned into monopolies.

Then we started trying to make free/open-source environments to combat this
problem, but they ended up so incredibly scatterbrained that compatibility is
a very real and current nightmare.

The monopolies are trying really hard to give us good environments, but first
of all they come at a cost, which isn't accessible to many (Apple's hardware,
MS's software, etc). And secondly they are not community-driven efforts, so we
have little control over them.

So the battle rages on between the plethora of options I have for a
programming environment. Meanwhile I'm just trying to write some simple apps
that help me pay the bills (we get dangerously close to not being able to each
month) and the competition between environments only slows me down.

~~~
Mikeb85
Free/open source OSes are great programming environments that leave you in
control.

As for the compatibility 'problem', install the compiler/interpreter version
you need from source, use chroot if you need to, etc... If you're making apps
to run on said scatterbrained systems, you can ship statically linked
libraries with the app, or use a cross-platform solution (Java, HTML5,
something like Haxe, etc...).

~~~
dorkrawk
I think a big problem with environments is the balance between "having
control" and "having to control". Sometimes just getting things set up to the
point where I can actually do the work I wanted to do sucks up a lot of
gumption.

~~~
sdegutis
Every time I try linux, I lose several days in config files, and at the end,
it's still not perfect, just "good enough for now".

------
yodsanklai
To me what is difficult about programming is to deal with huge undocumented
and badly written legacy code, and also understanding tons of frameworks and
APIs. Algorithms are the easy part.

~~~
abvdasker
Yes. My company's CRM uses a single 2500-line Perl script to handle all of its
licensing emails. The script was written by our current VP of engineering in
1998 when our CRM was still built on ActiveX. I started porting this code over
to Ruby for our now Rails-based CRM and I am beginning to doubt I will ever
finish.

~~~
codygman
[http://xkcd.com/224/](http://xkcd.com/224/)

------
fit2rule
Programming is difficult because people are profiting from the
difficultability of it. For as long as you can give someone a money-making
machine, but say that it will be 'a lot of esoteric work' to make it, grease
it, keep it clean .. there will be development work.

By the very nature of the business, if you are not improving something, some
human-describable human activity, by using esoteric magic, you're probably not
that good. If you're making it indescribable in the process of making
improvement, perhaps you've been in the business a long enough time to know,
the only difference is whether the customer can be bothered to learn the
language, or not. Anyone can 'program computers'; computers are a universal
language.

~~~
Iftheshoefits
> Programming is difficult because people are profiting from the
> "difficultability" of it

That's backwards. Not "anyone" can program computers. Anyone can _try_ , but
most will fail. Just like "anyone" can "do math" or "do chemistry" or "do
anything", but most will fail. The reason programming is lucrative, whether as
an employee or entrepeneur exploiting programmers' labor (or supplying their
own technical labor), is exactly because not everybody can program _well
enough_ to meet a market need.

It's a curious thing, this misplaced, or in some cases faux-humility about
programming, or any other academic/intellectual endeavour. It dovetails very
well with certain business interests who would love for nothing more than
programming to be as commoditized as, say, janitorial work is. These interests
are definitely getting their wish in some areas (e.g. web/mobile development).

~~~
supersystem
I see programming mostly as janitorial work. Why? Because it's mostly complex
rather than hard. Of course "real programmers" are upset with RoR jockeys when
it turns out businesses pay for delivered value rather than technical
complexity.

~~~
Iftheshoefits
Janitorial work isn't "complex" in any way that approximates programming--even
the programming that "RoR jockeys" do. If the two were on the same level of
complexity, "RoR jockeys" wouldn't be paid as well as they are. And, yes "real
programmers" earn more than "RoR jockeys," because what "real programmers" do
is both more complex and harder. But I think calling them "RoR jockeys" or
implying they aren't "real programmers" is both wrong and juvenile. Otherwise
I don't think you've written anything that conflicts substantially with what I
wrote.

------
duwease
Amen. When I think, "I love my job", I'm generally thinking about the "easy"
part, where the tools are all under my control and well known, and I just have
to build something with them using my knowledge of algorithms and
architecture.

However, the reality tends more often to be: \- Frantic Googling trying to
figure out the magic code to pass to a black box 3rd party component that will
prompt it to spit out exactly what I need \- Banging 3rd party components
together to see what happens to be compatible \- Trying to figure out how to
work around the limitations of an API without being _too_ inefficient or
complex \- Spending 4 times longer on conference calls discussing a problem
than actually fixing it

------
walshemj
Programing is the easy part of the job - getting the customer to agree exactly
what is they want is "hard"

~~~
moistgorilla
Maybe for web development. For everything else... no.

~~~
AnimalMuppet
I've hit that problem in embedded systems, too. It's not just web development
(though it may be worse there).

------
tantalor
According to Leiserson, the qualities of "great software" are,

    
    
      * performance
      * modularity
      * correctness
      * maintainability
      * security
      * functionality
      * robustness
      * user-friendliness
      * programmer's time
      * simplicity
      * extensibility
      * reliability
      * scalability
    

[http://www.catonmat.net/blog/mit-introduction-to-
algorithms-...](http://www.catonmat.net/blog/mit-introduction-to-algorithms-
part-one/)

------
joe_the_user
This article only scratches the surface of the "programming is easy,
programming is hard" riddle. It's a big question really, linking up with the
"mythical man month" and all the paradoxes that commentators have observed
since people began thinking about the process of programming.

The way I would put it is that programming gives a person more power to
realize their ideas than any other device in existence, in that sense,
programming is the easiest thing ever. But since programming put so much power
at your finger-tips, it gives you more ways to shoot yourself in the foot than
any other activity. So programming while avoiding the pitfalls can suddenly
look like the hardest thing in the world.

Arguably humans have a natural facility with language. And I am inclined to
believe that our ability to produce programs leverages that facility. But
again, the upshot is we wind-up with a really big cannon that, if aimed at all
wrong, blows our feet clean away.

------
dmunoz
I enjoyed this post for one very simple reason: it makes me realize that, no,
I am not the only one who dislikes these parts of programming.

Too often when problems like those mentioned by Joe are brought up in
discussion, the (seemingly) majority of programmers argue that these are just
complexities we have to deal with. Perhaps they're just the vocal ones. I
admit, it is a pragmatic attitude, but I constantly daydream about an
environment, both technical and social, where these problems mostly disappear.

Thankfully, we're starting to approach some solutions on the technical side
with virtual environments, deterministic builds, etc.. The social side I hope
will fall out of having better environments for reproducible behaviour.
Although I believe a total solution is technically impossible (at least
practically, e.g. requiring total system verification, managed behaviour,
etc.), I think we can make a lot of improvements to the environments we
currently use.

~~~
Consultant32452
I have always argued that programming is not "intellectually difficult" (for
me) but is rather "emotionally difficult" for a lot of the reasons mentioned
in the blog post.

------
w4f7z
Programming is hard. Proof-reading? Impossible.

------
Ryel
I don't know whether I think programming is hard or not. I think it's
difficult for the fact that it requires a unique way of thinking and it takes
a series of consecutive and uninterrupted thoughts in order to form a piece of
logic.

I cannot even imagine learning programming and not having instant access to
learning material/answers to my questions.

------
bitcuration
In short, working with computer is easy, working with people is hard. This is
also reflected by salary. It pays to have the skill communicate, influence, or
manipulate people.

Most programmer job is simply translate others thought to language that
computer can understand. Therefore the difficult is never the programming
part, but the understanding human being part.

Comparing to human ability making computer close to understanding human,
civilization has developed much more advanced in manipulate human to think
like computer, evidenced by all the gadgets surround us today. Comparing to
programmers inventing new ways to make computing smarter or say closer to
human, majority of corporate line of business IT programmers are merely
temporarily filling the gap between human and computer, but for how long?
There is no need exaggerate the Corporate experience, that's a translator job
can be easily replaced by cheaper labor and eventually by smarter computer.

------
yetanotherphd
Programming used to be hard because of the hyper-optimization needed to get
things to run.

Now programming is hard because of the giant scale of existing open source
codebases.

It's not just the libraries, it's the toolchains, the build systems, the
versioning tools, and that's just the things I've touched myself.

Someone once compared classical mathematics with modern mathematics, with the
analogy of open pit mining vs deep shaft mining. I think programming has
followed a similar trend. Modern programming involves strategically using
existing tools, combining them without making major modifications to any of
them. Of course, this is just for the individual programmer working on a
discrete task. There is still room to participate in or lead large projects.

------
thiloberlin
With the words of my mentor at my first programming job: Beginners guess
programming is hard. Advanced ones think programming is easy. Experts know
programming is hard.

------
Kluny
Maybe take another run at the spell checker problem though. I don't think you
fixed it well enough.

------
sh4na
I tried to read the whole thing, but gah my brain just couldn't get past all
the spelling mistakes. :-/

~~~
buckbova
You should have kept reading:

> When I’d finished this article, I wanted to spell check the content. At this
> particular time emacs-ispell mode decided to that it could not find aspell,
> the program that I use for spelling checking.

Does emacs have a grammar sanity check as well as spellchecker?

------
bryan_rasmussen
I don't care about the programming, what I want to know is why is using a
spellchecker so difficult?

------
elwell
If programming was 'easy', we would probably be having trouble finding work.

------
varg
Great post Joe!

/patrik.

------
knodi
Programming is not difficult.

------
benched
I think programming is easy. When I sit down to code something, it feels
deterministic, and everything falls into place. I attribute this to: 1) IQ 3
standard deviations above. If I hadn't been this way when I started, I
probably wouldn't have started. 2) I've been practicing hard, 25 years. That's
a lot of time to try a lot of ways to do a lot of things, and find what works.

Here's what's difficult for me, and what only gets more difficult as my own
time grows shorter and I'm less agreeable to wasting it: Working on teams,
under managers, within organisations. Sitting in the third meta-meeting that
week, listening to posturers quibble over what Agile means, rolling my eyes
thinking obviously it's anything but agile. Performance reviews and arbitrary
subjectivity-based rewards dressed in time-consuming process they swear will
make it more objective. Perennial "Strategic Roadmap Shifts", listening to yet
another CEO spout boilerplate bullshit about how this is the one way to glory,
never shall we mention that one from just six months ago - that never
happened. And that means another project cancellation. Then one by one the
coworkers you like the most get fed up and leave, until the day it's your turn
to get fed up and leave. On to greener pastures to enjoy a few months of a
semblance of accomplishment before the whole cycle starts to repeat again. All
that is what never gets any easier for me. Like everybody always says, "It's
the people!"

~~~
psychometry
Do you think that your inability to relate to other people in your
organization is related to your obvious superiority complex?

No one cares what your IQ is. There are many different kinds of intelligence
and some of them, like social and emotional intelligence, also contribute to
your personal success within any particular organization.

~~~
benched
I relate to straight shooters who say what they see. I understand that
fronting, ass covering, being indirect, and speaking the mel[odious] language
of business are ways to play the game.

Mention of IQ induces reflexive invocation of multiple intelligences like
ipecac, but IQ-style intelligence is directly relevant to programming.

High emotional intelligence makes it _worse_ when you're in a toxic corporate
environment.

~~~
psychometry
The only people who are overly concerned with IQ and take advantage of every
opportunity to mention their own score are the people who have nothing to
offer but an IQ score. You come across as incredibly haughty and
condescending.

~~~
mitochondrion
I agree that his comment seemed haughty, but I'd like to mention that yours
does as well.

I disagree that "only people who are overly concerned with and take advantage
of mentioning their IQ". More likely, it's just that smart people with
empathic intelligence don't mention it. You know, because they realize that
others don't like feeling "dumb".

------
jbeja
And thought that i was the only one.

