Getting Comfortable with Being Uncomfortable
alexanderell.is
alexanderell.is
When you're a student you generally have small, closed ended problems with a solution that someone has found before you.
When you're working you're generally the first person to solve a given problem, and it's never completely solved and it's never completely understood. You may have to dive down to a level of abstraction that you don't normally operate in, like machine code. Or up, eg to the business strategy.
The feeling of discomfort comes from the cave diving, you don't know what's around the corner. What does tend to happen is you learn a set of tools that are generally applicable, with a bit of customization for each time you see the same problem.
Additionally, student projects are strictly time boxed. If you go over by 1 day you will lose significant credit, no matter what the quality of your work is. Literally the best you can do is to avoid making 'mistakes' and accomplish the absolute minimum otherwise, and being late means 'no mistakes' is worth less, sometimes significantly less. In professional work if you go over by a week on a project that is supposed to take a week nobody will even be surprised and they'll just be happy that progress is being made. Taking more time to contribute a better work product is generally encouraged.
As a former educator who then mentored many professionals, I've long seen disconnect between assessment in "school" vs "on-the-job training" but never put together this essential difference.
I wonder what would a school look like that graded like we do at work.
I don't think we could compare them fairly as school and training is skill driven where learning at work is goal driven.
When we focus on skills, there is a right and wrong way to do things based on how a skill is measured. Whereas when we focus on goals, there are in most cases multiple avenues to achieve the same result, some of which don't teach you anything as they don't require the same level of understanding to develop those skills, especially for one-off problems.
Take grading, why do they start at 100 and just take points off for mistakes? It's just easier, most people most of the time get most things correct (or at least most work isn't worth discussing) so it's less work to just skim the work and paint some red where necessary than it is to evaluate and explain how each part contributed to the final grade. The latter would require a lot of thinking and would take a lot longer.
Why be very strict with timelines and time boxing of assignments and tests? Again, it is just practical and easier. Making everyone turn in work on time makes grading it less of a chore since you won't be grading this random assignment and that random assignment, you'll have a stack of 30 of the same assignment and you can get in the zone and burn through them with optimally low effort. The same with tests, why would we care if it took one student an extra week to get to mastery compared to a peer on test 1, and maybe vice versa on test 2? Isn't it better to encourage all students to reach mastery before continuing on, so they don't move to the next topic in the same class unprepared? Well then you have to have lots of equivalent tests, since once you give a test it is 'out there' and students aren't trusted not to cheat.
I am confident there is no rational for any of the above besides it being practical and/or less effort for teachers, and it isn't questioned because the teachers had absolutely no problem performing in such an environment.
Regardless of how schools teach, what they do is they teach skills. Skills are about how to do something in a certain way (including how to think about topics), and hence you have right or wrong answers that can be graded.
Whereas work is goal oriented, it is about solving a problem as opposed to how to solve a problem in a particular way. Hence, there are solutions which may be great practically, but doesn't teach you any useful skill. There are a lot of jobs that don't require any real problem solving. In fact, I would argue that's the majority of jobs.
Sometimes we need to be taught skills, and sometimes we need to be challenged with open-ended problems.
In my experience in many cases you may even get a complete fail for novel work at any education level below graduate work.
That's only if you work in roles which require or benefit from creative thinking. Not all roles require or even desire that. We sometimes tend to forget that in many industries and countries, human capital is not as highly valued due to various reasons.
Only if you're in the 0.001% of humanity that's working on innovation, the rest are working with solved problems that just need work.
by Kaitlin Woolley, Cornell University ; Ayelet Fishbach, University of Chicago
PDF: https://kaitlinwoolleycom.files.wordpress.com/2021/08/woolle...
"Abstract: Achieving personal growth often requires experiencing discomfort. What if instead of tolerating discomfort (e.g., feeling awkward or uncomfortable), people actively sought it out? Because discomfort is usually experienced immediately and is easy to detect, we suggest seeking discomfort as a signal of growth can increase motivation. Five experiments (N = 2,163) tested this prediction across various areas of personal growth: taking improvisation classes to increase self-confidence, engaging in expressive writing to process difficult emotions, becoming informed about the COVID-19 health crisis, opening oneself to opposing political viewpoints, and learning about gun violence. Across these areas of personal development, seeking discomfort as a signal of self-growth motivated engagement and increased perceived goal achievement relative to standard instructions. Consistent with our theorizing, these effects occurred only in areas of personal growth that cause immediate discomfort."
Keywords: motivation, self-control, self-growth goals, negative experience
That means, I will code knowing beforehand my first version will be crap. Because no matter how much thought I put into it, there's always a myriad of variables that get overlooked in a first version.
And once I done it, I get to know most of those variables.
But to avoid programming an amorphous blob of bad code, I take software architecture very seriously. If I split controllers, services, repositories properly, then I know I will be sitting on tip of a solid base without worrying about not writing a perfect first version.
[0] https://archive.curbed.com/2016/7/18/12215158/always-be-knol...
Side note, I also recommend the main "Ten Bullets" video by Tom Sachs (of which the link above is for bullet 8, "Always Be Knolling"); it feels a little over-zealous and pretentious at times, but there's something about it that makes me want to go back and watch it every couple years for inspiration...
Here are some tips from personal experience:
1) Program with refactoring in mind beforehand. Things like SOLID, Hexagonal Architecture or even MVC help make refactoring easier.
2) Practice a bit with SOLID principles in your language. Once you get the gist the first time, every project after that is just copy and paste. Upload that base project to a personal git repository if you like.
3) If your project doesn't have to be lightning fast then prioritize legibility over superb efficient algorithms. For example, directly operating and mutating an array may demand less CPU cycles than mapping and parsing an array into controllers and descriptive functions. But unless you can wrap that in an accessible way, it will make further development hell.
4) Software engineering is weird. Unlike other engineering fields, our requirements and constraints change all the time, and the product is never meant to be static. The more flexible a program is to develop and refactor, the more it will maintain its quality over time. Even a perfect and fast program will crumble over time.
The "I don't have time for good code" is a mental trap and a sign of either nearsightedness, or letting oneself be dragged by anxiety. It's our job to at least make notice when development is badly managed.
Leaving that aside, I assure you that once you have a good boilerplate project, every program built on top of that will be fast and flexible. And any bugfixing will be straightforward.
People usually crave security and certainty, and go to great lengths to attain it.
The thing is, while there are certainly variables in life one can control, things you know you know, or know you don’t know, there are also those things beyond your information horizon, beyond your control.
My takeaway was that there’s no real certainty in anything, and you can either spend your life trying to attain perfect certainty and never succeed, or revel in the uncertainty, the adventure, the unknown and maybe unknowable. I gave up long ago knowing everything I could know about software development, as the pool of knowledge is immense - and that in and of itself is a joy, to know that I can keep at it, at practically any discipline, software or otherwise, and never stop learning and experiencing novelty.
Agree.
Outside of the physical benefits of exercise, getting comfortable being uncomfortable is one of the big mental benefits. A more extreme version is something like jiu-jitsu.
I have found that routinely being uncomfortable through exercise leads to being relaxed in other uncertain life situations - software development included.
"Writing is easy. All you do is stare at a blank sheet of paper until drops of blood form on your forehead."
John Cleese has written and spoken about the creative process. One of the principles he shares is to never make a decision before you have to. In his experience the willingness to be uncomfortable produces consistently more creative work.
I usually get stuck in "cycles" where I know I'm not making progress, but I'm exploring my interests and seeing what sticks and what doesn't.
I've found forcing myself to a bare minimum has helped. The age-old "write one article a month" type of thing has forced me to find that sense of purpose to sit down and write something. Sometimes it turns out well, sometimes it doesn't. The process and lessons learned have been more important than the (immediate) results.
It's a state some people end up in if their upbringing and education is too rigid.
Being in an uncertain state while you're still learning, coming up with ideas, or creating something new is different, in my opinion. If you were unable to progress at all due to the uncertainty, maybe that's where it may be due to an inability to help yourself get through it. But, that being said, the creative process (and especially the early stages) can still be a very uncertain process even for people who are able to eventually work through it.
I think that's where the importance of knowing how to get through it (and what works for you, and practice applying those skills) makes the difference.
You... should feel that all day, every day (as a programmer anyway). If you don't, you're doing something wrong.