NewThistle LLC Turns One Year Old

NewThistle LLC is a year old at the end of September!

I just renewed NewThistle's business license and took a look at it's first year.

Here is a breakdown of my Revenue sources. As you can see, I am making the majority of NewThistle's revenue via App Dev Contracts.

To be honest, a huge push to start the company was the first contract I received. It was that contract that pushed me over the edge to start NewThistle and put more effort into app development.

For App Sales, I can say that Selfie Band, my Microsoft Band camera remote for iPhone, is my 2nd best selling app to date. It has only been in the AppStore since August 6th but it has been having steady, if not high, sales.

For NewThistle's first year, I am pretty happy with the results. I have achieved my initial goals to start a company that is profitable and which could bootstrap it's own growth. I had to start by giving the company a loan to get setup.

I then took a big contract first thing and sink a lot of after hours time into for 6 weeks.

With the close of that first contract I had made back the money I loaned the company to purchase new equipment and various web services (website hosting, domain, email). So, 90 days after I closed my first contract NewThistle LLC became profitable.

Since then, I have been trying to run a tight ship. I have decided not to purchase the new iPhone 6s+ since I can get by with the iPhone 6+ until I have a need to get the new phone or I can wait until the iPhone 7. I am on the fence about the iPad Pro but will likely stay away from it unless I have a business need to develop for it. The Apple TV I have app ideas for so that is something I plan to purchase for development purposes.

A big goal with the company has been to have it not cost my family money (though it sure eats up a lot of my time). In the money respect, the company is doing well and has cash in the bank to continue to pay business expenses.

For the coming year, here are my goals:

• Increase the share of revenue from App Sales.
• Two apps in the works and more planned.
• Introduce another source of revenue besides App Sales and Contracting.
• Continue to be self funding and not require outside financing.

Here's to the next year of NewThistle LLC.

DerivedData and xcodebuild

If you use Xcode you know about DerivedData. If you don't know DerivedData, you don't know Xcode.

If you are setting up xcodebuilds from the command line, say for continuous build and integration (CI), then you want to make sure you are using that command line the best way possible. Some things I keep running into as I see people's build systems are:

• Running out of space due to a backup of old DerivedData.
• Build performance hanging, due to a backup of old DerivedData.
• Unexplainable build failure, solved by deleting, you guessed it, DerivedData.

If you use the command line for builds then save yourself a lot of trouble in the future. Start using the xcodebuild option -derivedDataPath.

Here are the docs on it:

-derivedDataPath PATH                     specifies the directory where build products and other derived data will go

That one option huge significance. Here are some reasons why I use it and convert build systems over to this option:

• I can store the DerivedData in the temporary source workspace of automated builds (like CI builds, automated test runs, etc.) When the workspace is cleaned up the DerivedData goes away and net disk space should be 0 at the end of the build.
• With no shared DerivedData between builds the build performance does not drop due to large DerivedData folders.
• Without a shared DerivedData folder I see much lower instances of unexplainable build errors. This means less cleanup, less build host reboots, etc.

Personally, I am very interested in how remote builds with Mac OS X Server and Xcode have improve the build process for automated builds. Until I get the chance to put such a system together, for now and for legacy build systems, I will use xcodebuild -derivedData to improve build systems I have to work with.

Writing a Software Development Agreement

Now that the word has gotten out that I am contracting, I have had interest from friends and associates in doing "small" apps (iOS and web) for them. That's cool but I know very little about running a business and writing software for others is a business.

Currently I am contracting through a large contracting firm and so I have not had to deal with writing contracts or the business side of contracting. With the number of enquires I have fielded, I figured it was time I drafted a Software Development Agreement template that I can use for projects I consider taking on myself.

Being a developer for many years, I know that Software Development is hard. What do I mean? I mean that turning an idea into a finished product is hard. Delivering something that matches the original concept is hard, but we can make it easier. We make it easier by capturing requirements, agreeing on a process for change requests, and iterating on the design with frequent check-ins with the client to verify we are on track with the vision (the Agile way).

That said, business is business and I need something in writing that a client and I can use as our guide for how to deal with delivery, changes, intellectual property rights, compensation, and the other details we as developers seldom think of.

So, I did a few searches and here are some links I used as a guide.

• https://www.pandadoc.com/software-development-agreement
• Open Source Legal Documents for Developers
• And I found this after working on my version: Mobile Application Development Contract 

I took what I liked from each and dropped some stuff I was not in favour of. I am not truly happy with this format yet, I would like to write something a little more free flowing but this is a good start.

Take a look at my Software Development Agreement and see what you think. Also, remember, if you have been reading along here, I am not a lawyer, nor do I play one in real life or on TV. So, talk to a real lawyer if you want real contract advice.

Anything I should drop?

Anything you think is missing?

-- Mark

Is Contracting For You?

I have not answered that myself and as such I am asking myself that question. I certainly like the fact I am working on new things and getting to branch out into areas I might not normally get a chance to work with. That said, there are some downsides as well.

At first you are going to see that hourly rate and say, wow that is a lot per hour. Hold on there though. Most likely that rate does not include paid holidays or vacation time. So you need to take your salary/year based on 40 hour work week (if your contract is 40hr/week) and then minus the vacation time you'd like to have and the holidays you won't get paid for. Check up front to find out if you can work holidays. If you can't, each of those days off is 8 hours of pay you are missing.

That adds up to make your hourly rate start to not look so good.

The other thing to consider about your rate and contracting is are you going to go with a firm (I have) which makes finding contracts easy but eats into your rate. Meaning, that the contracting company is taking a cut of the rate per hour you are being paid. Now, you don't see that taken out of your pay cheque, but needless to say, if you want to do the harder path and run the business side of things then you can make more contracting on your own.

Also, do you want to gain ownership of something and make decisions about the design and direction of the product? Then contracting, unless it is an architectural position, may not be your thing. So far I have seen that contractors in general are paid to get stuff built. That is great if you don't want to have ownership and just like doing new things each day. Not so cool if you like to have a say in the product and help design what you ship.

I am still out on this one. There is certainly an advantage to just being a grunt, getting stuff done. It is amazing to see the amount of code/progress you can make each week just implementing and not planning. That said, it's nice to have some more skin in the game with the design of a product.

Some other things to keep in mind is that you (most likely) will not get matching contributions for retirement or other benefits. That is fine if you are getting paid a high enough rate. If not, then you are missing another chunk of cash.

Contracting has the allure of new projects, less maintenance of products, and the ability to make more hourly. The truth is that the new projects and less maintenance of long term code comes at the price of ownership in the product. The high hourly rate hides the visible benefits of full time positions that you might not consider.

So, like many things in life, it all comes downs to tradeoffs. Which ones are you willing to make and what do you want out of your job.

The Illusion of Expertise

Replacing a section of my front
step. Definitely not my area
of expertise.

How much time does it take to become an expert with a new thing?

Let's pick a language.

I mentored a Junior Engineer on a work term who did some Perl development for our project. He then applied to work with us full-time when he graduated. Hey, I must have done something right to have him want to come back.

When reviewing his resume he had listed Expert Perl Knowledge or some such phrase. He wrote 2 scripts for us based off of scripts I had written. I asked him in the interview if he had done more with Perl after we introduced him to it. Nope.

Expert level knowledge? Sheesh!

As a professional developer I get asked to solved problems I have no idea how to solve every day. It's par for the job.

This is no different than many jobs I am sure. I know I have asked building contractors to build or fix something that they've never built or fixed before. So as a professional your expertise comes from being able to tackle these problems without fear. I am paying them for their past experience and ability to successfully deliver; same goes for being a software developer.

What do I mean by without fear?

I have worked with people that say they can't do something since it is outside the realm of their experience? They are asked to add some new functionality to an existing app or script and they say they can't, they don't know that language. I think this is the wrong attitude.

As an Expert, you are expected to step up and say, "Sure, I don't know that language but the program is already written and it just needs some small changes. I can take that on and learn a bit about the language it is written in at the same time. Thanks."

That's how I like to approach tasks outside my realm of Expertise. With contracting, this has become something I have to say more often. Does it slow me down to learn a new language? Sure, I don't know it off the top of my head but with the wealth of information on the web and help within IDEs, there is no reason not to jump in and try out a new language.

If you think you need to be trained in a language or domain to work in it, then you are missing out on being more useful to your team. Being willing to jump in and work in any language is a plus for you in your career that will make you more valuable as an employee.

Don't fear your lack of expertise. Dive in and take on challenges. You grow more from them than staying in your comfortable shell.

Pointers for Signing Your First Contract As A Programmer

A couple weeks ago I had decided to go back to work. My wife and I talked it over and said soon will
be a good time so I would start the search. The next day I got a request to look at a contract job from a contracting company. It was interesting so I said sure.

Well, things moved fast. A little too fast I think and I should have taken my time more, since when I saw the contract I had some reservations. I also talked to some contractors and got some good tips for things to look out for.

Here are some things to do when you get an offer for a contract position:

• Make sure you have the job description and job title.
• I overlooked the missing title (on a recent offer) since I thought it was clear I am a Software Development Engineer. I was given a Software Development Engineer Test job description without the title and they can read very similar. If you do/do not want to do testing then make sure you are clear on this.
• Don't settle on an hourly rate until you have had the interview if you can hold off.
• Don't accept the position until you have read the contract for the position first.
• Don't go in to read the contract and sign. Get them to send the contract first so you can review.
• Once you are happy with the contract and hourly rate, then accept the position and go in to sign.

Now, here are some questions to ask based on feedback from fellow contractors:

• Do you get paid vacation days?
• Do you get paid statutory days?
• In general for these two above, you can get pay deducted from your hourly rate to cover these vacation days but be careful. If you do this and have to work overtime you get paid less while working overtime and that extra pay being taken off for the statutory and vacation days is not adding up for more vacation days so you are leaving money on the table. As well, for some contracts if you said you would take 1 week off during the contract time and the client manager that you are working for does not ok that vacation time during your contract, you may lose that vacation pay and hence leave money on the table.
• Where will you sit when you go to work?
• Who pays for the desk seat?
• Yes, some contracts do not include a desk and hence if you want a desk to work at you must pay for it, the hiring client must pay for it, or the contracting company has to pay for it. It may come out of your hourly rate and can be a non-trivial cost. Make sure you know this going in.
• Who pays for your computer and if on call your phone or data/text/call minutes plan?
• Again, this may have to be covered by either party in the contract: you, the contracting company or the client. Find out who since this can be an unforeseen expense to you.
• How do you report your time? To who? What happens when the client supervisor is on vacation who approves your timesheets?
• If you don't have this straight you go a couple weeks without pay. Not cool, but your responsibility to find out.
• Who pays for your taxes?
• You? Your contracting firm? Find out since this will impact how you. I you are taking on your taxes, that is another expense to hire an accountant to help out.
• Here is my most dreaded issue, the Non-Compete clause, also know as Restrictive Covenant. Is it too wide? That is, does it say you can not take a job in this field? With this company? With another contracting company? For a long period.
• I just had an offer that wanted me to sign a 180 day non-compete where I could not work at the company I was contracting to and I could not work with another contracting company during that period. This was for a 45 day contract. So for a 1.5 month contract that wanted to freeze me from working at this company or a new contracting firm for 6 months? A little harsh and overboard. I negotiated new terms on this point.

Here are some of the advantages I can see and others have told me:

• I am paid hourly. I am only allowed to work 40hr/week without supervisor permission to work more. If I work 50 hours I get paid 50 hours.
• I get to work on a project to ship date and then I can move onto another project. I am not stuck maintaining something.
• I am told that contracting gives a greater peace of mind. Many contractors are paid for output, not meetings and long term direction setting. So when they leave work their mind is freer and they do not dwell on work issues.

I'll let you know if that is true.

As I do more contracting I will post more updates as I learn more.