Getting Over The Initial Excitement Hump

So, you get a new idea for a project. It could be a game, a helpful desktop application, the next big iPhone application, etc... Your brain is working in overdrive with great ideas and you can't wait to start coding. This is normal, and it's great. No better feeling than fleshing out a brand new piece of software that you've come up with.

Chances are, you'll hop right into your IDE and start fleshing up some quick and dirty code to get the thing off the ground. You're probably too excited to bother with design documents and all of that boring stuff. This is fine to an extent, but before you get too deep into your quick proof of concept, you are going to have to make some formal outlines for your project if it is to be of any modest size.

Now that the boring stuff is done, (and unless you are working for a company or making a very large application, you shouldn't have had to spend too much time doing that boring stuff) you can get back to the exciting stuff: programming! At first, things are great. The excitement level is just as high, if not higher than it was at the outset of the idea. But sooner or later, something terrible happens. You lose that excitement and in turn you lose your motivation to work on the project anymore. So, what happened?

It is hard to say for certain, but it seems to be human nature, more specifically our tendency to prefer instant gratification, and who can blame us? We just came up with a new killer app, and we want to take the vision in our head and make it come to life. Such is the attraction to this field to begin with: making dreams and ideas into reality using our skills. However, this comes at a price.

Once you start getting deeper and deeper into your application, that buzz subsides and you are brought back down to Earth a bit when you have to go through all of the mundane tasks to convert your dream into snippets of source code. Of course, the scope of your project as well as the tools and methods you chose to use to create it will have a huge effect on these mundane tasks (converting between data types, proper design patterns, reusable code, GUI, etc...), but at the heart of the matter it is still the same issue: How do you get back that initial excitement after you drop off to the other side of the hump?

I'm not sure I have a good answer for that as I suffer from this situation myself in nearly every project that I start. I find that unless I complete something within a few days, this is almost certain to happen. One issue that plagues me is that I tend to have 3 or 4 of these "killer" ideas floating around at any single time, so once the initial buzz fades during the development of one idea, I go craving my excitement "fix" by starting one of the other ideas, and so the cycle continues. It is an easy trap to fall into for sure.

Income could certainly mitigate these effects. Professional developers encounter these same issues, and maybe more so because they are most likely developing someone else's idea, so that initial rush of excitement may never be there. However, it is their job, so they have no choice but to keep plugging away. On the other hand, if you are working on your own personal project in your free time and you have no financial stake in the application's completion, it can be much harder to get out of the rut. Sometimes just wanting that dream realized isn't enough, as I'm sure we've all come to find out all too many times.

I think the best solution I've found is balance. Although, there is a very fine line to walk. Initial surges are great, but we must take advantage of them and get as much done in those first few days or weeks as possible. Lay the ground work while your motivation is at its highest. Document your code extremely well, otherwise you'll lose time later trying to figure out what the hell you were doing when you revisit the project. That's where the balance comes in. Take breaks. Work on other projects for a few days, but always keep your main project fresh in your head. Ideally, your side projects should be very small pieces of software. Maybe proofs of concepts or something along those lines. It shouldn't be another full-fledged application. During these breaks though, keep your main project fresh in your head. Look over your source code once a day, revisit your design documents, add TODOs to the code if you happen to notice something, but don't add any actual code.

I believe these breaks will allow your mind to rest a bit and will prevent you from getting tired of a project. The side projects will keep your skills sharp as well as give you that initial buzz of excitement from working on something new, and hopefully this excitement can carry back over to your main project.

If anyone has something that works for them, please share. These are just some things I've found that help me.

Cheers.

Update: Daily Exercises

So, yesterday was the end of my first full week trying out my new routine of math, programming, and guitar each day. I felt it was a good introductory week to help me get used to the effort and time required to do such a thing, and I learned a lot about what changes I'll need to make in order to be successful with this process.

I stuck to my plan about 4 days out of the 7. It was a bit of a bad week to start this, as it fell over a holiday weekend, and 2 of the days in the 7 I had softball games (one of which I was injured in). Nonetheless, it was simply an introduction into what it would be like, and successful in that regard.

My guitar playing has improved dramatically. Not to say that I was bad, but I'm able to play some things now after only 7 days than I really ever imagined I'd be able to. As for programming, I found myself solving some complex problems of which recently I found rather stubborn. The Math was probably the hardest thing to sit down and do, and I failed in this department more than any other. However, when I did sit down and work some problems, each day they became easier.

I guess the main things I learned are:

• It's hard work to do a routine like this with 3 different things. Usually people have a focus on one thing, and that's easy.
• Tracking progress is essential. I didn't do any sort of that this past week and I don't feel like I can measure what I've accomplished in much of a concrete way. With guitar it's easier because I can set a goal to learn a song or a part of a song, and then do it. The other areas will require some structure.
• It works.

I'll update this again at some point, at the longest I'll wait until a full month, but I may update it before then. I encourage you to try this out, whether it's with 1 thing, 3 things, or as many as you think you can handle, although I wouldn't push it much past 3 or the point of diminishing returns will surely kick in unless you don't have any other daily responsibilities. I work 2 jobs, so it's a time management exercise as well to fit all this stuff in!

Good luck.

Something has to change

This encompasses more than just programming, but it's the best place for it to go and I didn't feel like creating a new blog section...

I have been pretty busy lately, or that is to say "I've always got a lot to do, but usually don't accomplish what I should due to lack of structure and being worn out."

So, in that light, I came up with a plan to improve my skills in the areas of which I require them: Programming, Math, and Music.

Every day I will do the following:

• Write code - I tend to do this anyways, but it's easy to do a lot of work for a 3 days and then take a day off. Nope, not anymore.
• Do Math - I'm not great at Math, but my shortcoming in it is only due to lack of general effort toward the subject. Each day I will work some Math problems, as I need to be ready for a placement test anyways, I also need to sharpen my skills and keep them sharp for my future career.
• Practice guitar - Practicing guitar is one of the most horrible things ever. Note I said "practice" and not "play". It's hard to force yourself to do exercises, but unless you do, you get into a rut and you never progress.

After one week of doing this, I'll post an update and let you know how it's worked out. All 3 of these areas are very closely related in terms of brain function, so while only doing one of them each day would greatly improve that area, doing all 3 should have a greater effect. The idea behind this is that you can't simply work on these things for 8 hours in one day, and then not do anything for the next 3. It's about the constant repetition of the activity day after day that will bring results. It improves memory, coordination, muscle memory, etc... I'll also make it a point to sit down and read something (other than e-mail...) each day. I don't particularly need help in this area, but reading often improves coordination (line skipping and such), concentration, vocabulary, and all sorts of other things worthy of improving.

I think not only will this routine improve the areas of which I'm targeting, but that it will also improve my overall productivity in life as I'll be on a more driven and focused path throughout my day, and I'll be more inclined to get something done rather than just chill out.

Until next time...

All I need to know I learned in... the library?

I was fortunate enough to attend a school for a year that had an amazing library. Not just for computer science, but for everything, from what I've heard. Clearly, since I'm a software guy, I only cared about their collection of computer science books, and they certainly didn't disappoint.

If you could find it on O'reilly, you could find it in this library. After I went there for the first time, I was hooked. Never in my life had I viewed going to the library as an exciting experience. I wanted to go to the library. I'd spend 90 minutes browsing the shelves.

Then, for reasons we won't go into, I transferred schools. I ended up at a pretty decent community college for a year while I was transitioning, and I was deeply saddened by what I found in that library. So, what's my point?

Those books are there for a reason, and they are free. Take advantage of them.

Computer science is one of only about a handful of professions that is pretty "take-home". Maybe that isn't true for everyone, but the vast majority of people in this line of work, namely programming, take their work home with them. It's not necessarily because they are work-a-holics, but simply because they love doing what they do. Their brains don't allow them to just "turn it off" and leave some programming issue for the office. They enjoy solving problems. Unfortunately, sometimes people's jobs depend on them taking their work home with them, but we won't get into that. In fact, this paragraph needs to be it's own entry, so I digress...

Basically what I'm saying is that you can't be the best programmer that you'd like to be by relying on your college courses to teach you what you need to know. I may not be done with school yet, but I'm not exactly naive on this matter. Your college classes teach you very little about what being a programmer means. In part, it's not their fault. They have to keep things at a general level to allow for a vast number of technologies that the students may have to work with. Still though, you have got to put in the work outside the class room. I don't think I need to belabor this point too much as if you've made it through at least 2.5 years of a CS/SE degree, you truly do love what you are doing. Also though, you will be expected to continue to learn when you graduate. You'll have to use a language at work that you may hate, or may not know at all. You'l have to learn API's you've never even heard of, etc... but you can't give that as an excuse to your boss. There will be some degree of toleration for your lack of experience in a particular area, of course, but when it comes down to it, if you want to keep your job and do well at it (which in-turn means you'll enjoy it a hell of a lot more), you've got to put some effort in "off the clock". I'm not saying you have to ssh in, vnc, whatever...and start writing your work code from home, but you will have to crack a book (or 5 as I find myself doing) and soak up some knowledge.

Take advantage of your schools library instead of taking it for granted. You'll be surprised how much you enjoy reading. Not a bad place to meet girls either, especially when you are carrying around fancy sounding programming books...

Why put a go-kart engine in a Camaro?

I was browsing some projects on Sourceforge yesterday and I came across a basic game of Checkers. I believe they were using GTK and maybe SDL as well. All of the source files were C++. Now, SDL works natively in C++, but as far as I know, you'd need to use GTKMM in order to write GTK code in C++. Nevertheless...

This person usesd absolutely NO features of C++ in his code. It was all straight-C. I really don't understand this at all. Why incur the extra overhead of the standard C++ libraries and then not use them? Secondly, why use C if you don't need to? When I say that, I'm referring to the need to do a lot of low-level memory manipulation, in-line assembly, and other things of the like. Of course, any of that stuff can be done in C++, but usually C is preferred. This application had none of that in it. It was just a bunch of structs, char*'s, and SDL/GTK library calls.

My stance on this particular instance is to just use C++ instead of simply changing the file extension to ".c". std::string is a lifesaver, and the C-style structs just get clumsy and very limited after a while, especially in a game. Those 2 things alone would have made the game more extensible, easier to maintain, and a lot easier to understand.

Just my two cents.

The Contract Job From Hell

It seemed easy enough. That's what I thought when I received an e-mail from the Computer Science chair at my University advertising a C++ programming opportunity involving a fairly simple API to interface with a radio receiver card. The details weren't great, so I replied and said that I'd like to get some more information. About 2 weeks later I heard a reply from the CS contact person. I was given the contact person for the job, the person actually doing the hiring. I shot off an e-mail asking a few preliminary questions such as the features he'd require, the time span, the pay, etc... The reply this time was fairly quick, and the job was sounding relatively do-able.

There were a few catches though. First, the programming would need to be done on a Windows computer and he would require some TCP communication with the data I'd be working with. I'd never programmed under Windows, and I'd certainly never done anything with Windows sockets. The other problem? They needed the entire project done in 3 weeks and they were only able to pay for 10 hours of work per-week at the University minimum wage of $5.50. Dealing with that insulting pay is one thing, but actually expecting someone to come in and write code for an arbitrary API in very little time is something completely different. On the other hand, I was a poor college student, and the actual programming didn't seem like it would be much of an issue at all so I figured I'd give it a shot.

I shot back an e-mail stating my concerns about completing the project in such a short amount of time, stating that it would probably require a number of hours that they weren't able to pay for in order to do it. About 2 weeks went by and I heard nothing. I assumed some other student had also responded to the e-mail and opted to sell their soul for $165. Then, 1 week before the original 3 week "deadline" I receive an e-mail from him saying that they can raise the hours to 15 per-week, but they need it done in 3 weeks (again). By this time, mid-terms are in full swing and I've got major programming projects for school to complete. I tell him flat out that I just don't have time now, but talk to me in May when school ends, I'll be available for the entire month. Again, I heard no reply from this message.

Fast forward an entire month. They inform me that they "finally have time to get the card programmed" and wanted to know if I was still available until June. I thought long and hard about this. I had just finished a demanding year of school, and 2 very advanced programming projects. I was burned out. I needed a break. I also needed money. By my math I'd make around $300. I took a deep breath and sent off an e-mail stating that yes, I was available until June. As was par for the course, it took him a week to reply to me. Just how important is it to get this thing done?! Honestly, their deadlines came and went as I waited around for e-mail replies from this guy.

Anyways, we got everything arranged and I met with him to pick up the equipment. This consisted of a really old piece of junk computer (the card used an ISA slot), a matching really old piece of junk monitor, and 2 antennas (high and low frequencies). Being of rational mind, I decided I'd do all of the core programming on my Linux box, use boost for the TCP communication, and then move over to my high-end Windows XP machine to add in the API-specific code. I wanted no part of using the computer they gave me for anything more than trying out the final code. I encountered a pretty serious problem right off the bat: The card had 2 inputs, a BNC and a SMA. The problem? Both antennas had BNC connectors. The project description as given would not be possible with this setup as both antennas needed to be used at once. I sent off another e-mail informing him of the issue and he promptly replied asking ME what he needed to buy, and to let him know and he'd get it. Reality check: I'm a programmer. I don't know anything about this stuff! I was brought in to write code that performs the task at hand. Troubleshooting BNC/SMA antenna connectors doesn't really fit in there anywhere. Nonetheless, I did a quick Google search and located 2 links that offered some adapters. I sent them to him and told him he needed to check into the matter further, and to let me know when he had acquired them.

One week goes by. Two weeks go by. I send him a status update on the project, pose a few other questions to him regarding his desired requirements. A third week goes by. A month goes by. At this point I'm convinced he's at the bottom of a lake somewhere. I see no other reason to ignore e-mails that only serve to accomplish a task that he needs completed. I keep chugging away at the code, making my own decisions about the questions I'd posed to him. I got to a point in which I was ready to test the code on the old crappy machine. I shit you not, the video card would not kick in. That's right, I'm given improper equipment, the contractor goes "Amelia Earhart" on me as soon as I get started, and the computer I'm supposed to develop for doesn't even WORK!

I send out a 3rd e-mail stating that I've finished the code as much as possible, and that I can't test the API-specific code due to the computer not working. I finally get a response stating that he was finishing up a trip in New York and that he'd be in town in a few days. At that point we were to meet and try to get another video card working. A few more days went by, and finally, we were set to meet. 9am, Thursday.

I arrive at about 10 till 9 and head upstairs where we met the first time. He works in a musical instruction type of building. Due to all of the expensive equipment, you can only access part of the second floor, the rest is locked off by 2 doors at opposite sides of a winding hallway. My process for handling this in the past was to knock at one door, wait, walk to the other end and knock, wait, then repeat. With each trip, my knocks get louder and louder. Now, you may be shocked as I was, but it was 9:30am and he STILL WASN'T THERE. I really should have known. Being relatively amused by the whole situation, I decided I'd get creative.

As I said, I was in a musical instruction building. This meant there were practice rooms all along the hallway, wide open. With pianos in them. There was never anyone on this floor of the building, either. I figured what better way to get someones attention in another part of the building than to start playing piano? So, I did just that. I sat down, and I just played. My basic line of thinking was that anyone that would be important enough to notice me playing piano and arrive to yell at me would also be important enough to have keys to unlock the door I needed to get into. I gave up after 5 minutes and decided to just leave. As I walked out the front door, I see the contractor walking up the sidewalk. Just a simple "Hi how are you?". I spent the rest of the day explaining all of the code and documentation to him, and never once did he mention being nearly an hour late.

The job is done now, and I feel very relived, to say the least. I accomplished a lot, I learned a lot, and I ended up making close to $500. Despite everything, I made sure that I wrote the best code I could, and gave the most informative and helpful documentation possible. At the end of the day, I even like the guy, he's very intelligent, and I'd be "more than happy" to do some future development on this project for him. Of course, if he reads this, he'll immediately know it's about him, but I suppose that's fine. He got the best $500 custom software package imaginable.

Attention: This is only a warning.

I tend to be pretty lazy when it comes to compiling my code. After I'm done knocking out the source, I want to make sure it compiles right away, and start testing it. However, taking the 10 seconds to add warning flags to the compile command could save me, and you, countless headaches trying to track down a bug that the compiler would have been able to point out right away if given the proper flags. The following example, unfortunately, is immune to compiler warnings, but it illustrates a basic error that compiler warnings would try to prevent you from making.

I was writing an application that dealt with unsigned integers throughout the entire program. At some point, I needed to convert those unsigned integer values into std::strings via a helper-function that I created. The values were read in via a binary file, and stored in unsigned integers. The deadline was approaching, and I didn't think about what would happen if there was a negative value in the binary file (perfectly legal, though) The result? The compiler silently converted the int that I retrieved from file to the unsigned int it was being stored in, thus mangling the sign value on my data. Luckily for me, I had been programming on a daily basis for many hours for about the past 5 days, so my brain was warmed up and I caught the error rather quickly. However, it isn't hard to imagine how something as minute as this could remain hidden for a long time, delaying the completion of your project, and driving you farther into insanity. Again, this particular mishap is unfortunately immune to warnings, but from this you can see how something of this sort could be avoided by enabling proper warnings.

There are many other error flags, please check the docs for your compiler to see what they are, but it should be a goal to not only use these flags at all times, but also to have your code compile with the strictest of warning flags in use. If you are receiving a compiler warning, there is a good bet you have a problem with your design, implementation, or maybe both. The above scenario would really be classified as design/implementation, depending on how you look at it, but really it was just a case of carelessness.

Enable compiler warnings with the needed flags. Get rid of them with better code.

Down Periscope

Hello. You've somehow stumbled upon my programming weblog. In this area, I hope to share with you various experiences I've had writing software. For this introductory post, I'll turn you on to something I was shown yesterday evening. I was so shocked/amazed/excited when I was shown this "trick" that I exclaimed aloud numerous times...

The issue I was having in my code involved objects being duplicated (copied) as I stored them in a std::vector. Oh, by the way, I code almost entirely in C++. Anyways, the way this bit of code worked was that a line was read from file, and that line was then used to construct an object of my type. From there, those objects were added to the vector. The problem was, those original objects stuck around, so I'd have TWICE as many objects in existence than I was actually using! I asked for some assistance on IRC and I must say, my life has never been the same.

The "Trick"

Maybe I've just been living under a rock, but I had never seen this before. Apparently, you can arbitrarily create scopes anywhere in your code! I'll demonstrate it below with a basic example:



Output
$ ./scope
ctor
dtor
Only 1 Foo object exists at this point, good!
dtor

Now, instead of having 2 copies of foo in existence (the one I create, and the one that gets copied into foos), I only have the one inside of foos. Depending on your situation, this is preferable because if you need to add an object to a vector, chances are good that you'll be referencing it from within the vector for the rest of the program.

Hopefully you learned something from this, stay tuned, I'll soon be posting a very amusing and interesting story about my recent job as a contract software developer. Take care.