I am having these episodes where my mind goes into a total halt. I cant focus or think on what i am wanting to think about, and its like my problem solving skills go on a vacation of some sort and leave me to go over the same step again and again.
I am having this problem as i type this. It annoys and frustrates me so very much. This same incident happened last week before i had finally implemented my memory manager. This week involves phase two where i am to write drivers, but i am first to make a file system read/write code. It basically involves everything from checking the drive to see if it exists or if the file system on it is supported. Too add, i am implementing directory support, and will not settle for just root directory checking, its too simple, i must accomplish more to get it out of the way. Just a day ago i had this all down as to what i am to do, today i had wanted to plan out in pseudo code how it will all work.
But then my mind goes into the break down, where i can not focus, or come up with any ideas to divide all of the functions into smaller ones. I just can't think anymore about it, i can barely keep track of what i have put down.
The problem is not about what i know, i understand everything. Have read all pdfs i could find more then once, and am in the midst of writing a paper on it and how it works. I cant with this though, its like i have gone into an overload and i need help. I am completely stressed out because of this too and afraid that if i leave it for more then a day or two that ill have to rethink up my ideas.
I am truly embarrassed to post this in front of the eyes of some professionals, as i myself am trying to make my image here more professional. Consider this as a desperate cry for help, i do not know how to handle this. I just want to get back into it. Is this some form of ADHD? What would you consider i do to improve my problem solving skills with no crash.
Burnt out and frustrated
Re: Burnt out and frustrated
I'm basically in the same position with vfs, fat12 and program/driver loading. I don't want to settle for just root access and keeping all aspects sorted out at once can be overwhelming to say the least. But I just have to accept that it's won't be perfect at first and break it up as much as possible to smaller functions that need to exist before I can tie the knot on the whole thing. I've just accepted that the fat12 functions might need small changes or rewrites once my vfs design is more complete and that in order to ever reach that state I need to get the smaller base functions working.
Hope that helps, and when in doubt, break it up to even smaller and more modular parts. Also don't be afraid of rewrites or changes to your code - as long as there is something to change in the first place it's all good.
Hope that helps, and when in doubt, break it up to even smaller and more modular parts. Also don't be afraid of rewrites or changes to your code - as long as there is something to change in the first place it's all good.
Re: Burnt out and frustrated
Thank you for your response,bubach wrote: I'm basically in the same position with vfs, fat12 and program/driver loading. I don't want to settle for just root access and keeping all aspects sorted out at once can be overwhelming to say the least. But I just have to accept that it's won't be perfect at first and break it up as much as possible to smaller functions that need to exist before I can tie the knot on the whole thing. I've just accepted that the fat12 functions might need small changes or rewrites once my vfs design is more complete and that in order to ever reach that state I need to get the smaller base functions working.
Hope that helps, and when in doubt, break it up to even smaller and more modular parts. Also don't be afraid of rewrites or changes to your code - as long as there is something to change in the first place it's all good.
I understand you, when you explain that building a bridge has to be done plank by plank, rather then designing the entire frame in one day. All of my attempts today were slow, and easily forgotten. I was told..
That if i were to clear my mind, not think about it for a day or so. To just work on it the next night, ill be fine and have a fresher mind. What i had now was a burn out, and i just have to recover from it by staying away from my project for a day or so. So far it seems to be working, each moment i sm not working on it however, is another moment i feel i am wasting.
- gravaera
- Member
- Posts: 737
- Joined: Tue Jun 02, 2009 4:35 pm
- Location: Supporting the cause: Use \tabs to indent code. NOT \x20 spaces.
Re: Burnt out and frustrated
Design stuff properly so that the only time you lose interest is when you encounter a difficult bug. If you're being outpaced at design that's just bad planning
17:56 < sortie> Paging is called paging because you need to draw it on pages in your notebook to succeed at it.
- piranha
- Member
- Posts: 1391
- Joined: Thu Dec 21, 2006 7:42 pm
- Location: Unknown. Momentum is pretty certain, however.
- Contact:
Re: Burnt out and frustrated
Just take a break. Go somewhere that is a completely different environment than where you code. I've hit blocks like that where I just massively fail at being motivated to do anything, or implement stuff, or whatever. Some of my best ideas and epiphanies have been while backpacking in the high country. I can code for a couple months at a time, doing quite well on my OS, but then I just burn out and take a break for a couple months, only doing minor things (like a few commits per month). Then I have some epiphany or idea for implementing something, and the cycle repeats.
As for your big list of things to do, design it all first and implement later. And make sure you see results. You may implement a feature that you know is useful and good and important, but if you don't see it do anything, subconsciously you'll see it as a waste of time.
-JL
As for your big list of things to do, design it all first and implement later. And make sure you see results. You may implement a feature that you know is useful and good and important, but if you don't see it do anything, subconsciously you'll see it as a waste of time.
-JL
SeaOS: Adding VT-x, networking, and ARM support
dbittman on IRC, @danielbittman on twitter
https://dbittman.github.io
dbittman on IRC, @danielbittman on twitter
https://dbittman.github.io
Re: Burnt out and frustrated
Rule #1: Don't be embarassed or ashamed. I believe everyone has gone through this, once or multiple times, both professionally and in spare-time projects.
You basically have two options:
1) Push through it. Set your mind, block out things that are distracting you, and sink your fangs into the problem. Don't let go until you have solved it. This takes lots of energy, and poses the threat of burning out in frustration, but it's usually the only way if it's a professional project you're working on. The feeling of achievement when you finally "reach the other side" is great, but prepare for a break afterwards to recharge your energy. Take a couple of days off, if you can.
2) Set it aside and do something completely different, until you feel like picking up the project again. This is easier, doesn't take as much energy, and doesn't pose the danger of burning out. On the downside, your project won't make progress for some time, perhaps even forever. But for spare time projects, this is usually the way to go. After all, you're doing this mostly for the fun, and where's the fun in fighting your frustration?
As for personal experience... in my work on PDCLib, the implementation of <stdio.h> was such a problem for myself. The interdependency of the I/O functions with regards to internals is rather intense, and my usual working scheme (about an hour at max before I have to do drop it again, sometimes with several days inbetween with no activity on the project at all) just didn't work here. It took too long to pick up the threads again in each session, to the point where I couldn't make any progress anymore at all.
I went for 2) several times, and when I returned I found I had to start over, either because I couldn't pick up the threads anymore, or because I felt a complete redesign was in order. I didn't get anywhere.
Eventually (and I'm talking years here), I took two weeks worth of vacation, most of which I used to get the design nailed down, and then went with 1) at best I could with a spare-time project. When I finally "got to the other side" (i.e. got <stdio.h> working), I did some of the "easy things" I had put off all the time (a simple implementation of <ctype.h> / <locale.h>), then shelved PDCLib for the duration and picked a completely different thing to do (a Role Playing Game translation, set in LaTeX). PDCLib doesn't make any progress since about this time last year, but I needed the break. Once I finish the RPG, I'll actually look forward to working on PDCLib again, instead of considering it a chore.
All the best wishes,
Solar
You basically have two options:
1) Push through it. Set your mind, block out things that are distracting you, and sink your fangs into the problem. Don't let go until you have solved it. This takes lots of energy, and poses the threat of burning out in frustration, but it's usually the only way if it's a professional project you're working on. The feeling of achievement when you finally "reach the other side" is great, but prepare for a break afterwards to recharge your energy. Take a couple of days off, if you can.
2) Set it aside and do something completely different, until you feel like picking up the project again. This is easier, doesn't take as much energy, and doesn't pose the danger of burning out. On the downside, your project won't make progress for some time, perhaps even forever. But for spare time projects, this is usually the way to go. After all, you're doing this mostly for the fun, and where's the fun in fighting your frustration?
As for personal experience... in my work on PDCLib, the implementation of <stdio.h> was such a problem for myself. The interdependency of the I/O functions with regards to internals is rather intense, and my usual working scheme (about an hour at max before I have to do drop it again, sometimes with several days inbetween with no activity on the project at all) just didn't work here. It took too long to pick up the threads again in each session, to the point where I couldn't make any progress anymore at all.
I went for 2) several times, and when I returned I found I had to start over, either because I couldn't pick up the threads anymore, or because I felt a complete redesign was in order. I didn't get anywhere.
Eventually (and I'm talking years here), I took two weeks worth of vacation, most of which I used to get the design nailed down, and then went with 1) at best I could with a spare-time project. When I finally "got to the other side" (i.e. got <stdio.h> working), I did some of the "easy things" I had put off all the time (a simple implementation of <ctype.h> / <locale.h>), then shelved PDCLib for the duration and picked a completely different thing to do (a Role Playing Game translation, set in LaTeX). PDCLib doesn't make any progress since about this time last year, but I needed the break. Once I finish the RPG, I'll actually look forward to working on PDCLib again, instead of considering it a chore.
All the best wishes,
Solar
Every good solution is obvious once you've found it.
Re: Burnt out and frustrated
Thank you all for your responses, i have read them all and taken them into consideration for future reference when i stumble upon this problem again.
This solution matches my current one, and will be using this to help from now on.Solar wrote:Set it aside and do something completely different, until you feel like picking up the project again. This is easier, doesn't take as much energy, and doesn't pose the danger of burning out. On the downside, your project won't make progress for some time, perhaps even forever. But for spare time projects, this is usually the way to go. After all, you're doing this mostly for the fun, and where's the fun in fighting your frustration?
Re: Burnt out and frustrated
I'll second to Solar: at work you have no choice, but to push it. Unfortunately when you've "reached the other side", usually there is no time for "recharging". You may try to slack off for a couple of days, but that's it. Sometimes it really becomes unbearable, I've actually considered to quit programming an go to work as a construction worker for a half or year or so (since there was a housing boom in my country before "late 2000's recession", it was a viable option), to relieve my brain from programming.
With hobby projects it's a completely different story. It's not like you have deadlines or something. Just take your time to develop, redesign, rest and whaterver... Nobody's waiting for you!
Bits from my OS development: it happens in a few stages - pushing forward (when I add new features), refactoring (when I do not add any new features, just making my code easier to read), complete stop (I'm not doing anything to my OS) and "complete rewrite" stage.
I'm not afraid of "complete rewrite" anymore, since it mostly turns out to be "redesign bad parts and reuse good ones". In fact, my current OS is a 4-th reincarnation of project I started sometime in 2008. But I consider code I can not understand easily to not being worth to keep. And yet just a few days ago I found a use for part of code I wrote for my 1-st incarnation.
A normal workflow for me is: pushing-refactoring-pushing-refactoring... Unfortunately it doesn't go that smooth all the time, interruptions happens. One being too much load at work, but it's not the worst one, once workload drops I can return to OSDev.
But the worst ones are happening when I spend too much time in "pushing forward" stage, without switching to refactoring. Things becomes too tangled-up to comprehend, and this usually leads me into "complete stop". It takes a few months before I recover and take a look at my code again. And then I feel lucky if I can return to "refactoring stage", worse being when I feel it's time for "rewrite".
If you do not lose interest altogether, you will reach your goal eventually.
With hobby projects it's a completely different story. It's not like you have deadlines or something. Just take your time to develop, redesign, rest and whaterver... Nobody's waiting for you!
Bits from my OS development: it happens in a few stages - pushing forward (when I add new features), refactoring (when I do not add any new features, just making my code easier to read), complete stop (I'm not doing anything to my OS) and "complete rewrite" stage.
I'm not afraid of "complete rewrite" anymore, since it mostly turns out to be "redesign bad parts and reuse good ones". In fact, my current OS is a 4-th reincarnation of project I started sometime in 2008. But I consider code I can not understand easily to not being worth to keep. And yet just a few days ago I found a use for part of code I wrote for my 1-st incarnation.
A normal workflow for me is: pushing-refactoring-pushing-refactoring... Unfortunately it doesn't go that smooth all the time, interruptions happens. One being too much load at work, but it's not the worst one, once workload drops I can return to OSDev.
But the worst ones are happening when I spend too much time in "pushing forward" stage, without switching to refactoring. Things becomes too tangled-up to comprehend, and this usually leads me into "complete stop". It takes a few months before I recover and take a look at my code again. And then I feel lucky if I can return to "refactoring stage", worse being when I feel it's time for "rewrite".
If you do not lose interest altogether, you will reach your goal eventually.
If something looks overcomplicated, most likely it is.