Ask HN:Ok to be in programming if you hate the process but love the result?
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?
39 comments
[ 4.0 ms ] story [ 110 ms ] threadPlenty of exposure to the tech and instrumental to the end result without what you dislike about the practician.
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.
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?
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
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).
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.
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.
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.
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.
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.
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. Manager...
I take the "extreme" (but IMO correct) view that all proprietary dev work is immoral. This seems clear to me because whatever you build will some day need to be rebuilt in a libre way.
That might not be true if you work at some exceptions, like Mozilla or Open Whisper Systems or FSF, but for 99% of jobs, you're doing a bad thing that's making the world a worse place.
With that understanding, I recognize that I'm pretty much a slave until I can achieve financial independence. If that ever happens, then I can work on things that matter.
So I don't choose my work domain based on what I like or dislike, I choose it based on pay and living conditions. Right now I'm remote and have pretty good pay, so this is ok for now, but I know everything I'm doing is contributing to a great evil. I hope it won't be that way forever.
Selling ads is about equivalent to me as working on surveillance systems or malware. I don't want to do any of those things, but I'll do whatever is legal and pays the best, so that I can someday get back to the business of making computing better for humanity.
You might appreciate this: https://medium.com/thrive-global/ikigai-the-japanese-secret-...
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.
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.
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.
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.
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.
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...
Good advice from other posters here, I found myself repeating it so I'll keep it short.
Enjoy work if possible. Find happiness.
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.
What do you mean by this?
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.
"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.
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.
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.
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.
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.
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.