Green Moon Software, LLC

Professional Insurance

DISCLAIMER: I am not am employee of nor did ask that I write a review. I am merely a very satisfied customer.

I recently quit my day job to work full-time as an independent contractor. One of the hurdles of going alone is purchasing insurance for a business. I am required to carry Commercial Liability insurance and Professional Liability insurance including Errors and Omissions (often abbreviated as “E&O”).

I started with the insurance company that I use for my home and auto. The application was long and confusing. After I submitted it, I had to wait 6 business days to hear the bad news. They were unable to cover me. I must have answered some of the questions incorrectly. I recently moved and have not found a local agent. Therefore, it was difficult to ask my agent questions regarding the application. I am mostly to blame for that.

I now had 2 weeks to scramble and find insurance prior to the start date of my new contract. I immediately setup meetings with two local agents. I feared that the underwriting process would take too long and I would not be insured by the start date.

I learned about from a fellow contractor less than one week prior to my start date. I had not heard back from either of the two local agents so I was really stressed and worried.

I filled out the online application form that night. It was straightforward and easy to understand. Their website says that they are often able to give real-time quotes. However, they were not able to for me. The following morning, I received an email with quotes from several reputable insurance companies. I was also assigned a licensed agent to work with me through the process.

The quotes given to me from were effective immediately. No more waiting 6-8 business days for underwriting. I was relieved to know that I would have insurance for my first day. Not only that, the quotes were good rates. The E&O insurance is half what a fellow contractor is paying. However, one of the local agents had a lower quote on the Commercial Liability. I mix and matched the plans and came out with a great annual premium for all of the insurance required.

I am very impressed with The assigned agent, the quick quote process, and the easy purchase experience is what made it great. I would highly recommend them to any professional that needs commercial and professional liability insurance.

Let's Talk About Salaries

In my career, I have always disliked talking about salaries. I hated salary negotiations. I have never asked for a raise. I had never told anyone my actual salary besides close family, HR, or recruiting managers. Why is that and has it hurt me?

Let’s be honest. Software developers typically make a pretty decent living. Three years ago, my wife quit her day job to stay home with our kids. I have made enough to provide for my family with my sole income. I feel like I have been compensated well enough. So what is the purpose of this post?
I would love to remove the taboo that exists around salary discussions. Who benefits from keeping salary information scarce? The employers. I have seen some contracts and NDAs that explicitly disallow employees from discussing current salaries and bill rates. If developers do not talk to one another, the employer has a lot more leeway to steamroll naive or timid developers (like myself).

I would love for every developer to have the confidence to know what their skills are worth while negotiating a salary increase. There are websites like that attempt to provide a range. However, these are often off or give a wide range of salaries.

So what are some options for determining how much you are worth as a developer?
As previously mentioned, you could try using online salary range calculators. You could job hop and find what other companies are paying. Or you could simply ask your fellow developers.

For me, I am no longer going to be timid when it comes to compensation discussions. I will have asked my fellow developers, I will have done my research, and I will come prepared to any future negotiations. I hope you are open to the discussions.

Some Thoughts on Pair Programming

Two programmers, one computer. To management, it sounds like waste. To agile mentors, it sounds like the answer. What does it sound like to developers? The answer (as with most things) is “depends”.

I have only been pair programming for a little over a year. Prior to that, the majority of my career has been spent alone in a cube or office.
In 2001 when I started in my first job, we did something like pair programming. Obviously, it was not called that at the time. It also did not look like today’s pair programming. It consisted of me sitting next to a more senior developer while s/he wrote code. I would help dictate requirements and help transpose. It was still two eyes on one screen. This style of work helped me get learn the system, but it didn’t really help me learn to program.

Fast-forward to today. I am in a position that pairs 100% of the time. We switch pairs after every 2 week iteration. One developer usually takes the keyboard in the morning, and the other takes over in the afternoon. We sit at large tables with a single monitor between us. We each have our own laptops and simply switch the video cable for the monitor. This allows us to setup our own computer to suit our unique needs (ie: plugins, keybindings, etc). It also allows us the ability to turn away and check emails or text messages on occasion.

After working in this environment, I have seen how well it works to get new hires integrated with the software. I have seen how it helps fresh graduates start learning the “right way”1. I think about all of the missed opportunities from my past career with regret.

In addition to the two benefits described above, it is also beneficial on new features or working around critical components. Two sets of eyes are better than one.

However, pair programming is not a silver bullet. I feel it does not work for every company or situation. Production support is one such situation. Often times tracking down bugs is a hunting mission. Lots of different paths have to be explored to find the bug. Pairing will only get in the way here.

Simple feature enhancements usually do not require a pair. These features are fairly simple and straight-forward. They do not touch critical components. Pairing on these types of features is a waste of time.

In conclusion, I am not advocating NOT pair programming. I advocate to use it in the correct situations and not just simply applied as a constant practice. I highly recommend doing pull requests prior to integrating any code into the main branch. This will allow a second set of eyes to review code. I also highly recommend writing tests. In my opinion, these add up to more quality than 100% pair programming.

1 Obviously, there is no one “right way” for everything. But there is usually a lot of predisposed teaching that needs to be undone to most fresh graduates.

Asynchronous Functional Testing

I previously wrote about writing sql tests. Another difficult-to-test scenario are asynchronous processes. If a method-under-test has threading, getting the timing right for the testcase asserts is difficult. Typically, the method will return control to the test class prior to competing the logic that is being tested. The test class then immediately starts processing the asserts. These tests are flaky at best or completely broken at worst.

One way to avoid testing asynchronous scenarios is to simply test the units individually. I am going to take a moment to discuss my view on unit tests.

I am personally not against small unit tests, but my view of them is different than some developers. For me, automated tests are about boosting my confidence in the codebase. However, unit tests are only a small percentage of that confidence. I have encountered many, many bugs in code that was thoroughly unit tested. In my experience, a large number of bugs appear in the communication between the individual units. I usually find there are not enough “integration” or “functional” tests. I personally prefer testing my application at the interface-level; not the implementation. Unit tests that rely heavily on mocks or other tricks are a big concern for me.

So with that in mind, let’s discuss how a technique to test asynchronous process. Please review the following code.

This is a simple use case, but is easy to understand. The method under test accepts a string and a callback function. The threaded logic simply uppers the string and calls the callback with the new value. The Thread.sleep(500) simulates a process taking a little time to complete.

The result of running the above is as follows:

Try running that in GroovyConsole. If you were to comment on the Thread.start{}, the assert would pass and “Success” would print. That’s great, but we need it to pass in a multi-threaded implementation. We can take care of that with a little test helper. Review the AsyncAssert class in the following example.

The run method in AsyncAssert executes the asserts and catches all exceptions. It checks if the timeout has lapsed in the exception handler. If not, then the asserts are ran again. If the timeout has passed, it will throw the exception (typically an AssertionException of some sort). If the asserts pass without an exception, the loop breaks out and the test passes.

So yes, asynchrouns tests will run a little slower than your typical unit tests. For me, the piece of mind that the process works is worth a couple extra seconds. How do some of you test your asynchronous processes? Let me know in the comments.

Sometimes You've Just Got to be Negative

I like writing tests. I think that is a well known fact. I even write tests for most of my “pet” projects. However, some of the most difficult tests to write are those querying data. The “get” repository functions or the “findBy” functions. Why are these functions so difficult to fully test? Because there are so many different permutations.

Let’s start with a simple example. A findPersonByName(String firstName, String lastName) method. The SQL for this method would seem straightforward.

Obviously I will want to test this with a live database. So I will need to setup test data.

Then execute my method and verify it returned the row. “What’s so hard about that?” you might ask. My test data did not exercise the query. The same test method would pass if the SQL was written as so.

Why is that? Because there was not any negative data. There was only one record, so of course it would return the expected record. A more complete set of data would look like this.

Now there is negative data in the table that the original query should exclude. Notice I buried the expected record in the middle of the data. This helps guard against database ordering. If the expected record was inserted first, then the bogus “limit 1″ query could potentially still pass.

Now, what happens if the findPersonByName(String, String) method should allow for wildcard searches? The sound you just heard was an unhandled exception in your brain. And this is for a simple “find” method with 2 parameters. Think about how many “find” methods you have in your codebase with how many different parameters.

I often find it very difficult to anticipate and produce all of the negative data. I simply try to cover as many as I can. Please comment if you find any cases that I should have covered.