On Finding A Project That You Love

In what little spare time I have, I have cycled through several projects looking for a side programming project to work on. Here are several of the reasons that I've used in the past to start a project. After listing them, I'll give you the main reason why they're all bogus:

• I want to learn <insert some in demand technology>
• This project is associated with a big name company ... maybe they'll notice my contributions.
• There are lots of companies using this technology. That would be a good one to learn.
• <Insert famous developer> says that learning about this topic will make me a better developer.
• This <insert subject>was interesting when I worked on it for a class in college. I could re-learn about it and maybe that will lead to a project I'm interested in.

The main problem with all of these reasons? There is no passion in any of them. When using these reasons (except for maybe the last one), the project is a means to an end. If something else comes up that keeps you busy for long enough to lose momentum on the project, you're not going to want to finish the project. You have no reason to.

Given this, how do you go about finding a project to work on?

Take some time to be honest with yourself and answer the following questions:


Who am I trying to please?

If you are working from the path that somebody else took to success or the list of things they put forward on how to run a successful project or become a successful developer, you'll only reach moderate success at best. Nobody can give you anything but their opinion on what you should do and how you should get there.

You must take some time to find something that is important to you. You'll learn what you need to learn in order to reach a goal that you care about.

What are my goals?

What do I care about? Here, for example, are some of the things that I have as goals for myself regardless of if they directly apply to software engineering:

• Become a better husband to my wife every day
• Become a better father to the children in our home every day, whether they're foster kids or, someday, our own
• Grow deeper in my faith every day
• Grow deeper in my understanding of the world around me every day
• Become a better singer
• Win an international gold medal in the Barbershop Harmony Society's chorus contest (here's the first concretely achievable goal)
• Gain the respect and admiration of the people in the communities I take part in (respect and admiration from your peers is a need everybody has, including myself. How important is this need to you? Although it is a need, are you letting it control you?)
• Improve upon a complex project in such a way that people can get more creative tasks done and spend less time on tasks that can be automated (ray tracers and compilers are of interest to me at the moment)

Am I willing to shift my focus if pursuing my goal reveals a worthier objective? 

Regardless of the reason that you start a project and whether there is passion there or not, be ok with a shift of focus. If you find yourself drifting off into some other part of the process of the project, take some time to consider whether the direction in which you're drifting will be useful to you and others.

As an example, drift on one project (pb_ray) has lead me into working with build tools such as cmake (to make it build on multiple OSes) and editing tools (vim, syntastic, etc). Some of these things even lead to topics to start this blog with. Eventually, I imagine that I'll get back to working on the original project.


In the long run, having a project or goal that you care about makes life much better. It gives you something to live for. Otherwise it is too easy to let life happen day by day becoming further chained to someone else's opinion, drifting on the waves of their changing whims. I will keep working every day to find what that goal is for me. 

Introducing Automated Testing to a Legacy Product and Team

Testing your product is critical to its success. But if you've got a legacy product that doesn't have any automated testing facilities and is eyeball deep in critical change requests, how do you go about testing it effectively?

How do you convince team members who've been reacting to "emergency" change requests for years that it is a good idea to take extra time to make the code more maintainable and cover it with tests? If they think this is a good idea but don't believe there is time to do so, what then?

Following are some of the general reasons why automated testing is a great idea. While each person that is resisting writing automated tests will take different evidence to convince, I hope that these can provide a good starting point.

Start with testing only the code you are actually changing for the change request. By doing this, we don't have to worry about taking the time to write tests for the entire program. Additionally it may help alleviate some of the "where do I even start?" blues that can be associated with facing such a monumental task.

Refactor the code being changed along "seams" as described by "Working Effectively With Legacy Code" by Michael Feathers. Look for places where sections of logic can be pulled into smaller, easier to test modules (functions, classes, etc). The process of doing this forces us to simplify the code as much as possible. Doing so will allow us to test it in a sane manner.

Set team expectations that testing can be ignored if the situation is truly an emergency (and define what an emergency is so that it is not defined by default as "any change request"). Setup the project configuration in the build system such that tests can be built or not built. This will allow the flexibility to not write tests if there is a rush on the change request. Given that the team is used to working without taking the time to add tests, some of the team members will appreciate this as well. It can be used to ease such team members into testing; allow them to make changes to the project while we build up enough of a test suite for them to see how effective it is.

Now, having suggested that an option for not writing tests be implemented, let me also suggest setting team expectations that demand tests be written and run for emergency fixes the next time the code is open for changes. The goal here is to make sure that the tests don't become broken or stale through several sets of "emergency" changes. This also helps make sure that you actually start writing tests instead of just declaring everything an emergency that doesn't need tests.

In order to write tests we have to understand the requirements of the code that is being changed. We have to understand what good input (or beginning conditions) are. We have to understand the output that this will produce. We have to understand what bad input is and what, if any, errors the code will produce. If we don't truly understand any of these things, even if we think we do, attempting to write a test will quickly make it blatantly apparent that we don't actually understand. Consequently the process of writing tests will help us to understand why we're changing what we are. This helps us to write code that does what was asked for the first time (as opposed to having to go through cycles of coding, failing QA for requirements issues, coding, failing QA, etc).

There are many other reasons (and ways) to write automated tests which can be found in a variety of books and blogs. There are also many tools that can help with many aspects of testing from mock generation to test generation. Please take some time to think about how automated testing testing can help your project. I promise that it will help you in the long run.

Why VIM + Syntastic? My editor has had syntax checking for years!

After my initial post on using Vim and Syntastic, I thought it would be a good idea to expound on *why* I'm using Vim. After all, there are numerous highly developed, great IDEs that have the same functionality plus lots more. (That being said, there are plugins that make those IDEs act like Vim: several plugins for Eclipse, ViEmu for Visual Studio)

First, Vim runs pretty much everywhere (vim for *nix, gVim for Windows, MacVim). The interface and commands are *consistent* between all of these locations. That means that whatever computer I'm logged into, I don't need to think about how to do something in the particular IDE that I'm using. Muscle memory takes over and I can focus on the content. Muscle memory does take practice to form, but it's worth it in any case and especially if switching environments is a necessity of what you're working on.

Vim's powerful commands and macros help me to edit text considerably faster I can when I only have the standard cut, copy, paste, and highlight commands available from the keyboard. Take a look at the explanation of how Vim evolved it's command syntax and the examples here (pardon some of the language). I'd explain some of the reasons, but why repeat information?

Vim is fast. It starts up almost instantaneously, especially when compared to larger IDEs with more functionality. It's commands and macros run quickly. This is another way in which Vim does not get in the way of my train of thought but allows me to continue working. When I've started up Eclipse in the past, I can go get a cup of coffee in the time it takes to start up. If I have to start it up or use any other functionality that takes a significant amount of time my train of thought will come to a screeching halt and it'll take a while to get back in the zone. (Yes, there are ways to get around these things, but that's not the point here)

Vim is open source, free, and extensible. That means that if something goes wrong with it, I can take a look under the hood myself and fix it (or write a plugin to do something I want to do). It also means there are many other users who are doing the same thing. Chances are that, if you're running into a problem, somebody else has too and might have found a solution. Additionally, I take pride in the fact that I've been able to help with a plugin, simple though the help might have been. I'd encourage you to pay with your time by contributing to vim itself or a plugin.


Are there cases in which Vim should NOT be used or in which it is not helpful?

Projects where IDEs are already used and the project setup files are static. It doesn't make sense to waste time trying to setup Vim to work with a project when all of it's settings (dependencies, paths, etc) are already setup in an IDE. However, as mentioned above, there are plugins that can be used with the IDEs to allow keyboard shortcut muscle memory to still help your productivity. That being said some projects can be setup to use multiple types of builders. If that's the case, you might be able to set it up in a way that is conducive to using Vim.

Vim's commands and macros are powerful, but  they only help when I know exactly what I need to edit. It does NOT help me to determine what and how to edit the source code. Figuring out the what, why, and how is, of course, the hard part of software engineering.

While I can work on Vim itself or a plugin, it means that I'm paying for Vim with my time. Depending on what I'm working on at the time, this may or may not be worth it. There is certainly something to be said for paying for a product, being able to call somebody responsible for said product, and getting them to fix the problems you've got while you continue your work.

Debugging is an inevitable chore when working on a program. IDEs with integrated debuggers can make this job a lot easier. Here is a StackOverflow answer suggesting several plugins that can do the trick for C/C++ with Vim. However, not having tried them and being used to Visual Studio's debugger, I'm marking this under a negative (if you've got other suggestions for other languages, please let me know).


All in all, Vim has helped my productivity a lot. What are your thoughts?

Vim and Syntastic

Since the days of writing everything from a "Hello World" app to a ray tracer in college, I've used the vim editor. Of late, I've had several projects touching apps that run on our Linux machines and, having read about the great power and extensibility of vim, it seemed like a great time to dig in and make myself more productive with it. (Here is a good argument for easing yourself into vim instead of diving headfirst into the hard stuff.)

Over the years, I had already started collecting a small set of settings for vim. I thought it'd be a great idea to make that set of settings public so that they might be of use to someone else (or so somebody can clue me in to a better way to do things). So here they are.

Of course, wanting to be more productive, I started hunting around the web for ideas on how to use vim better. In the process, I stumbled across this entry by Ian Langworth about how he uses vim and the plugins that he uses. Given that we had just turned on static analysis on some of our code, Syntastic stood out to me as a great idea.

               ,
              / \,,_  .'|
           ,{{| /}}}}/_.'            _____________________________________________
          }}}}` '{{'  '.            /                                             \
        {{{{{    _   ;, \          /            Ladies and Gentlemen,              \
     ,}}}}}}    /o`\  ` ;)        |                                                |
    {{{{{{   /           (        |                 this is ...                    |
    }}}}}}   |            \       |                                                |
   {{{{{{{{   \            \      |                                                |
   }}}}}}}}}   '.__      _  |     |    _____             __             __  _      |
   {{{{{{{{       /`._  (_\ /     |   / ___/__  ______  / /_____ ______/ /_(_)____ |
    }}}}}}'      |    //___/   --=:   \__ \/ / / / __ \/ __/ __ `/ ___/ __/ / ___/ |
jgs `{{{{`       |     '--'       |  ___/ / /_/ / / / / /_/ /_/ (__  ) /_/ / /__   |
     }}}`                         | /____/\__, /_/ /_/\__/\__,_/____/\__/_/\___/   |
                                  |      /____/                                    |
                                  |                                               /
                                   \_____________________________________________/

Simply saving the file I'm working on calls the appropriate compiler and instructs it to run a syntax check on the file. From there it visually highlights the lines with errors and, when the cursor is moved to that line, it displays the error at that line. Incidentally, it can also load the errors into the location list by running `:Errors`.

Of course, it took a little tweaking to get exactly right, for several reasons:

1. Using the compiler to compile a single C file doesn't make much sense if it's part of a larger project. You'll get a lot of errors that are non-sensical because the appropriate headers aren't loaded, among other things. Running make makes a lot more sense. I updated the make command called by make.vim (located in the c syntax checker folder) so that it would call the appropriate target with the syntax checking flag turned on.
2. We're using a different compiler than is assumed by Syntastic, so I came up with an appropriate error format that would parse the errors correctly. The discussion of this is here.

Syntastic is now providing me with immediate feedback to changes I make which is critically important to being productive. The sooner I find out something is wrong, the sooner I can fix it. Now, on to getting more done.

Easter and Community

Yesterday was Easter.

I am a Christian and, for me, it was the celebration of Christ's resurrection from the dead and the forgiveness of sins that His death and resurrection bought. I celebrated today with my family and friends at church and afterward at a party with a friend who chose to be baptized.

I don't say this to preach to any who reads this because I hope the way that I live would reflect my beliefs to those I come in contact with. In addition, beliefs are an intensely personal choice that each and every individual must wrestle with. I would be happy to talk to anybody one on one about my beliefs, but I will not do that in a public forum.

I say all of this because Easter and our celebration of it has reminded me of the importance of being a part of a loving community of close friends where you are fully known and where you fully know others. This community will be small because we cannot be fully known or know others fully when there are too many people to get to know.

In this sort of community, several important things can happen. Part of being fully known is that there are close friends who will know the things about yourself and the things you've done that you consider ugly and shameful. And they will love you anyway. They'll help you work through forgiving others for what you perceive they've done to you. And they'll help you forgive yourself for things that you feel that you've done. And you'll help them do the same.

Building relationships to the point where they are this close requires a lot of wisdom in who you reveal yourself to and a purposeful pursuing of those people. And once at this point, maintaining such a relationship is also hard work. It requires a willingness to be hurt by the people you care about and the courage to forgive and continue pursuing.

Obviously, not all of your friends can be this close. There will be a spectrum of how close they are to you, ranging from someone you share all with (this will likely be your spouse or significant other) to those who know your hopes, fears, and dreams but not everything.

I encourage all of you to be purposeful about seeking out a close community of friends. You could seek them out where you find yourself spending your time and energy, whether that be church, hobbies or work. It will feel slow in coming, but I'd be willing to be you'll find yourself healthier in the long run.

Hello World!

I've thought for quite a while about starting a blog and have finally decided to take the plunge.

I realize that, quoting from Jeff Atwood, that the following are true. Jeff was quoting from somebody else, but the link his blog appears to be dead.

• you have to want to write
• you have to believe you have something to say
• you have to have an interesting way of saying it

While I've never been a spectacular writer, I know that I can always improve. Increasing my ability as an effective communicator will allow me to understand the problems that I am solving for my users and lay out my suggested fixes more clearly and concisely than I do now. Given that this would definitely be a good thing, it's my reason for wanting to write.

I've also got ideas for topics ranging from project ideas that I've had (a ray tracer), side projects I've been distracted with along the way (vim stuff, a cmake tutorial, etc), foster care, to my hobbies (singing in the Masters of Harmony, playing games of all sorts, and programming).

As I continue to work on my projects, I'll endeavor to post here about them.