Pain is like a compiler warning. 99% of the time it's telling you that something is wrong, and so you should only ignore it if you're 100% positive that you know what you're doing and the warning is a false positive.
The Jane and Joan example is a case in point. Rather than "merging often" to take small pain now rather than big pain later, they should be taking a step back and looking at WHY there's pain. They could, for example, choose to stagger their work (work on stories involving unrelated files as much as possible) such that they're not stepping all over each other all the time. Are nicer messages REALLY that important RIGHT NOW? Couldn't Jane just work on the purchase system instead on this sprint and do messages later and save everyone a lot of pain?
Pain exists for a reason. Don't ignore it. And for the love of Pete, don't just blindly push through it!
In the Jane and Joan example, merging features and error messages into the same file is what the underlying problem is and doing it more often or staggering their work isn't the solution. Most languages have the concept of a resource file where you can say "Retrieve the error message for condition XYZ". If no such error has been defined, the code returns "Unknown error" otherwise you get the error message. As a result, to add or change error messages Jane only needs to go in and update the error messages resource file which has zero impact on Joan's code. They can both work simultaneously because they're no longer baking error messages into feature code.
Imagine the pain they will go through when they next need to internationalize the application into multiple languages. If the errors are in the feature code, they'll need to strip them out and convert it into what they should have been doing in the first place which would have avoided the initial pain altogether.
"Imagine the pain they will go through when they next need to internationalize the application into multiple languages."
Actually I did just that late last year. It took one day to write a parser to find string constants in source code and put them into a CSV file, then another day to write and test a mutator script to replace the text with i18n constructs and generate the resource file. Meanwhile, we sent out the csv file to multiple translators to translate into 8 different languages. Total development and implementation time: 3 days. Getting good translations made, on the other hand, took weeks and required multiple verifications and lots of pain.
I'll take a possible future 3 days work any day if it avoids daily pain from implementing annoying localization constructs that we may never actually need.
If it ain't broke, don't fix it. It sounds like for you merging of simultaneous changes to the same file by multiple developers due to one person coding features while the other writes error messages wasn't a pain you needed to address so it made sense to delay the work to a future date.
I think you've mixed up the stories... The merging issue was a fictional story. With us, we simply didn't bother writing for internationalization to begin with (following the principle of YAGNI). And it turns out that when the unlikely DID occur (we actually needed it after all), the pain was minimal after a little creative thinking.
Merging often is something I like, but not for the reasons laid out in the article. I like it because it lowers the chances of a freak ugly merge, and more importantly because smaller merges means smaller code reviews (my eyes-glaze-over point is about 200 lines or so). But I wouldn't use it simply as a way to make painful merges more frequent yet less intense. Recurring painful merges are generally a sign that something could be structured better. That's where strategy separates the good teams from the mediocre.
Yes, I get that Jane and Joan are fictional and that your story is real. Perhaps I didn't state things clearly so I'll try again:
If you'll allow me to propose a hypothetical: let's say you did have recurring painful merges because (borrowing from the fictional story) someone was continually adding new features while someone else was continually tweaking error messages such that there were many conflicts which needed resolving upon every code check-in. You likely would have put the error messages into resource files much sooner and avoided these recurring painful merges. But because you didn't have this hypothetical situation (it ain't broke, thus you didn't fix it) it made sense to push the pain of localization off to when it was actually needed.
> Rather than "merging often" to take small pain now rather than big pain later, they should be taking a step back and looking at WHY there's pain. They could, for example, choose to stagger their work (work on stories involving unrelated files as much as possible) such that they're not stepping all over each other all the time.
I guarantee you that the people who invented "merge more often" tried this approach first.
It's a bad example, but the principle still applies. All the things you're talking about doing are also painful, in the sense of what the article is getting at. Designing a system where you don't have to merge as often? Sucks. Figuring out your schedule weeks or months in advance instead of just doing it? Sucks.
These are painful things that you have to do, and have to get better at, and by doing them early and pushing through the pain, you avoid the real pain, the dangerous pain later on.
You don't need to plan weeks or months in advance. All you need to do is push that particular story onto the backlog and wait for a more opportune time.
There will always be files in a project that are more conflict prone than others, so it makes sense to be mindful of that when working on features in parallel. Perhaps it would even make sense to split the file to minimize further conflicts.
Pushing through pain that can't be avoided is fine. Pushing through pain that could be avoided with a little strategic planning is silly and wasteful.
What I'm seeing in this admonition is "when you feel pain, push through it now to avoid more pain later" instead of "when you feel pain, look for a strategy to reduce total pain over time".
And what I read was "quit procrastinating just because something makes you uncomfortable."
All the strategies you've described require you to face the problem head on and make an informed judgment about it, instead of just keeping on doing whatever you were doing. They're better strategies than the example that the article came up with, but they still require you to think about something that you've been avoiding.
First of all, the whole kind of "no pain no gain" philosophy is particularly American. In a lot of other countries they find this mindset bizarre. If you go to the gym and it hurts, you should STOP. Maybe it will take you twice as long to build up muscles as the guy who "leans into the pain", but you're also not going to tear your hamstring, or slip a disc, or whatever, and you'll still achieve your goals.
As for "psychological pain", again, don't "lean into it". Figure out where it's coming from, and fix whatever is causing the pain. In the example of merges, use continuous integration, or merge daily. Which is what the author says... but that's not leaning into the pain, that's intelligently avoiding it!
And if selling is a painful process for you, then don't "lean into the pain" and keep doing it painfully -- find someone to teach you how to do it better, so it stops being painful.
Could you avoid making baseless statements that an attitude is "particularly American"? I'm doubting you've done any sort of survey, even informal, to back this up. There's a mental shortcut a lot of people like to take, where if the USA does something one way, and another country does it a different way, it's because the USA is wrong, and the not-USA country is doing the same thing as the entire rest of the world. It's stupid, it's mildly insulting, and it doesn't contribute in any way to the conversation.
Your post would have lost nothing, in fact would have gained quite a bit, if you had simply left out the "Americans are weird" bit.
Ha! Well, I'm American myself, and my experience comes from signing up for gym memberships in other countries I've lived in -- it was really eye-opening to see how rare the whole "no pain no gain" philosophy is, when it's the mainstream attitude in the US -- and it fact it's very relevant, because the whole "no pain no gain" philosophy pervades a lot of American life -- working longer hours, etc.
And I'm not talking about Olympic athletes here, I'm talking about normal people who go to the gym. And obviously I haven't lived in every country, so it's just anecdotal.
I don't know where you're reading in the "mental shortcut" you're talking about to my comment... but I really don't think I was being insulting to anyone :)
As somebody who took up running in my mid-30s (and now often do 10k runs and 100-mile bike rides), I think changing my relationship to pain was one of the key things I needed to learn.
Sure, there is "you are damaging yourself" pain. But there is plenty of other pain that for me is a pretty normal component of exercise. The creaks and groans of getting started, the burn of pushing my cardio limits, the delicious agony of deep stretching, the glorious next-day soreness, the fire of muscle exhaustion when doing lots of reps. I used to see that as all "pain" and avoid it. Now it's just reasonable stuff my body does, part of the game I'm playing.
Regarding leaning into psychological pain, leaning into it is exactly what you have to do in order to fix things. If you lean away from it, then you will never get to continuous integration and continuous delivery. Organizations that don't lean into the pain keep slowing their release cycles, adding more process, and doing anything they can to avoid the pain. Which ends up being much more painful.
Was the wording of the headline that made you completely disagree? You can interpret stuff in anyway you wish, especially when you feel a need to argue against a point for the sake of arguing. From the context, overall OP's message is very clear. Basically, it's the same old "get out of your comfort zone" motivational preach, but OP sheds a different and interesting light and gives simple analogies that HN audience can easily relate to. I fail to see any reason to criticize it purely due to the word choice.
PS, this comment reminds me a pattern in HN where an article ends up in front-page; say, about the need for hard-work in a startup, and the comments which would go up in arms about how working "smart and not hard" was the key, that there is more to life than just work, blah blah blah, sometimes arguing with a straw man. Yet, when some 37 Signals article hits about working 4 days a week, etc etc, again some people arguing how the "great" work was only done by putting a lot of work, crossing the higher walls, etc. All in unnecessary amount of comments by making a mountain out of molehill. Without taking to extremes or pointing out some edge cases all this would be avoided.
I think the problem here is a misuse of the term "pain." I think what is really meant is "discomfort." Pain is an indicator something is wrong; whereas discomfort is simply being beyond your comfort zone.
Growth takes effort, and usually that effort needs to push you outside of your comfort zone, and I don't mean that metaphorically.
To me, "lean into the pain" means "be willing to be uncomfortable while growing."
Not all pain is the same. There's the "I'm pushing myself hard" pain and then there's "I'm in injury territory" pain. Clearly the author is talking about one and not the other.
At least back when I was on a track team, if I didn't run so hard every practice that everything hurt after, my times did not improve. If I even ran on my own during the summer instead of competing with teammates, my times were terrible when I got back to school. What's the point of being on the team if my times didn't improve?
Unfortunately, at startups, everyone does everything and there's a ton of muck work. At a big company maybe you can get away with saying, that's not my job so I won't do something tough, but at a startup you just aren't going to beat the big guys with that attitude. You have to do the muck work, and if you can excite yourself about it, even better. Maybe you'll even automate it or hack around it somehow, but you can't leave it undone just because it is painful.
I think you're mistaking the spirit for the letter. I'm not fond of making that distinction, but you seem to be pointing out edge cases. It was Nietzsche, a German, who told us that whatever doesn't kill you makes you stronger, and even there you have to watch out for mistaking the spirit for the letter (of the law, dunno if that reference was clear).
If you go to the gym and it hurts, you should STOP
Woah, hold on. Are you telling me that when my arms get sore from lifting or pressing, I should just stop? There's something to be said about incrementally getting better, but the pain is there for a reason: you're literally tearing your muscles so that they can be rebuilt stronger. How do you fix that?
That aside, the author suggests to lean into it, not to run haphazardly. Also, your last statement is willfully dense. If selling is a painful process for you, let me guarantee you that sitting in a class or reading articles about how to sell better is going to be equally painful. The psychological pain the author speaks about is reluctance due to previous bad experiences. And in that case, a lot of the time, it would help to continue trying until you get better. There is a lot to be learned from failure.
I once knew a guy who trained martial arts, a lot. He had a proverb he was fond of. He used to say "Pain is just the sensation of weakness leaving the body". And so he kept on training, even when it really hurt, because he knew it was just weakness leaving his body. And it worked; over a period of twenty years, nearly all the weakness left his body. When I last saw him, there wasn't enough weakness left in his knees or ankles for them to even bend. He walks with a stick, of course. Turns out that you probably ought to leave a bit of weakness in there.
I'm not familiar with this blog, but the post preceding this one is pure gold. I don't often read these "blog psychology" posts, but this guy is an excellent writer and addresses some important topics in personal growth.
Similar theme as the "Lean into the Pain" post above, but it hits harder, and is potentially more useful. The post's tl;dr? Never stop looking in the mirror and facing criticism with honesty. But take the time to read it if the topic is of interest.
Having some familiarity with both technology and physical training, there are causes of pain in both which have various causes and implications.
In exercise, there are various types of pain which may indicate little more than a solid effort, while others indicate acute tissue damage or injury which can lead to chronic or debilitating issues if left untreated. There's a huge difference between the strain of exertion in lifting, lactic buildup from a sprint, weightlifting burn, blisters or other chafing injuries, DOMS, the pain of tendinitis, a cramp, and plantar fascitis.
Some of these are momentary and transient, disappearing in a few minutes. Others are the result of tissue damage but will heal, if properly treated, in a few days. Others indicate either damaged or traumatized tissues which heal very slowly if at all, and can be debilitating if left untreated. None are of themselves an indication of progress or "goodness" of a workout: you measure progress in training by your success in acheiving goals, not through pain.
Sure, DOMS after a hard lifting session, or sore muscles after a long run or ride can feel "good" in a sense, but it's not a sign of progress of itself.
It's a similar situation in technology.
There are things I encounter in technology that are similar: practices which are tedious, or vaguely challenging, or require thought, vs. others which are automatic. But there are also patterns and trends which just feel obviously wrong, and which practice has shown are really bad ideas. The current trend is to call these "patterns" and "anti-patterns".
Again, the important things aren't the presence or absence of pain, or even its intensity. If you want to gauge your progress toward goals, then measure your progress toward goals, not how much pain you're experiencing en route.
"Yes it’s painful, but the trick is to make that mental shift. To realize that the pain isn’t something awful to be postponed and avoided, but a signal that you’re getting stronger — something to savor and enjoy. It’s what makes you better."
Once you realize what level you are experiencing you can get to know your body and learn to push it through the pain.
This summer I did a 150 bike ride that ended on a climb, it was intensely painful mentally and physically, but I was able to push my pain because I knew from previous rides that it was a false boundary. My body still had fuel and strength to do the last 15 miles even though I was exhausted.
The same goes for startups, the mostly mental pain is a signal that we are pushing our limits. If we do it gently we can expand our understanding and knowledge of the subject. It is in the quitting when we hit the pain wall where we fail, push through it and the downhill on the other side will be joyous!
Agatha Christie wrote a book “Elephants can remember”, a detective story structured around people recollecting events that happened long ago. Years later, a group of researchers discovered that she had the starting signs of Alzheimer during this period. They did this by analyzing the range of vocabulary in her writings and there was a significant drop in the size of her vocabulary (15-30%) and an increase in the usage of indefinite words like something/anything. We can never be sure if she was aware of her slow deterioration, but something has pushed her to dwell on the subject of memory long enough. Even before we can consciously articulate the experiences of our brain, clues to our deep inner experience is scattered all over in the everyday choices we make, even in the choice of our thoughts. Look at the books that you bought, and the books that you ended up actually reading. You can apply the same to every bit of choice you make in your life, and you can put together a wonderfully detailed picture of your deep inner experience.
One particular corollary to this interrelation of pain and choice is our relationship to deficiency. Chuck Close drew pictures of human faces. His portraits are highly sought by museums and collectors. Chuck Close has a neurological condition known as face blindness. He cannot recognize human faces.
Rivers flow. The fertility from the resulting flow leads to formation of entire cities along its edges. The overwhelming focus that pain brings to particular deficiencies we face makes them the central structure around which we form our characters. I would not exactly say this is a bad thing necessarily, but it is a narrative that will help you explore yourself. It will take you to the far corners or more likely to the very foundation of your personality.
Shouldn't the agile motto be, "If it hurts, find a better way"? The whole point is to have the agility to adjust around different circumstances. We're not bound by natural laws, and our output is more likened to art than science because of the many variations you can take. So take advantage of it!
This article assumes there is only one way to get something done, which smells of rigid Certified processes. And our industry has enough of a bravado culture that people put themselves through pain just so they can show off their scars. Why not promote pain-avoidance thinking instead? We should all be thinking, "there's got to be a better way", because most times, there is.
Knees hurt when you exercise? Try swimming. Merging is a painful process? Try scheduling the work better; dividing the codebase smarter; allowing the smaller work to be sacrificed in order to get the important worked checked in; finding tools to help visualize the merge easier.
Of course, there's also injury, leaning into the pain so much you do damage to yourself. Or even overtraining, a system wide failure cause by leaning a little too far (this is actually fairly rare in physical training, but seems to be a good analogy for burnout).
I would hate to see someone fail to achieve their full potential from either avoiding what's difficult for them thereby failing to improve, or focusing a little too much on what's difficult, thereby failing to achieve their potential. I will never be a gold medal sprinter, and if I'm hoping to be, I will be sorely dissapointed with my life. Doesn't mean that if I was a sprinter, I shouldn't work on my weaknesses to improve my overall ability.
It's a good piece, but a little self-knowledge goes a long way. Perhaps he deals with that in the upcoming piece "Confronting Reality".
His premise, in my opinion, is wrong and therefor invalidates everything following it:
The problem is that the topics that are most painful also tend to be the topics that are most important for us: they’re the projects we most want to do, the relationships we care most about, the decisions that have the biggest consequences for our future, the most dangerous risks that we run.
Am I missing something, or am I just weird? This makes absolutely no sense to me. On the contrary, the projects and relationships I care most about are what bring me the most pleasure. Things that bring me the most pain are projects and relationships that I can't stand or don't want to deal with. What am I missing here?
I don't buy the Agile part but I find it interesting that the part about pain and exercise has to be explained at all. I have a friend who used to talk about improving his physique. It was one of the hopes and frustrations that we shared chronically for fifteen years. Then one day I realized he hadn't said anything positive about exercise in... years! (Apparently I can be slow to recognize when an old friend changes something about him that's been the same since I met him twenty years ago.) So what's the deal, I asked him.
"Exercise hurts," he said. Well, yeah, I said. But that isn't really a strike against it, is it?
"How can you say that? Pain is unpleasant. When I exercise, it hurts, and I feel really bad." That doesn't make any sense, I said. I mean, it makes superficial sense, I said, but does it doesn't really work that way. It hurts, but it feels good. "Yeah, it does work that way. I've tried it plenty of times. It hurts, it makes me feel bad, it makes me miserable. It always made me miserable, but I figured I'd be better off if I could do it and live with being miserable. Now I'm married and [wife's name] doesn't care that I'm fat, so I'm done with it." (The part about his wife is true. They're both obese and revel in eating huge amounts of food together. Sometimes she tags him on Facebook when posting about "fourth meal," which means hitting a drive-through at midnight for burgers or fajitas.)
This is something you've always wanted to do, I said. You bought the P90x DVDs and yoga mat. It was just a few years ago when you bought the Chuck Norris Total Gym. You were already married then.
"Old habits die hard. I wanted to be tough enough to take the pain. Wishful thinking. Now I know it's okay that I'm not a badass." Badass? You think I'm a badass? You think everyone at the gym is a badass? "More of a badass than me."
That was it. I've brought up exercise a few times since then, and his story hasn't changed. I get that he legitimately finds exercise to be extremely unpleasant. I guess I get that my experience of exercise requires as much explanation as his. What I don't get is how we arrived at opposite ends of the spectrum and why his experiences with physical exertion didn't push him over to my way of experiencing it. Did he not work out hard enough? Did he not work out long enough? What was the missing ingredient that would have made him experience exercise the same way I do?
The important shift for me was developing a little humility and learning how to train at my own pace.
When I started running, I would try to go as fast as I thought I should be going. Which meant as fast as other people were going, or as fast as my high expectations for improvement told me I should be going. It was hard, it hurt a lot, and it wasn't fun at all.
Eventually I learned to pay attention to my actual (rather than desired) fitness level, what my recent training history actually looked like, and how my body was responding. That hurt a little, but was also very pleasurable once I got going, and the pleasure more than counterbalanced the pain. I also learned to distinguish different sorts of pain. For me the first mile is never very pleasant, but I know it's all getting-warmed-up pain. That's different that the you're-training-too-hard-and-its-time-to-stop pain.
Then, don't be arrogant about it. Don't say, "Hey, I want to run a race sooner, so I'll just skip 4 weeks ahead." If you are going to err, err on the side of gentleness. Start with week 1, and if that seems hard, just do week 1 again until it seems right. You are trying to develop a lifetime habit, so you have a lifetime to get this right.
Also, get a heart rate monitor. Set it to beep if you your heart rate gets too high. Ideally, get one that records data, so you can understand your workouts in context. If you are looking mainly forward, it's easy to get impatient. But if you have actual data showing what you ran the last month, it's easier to say, "Oh, I can see the improvement, so I'll try to do a little better next week."
I am almost like your friend in that I only enjoy the results of exercise. It's really, really difficult to make myself go through the pain for indefinite results at an indefinite time in the future, which means I go through cycles of exercising steadily for a few weeks or months (during which I see almost immediate and quite noticeable improvements) and then quitting once the improvements are not so immediate or noticeable.
I notice the same pattern in other areas of my life: when I played World of Warcraft, the first 15-20 levels were great fun, and I usually could convince myself to keep going to level 30 or so. Somewhere between 25 and 35 I'd stop playing. Later, they made it faster to level, and the sweet spot moved up to 45-60, and then it became faster still, and I managed to get a coupla characters to 80. I was still treating the actual game as something to get through to enjoy the leveling up experience, though, and if I couldn't expect to level up in this session of play, I would have very little interest in playing right now.
In programming, if I'm working on something I don't actively enjoy, I have to structure my work as a series of small victories, or I will put it off until time pressure forces me to grind through it all at once.
Regarding that specific case the issues of subjective and objective pain migh be a hint to a broader explanation.
I also know that different individuals will objectively feel pain in various degrees for the same stimuli(not sure about the spelling).
Time needed to restore the body to a "normal" or relaxed/replenished state after physicial activities isn't the same from one individual to another.
An another social theory also states that people tend to get fat/lean, give up smoking/etc., when most of their social connections do (even though they aren't in direct contact with them). Citation needed, will dig later after it but not sure if i can find it again.
I believe that there are physical and/or neurochemical properties that make this either true or false for specific individuals. I'm just like your friend: exercise doesn't make me feel good or give me any sort of endorphin high; it just makes me tired and sore. I do the minimum that I figure will keep me in reasonable shape (and yes, I've done more in the past), but I'd much rather spend my time either being productive or relaxing.
For what it's worth, I totally buy the Agile part. By the time I left my last company we were releasing circa 5x/day. We got there bit by bit, and often through applying "if it hurts, do it more".
Indeed, I learned the principle first professionally, and it was only later that I realized how many areas of my life it applied to.
Agile focuses on painful things with the goal of making them less painful. The blog post compares embracing the pain of exercise to the Agile practice of taking big painful jobs, like merging and releasing, and streamlining them so you can do them more often in smaller increments. The pain decreases because of automation, practice, and reduced change size. Basically, the complexity of tackling change scales more than linearly with the size of change, so splitting a large change into smaller changes means less pain if the constant factor of handling each change can be made small. From this perspective, Agile means tackling change in small chunks, and Agile practices are focused on reducing the constant factor. The end result is less pain for the same amount of forward progress.
The reason I don't buy the analogy is because embracing the pain of exercising doesn't reduce the pain and doesn't have anything to do with the size or frequency of workouts. It's entirely about perception. You know the pain is there, but your experience of the pain changes. It's like your brain learns the pattern exertion => accomplishment => pleasure and satisfaction and short-circuits the logic so that exertion is rewarded directly with pleasure and satisfaction. Or maybe it's endorphins. Whatever the explanation, pleasure is layered over the pain, but the pain remains underneath. It's still there, but it doesn't hurt. Or it hurts, but it feels good. I don't know how to describe it, but the physical sensation of pain is still there.
I disagree specifically, and also with your interpretation of his point.
Embracing the pain of exercise absolutely does reduce the pain. If you don't exercise for months, it hurts like hell to get started again. The natural reaction, especially for people who have never exercised, is to avoid the pain and stop. But if you are returning to exercise after, say, an illness, you will slowly work through the pain until your body responds. There is still some underlying pain, but it is much less for a person who's in shape.
But I don't think he's making the direct analogy you're seeing. I think his broad point is exactly what the title says, that one should lean into the pain in many aspects of life. Exercise and software development are just two examples of applying the principle.
It is important to remember that physical pain is divided into two categories by athletes. "Pain" that indicates a broken bone or injury, which is typically a lot sharper pain and "Pain" that indicates growth, which is being sore after a workout.
Taking a shades of gray approach such as the above is beneficial in most situations. "Pain" is not black and white all the time.
tldr; Learn what kinds of pain you should be pushing through.
In my opinion, there can be another argument: Preplanning carefully and doing things when they are less painful but in advance, we can avoid huge last minute pain and thus less prone to procrastinate. But if you fail to preplan and execute, you have to go thru huge amount of pain to achieve success.
It's a good sentiment but the exercise analogy isn't the best... there is PLENTY of pain in exercise that you should not "lean into" because you will make injuries worse.
Not to mention exercise is mostly about routine and habit -- you'll make plenty of progress of progress over time.
The Jane and Joan example is a case in point. Rather than "merging often" to take small pain now rather than big pain later, they should be taking a step back and looking at WHY there's pain. They could, for example, choose to stagger their work (work on stories involving unrelated files as much as possible) such that they're not stepping all over each other all the time. Are nicer messages REALLY that important RIGHT NOW? Couldn't Jane just work on the purchase system instead on this sprint and do messages later and save everyone a lot of pain?
Pain exists for a reason. Don't ignore it. And for the love of Pete, don't just blindly push through it!