Ask HN:Ok to be in programming if you hate the process but love the result?

[kpennell]

I've been really debating this a lot. The process vs. the result. I think I'm finally more admitting to myself that I actually dislike the majority of the process of making a web site/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's why I develop/code. The process is mostly just endless tedious task after endless tedious task.

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

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.

[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.

[cr0sh]

> E.g. music. Nobody* likes practicing. They like making music.

The really hardcore musicians in my mind are those who take up electric guitar. The practicing can literally destroy your hands and fingers, but the results and output can be worth it (I'm only a listener - but I appreciate their sacrifice and effort, and love to watch players perform their craft).

[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?

[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?

[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.

[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.