I feel like this when I need to think up a new project idea. What if this time I won't come up with anything? I wonder if that agony is an important part of the process. Maybe without it your subconscious wouldn't assign enough resources to solve the problem. I hope not.
That's an interesting point - this uncertainty seems to really show up when pulling from creativity to create something new. I'm reminded of the Gene Fowler quote:
"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.
Comfort in the unknown helps a lot with this -- creativity is also a skill that can be trained and tested like muscles.
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.
Personally I like the idea of iterative development.
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.
This is also why I think being good at refactoring is a secret superpower. So long as you keep moving roughly in the right direction and knoll things as you go, you can always iron out the kinks in the end.
If you search "knolling" you might have an easier time. It's a process of arranging things for photography but could mean more generally "arranging things neatly".
As far as I know, the term was originally used to mean roughly "always be arranging like objects in parallel or 90-degree angles" [0] [1]. The idea is to keep your workplace tidy as you work, meaning that you keep your tools and working pieces organized as you go. Taking pictures of knolled workspaces etc is a more recent addition from the social media generation if I'm not mistaken.
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...
This is a big issue when the org you are at doesn't give you space to refactor and rework your system. Because the value added of refactoring is opaque to business goals (why are you spending time on something that was already working fine?) it can be soul crushing to know your first (crappy) try at something is the one that counts and there are no do overs.
Thing is, trying to create a perfect first version actually takes more time and mental energy than having a defined good base, creating a first draft and testing it.
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.
Thank you for the tips! SOLID has indeed been an excellent tool in dealing with this. Unfortunately, there are a few issues at my current day job that make even your principles a band aid. 1) We have a "project board" composed of non technically inclined managers who set deadlines independently, this has resulted in an environment where everything is for yesterday. Once something works, I'm already late for the next thing. 2) My teammates are not really well versed in SOLID principles, so my good boilerplate project I've set up at the beginning of the product cycle has already been mangled (I wish I had time for mentoring). Indeed, it is our duty to raise these issues but if you are powerless to change the org structure it is best to let go (and update your CV). I'm just venting a bit here I hope you don't mind :)
This is the big difference between studying and working.
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.
The other difference is that student problems are graded starting at perfect and then points are deducted for every 'mistake', but professional projects start at 0 and the value of a project is the sum contribution towards to the shared goals of the organization. You could come up with something totally new that totally changes the state of the art, and if you turn it in as homework but make a couple of insignificant mistakes you will still get a B.
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.
This is absolutely the most fascinating thought about education I've seen in a long time. Bravo for uncovering such a profound insight.
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 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.
You didn't spell it out exactly, so I want to add another point to your comment: there is also a value in teaching a skill versus the goal oriented problem solving at work, as these skills can become part of your toolbox to be able to solve the things you later encounter at work
I don't think schools put any thought along the lines you just did. I think schooling operates the way it does because that is just the easiest. It continues to operate that way because the people who decide how schools, especially colleges, are run are exactly the people who overachieved to a huge degree in that same environment, so they have their ego tied up in it being meaningful to do well in it.
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.
> You could come up with something totally new that totally changes the state of the art, and if you turn it in as homework but make a couple of insignificant mistakes you will still get a B.
In my experience in many cases you may even get a complete fail for novel work at any education level below graduate work.
>This is the big difference between studying and working.
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.
> 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.
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.
I would go a step further and say that sometimes that moment of uncertainty is useful and needs cultivating as it is where you have most freedom to define solutions. Once you step away from uncertainty your path is one of ever decreasing options, which is good if you're on the right path but uncertainty is when you get to choose a direction.
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.
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.
And what is it exactly that is so uncomfortable? Is it the idea of failure or is it the feeling itself? What if you got comfortable with all your uncomfortable feelings? When we were growing up we got use to all kinds of new, uncomfortable feelings. Why not keep doing that? Let the feelings happen, get use to them. You might find yourself freed from a prison you didn't even realize you were in.
"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."
That's an interesting take, but I think learned helplessness is tangential to this uncomfortableness. I think of learned helplessness as an inability to progress or work towards a goal because of the over-reliance on those training wheels.
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.
Similar to the footnote, a lot of my most interesting ideas for my graduate research, and life in general, have come to me during runs. I got an Apple Watch with drafts for the express purpose of dictating these thoughts before they evaporate.
32 comments
[ 5.6 ms ] story [ 70.3 ms ] thread"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.
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...
[1] https://en.wikipedia.org/wiki/Tom_Sachs#Knolling
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.
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.
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.
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
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.