
Programming is boring - mhotchen
http://dividebyze.ro/2016/11/04/programming-is-boring.html
======
rietta
I'm 34 years old and have been programming since I was 14. I loved it from day
one. I still love it. Even after tens of thousands of hours, two CS degrees,
and hundreds of projects, I still am still amazed that I get to get up every
day, go to my office in the basement, and can literally type into existence
complex systems. I love it. I love the problem solving and making stuff work.
I get frustrated with people from time to time, but on balance I want to
continue to be a programmer as long as I live.

~~~
kzisme
I'm the exact same way I'm still very new in my career - I often hear co-
workers say "The last thing I want to see/do when I go home is a computer"

I'm the exact opposite of that. I work full time as a programmer - go home -
do more things on the computer or work on tech related things. Maybe since I'm
younger I feel this way, but I ~really~ don't think like my mind will change.

~~~
travv0
I'm the same way. I wouldn't want to go home and do what I do at work, but I
love programming things that I choose to program.

~~~
spynxic
"I wouldn't want to go home and do what I do at work, but I love programming
things that I choose to program."

This statement here is what has kept me a good distance away from developer
positions. I love to come up with programs, study them generally, and even
/potentially/ develop a new branch of mathematics with which to frame my ideas
BUT I can't bring myself to write code for cash (unless the program is
something I came up with personally and just happens to be worth something to
someone else.. but even then I dislike the added stress of selling a hobby
project).

tl;dr: I like to program BUT my consideration of having fun doesn't involve
production-ready code. (In fact, I'm not sure what would make code production-
ready [cleansing user inputs(?)], so perhaps it already is.)

------
Koshkin
What _is_ boring is having to spend eight hours a day among people who think
that programming is boring.

~~~
mjburgess
Hackernews fetishes articles from managerial programmer types who have come
down from the mountain of business mediocrity to tell all people with
creativity and passion that it's getting in their way.

~~~
Koshkin
From my experience, managerial types in general seem to not think much at all
about whether programming is boring or not. They usually concern themselves
with other things. But those who do, and, worse yet, find programming exciting
- those are the ones that tend to wreak havok and end up inflicting the
biggest damage.

~~~
candiodari
What sort of damage is that ? I'm of just the opposite opinion. There's people
who like to talk about programs, and there's people who like to program. Those
who like to talk about it ... well this somehow seems to be appreciated by
everyone but they never accomplish anything.

The thing is, I've seen people who love programming learn how to get the
talking part down. I've never seen one who seem to enjoy the talking more fix
the inability of meetings to achieve anything. Everybody is always convinced
meetings fix things, but they never do.

The people who love meetings really seem to hate people who just want to
actually do things though. I even think I know why. Actually doing something
real, like creating a working program, kills what the organization, the team
is doing, for the very simple reason that it's now done. And clients respond
to that: either take what is actually there and working or talk about it some
more ... well they'll take the working thing every time, after all, that's why
they're clients. So for the meeting maniacs this sucks : no more talking about
it. No more talking about the need for more people to achieve things. No more
getting promoted or getting more reports. No more having meetings about the
need for more meetings. No more publishing internal memos about the need for a
new standard for publishing meeting standards within the organization (no
joke: there is an actual file shared with everyone in my company that's
exactly that).

The thing is, it's the life cycle of organizations. When an organization comes
into being, there are few meetings, and only when truly necessary. People just
go off and do things and little regard is placed into communication ...
because doing anything other than actually programming/working would kill the
business. Then they get bigger, and bigger and bigger. Not because, but
despite the meetings, and at this point there come ever more and more and yet
again more meetings. And then meeting paralysis finally kills the business.
Nobody is able to achieve anything, why ? Because the meeting folks have
convinced management to block people doing things without agreement from, by
this point, thousands of other employees. Everything the business does becomes
a disappointment, first just internally, then it becomes visible to clients,
then someone successfully actually does what this company needs to do, and
clients leave in droves. And what does the meeting-infested company do ?

They have endless meetings on what could possibly be wrong. Ironically, this
is used as an argument to prevent engineers from doing anything because
they'll just make it worse !

I once heard a joke that being a lawyer is a sweet gig: the more lawyers there
are, and the more they work, the more lawyers are needed to deal with the
problems created. Meetings truly are like that.

~~~
Koshkin
Looks like you did an excellent job answering your own, now almost rhetorical,
question.

------
manish_gill
This is something I've thought about quite a few times. It's almost counter-
intuitive. The community that we surround ourselves in keeps telling us how
exciting XYZ technology is. But at the end of the day it comes down to reading
documentation/man pages, and trying to implement something that you're trying
to get up and running. I ascribe this feeling of boredom that I get partially
to my perfectionism. But a lot of the times, it's just...why? Frankly, I'd
rather just enjoy life. Programming is great. Latest technology in language
XYZ or framework ABC is fantastic. But there's more to life than that.

Sorry for rambling. Just got home and it's 1am here :)

------
agentultra
Programming is beautiful!

I'm writing an authorization expression parser that generates a Validation
applicative functor (whose errors form a semi-group, so cool!). The users will
only notice that the error messages when they fail authorization will be
descriptive of what they're missing. The developers love it because they get a
rich, descriptive language. And it makes me happy because it's actually not a
lot of code.

If I had written it the boring way there would probably be more code, be less
useful, and I would've tried to find some way to punt the work onto someone
else.

Beautiful code is not just a way to check of your *-ility's. It's also
inspirational. And being inspired leads to creative solutions which amplify
the value you can generate. Sometimes the boring solutions lead to byzantine,
institutional code whose intent, purpose, and function remains a mystery.

For me clarity and utility stem not from documentation and mountains of tests.
It comes from being succinct, clear, and precise. At least the author and I
agree on one point: simplicity is key.

~~~
hawkice
> I'm writing an authorization expression parser that generates a Validation
> applicative functor (whose errors form a semi-group, so cool!).

It's either the successful result or a list of errors. That's what you're
describing here. Boom -- boringified.

~~~
marcosdumay
Well, if you do that with the right interface, a "successful result or a list
of errors" is a "Validation applicative functor (whose errors form a semi-
group)".

------
tomc1985
This times a thousand.

I love programming but I want it to be boring. Boring means no stress,
attainable deadlines, repeat ability, the ability to walk away, and the
ability to tell these 10-hours-a-day hacks to fuck off. Boring means 5-nines
reliability without a devops team because the design was simple, elegant, and
most importantly worked. Boring means you're able to get it right the first
time. Boring means being able to have a life, with other passions or hobbies
completely unrelated to programming or code or geeks, which frankly everybody
needs because we nerds are an unbearable bunch.

I want to slap all these Show-HN innovation fetishists that reinvent the same
thing over and over again. They make life worse for everyone.

~~~
rezashirazian
You just described the fixed mindset to a T.
[https://www.brainpickings.org/2014/01/29/carol-dweck-
mindset...](https://www.brainpickings.org/2014/01/29/carol-dweck-mindset/)

~~~
tomc1985
How?

I've seen this chart and it has very little to do with what is described
above. My point isn't that people should reject challenges, or to push back
unnecessarily when confronted with pressure, or resist deadlines. The point is
that you optimize your environment, methodology, tool usage, workflow, designs
for simplicity, and that when you've done so it grants a level of control and
predictability over one's work that it would appear you guys think is
unattainable.

The above mindset embraces challenges by controlling for their parameters, and
when confronted with a challenge too large you break it up until the pieces
are something that one can assert control over. If that's still too much then
you start shaving off requirements, and if that's still too much then yes, you
might have to dive in and power through it. But that's where the boring
mentality saves you: "diving in" and "powering through it" become more like a
light swim than a sprint or marathon. Plus, when the code is simple and
predictable its very easy to make estimates and then you can give yourself a
larger deadline than you need.

Obstacles are confronted and plowed through -- but again this is not as
difficult because the system is simple enough that most of it can be held in
one person's head. When that fails, though, a little bit of creativity can get
one out of a bind.

Effort... well you got me there. Less work is always better. Smart work, not
hard work. If you are working hard, step back and think for a minute, because
you are doing it wrong and you should probably optimize. There are very few
scenarios for which this rule doesn't apply.

I don't see how my assertions have anything to do with feedback and criticism,
other than to say that there is not as much in the bugs department because the
boring system generally works. How one handles feedback has little to do with
the other components.

It should also be noted that my mentality DOES involve a lot of questioning
management, but that is because management desperately needs questioning. When
a cabal of socializers and non-technical soft-power types try to run a
technology-centered business, they require a lot of course correction so that
development can continue unhindered and not get distracted with silly little
initiatives (or whatever the third-party enterprise sales hacks walked through
the door with this week)

------
Matachines
Programming is boring after five years of CRUD/"business"/"enterprise" apps.
Unfortunately they make up the majority of the jobs out there but making the
effort to get a more interesting job is worth it.

~~~
blowski
I love building CRUD apps! I guess I'm fascinated by learning different
business models and mapping them to code.

~~~
nxrabl
I'd love to hear more about your workflow! It sounds like you've been able to
take a thing people consider tedious, and find joy in it.

~~~
blowski
It's nothing special - I'm just genuinely interested in learning about other
people's problems. Every organisation has some pain points that can be solved
with a CRUD app, and I love discovering them.

I know my tools very well, keep up to date with trends, and I'm constantly
grateful at how lucky I've been. I'm a very mediocre developer, but I'm
fantastically well paid for a job that really isn't very difficult.

FWIW - I use Symfony (especially the form bundle), Behat, and nginx. At some
point, I want to start building Angular front ends as well. I try to be Agile
by delivering early and often.

------
debt
"and making sure your solution is easy to maintain and nurture in the future"

...this is why programming is boring

there's nothing actually more exciting then building out a whole idea and
being like "didn't exist, now it exists and i built it."

making it maintainable is a thing, but it's separate from that initial
excitement. i never go "man i can't wait to make this thing maintainable and
write a bunch of tests and shit omg"

i approach programming as more of a way to make cool art. so idk i might be
different from most programmers.

he's got some good points though.

~~~
vec
Writing something new and cool gets me out of bed in the morning. Writing
tests for my code lets me sleep peacefully at night. Can't have one without
the other.

------
gandolfinmyhead
People who say programming is boring belong to one or more of the following
groups

\- people who haven't explored the concept enough, which may be a symptom of a
larger issue possibly and most likely the one below

\- people who are just in for the money and are trying to convince themselves
otherwise

\- people who don't know how to use atomic concepts to make more interesting
concepts because they lack creativity and imagination (whatever these terms in
comp sci domain)

~~~
rak00n
I'm learning an instrument over last few years. To be honest it's super boring
to practice the same notes over and over again. Then again all the skills I
learned I learned through boring repetitions.

So if someone tells me programming is boring I'll just nod. It takes too many
repetitions to finally start to appreciate something.

------
EdSharkey
I would like to propose that we all investigate how we can be more scientific
about our programming.

I imagine we can create artificial scenarios wherein we subject our code to
rigged experiments. These experiments can serve to isolate parts of our
codebases, pushing known values as inputs to the part and then inspecting the
output for what we expect are correct values. We can posit theories about how
our code should work, and then test those theories with experiments.

I envision a few benefits to these experiments:

1) isolating our modules to make experimenting easy may help to reduce the
complexity of our programs.

2) overall 'correctness', whatever we define that to be, can continue to be
verified over time as our programs change and grow as long as we update the
expected values in our experiments at the same time or create additional
experiments as needed.

3) the experiments themselves will serve as a kind of documentation of the
codebase because they will show the code in action in fine detail.

What does everyone think of my idea? I know it sounds like an odd proposition,
but science seems to work good in other disciplines. Maybe we can try it in
ours?

~~~
plandis
You heard it here folks! HN just invented formal methods of verification and
fizz testing! ;)

(But seriously, I do both of these to test/verify the distributed systems on
which I work -- both are great ideas)

------
cygned
Programming might be boring. Engineering is not.

------
huangc10
Truth but unlike other professions, throughout the rise of the internet,
github, what-have-you, we, programmers have been able to counter the
boringness and move to other opportunities in the industry.

For example, someone who wrote test hardware code in embedded C, can move
towards full software iOS development which is at two ends of the tech
industry. The opportunity produces excitement and the further attainment of
knowledge.

On the other side of the spectrum, a pilot who flies a Boeing 777 will not be
able to easily switch to flying an Airbus 330.

Simply said, programming is boring, if you make it so.

~~~
adambard
> On the other side of the spectrum, a pilot who flies a Boeing 777 will not
> be able to easily switch to flying an Airbus 330.

This sounds super dubious, I feel like you fell down on this analogy. I mean,
they probably have some different controls and systems, but you can probably
just run co-pilot for a few flights to get acquainted and then be good to go
(leaving out the fact that most commercial planes essentially fly themselves
for most of the trip these days anyhow)

~~~
huangc10
Ah yes. To be honest, both examples I used are real life examples. My brother
happens to be a 777 pilot. He tells me it's not really feasible for him to
transfer to an Airbus. He can see himself flying another Boeing, but both
would take years+ of training.

------
wvenable
The part I like the most is refactoring -- once the problem is solved, the
requirements are all completely defined -- going back and making it as clean
and organized as possible.

------
20years
All of the stuff that comes before, after and in-between the programming part
is what's exciting imo. The idea phase is exciting. The planning phase is
exciting. The thrill of seeing users use what you have programmed is exciting.
Being able to iterate upon user feedback is exciting. Watching something that
you programmed grow into a useful and productive app is exiting.

I would be bored to death if my days only involved programming.

------
spynxic
"You don’t create “possible problems” of the future, you don’t pigeonhole the
solution in to some tool you fancy learning and working with; that’s called
over-engineering -- ..and keep it simple. That’s what being professional
means."

The author goes as far as making an analogy between doctor:chest-pain as
programmer:program-features to argue the dangers of acting unprofessional but
I'd argue that always acting professional can lead to insufficient solutions
in the long run.

Creating "possible problems of the future" is often what keeps me on track in
the present. Often times I will finish developing a feature prior to fully
writing its foundation so as to see how the feature might influence the
foundation. It seems a bit ironic but I'd claim over-engineering is what keeps
a code-base flexible to change.

But perhaps the type of development I enjoy is unprofessional. It would make
sense in explaining why I haven't made a dime on my code.

------
hoodoof
This article is wrong. It assumes that priorities are the same for all
programming.

When programming you should be programming to a set of priorities i.e.:

software performance/speed

maintainability

security

reliability

conformance to organisational statndards

conformance to testing requirements

time to market

compatibility

research/problem solving

prototyping

probably more...

The priorities of your project dictate your approach.

This guy says one size fits all.

------
autotune
Great! Since programming is so boring all that's left is to start
understanding system administration concepts as well and making things easier
for your ops team. Right? Right????????

------
jlarocco
It has a flamebait title, jumps straight into false dichotomies and straw man
arguments, and is talking about something that's obviously personal opinion.
Looks like a troll, IMO.

------
AnimalMuppet
When I got married, as part of our pre-marital counseling, we had to take a
personality test. One question I got rated as a "2" (on a scale of 1-5), but I
couldn't figure out what the question meant.

Turns out that in our world, it's product lifecycle. 1 is initial conception,
2 is prototype, 3 is rollout, 4 is major enhancement, and 5 is maintenance. My
_personality_ is that I find maintenance boring.

But that isn't necessarily true of all programmers...

------
agumonkey
You can always give yourself challenges. See that famous kragen bootstrapping
marathon:
[https://www.reddit.com/r/programming/comments/9x15g/programm...](https://www.reddit.com/r/programming/comments/9x15g/programming_thought_experiment_stuck_in_a_room/c0ewj2c/)

------
ozim
Nope, in the way I encounter people it is: "Programming boils down to:
understanding the problem, solving the problem, and making sure you are
getting paid." which is quite far from "making sure your solution is easy to
maintain and nurture in the future." because the future usually is not there.

------
danbruc
If programming is boring, then you haven't abstracted enough things away or
haven't automated enough things. Things become boring if you are doing the
same thing over and over and if you are repeating yourself, then you are doing
it wrong. Most of the time.

------
pklausler
I have been programming digital computers for four decades and I still find
them magical. A machine does things at your command while being composed of
simple understandable parts -- programming is magic that works! How can that
possibly be boring?

------
skiplist1
Since I was a child I thought that programming could be the amazing tool to
create something that should be a breakthrough and would make me rich. I am
still struggling to find that magical key, so I am not bored at all!

------
stuaxo
Writing something that is neat and and understandable is not boring.

It can be challenging and frustrating to get to that point, but it is pleasing
once it is done.

Of course, that moment doesn't last for long at all before ascending the next
hill.

------
twelve40
omg I work with a dude now who is brilliant, prolific and super-efficient - he
successfully rolls out twice the number of features the next best person does,
but he leaves behind 0 comments ("code documents itself"), 0 unit tests ("unit
tests are for rookies who are unsure about their code") and 0 documentation.
How? How to get across the point that he's forcing all of us into the dead end
when it comes to team scaling?

------
wyager
The boring stuff should be automated away, leaving only the fun parts.

I try to make the compiler do the boring stuff.

------
bananabill
Entertainment is subjective you fucking dweeb. Just say "I don't like
programming, it's not for me" if you feel that way.

~~~
spelunker
If you read TFA the author wasn't talking about programming being
entertaining, he was talking about how the process should be consistent &
unsurprising. A silly comparison, but not about what he finds exciting.

------
sickbeard
Programming is boring when you're solving mundane problems, when everything
you need is already written in a nice library or package for you to put
together like a 24 piece jigsaw puzzle.

Get yourself an arduino, maybe esp8266, now program it to do something
exciting.

Another suggestion, an occasional after work punjabi sword fight might do the
trick

~~~
eagsalazar2
Jigsaw puzzles are not boring, nor is mundane programming IMO. Challenging
stuff is super fun of course but there is something satisfying and meditative
about just doing a really meticulous job even if you are doing routine stuff.
Just me?

~~~
6DM
Sorta not really, I get where you're going with it, but for me it's finishing
the feature and getting it to work properly. This can involve wiring up some
stuff for CRUD operations. But hey it works well and someone appreciates it,
therefore I enjoy doing it.

Meticulous to me is when I have to pour over some very badly written code,
carefully stepping over all the frayed knots and ducking under wires, trying
to make that one fix without introducing another bug. Hoping to leave behind
my little corner of the room in a slightly better state than I found it. It's
a thankless job and always takes longer than expected. :(

------
british_india
Programming is fascinating and endlessly fun.

~~~
prefect42
And addicting ;-)

------
gorbachev
Most of the comments are completely missing the point of the article. I
thought it was pretty self explanatory. He's talking about the part where you
write code.

I don't get pleasure from writing code. It is actually kinda boring...you've
(mostly) already figured out what you're going to do and you're just typing.
Most of the time you're fighting against the limitations of whatever
programming environment/language/framework you may be using. It's more boring
the more familiar I'm with the problem I'm working on.

I get excited when I finish and I see the actual impact of people actually
using something I created. Or when I'm in the problem solving mode and I'm
learning something new.

That's why I enjoy being a software engineer, not because I spend all day
typing on a keyboard.

