This article made me think of a list I’ve been informally trying to make, of what stupidity feels like on the inside. The point is to identify when I’m writing code poorly—as the output will probably be even more bugridden than normal, and possibly the output is appropriate to debug-by-starting-over (Though starting over violates my normal policy.)
Stupidity feels like being bored, being in pain, being distracted, wanting to do anything else than this.
Stupidity feels like being unworthy of these divine (external) ideas.
Stupidity feels like blind plodding obedience.
Stupidity feels like lovely and/or grotesque baroque clevernesses.
Trying to stop working and recover when I notice myself being stupid might be the right move, but I think pushing through it (aside from staying up late, which is a mistake) is a better policy. You have to learn to be productive on demand rather than when you’re in the mood for it.
There are some pieces of code I can implement just as well whether I’m motivated or not (whether I’m sharp or not). I think knowing the personal difference between what I can do while motivated and what I can do otherwise is the real key to consistent productivity. I try and mentally break down my to-do lists into those categories, so that when I’m feeling less sharp I can just fall back into a cache of problems that I know I can solve well even given a temporary decrease in ability.
Somewhat agreed, with the caveat that there is code I can implement when not sharp, which, when I am sharp, I realize why I shouldn’t implement it and use a more elegant approach. This makes it important to set up the to-do lists you mention during sharp time.
I find that I’m occasionally in a mood where I am very sharp but very lazy. That’s the time I use to do most of my planning. Thinking out the high level form of code is almost always fun.
“That sounds like a way to end up spending your in the mood for productivity time undoing the damage you do when you try to be productive on demand.”
I find that once I’ve pushed myself to finish something I’ve been procrastinating on, or even to do a small amount of work on it, my mood and general sense of my own competence improves enough to make the minor pain worth it. This is true of any work that has a deadline, self-imposed or not, and yes it’s usually true when I’m sleep deprived.
However, I’m not a programmer, so this applies more to school assignments or to extracurricular projects like composing music. Maybe coding is different. (My experience of programming is limited enough that there isn’t much creativity involved, and the limit is my knowledge, not how sharp I am.)
Do any of these projects involve anything as hard as designing and implementing novel software that you may have to debug or expand a year later? Or designing an API that you will have to expand later after after lots of other programmers have written programs that use it, which you are not allowed to break?
I have no idea how to do any of those things. I would assume that they involve applying the rules of a given domain more rigorously than when you are, say, working on a novel or composing a piece of music. Which for sure would make them harder.
Also, I think I misunderstood your comment. You mean “damage” as in bad coding that you’ll just have to redo later? As opposed to damage to your own motivational framework that will make it harder for you to motivate yourself in future? The latter is the way I understood it.
Regardless, is it not true that anyone who works as a programmer has deadlines, and can’t afford to leave a project for later because they’re not in the mood to be productive?
You mean “damage” as in bad coding that you’ll just have to redo later?
Yes, though it is worse than that. Bad code can contaminate otherwise good code that interacts with it, if the interface is not right.
Regardless, is it not true that anyone who works as a programmer has deadlines, and can’t afford to leave a project for later because they’re not in the mood to be productive?
No, not necessarily. Usually the closest I have to a deadline is my own declared estimate of when I will be done. Sometimes it is an effort just get the relative priorities of my concurrent projects.
If you are working full time programming, you should manage to get in the productive zone at least once a day. “Not being in the mood” is not an excuse to put a project off indefinitely.
If I wasn’t already halfway through my undergrad, I would consider programming as a career solely on that basis!
Your existing undergrad experience is a sunk cost. Do you want to be a programmer, or a whatever-you’ve-already-started-learning-to-be? (For that matter, do you have spare time? You could learn to program therein.)
I am studying nursing and for various reasons, that’s where I want to stay. (There’s actually a lot of appeal for me in a field where I’ll never be out of work, can travel and work pretty much anywhere, and can easily branch out into many, many related fields.)
I took programming as one of my electives and I’ve tried to continue the learning process by giving myself extracurricular projects, but spare time is a limiting factor. Thanks for the advice though. If you have any advice for good books/online tutorials to read, or challenging projects I could assign myself, I would really appreciate that.
“Bad code can contaminate otherwise good code that interacts with it, if the interface is not right.”
Coding is dealing with abstractions and the way that things relate to one another. You’re not just constructing the pieces, you are constructing how they will be put together. If you set it up wrong, it can be tricky to change later, if other people are relying on the parts that you’d like to change to keep working the same way they have been working from the beginning. And creating new software is usually a process of discovering requirements and uses for the software as you go along, so it is often difficult to know how to approach something at the beginning. Also, working with other people on the code means working with people who set up abstractions differently and have a slightly different, or wildly different understanding of what the code is meant to do, and the assumptions that underly it.
Working on a software project is a good way to see how people think differently, and how errors and assumptions affect the project and how people work together.
I like Frederick P. Brooks’ books on software design, and design in general. They are classics: “The Mythical Man-Month” and “The Design of Design”.
f I wasn’t already halfway through my undergrad, I would consider programming as a career solely on that basis!
Then learn to programme and see if you like it enough to do it as a job, or if it could be helpful in the field you’re doing your degree in. Being an X who can programme can be a powerful force multiplier of your effectiveness in quite a few fields. An assume very little intro to programming is Learn Python the Hard Way
I did take a class in programming last semester as one of my electives. My major is in nursing, and my father made the comment that “you’ll be the only nurse in Canada who can program.” I learned it pretty effortlessly (that class was the easiest A+ I’ve had in years) but it was a huge time sink, and I think I drove the TA insane by starting projects at home and then sending him emails at 2 am asking why my program wasn’t working.
Also I’m sure you’re right and it could be very helpful just to know programming as a nurse. At one of my part time jobs, the software we use to keep track of dialysis patients was actually written BY a dialysis patient, who I guess worked as a programmer and saw a need that wasn’t being filled. (I’m not QUITE at the level where I can write big, complex, useful programs.)
A while ago i started to motivate myself with good old conditioning. Every time I started to work on a project I ate an M&M. (I actually got the idea from the very first lecture from what will soon be the “Center of Modern Rationality” concerning the sunken cost fallacy.) This “technique” worked suprisingly well. After a while my subconciousness seemed to become a little less reluctant to start working. My “mod” was better.
Could be a placebo effect of course, and could only work on myself, but its cost nothing to try. Let me know please if someone actually does.
“You have to learn to be productive on demand rather than when you’re in the mood for it.”
Very true, and it’s part of the reason I like to arrange structured activities that force me, on a day-to-day basis, to do the things I enjoy. I could have taught myself programming (maybe) but taking a course as my elective forced me to actually write the code when the assignment was due the next morning, as opposed to when I felt like it. It’s a good feeling, getting something done and knowing you did a good job, but it’s depressing how bad I am at motivating myself to push through and get it done without a deadline. (I don’t know if this is true of other people, but actually I’ve been told I’m unusually productive.)
The best way to make a good use of unstructured time that I’ve ever found is to optimize towards highest utility. In plain terms, you have an ultimate goal, a be-all-end-all reason to be doing something, and you’re doing your best to achieve this goal as efficiently as possible because each time-unit of delay is negative utility.
This takes a goal, of course, which is pretty much comparable to Step 7 of 11 For Building a Goedel Machine, if you’ve seen Eliezer’s Summit presentation that touched that subject.
This article made me think of a list I’ve been informally trying to make, of what stupidity feels like on the inside. The point is to identify when I’m writing code poorly—as the output will probably be even more bugridden than normal, and possibly the output is appropriate to debug-by-starting-over (Though starting over violates my normal policy.)
Stupidity feels like being bored, being in pain, being distracted, wanting to do anything else than this. Stupidity feels like being unworthy of these divine (external) ideas. Stupidity feels like blind plodding obedience. Stupidity feels like lovely and/or grotesque baroque clevernesses.
Trying to stop working and recover when I notice myself being stupid might be the right move, but I think pushing through it (aside from staying up late, which is a mistake) is a better policy. You have to learn to be productive on demand rather than when you’re in the mood for it.
This is something I thought about a lot while I was recovering from brain damage and thus transiently a lot stupider than I normally am.
A few of mine:
Stupidity feels like not having enough fingers to hold all of my thoughts in place.
It feels like being tired all the time, even when I’m not.
It feels like merging onto the highway when I can’t see all the oncoming traffic.
It feels like someone’s playing loud distracting music that I can’t hear.
It feels like riding on a train with square wheels.
This metaphor is excellent. That is exactly how I feel when I undersleep/oversleep.
That sounds like a way to end up spending your in the mood for productivity time undoing the damage you do when you try to be productive on demand.
There are some pieces of code I can implement just as well whether I’m motivated or not (whether I’m sharp or not). I think knowing the personal difference between what I can do while motivated and what I can do otherwise is the real key to consistent productivity. I try and mentally break down my to-do lists into those categories, so that when I’m feeling less sharp I can just fall back into a cache of problems that I know I can solve well even given a temporary decrease in ability.
Somewhat agreed, with the caveat that there is code I can implement when not sharp, which, when I am sharp, I realize why I shouldn’t implement it and use a more elegant approach. This makes it important to set up the to-do lists you mention during sharp time.
Agreed.
I find that I’m occasionally in a mood where I am very sharp but very lazy. That’s the time I use to do most of my planning. Thinking out the high level form of code is almost always fun.
“That sounds like a way to end up spending your in the mood for productivity time undoing the damage you do when you try to be productive on demand.”
I find that once I’ve pushed myself to finish something I’ve been procrastinating on, or even to do a small amount of work on it, my mood and general sense of my own competence improves enough to make the minor pain worth it. This is true of any work that has a deadline, self-imposed or not, and yes it’s usually true when I’m sleep deprived.
However, I’m not a programmer, so this applies more to school assignments or to extracurricular projects like composing music. Maybe coding is different. (My experience of programming is limited enough that there isn’t much creativity involved, and the limit is my knowledge, not how sharp I am.)
Do any of these projects involve anything as hard as designing and implementing novel software that you may have to debug or expand a year later? Or designing an API that you will have to expand later after after lots of other programmers have written programs that use it, which you are not allowed to break?
I have no idea how to do any of those things. I would assume that they involve applying the rules of a given domain more rigorously than when you are, say, working on a novel or composing a piece of music. Which for sure would make them harder.
Also, I think I misunderstood your comment. You mean “damage” as in bad coding that you’ll just have to redo later? As opposed to damage to your own motivational framework that will make it harder for you to motivate yourself in future? The latter is the way I understood it.
Regardless, is it not true that anyone who works as a programmer has deadlines, and can’t afford to leave a project for later because they’re not in the mood to be productive?
Yes, though it is worse than that. Bad code can contaminate otherwise good code that interacts with it, if the interface is not right.
No, not necessarily. Usually the closest I have to a deadline is my own declared estimate of when I will be done. Sometimes it is an effort just get the relative priorities of my concurrent projects.
If you are working full time programming, you should manage to get in the productive zone at least once a day. “Not being in the mood” is not an excuse to put a project off indefinitely.
“Bad code can contaminate otherwise good code that interacts with it, if the interface is not right.”
That’s kind of fascinating, but I can see that it would be really irritating as well having to deal with it every day.
“Usually the closest I have to a deadline is my own declared estimate of when I will be done.”
Really? If I wasn’t already halfway through my undergrad, I would consider programming as a career solely on that basis!
Your existing undergrad experience is a sunk cost. Do you want to be a programmer, or a whatever-you’ve-already-started-learning-to-be? (For that matter, do you have spare time? You could learn to program therein.)
I am studying nursing and for various reasons, that’s where I want to stay. (There’s actually a lot of appeal for me in a field where I’ll never be out of work, can travel and work pretty much anywhere, and can easily branch out into many, many related fields.)
I took programming as one of my electives and I’ve tried to continue the learning process by giving myself extracurricular projects, but spare time is a limiting factor. Thanks for the advice though. If you have any advice for good books/online tutorials to read, or challenging projects I could assign myself, I would really appreciate that.
Here are a few websites:
Software Carpentry: Getting Scientists to Write Better Code by Making Them More Productive http://software-carpentry.org/
Invent Your Own Computer Games With Python http://inventwithpython.com/
“Bad code can contaminate otherwise good code that interacts with it, if the interface is not right.”
Coding is dealing with abstractions and the way that things relate to one another. You’re not just constructing the pieces, you are constructing how they will be put together. If you set it up wrong, it can be tricky to change later, if other people are relying on the parts that you’d like to change to keep working the same way they have been working from the beginning. And creating new software is usually a process of discovering requirements and uses for the software as you go along, so it is often difficult to know how to approach something at the beginning. Also, working with other people on the code means working with people who set up abstractions differently and have a slightly different, or wildly different understanding of what the code is meant to do, and the assumptions that underly it.
Working on a software project is a good way to see how people think differently, and how errors and assumptions affect the project and how people work together.
I like Frederick P. Brooks’ books on software design, and design in general. They are classics: “The Mythical Man-Month” and “The Design of Design”.
Thank you, those look interesting.
Then learn to programme and see if you like it enough to do it as a job, or if it could be helpful in the field you’re doing your degree in. Being an X who can programme can be a powerful force multiplier of your effectiveness in quite a few fields. An assume very little intro to programming is Learn Python the Hard Way
I did take a class in programming last semester as one of my electives. My major is in nursing, and my father made the comment that “you’ll be the only nurse in Canada who can program.” I learned it pretty effortlessly (that class was the easiest A+ I’ve had in years) but it was a huge time sink, and I think I drove the TA insane by starting projects at home and then sending him emails at 2 am asking why my program wasn’t working.
Also I’m sure you’re right and it could be very helpful just to know programming as a nurse. At one of my part time jobs, the software we use to keep track of dialysis patients was actually written BY a dialysis patient, who I guess worked as a programmer and saw a need that wasn’t being filled. (I’m not QUITE at the level where I can write big, complex, useful programs.)
A while ago i started to motivate myself with good old conditioning. Every time I started to work on a project I ate an M&M. (I actually got the idea from the very first lecture from what will soon be the “Center of Modern Rationality” concerning the sunken cost fallacy.) This “technique” worked suprisingly well. After a while my subconciousness seemed to become a little less reluctant to start working. My “mod” was better. Could be a placebo effect of course, and could only work on myself, but its cost nothing to try. Let me know please if someone actually does.
“You have to learn to be productive on demand rather than when you’re in the mood for it.”
Very true, and it’s part of the reason I like to arrange structured activities that force me, on a day-to-day basis, to do the things I enjoy. I could have taught myself programming (maybe) but taking a course as my elective forced me to actually write the code when the assignment was due the next morning, as opposed to when I felt like it. It’s a good feeling, getting something done and knowing you did a good job, but it’s depressing how bad I am at motivating myself to push through and get it done without a deadline. (I don’t know if this is true of other people, but actually I’ve been told I’m unusually productive.)
As far as I can tell, making good use of unstructured time is very rare.
It’s possible that conventional schooling makes people worse at it.
The best way to make a good use of unstructured time that I’ve ever found is to optimize towards highest utility. In plain terms, you have an ultimate goal, a be-all-end-all reason to be doing something, and you’re doing your best to achieve this goal as efficiently as possible because each time-unit of delay is negative utility.
This takes a goal, of course, which is pretty much comparable to Step 7 of 11 For Building a Goedel Machine, if you’ve seen Eliezer’s Summit presentation that touched that subject.