
Ask HN:Ok to be in programming if you hate the process but love the result? - kpennell
I&#x27;ve been really debating this a lot. The process vs. the result. I think I&#x27;m finally more admitting to myself that I actually dislike the majority of the process of making a web site&#x2F;application. For me, I just want to have the working app or prototype or functionality on the other side. I want to solve a specific problem. That&#x27;s why I develop&#x2F;code.
The process is mostly just endless tedious task after endless tedious task.<p>Is it ok to stay in web development if you generally loathe the process and are only in it for the end result?<p>Does anyone else here face this dilemma?
======
proverbialbunny
When I fall into the mindset of just the end goal, my 9 to 5 becomes hell.

There is a lot of busy work googling and finding code on Stackoverflow to
solve some tedious problem. It's not exactly fun, and if I get stuck googling
for a day or two on a single problem it's incredibly stressful.

Alternatively, I put on my research hat and see the source code and the tech
stack as a series of questions and unknowns I have yet to figure out. Every
piece of tech has a story of what the world was like before it, and that tech
is the solution that was created to fill that need.

When I put on my research hat I slow down, and focus on learning everything
around me inside and out, bit by bit. If I google vocabulary I'm unfamiliar
with and end up on a Wikipedia page, this might lead to a handful of new
questions. I recursively learn everything around me.

There is a middle ground between research and getting the product out the
door. When this middle ground is found, not only is development accelerated,
but work becomes smooth sailing. You become an expert in the tech around you,
and if you learn it properly you only have to learn it once. After a few
months of doing this you stop having to Google so much. You start being able
to help others around you. The pressure of the goal stops becoming the
obstacle and the challenge of writing code that minimizes future bugs and
increases readability fades into the forefront.

Unless it's crunch time, being tightly focused on the end goal is one of the
least productive and most painful ways to write software. There are better
ways to go about being a software engineer that are at least worth
considering.

~~~
anon9001
I think you've got some great advice here, and "recursively learning" is a
good way to explain it.

In open source, especially, this is such a good strategy to follow. It's why
Linux is fun :)

I don't know how you apply your philosophy to employment though. At work, I
pretty much do the opposite of what you're suggesting to avoid my 9 to 5
becoming hell. I focus only on the end goal, where that goal is employer
satisfaction.

Here are some pragmatic tips for how to achieve satisfaction for all parties
in employment:

* Maximally pad estimates. Don't know how long something will take? Tell your team that you need some time to figure out how long a project will take. Use this time to get to an 80% solution, or at least have a very solid plan. Now that you understand the problem but your employer doesn't, you're in a much stronger position to provide good support for your heavily padded estimate. If a manager pushes back, you have lots of info already and can speak with confidence. Compromise as appropriate and be friendly about it, but remember that every hour you can pad is another hour you've reclaimed. This is by far the most important thing. The ratio I look for is 40 hours of estimated work to 8 hours of heads-down problem-solving.

* If you can't figure out the solution to a problem in a couple of hours, break the problem into parts. Only give estimates on the parts you've already solved. Managers are happy to see multiple tickets for what you might think of as one task, because it gives them the appearance of their team achieving more.

* In agile, you should try to stay at least one sprint ahead. Your team will appreciate you being proactive if you're always looking at what's coming up next sprint.

* Save your teammates from themselves. Look at their estimates before sprint meetings, try to come up with a few things they maybe didn't think of, and ask "are you sure that's enough time? what about x, y, and z?". You want to both pad your estimates and help your coworkers and managers pad their estimates as well. I believe the #1 reason for underestimating is not putting in enough time to come up with good reasons why something may take a long time.

* Keep good notes. Always be ready to give an update on what you did on any particular day. I write bullet point notes every day in a personal wiki, and I use them as talking points in standup the following day. Share some of these notes (re-phrased as a friendly update) a few times a week with management via text. If you think someone's nervous, take a little extra time to give them an update so they feel in control.

* Make sure you have one "no meetings" day where you can go heads-down with a stimulant of your choice. Complete all of your obligations for the sprint on that day, but keep them stored on your local machine so you can roll them out as you like. Try to make sure that's your only real work day. The rest of the time should feel more like a social club if you're doing it correctly.

* For remote workers, always be on Slack. Use a script that prevents you from going idle, and set up your phone to get your messages. That shows that you're always online and available if someone needs you. Usually people won't bother you outside of core hours anyway. Respond quickly when contacted, even if it's just an acknowledgment that says you saw it and you'll get back to them.

* For office workers, spend as much time in the office as you can. Try to make it pleasant for yourself. Come in early and have breakfast while people show up. Eat lunch with the team, but take a little extra time for a personal phone call to catch up with a friend or handle some personal business. Late afternoon, a few days a week, try to get to the gym. Your goal is to be first in and last out, but without actually making any personal sacrifices to do it.

* Sometimes hold your commits until after work hours. Managers who pull these metrics from github are evaluating the completely wrong thing, but it doesn't hurt to give them what they want to see. You can use a shell script to sleep then commit/push/pr.

* Be friendly and helpful. A little extra attention goes a long way. Make notes about significant events in people's lives and reference them later to show you care, just like a CRM.

* If you see someone stressed and struggling, offer to jump into their problem with them and try to help them solve it. If you can help, great. If you can't, at least you tried, and maybe you added some value.

* If someone asks you for something or to do something, write it down and set a reminder. Never let a request go unanswered. Failure is often ok, but disregard is never ok.

If you follow my approach, you should be able to acquire goodwill with your
team and a track record of dependability. You'll complete all of your work
with minimal stress, make friends along the way, and present very well to
management.

I still hate work, and I would rather do pretty much anything else with my
time, but this is the most palatable strategy that I've come up with.

When I tried your approach, which again, I think is the correct way to
actually learn and build anything, work was a daily struggle. Now that I do
about 20% of the "work" (as I used to think of it) and spend 80% of my time
managing relationships, I find myself in a much better situation.

~~~
throw51319
Wow both your response and the original response are great! Basically you guys
wrote out exactly what I've been feeling as I get to my 9th month at my second
job. Any tips about working in an area you don't care about? I care about
getting better at tech in a utilitarian sense (I'm not a nerd that fawns over
deep irrevelant stuff) and professional skills. I don't like the domain I'm in
now.

~~~
proverbialbunny
>I don't like the domain I'm in now.

You might appreciate this: [https://medium.com/thrive-global/ikigai-the-
japanese-secret-...](https://medium.com/thrive-global/ikigai-the-japanese-
secret-to-a-long-and-happy-life-might-just-help-you-live-a-more-
fulfilling-9871d01992b7)

Not everyone can meet all of that criteria, and that's okay. But if you slowly
work towards ikigai, your life will become happier for it.

~~~
anon9001
This doesn't work for me.

1\. What do I love? Software!

2\. What am I good at? Software!

3\. What can I be paid for now — or something that could transform into my
future hustle? Software!

4\. What does the world need? Software!

I absolutely hate being a commercial software developer.

~~~
proverbialbunny
Is it that you love using software and hate developing software, or is it that
you have a love-hate relationship with developing software?

For me, most of what I hate about being a dev is the culture and who I'm
working with. Though I hate getting stuck on a problem I can't figure out too.

By being able to identify what I like and what I dislike about a thing, diving
into the gritty details, I am better able to steer myself towards a better
future.

~~~
anon9001
I love free software, and I hate non-free software.

Writing free software doesn't pay very well, on account of it being free.

Maybe I should work for FSF or Mozilla, but I'd really like to make enough in
industry to be comfortable far into the future before I forfeit the chance to
retire.

~~~
proverbialbunny
What about free software do you like in the work place? What about non-free
software do you not like in the work place?

Keep increasing your awareness by responding to your answers by asking
questions, breaking it down further and further.

For example, I patched Squid and Apache on the job, and those are "free"
software. Out of everything I've done on the software engineer side, I hated
that one the most, because the code bases were difficult to navigate for me at
the time.

------
ta0987
I think that wanting the end result is the _best_ reason to do something. If
you foresee the value of the uses you put programming to, to be greater than
the pain of programming, then keep at it.

E.g. music. Nobody* likes practicing. They like making music. The people who
like (or find meaning in) making music enough will stick with it and grind out
the hours so they can get the prize: the music itself.

(*) I mean sure, someone somewhere probably does

~~~
muzani
The most extreme example I can think of is probably sports. Something like
Olympic running or swimming is probably about 99% pain.

You don't always have to love the work you do. But I suppose a lot of people
find pride in being one of the few to push past the pain barrier.

A lot of high end coding is like that too. You still have to slog through
actual books.

------
SiVal
_Is it ok to stay in web development if you generally loathe the process and
are only in it for the end result?_

"Ok to stay"? It depends on what you're really asking, but I'm going to assume
you mean, "If you were a close friend and cared about me and my future, what
would you advise?"

If that's the question, my answer would depend on your other options. Most of
a developer's time is spent developing, not admiring the result, so I would
recommend doing something you like more overall (like both the process and the
result), provided such an option is available. But then, if it were, I can't
imagine you'd be asking. You'd do the obvious thing.

So maybe you're question really means, "I hate it but don't seem to have any
better options. Will it get better?" In that case, I suspect it won't get
better. If you actually do like the product but hate building it yourself, you
might be a good candidate for marketing or sales. I've always loved
programming, but I've worked with plenty of people who only did it because it
was a "good job", and I've seen some of them switch to marketing or sales
where they were much happier.

~~~
throw51319
What kind of marketing or sales jobs? Did they use their gained experience in
software dev and understanding software systems from a holistic level, down to
the details?

~~~
SiVal
Yes, I'm referring to a few people I've known who switched to marketing and
sales jobs at software companies. Technical credentials (such as work
experience, not just school) always make candidates more attractive to
sales/marketing teams at companies with technical products/services.

------
WheelsAtLarge
>> The process is mostly just endless tedious task after endless tedious task.

This is why work is work and it appears on all jobs so you might want to
figure out how to change your mindset so you can deal with the never-ending
tedium that comes with every job before you move on.

Having said that I will say that this type of situation happens in many
fields. There are doctors that hate being doctors but love medicine, lawyers
that hate being lawyers but love the law and on and on. What they end up doing
is that they explore tangent fields that they like better. Some look at
journalism and specialize in their field others go into management and still,
others go into sales.

I think you should start exploring other fields. You might want to try project
management, web design or maybe product manager. If you really have the
discipline you might even start your own business.

The way I see it; life is too short to be stuck doing something you don't
like.

~~~
o-__-o
> you might want to figure out how to change your mindset

What do you mean by this?

~~~
WheelsAtLarge
It is possible to set your way of thinking in a way that helps with your
work's satisfaction.

You can have a negative mindset or a positive one. It's possible to look at
all the work that needs to get done as the building blocks towards the
production to a great end product rather than endless tedious work. Each step
is very important to get the product done so the better you master the steps
the better the end product is. Or you can look at work as what you need to do
to feed the family you love. Or whatever you decide.

Life is all about how you think about things. You can look at them from a
positive view or you can look at the negative view. Looking at it positively
is immensely helpful towards life's satisfaction.

------
ilaksh
Well there are a few different aspects. Tedium is one. Frustration is another.
Motivation is another.

Tedium means it's boring or dull. It is normal to have a fair amount of boring
or dull tasks in programming. Ideally though, you can generally find at least
some problem interesting and not totally dull because you are engaged in
solving it.

I have found that it's much easier to be motivated about side projects. It's
also easier to be motivated when there is something slightly challenging about
your tasks.

Loathe is a strong word. I would say though that many programmers do hate
their job sometimes. But if it's really a constant then that is basically
torture.

I would try to find a side project you are interested in as a test. If you
really hate the process entirely of a challenge that you created for yourself,
the entire time, then that makes it sound like you are just abusing yourself.

Don't be quick to decide it's not for you though. Programming is definitely a
job that requires patience and perseverance and sometimes boring tasks. Try to
mix things up a bit by coming up with creative solutions. Maybe create a
module or tool to help you accomplish a task that seems boring.

It's not necessarily the funnest career. For example, playing video games on
YouTube is a job for some people now. Or filming Nerf gun battles. But solving
problems is more rewarding than that stuff probably.

------
uberman
Perhaps you are better suited to a business analyst or technical project
management role.

Plenty of exposure to the tech and instrumental to the end result without what
you dislike about the practician.

~~~
robodale
I agree with this. Less being in the code all day, and more handling what you
want the result to be.

Learn what a software architect, possibly a solutions architect does. You may
need a few more years experience in software development, but those types of
roles deal with more of the expected result, without having to deal with the
day-to-day programming details.

~~~
abcdefabcdef456
Or an Architect role, if you can see the "bigger picture" aspect of the
problems you are solving -- which is far less common than one might think.

------
7402
I have felt that every job has its irritations, but one should choose the kind
of irritations with which one is most compatible.

When there's a miserable frustrating bug that comes and goes, it's not
something I'm happy about (I, too, would prefer to get quickly to a working
result), but it's something I'm used to dealing with and I'm willing and able
to tackle. It doesn't keep me up at night. It doesn't make my stomach hurt.

On the other hand, a friend of mine is an excellent manager. Dealing with the
kind of work inter-personal conflict that _would_ cause me pain and sleepless
nights is just a part of _his_ job. He knows how to deal with it. He doesn't
want it to happen, but fixing it is what he's good at.

And I've heard that even the best sales people are constantly dealing with
rejection and failure to close a sale. It's just part of the job - if they've
got a good enough batting average then they just don't beat themselves up
about the one that got away.

------
ctn40
I face the opposite dilemma, I enjoy coding, but I’m never fully happy with
the result.

I think there is an element of extrinsic motivation vs intrinsic motivation
here.

Extrinsic motivation is where there is something external that is driving you
to develop software (money, prestige or perhaps a finished product in this
example)

Intrinsic motivation is where you motivated to develop software (or whatever)
because you want to develop software (no external reasons)

Obviously there is always an element of both present, and there is nothing
wrong with either type of motivation.

The thing to consider is that with extrinsic motivation, it changes. You might
have to constantly remind yourself about the reasons, or the motivation may
disappear entirely at stages.

With intrinsic motivation, your motivation doesn’t change much over time, and
people who are motivated intrinsically to do their kind of work usually do
well in their field with far less effort than others.

But even for those that are intrinsically motivated to code, there are always
parts of it that are just pure toil.

------
cr0sh
Ultimately only you can make this decision for yourself; if it were me
personally, I wouldn't want to have a job or career (or hobby for that matter)
that I hated, no matter how much I liked the output.

Which is perhaps why some people start software development companies...?

I have heard of people who absolutely hated programming, but were extremely
good at it and made great money, so they continued to do it. But they hated
every minute and couldn't wait to get back home.

That doesn't sound like a fun existence to me, but I know honestly I am lucky
to have a career as an SWE as something I love to do. Most people don't have
that luxury. Most people are lucky if they have a job they can tolerate, let
alone love. Many more have jobs they dislike, but they can do them well, and
go home later to unwind.

So "is it ok"? Again - only you can answer that, but I would say for some
people - maybe many - outside of SWE - would say that yes, it is ok to stay in
a job you loathe.

------
oldboyFX
For how long have you been doing web development?

For a novice it's common to feel a bit frustrated and lost. You however are
simply bored by it, so I don't think that matters in this case.

Is there anything else (realistic) you'd prefer to be doing? Can you imagine
yourself in some other position? Does it invoke happiness?

~~~
bdcravens
In addition to the the frustration, I think there's a lot of idealism around
programming, whether that comes from the media, forums, Twitter, the
blogosphere, etc. You dream of best practices and beautiful code and trendy
frameworks but find the reality is writing error handling code for malformed
CSVs you import from a website that looks like it was last updated in 2002. As
in all things, you learn as you get more mature that the world is no where
near as beautiful as you were told, and often the messengers are nothing more
than that, and haven't written production code in years.

------
DoreenMichele
_Is it ok to stay in web development if you generally loathe the process and
are only in it for the end result?_

That's totally up to you to decide. If you think the results (and presumably
compensation) are worth it and you are willing to grit your teeth and bear it,
then you can do that.

It's also fine to feel it's worth it this year, then change your mind at some
later date. Maybe you decide there's more to life or maybe you start grinding
your teeth in your sleep because the process is so miserable and you decide
you've finally had enough.

Things that are worthwhile usually involve some level of discomfort to make
them happen. It's up to you to decide which things are worth which personal
costs.

------
muzani
You don't have to enjoy the work itself. I think there's a lot of pain in
development. I can work on my feet in a hot kitchen for 14 hours straight, and
that is less painful than say, an hour of data entry or 2 hours of
programming.

But the way I see it, the pain is a necessary part of getting there. The only
way you can stand out is to go through more of it.

Is it really a bad thing? Like exercise, it hurts, but it's really just up to
us to not take it personally.

The pain isn't there to discourage us. It's there as a warning. It's up to us
to learn how much of it we can safely ignore and push through, and when we
should be taking a rest.

------
gitgud
That's actually a positive quality in business. The end product is what makes
money, so getting there should be the goal, not to enjoy the journey of
programming...

Some programmers (like my self) enjoy the act of programming and lose sight of
the end goal.

Ideally when making an app or website you want to code as little as possible,
whilest leaving it open for extension.

Your distain for the software development process would actually motivate you
to iterate on products faster and choose better ways to develop faster...

------
DannyB2
You may not like the process. But if you do something really amazing, it will
take time and effort. Just like music. Or doing anything worthwhile, actually.

If you get any good at it, the process may actually grow on you. In order to
build something complex, you need strategies to manage the complexity.
Discipline to use naming conventions, etc. All the things that programmers
universally do -- because it actually makes life easier.

------
JohnFen
I think it's OK.

Everything has things about it that suck, after all. The question is do you
love it as a whole, not do you love every aspect of it.

I honestly think that Sturgeon's law (80% of everything is crap) is more true
than false. It's just a variation of the 80/20 rule in computer science.

------
tmpmov
Yes, my dilemma goes away and comes back. The tedium can be good, neutral, or
"sub-optimal." I value the dilemma, not necessarily the tedium.

Good advice from other posters here, I found myself repeating it so I'll keep
it short.

Enjoy work if possible. Find happiness.

------
elindbe2
Sort of a judgement call but from my perspective the process part (which is
actually the part I tend to enjoy) of things takes up way more of your life
than the result part.

------
burntoutfire
Is it ok to do something you hate 95% of the time and love for the remaining
5%? Only if it's your best available option...

------
throwaway6734
Have you tried designing/project management? Imo more abstract portions of a
project?

------
adamnemecek
Most people have some qualms with programming, yes. Most people love the
result.

------
mmwanga
Is it OK to be cook if you love to eat but don’t like working in the kitchen?

------
theandrewbailey
That's what side projects are for.

