Consider the following - maybe your managers realize how vague task is, they also realize that you put a lot of pressure on yourself to make it, as I understand without strong support. I have been many times in same situation, usually when this happened first: I read "The humble programmer" :-),which reminds me that there is always something that I don't know, second: look again on the task and try to find its challenges, things that after completing them will make me a better programmer.
Ask HN: What do you do when your entire being opposes the task at hand?
31–40 of 210 posts
Re: Ask HN: What do you do when your entire being opposes the task at hand?
#32I wish I was done with the series of blog posts that helped me get over this! :)
I struggled with this for years and years. This is not one problem , but three: it is a problem with wisdom, speed, and discipline.
Luckily, we can learn tricks to improve each one.
If we want to attack this from the wisdom perspective, it is this: You are afraid of making the wrong decision because you are afraid to refactor. You are afraid to refactor because you don't have sufficient test coverage.
The good news is, for developers like us, test driven development is very helpful as a technique for getting us over these problems. If our team is not test-friendly, however, it will be difficult for us to make the jump because their code will not be written in ways to make it easy to test.
There are a few books I can suggest to help us jump the chasm:
1. Clean Code by Bob Martin. This book helped me think in more testable code, and also helped me understand how to make better decisions the first time around. It helped me by seeing patterns I didn't know first.
2. Refactoring by Martin Fowler. This one is old, but knowing the patterns of changing code gives us more confidence in knowing what is right, rather than hemming and hawing over what is readable and maintainable.
3. Refactoring From Legacy Code by Michael Feathers can help get from here to there. All of these help from three aspects: They help us develop a set of tests so we are less afraid of breaking existing things, they give us the freedom to experiment, and they help us break things down into smaller, more manageable problems by letting us think about "what is the next thing I can test?"
If we have the tests, we can be more aggressive in reducing complexity.
___
If we want to attack this from a Speed issue, then look for these things.
1. Look for patterns you use repeatedly, and try to settle down into a process. The fewer choices we make, the faster we can go.
2. Look to learn more about your chosen stack and language. It is possible that we are rewriting the wheel over and over. The more you understand the zen of your stack, the faster you can go and the more time you can devote to writing the same thing twice (without them knowing.)
3. Instead of hemming and hawing about the right solution, write all three. It is often faster to write all three and choose one than to get stuck in analysis paralysis. (That isn't to say you shouldn't think before you write code!)
___
Finally, you can attack this from a discipline angle.
1. Learn to meditate. By doing so, you can become more self-aware of analysis paralysis, calm your mind quickly, and mindfully choose a path.
2. Exercise. In the same way as meditation, exercise helps us learn to clear our mind and focus on command, and it helps sharpen our discipline chops.
With these, we can develop an awareness of how our body feels. Then we can develop an awareness of how analysis paralysis feels. If we can catch ourselves in the act, we can then institute something from our analytical skills: When caught in the trap, set 30 minutes on your timer, and bring out a pad of paper. If you feel you have the freedom, turn off the monitor.
Take deep breaths, and sketch out the solutions in the first ten minutes on the first page. Use UML or your own system.
In the next ten minutes, write a pro/con analysis on each path.
In the final ten minutes, make the decision. After this, your analysis time is up and you must code.
I suggest a combination of the above.
Good luck! It was one of the hardest things for me to defeat.
Re: Ask HN: What do you do when your entire being opposes the task at hand?
#33First and foremost, remember that you're writing code to bring in customers. Your codebase can be beautiful, pragmatic, semantic, and have 100% test coverage; if you don't have any customers, you don't have anything.
"Unnecessary complexity to the codebase"
It depends on what you mean by unnecessary. If you mean "won't bring in anymore customers", have that conversation with your managers. Not all of them are brilliant, and no one gets it right 100% of the time. If you can prove that the feature doesn't provide value, have that conversation with them.
On the other hand, if your boss ignores your input, and you're 1000% sure that there are other features that are more valuable to your business than the one in question, you can always push that one to the back and work on something that's more productive to the company. Depending on your political and professional circumstances, your boss may not notice or care, and their boss may forget about their red herring feature; you might be able to side-step the conversation altogether. This will only work if there's more than a few items on your plate that need to get done soon, and this feature can get pushed aside without delaying or blocking anyone else.
Bear in mind that if you go this route, you're putting yourself, your career, and your neck on the line. If it turns out that it wasn't a good idea and everyone agree with you, you'll look like a genius and gain some clout as a clairvoyant; if it turns out it was seriously necessary, you'll look like someone who pouts when they don't get their way. Either way your boss may also hold a grudge. I'm not saying it's the greatest way to go, just adding it as an option. It's helped me more than a few times in my career, but it's also frustrated my bosses a few times. Be gracious if you're shown wrong though, and quick to admit defeat if it's obvious you chose the wrong path, and you should be fine no matter what happens.
Re: Ask HN: What do you do when your entire being opposes the task at hand?
#34Not a therapist, but have a look (or better, have a professional have a look) at ADHD-PI. What you've said describes perfectly how I feel at work a lot of the time, and it's what I was diagnosed with. I seem to have a finite pool for motivating (or more accurately forcing) myself to do work. And when that pool is empty, it's off to HN or Reddit I go. Frustrating, and I still don't have a solution yet. Hope this helps…
Have you tried modafinil? I've heard it works for some people, but lack first hand experience. I'd be curious though.
Re: Ask HN: What do you do when your entire being opposes the task at hand?
#35you quit.
Re: Ask HN: What do you do when your entire being opposes the task at hand?
#36Been there before, luckily just few times.
- Put yourself in a good mood, music helps a lot, energizing beats, try Panjabi MC!
- Slice the feature into small deliverable, hint: use index cards and a sharpie, yes, it's magic.
- Finish one story (index card) at a time and have a tiny celebration (coffee, cookie, walk ...) every time you do that. DON'T skip the fun part.
Always think of yourself as an explorer collecting and connecting clues on a mysterious adventure!
Keep in mind, business drives programming, not the opposite. The codebase is only worthy as long as the product is selling (with the help of your managers).
Re: Ask HN: What do you do when your entire being opposes the task at hand?
#37You might be burning out, and not even realize it. I've been in a similar situation. The unmotivated mindset leads to additional hours compounding the effects.
My suggestion go on a vacation, if it doesn't get better... leave. You say you're not in a position to leave... but you have to, because its not going to get any better. You're not really doing anyone a favor by burning yourself out for them.
Re: Ask HN: What do you do when your entire being opposes the task at hand?
#38Open HN.
No, seriously. I go work somewhere where people can see my monitor. Helps me keep out of Facebook, etc.
Re: Ask HN: What do you do when your entire being opposes the task at hand?
#39Hi,
I'm a manager, and sometimes I feel like you. Sometimes I need to ask developers to do things I don't believe in or things I'll throw away in a few months. This also demotivates me. You need both a lot of discipline and just a bit "aloofness" to keep going. Care less about those tasks, think about friday.
If your managers are any good, they know you have wasted hours, they know you are unmotivated, and they know those meaningless tasks are the reason, this is why you are a valued employee. I'd rather argue to death with an employee because he thinks his idea is best for the company than one that will just accept any task like a robot. But sometimes you have to implement ridiculous things into software, from clients being just crazy or because of some strange contract clause. This is when discipline kicks in. Such situations shouldn't happen often, but if they are, that's when you should move on.
You don't need to get "in the zone" to get the job done. Just start by doing smaller pieces, put your headphones on. You could just ask why feature is being built, but I doubt knowing the reason will motivate you at all.
Re: Ask HN: What do you do when your entire being opposes the task at hand?
#40You can't care about the problem more than the customer, or you'll go crazy.
That is not to say you shouldn't be proud of the workmanship of what you build (not quite the same thing as being proud of the product).
Unless you have a position where you have design authority, stop worrying about the why, and focus on the workmanship. Impress those that do have this authority with how well you do with what you're given.
If you believe that you have insights into making a better end product, then learn to communicate those insights at the appropriate time (before they've made up their mind). Try to get ahead of the curve and propose your ideas.