Our Foray Into Foster Care

My wife and I have had a long term dream of being foster parents. This dream was born from the desire to provide a home for children who are in a hard place, to help those children through whatever situation they're in, to heal them, and to help heal their families.

Following is the process we went through to become foster parents and how we received our first foster child. I realize that this post stops at a point in time about a year ago, but I wanted to get it out there. I've got a further post (or posts) in the works about what it was like having a foster child, about receiving a sibling, and about seeing them go home that I'll share when they're done.

Process of Becoming a Foster Parent

We started the process of becoming foster parents by looking into the differences between going through a foster agency and going through the county. The Department of Children and Family Services (DCFS or "the county") is the governmental organization in LA that handles all of the cases for foster children. They are the first line of defense when dealing with these children. Stereotypically, the social workers working for DCFS are burdened with too many cases, are overworked, and because of these things can't give each case the full attention that it needs. (Please note that I don't say this to bash county social workers at all. This is simply the stereotype that I've heard propagated and, to some level, experienced.)

Foster agencies exist to help extend the support, services, and attention these children  This is a wonderful thing, but in order to be able to operate on a day to day basis they take a significant cut of the monthly stipend given to foster parents from DCFS. We decided that we want to be able to provide the best care possible for the children regardless of how much or little money we'd be getting (it would never be enough to provide fully for the kids anyway). Because of this we decided to go with a foster agency so that we'd have access to the extra support that they can provide.

Once we had decided on working with an agency, it came down to choosing an agency to work with. We received several recommendations for Five Acres. Given how long they've been running as an organization and that their mission aligns with our goals of providing care for the whole person (emotional as well as physical) and permanency (reunifying with the biological family if it makes sense, otherwise finding a good fitting permanent home asap), we decided to go through them. In addition they've got a group home and offices in close proximity to our home which provide meeting space for family and therapy visits.

There were things that we expected to have to do to prepare ourselves to be foster parents. Things like going through some sort of training and child proofing the house. Five Acres requires that parents get a certain number of hours of training per year to become and to maintain their status as foster parents. They provided a Sat/Sun course over several weekends that allowed us to meet the requirement. From there, although there were a couple items that caught us by surprise with our house, we were able to get it setup and approved rather quickly. (By quickly I mean 3 months from when we "officially" started going through the process. We had finished up a lot of stuff beforehand since we'd heard how stringent some of the house rules could be.)

The thing that I personally did not expect was the interview with the social worker. Going into foster care, I knew that the children that we'd be dealing would have been through experiences that I wouldn't wish on my worst enemy. The social worker reminded me of this and said that we needed to explore in detail any traumas that I had personally been through in my life. When I asked why, she gave me a response I'll never forget:

These kids will have triggers around the issues stemming from their traumas. As foster parents, you MUST know what your traumas and triggers are so that, when a child reacts out of place of hurt, you won't allow yourselves to be triggered and respond in a way that will further hurt the child. If we can avoid placing a child in your home that has the same triggers you do, we will.

This conversation lasted for quite a while with my wife and I individually, moving through all of the parts of our lives. After these discussions and fixing a last few items at our house, we were certified as foster parents!

Meeting the Need We Expected

While we were preparing our hearts and home, we discussed whether we'd prefer to take care of a child in any specific age group. As is typical, my wife had more experience with children than I. Because my experience was lacking a bit, we decided that starting where every other new parent starts would be a good idea. We found out after finishing our training that there was, at that time, a great need for families to take in infants. By the time we were actually certified, we'd been told this so many times we were convinced that we would get a call that very day. While it wasn't that day, it didn't take long for us to get the call that the was a baby boy who needed a home.

Later that night, the county social worker knocked on our door and then walked in to our living room with a handsome baby boy in his car seat. We went through the paperwork and, while we were doing so, the little guy stared up at our dining room lamp from his car seat enamored by all of the colors. Then she asked us to pull him out of the car seat.

I imagine that the nervousness I felt was similar in nature to what first time fathers feel when taking their baby home for the first time. Plus a little, maybe, since he wasn't my child but was mine to take care of. My wife pulled him out of his car seat and held him for a bit .... then handed him to me. What a feeling to have such a small life in your arms!

Creating Work From Your Passion ... or Finding Passion in Your Work

Recently I wrote an entry about finding what you're passionate about to help determine what projects you might want to work on during your time off. In the past few days, I've read a few blog entries that not so gently reminded me that if you want to take your passion and make it your bill paying work instead of your hobby, it will only work if your passion includes or can withstand the nasty, smelly, ugly side of running a business to make money. (Note that this is totally doable, but it's best to go into the business eyes wide open to some of these items)

These posts reminded me that leaving your passions as hobbies so that you enjoy them as such is a perfectly valid choice. If this is the route you take, make sure to find *something* that is part of your current work that you can take joy in. This will help bring several ways:

1. You'll be happier/more joyful during your work hours. This will help you be a more productive employee since you'll have something you enjoy while you're there.
2. Your passion can stay your passion. You'll have more enjoyment of it while you're doing it since you're not depending on it to pay your rent.
3. Finding something to take joy in can be hard. Look anyway.

Here is Matt Linderman from 37Signals describing this idea:

"Find meaning in what you’re doing. Work to improve your industry. Get joy from making a customer’s day. Surround yourself with the kinds of people and environment that keep you engaged. Figure out the details and day-to-day process that keep you stimulated. Focus on how you execute and making continual improvements. Get off on how you sell, not what you sell."

In my list of priorities that I laid out in my previous post on this topic, I listed a lot of things that are not work related. Some of these include my wonderful wife, our awesome kids, my faith, and singing in a barbershop chorus. These are the really important things to me outside of work. Sure, I'd love to work on a famous project and/or for a big company, but is it important enough for me to take the time away from these other priorities to do so?

Should I realign my priorities? I'm not particularly inclined to at the moment because I love my wife and our kids, spending time with them, and taking care of them. Apart from that, singing brings great joy and has been a wonderful way to spend my personal time away from my family.

This does not mean that I'll abandon pb_ray or my vimrc repository. I will continue working on them as I get the opportunity. I'll also continue practicing my craft so that I get better. I just haven't yet found that project that is special enough to be a passion for me.

In the mean time, I plan to do my best at going through the 6 steps at the end of Amy Hoy's post on the subject. In other words, to steal her punch line, to practice open eyed passion instead of blindly following my passion.

Any suggestions, of course, are welcome. As is debate with anything said above.

pb_ray: A Ray Tracer Based On pbrt

One of my projects on github is pb_ray. It's my implementation of pbrt from version 1 of Physically Based Rendering: From Theory to Implementation. I'm using version 1 since I can read that version of the book on Safari Books Online and version 2 isn't there at this point. I'd happily read version 2 but, compared to the price of the Safari Books Online subscription (free for me from my company), it's very expensive.

Edit: I checked Safari Books Online this morning and it looks like the 2nd Edition of Physically Based Rendering has shown up. Given that, I've just added it to my favorites list there and will start taking a look through it. Thanks guys!

I'm pretty sure that my version of the code is still in line with what Matt Phar and Greg Humphreys have since I checked in on their code base in github to get some clues for some specific questions, but it's great to see the second version of the book available.

As I've mentioned in a previous post, passion is necessary to a project to get it done in a reasonable amount of time. Which is exactly why this project is taking so long. It's become a playground for technologies that I want to learn at my leisure.

Here are some of the things I've focused on:

1. Building in multiple environments.
1. Why? Because I'm lazy and want to be able to use Macbook Pro on the couch when I don't want to be tied to my Windows desktop. The fact that anybody can pick it up and configure as needed with a single command is also a benefit.
2. Because learning to use CMake may come in handy on a future project.
2. Unit Testing
1. While I can't follow TDD with this project to flesh out what the code is supposed to do since the book has broken down the tasks into code already, I hope for a couple things. First that, if there is anything in the code that could be written in a clearer, cleaner, more testable way I'll find it. And second that it might be useful to the actual PBRT project.
3. Vi Plugins
1. This project gave me an excuse to play with Syntastic.
2. I will likely start taking a look at adding YouCompleteMe to my vimrc repository next.

Why did I pick ray tracing? Simply because it's interesting. It was one of my favorite projects in college.

Additionally, the idea of being able to take a piece of hardware and figure out how to harness its power then tax it to the limit in service of something productive has always interested me. Ray tracing is not only computationally expensive but generates a visually pleasing result (if your input is good, of course).

The idea of pushing hardware to its limits also encompasses finding out how far I can push those limits. It's a challenge to myself to find the biggest time consumer in the run of a program then to see if I can make that part run faster. (Ok, so I know that there are a TON of people who are way smarter than I am who are also doing this and getting paid for it, but it's an interesting challenge for me)

Lastly, I'd like to learn how to make the ray tracer runable on a GPU. This has been done before, of course, but I'd like to learn how it's done. Just from a quick Google search on the subject, here is NVIDIAs page showing their work on this subject and several different renderers using their work. Doing this falls under the idea of marshaling all of the available resources to name a project run more quickly. If there's a GPU sitting on the computer idle while the CPU is crunching away at something, it might as well be used to help.

Utter Ridiculousness in the Visa Process

I recently read the following letter to the president regarding a Jordanian citizen who, having spent several years in the US studying for a PhD, was denied re-entry after getting married in his home country. He was, according to the author:

1. A model student who excelled at his studies which some $200,000 of taxpayer money was spent on.
2. Had a great job lined up that would've brought lots of benefits back to local and federal government.
3. Was a great ambassador for the Muslim faith, showing by example what the faith represents at its best.

I'm sure that there are details regarding the denial of re-entry that neither I nor the professor at Johns Hopkins University are privy to. That being said, this seems utterly ridiculous given the information that I do have. Why would we want to keep somebody who seems to be the best possible representative of another country and culture out of our country? Especially when they're poised to contribute so well to society and to a successful company?

I suppose that I'll never get the whole story and so, at this point, I'm left with praying that:

1. There was no injustice from anybody involved in the process.
2. If there was that it would be rooted out and the people punished as appropriate.
3. That the officials involved would realize that this is ridiculous and grant Omar a visa if he is still willing to come to the States.
4. That he would have the grace to not hold this silliness against the country and it's people as a whole.

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.