[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [fluid-dev] State of things

From: Kevin Fishburne
Subject: Re: [fluid-dev] State of things
Date: Wed, 27 Jan 2010 14:09:29 -0500
User-agent: Thunderbird (X11/20090817)

address@hidden wrote:
I would like to get back on the right foot with FluidSynth.  I find I often feel like I'm neglecting the project and then try to avoid thinking about it at all, to try and side step the unpleasant feeling there.  My intent is to change this.  After all its a volunteer effort and should be fun to work on! :)
Hi Josh, glad you're back and feeling better. Ironically my ten year "vacation" from computer obsession involved a lot of drinking and substance abuse, so now sitting in front of the computer half the day is comparatively healthy for me. What's interesting is the feeling you describe having about the project. When I was a teenager I would literally code so long into the night I had to stop from exhaustion, only to repeat the procedure again the next afternoon. Back then I was the old-school definition of a hacker and I just kinda winged it through complex projects without doing a lot of preparation or planning. After a few months of this I often would have painted myself in a corner. The project code would be so immense and convoluted that I was no longer able to comprehend it as a whole. Any time I'd try to work on it after that, whether fixing bugs, finishing features, or adding new features, I would get this odd feeling of dread. Even thinking about the project while away from the computer would fill me with that feeling. Ultimately the projects were abandoned and lost due to hardware failure and insufficient backups (tears...).

I don't know if your bad feeling is caused by the same reasons as mine or not, but if so I recommend a few general things that could help:
  1. Create a simple but complete document describing the program flow. Make sure the descriptions in the document actually match the modules/procedures/functions/whatever in the code, grouping several together if necessary. I don't know if a full blown flowchart is necessary, but even a simple linear outline with indentations could help.
  2. Decide based on that document whether that is the most logical way the program should flow. If not, create a draft document by rearranging and modifying the descriptions in the first document so the proposed program flow is more logical.
  3. If the program logic did need to be rearranged, do all the copying/pasting/modifying necessary to rearrange the actual code and test it to see if it still works as before.
  4. Clean up the code (formatting, procedure names, variable names) and comment it exhaustively so you can read through it faster.
At least in my mind, half of the coding logic's goal is to make it work and be efficient. The other half is making it sensible to human readers so it can be easily improved and maintained. My coding skills these days probably suck compared to yours so my suggestions may already have been implemented, but hearing about the feeling you were having worried me because it brought back my own memories of my old projects and how they ended up.

Kevin Fishburne
Eight Virtues
 (770) 853-6271

reply via email to

[Prev in Thread] Current Thread [Next in Thread]