It’s been a year in NYC as a freelance software developer for me and there have been a few bumps and bruises along the way. Some of it I documented here but today I’m going to show off scars of the self-inflicted variety. I made my share of dumb moves and hopefully this will help some people avoid the same mistakes:
Don’t Reinvent the Wheel
In one of my earlier assignments, I inherited a codebase for version 1.0 of a geo-location based app and my job was to implement new features for an upgrade. I found the code difficult to navigate and thought it was poorly designed. Since the upgrade included a complete UI overhaul, I suggested we tear up the codebase and buld it back up from the bottom. The client went along with this and we spent about three weeks building the app back up from scratch. As any experienced developer could tell you, this was dumb. The codebase covered a million different contigencies that I could not have possibly planned for in a few weeks and was proven to be reliable during the initial release. After about three weeks trying to build it back from scratch, I reversed course and went back to the original code base. I tried to make it right by doing much of this very early in the morning before getting to the office and not billing the hours but it definitely did not make up for three weeks of lost time. Today, this episode reminds me of something I read on Hacker News once: it’s easier to write code than it is to read code. My job as a developer was to learn the environment, not to recreate it. Never again will I make that mistake.
Better You Than Me
When the shit hits the fan, everyone looks for someone to blame. If the shit is an iPhone app and you’re the developer, you’re the fan. During an assignment last February, we were racing against the clock to release in time for SXSW. Most of the work was cleaning up bugs and improving stability but whenever we corrected a particular set of problems, the founder wanted to add new features. Up until the very last day before submitting to Apple, we added new features without testing. This is about as wise as going into the octagon against George St. Pierre just for shits and giggles. We held weekly meetings with the project manager who asked if it was wise to submit. I told him that we can always use more time but the founder wants to submit so that’s what we’ll do. After all, he signed the checks.
So we submitted and the app was approved in time. Of course, all the cool new features were buggy, wonky and unstable. It wasn’t long before the whispers began and people looked around for someone to pin it on. Even though I gave my honest opinion to the PM, the blame still fell squarely on my shoulders.
Now, it could be argued that I wasn’t good enough to hit the target deadline and I would accept that but I knew we were pushing too many new features at the expense of stability. We weren’t even testing in the field – the founder would just look at his iPhone, try it out, and say “great, now let’s add this new feature.” I knew we were taking risks but I should have been much more forceful about submitting and/or adding new features that weren’t planned. I should have put my foot down: either we don’t submit on time or we stop adding new features that were not in the specs. Otherwise, I’m out. By failing to take charge of the process, I took the bullet after releasing. The investment company was deeply disappointed and people pointed at me. I didn’t protest by saying “I told the PM we shouldn’t release but no one listened.” I just took it, accepted the outcome, and moved on. That part I can deal with. What bothers me is that when the time is right, I certainly cannot approach the investment company with my own project. That’s the real damage from the situation – they are a well run group.
Quid Pro Quo
This is a lesson I’ve had to learn several times and still don’t take to heart on occasion. Bartering my development services has led to near disastrous outomes. The main reason is, the other party rarely understands the level of effort developers commit to writing polished software. Most people think making an app is as challenging as creating a WordPress site and installing a theme. This is why you see ads on CraigsList that read: “Two free Yoga Sessions if you make an iPhone App for me.”
Over the summer, an acquaintance approached me to make an iPhone/iPad app for his website. This individual is a retired professional athlete and said he would be willing to help promote one of my apps in exchange. Without going into specifics (another mistake – I should have clearly enumerated EXACTLY what I wanted in exchange), I put together most of an iPhone/iPad Newstand app. If you have ever done a Newsstand app, you know how crazy it gets with the background downloading via push. Setting up the UrbanAirship and using it to initiate a download to the app when it’s not even on is not exactly easy the first time. I got it done but it kicked my ass for a couple days. Anyway so, I asked this person to do the following: sign up for my app and provide an email introduction to a particular contact. These requests went ignored. This is after I spent around 100 hours working on the app. As you may imagine, this made it much more difficult to stay motivated on the project. I started to ignore his emails, texts, and phone calls. After a while, I just told him why I was ignoring him and this led to a bad falling out. Our relationship is definitely done and there’s no repairing it. I already came to that resolution after he didn’t fulfill my initial requests. There’s more to it (as always) and his version of events will differ from mine but the point is this: he had no idea how much work it took to put together an iPhone/iPad app from scracth (esp when you factor in the Newsstand stuff) and so he didn’t feel compelled to return the favor as quickly. From his angle, making the app was probably the same as giving someone a ride to the airport.
The thing is, I’ve been through these situations more than once. I don’t blame the other people anymore. They truly don’t know how much time software development requires and don’t think they are taking advantage of anyone. I blame myself. I should have told them my hourly rate, the amount of time their project will take, and that it will cut into my free time. Then, they would have a frame of reference for offering something of equal value in return. My real solution is, I don’t do quid-pro-quo work anymore. As Randy Moss would say, straight cash homey.
So year one brought these nuggets of wisdom to my arsenal. Hopefully you won’t have to learn them the way I did. If you have any battle scars of your own, I would love to hear about them.