In the life of an organization, there is the inevitable changes; people come and go, products get updated and old products get phased out. It’s a common occurrence, and one that usually can be dealt with in a reasonable manner. Often, we have someone in a position, typically because they have done it for a long time, that we feel it just makes sense to let them do their thing. They are effective, they are productive, and really, we can get what we need when we need it. Days go by and we let those people do whatever it is they do.
The problem with this is that there are situations where someone who is key to a role may be here today, gone tomorrow, and no one can do anything about it. It’s one thing when that person leaves to find a new job, but they are able to be reached for troubleshooting or as a resource to figure something out. There’s also the possibility that someone who has to leave suddenly will not be available to speak (think medical emergencies and situations where communication is not possible any longer). What do we do then?
Last Friday marked my second full week of working as a contracting software tester from my house. A while ago, I worked from my home office for 2 years while working for a completely distributed company. We had an office space where the VCs were located, but that was really for show. No one wanted to work out of that space.
Instead, we had people working from their house in Boston, Dallas, Nashville, and Nebraska.
It’s a little different this time around.
One of the last things I did before departing my last full time position was helping out with interviews of potential candidates to fill my shoes when I was gone. There was only one real candidate, getting testers in Nashville, or anywhere really, can be difficult.
A few of us spoke with the candidate and we all came to our respective decisions, but in the end, the boss didn’t like how I made my decision.
Today is the second day of my life as a full-time independent (contracting / consulting) software tester. There has been about 4 years of build up to this that involved getting better at what I do and expanding that skill set to other marketable areas, reading about sales, finance and marketing, and meeting people and developing relationships.
Little bits of this was mentioned in a blog series called ‘Starting Freelance’ that I wrote here on ITKE. Maybe in a few months I’ll have to start a new series called Doing Freelance.
It just never turns out to be quite the profit center I’d hoped.
In theory I should make so many euros per trip, plus travel. With an exchange rate of 1.08 euros per dollar right now, that means I should come home with 1.08*rate in dollars, right?
If only things were that easy.
A Cautionary Tale
Flying out of Grand Rapids, I get to the airport hours early, order a meal … and I can’t find the receipt. In Philly, I have a decent layover and want to use the Delta Lounge, which is usually free for me, but I’m not on a delta flight. As I won’t ask for reimbursement for the lounge fee, it ends up costing me twenty-nine dollars of my own money, I also get some cash, which has a fee, and not-great exchange rate both ways.
Then there are tips, offerings at Church, gifts for the kids. A soda here, a pretzel there. I just ordered a coffee at the hotel and realized it was three euro — I thought they were complimentary! For part of my trip, only hotel and airfare is covered (no food)—and then there are wire transfer fees to get the money, and the not-great exchange rate I will get. And the tips.
All told, for these kind of trips, I plan on a 20% difference between potential and actual pay.
Add up all trips all year, and that is a lot of money.
The trick of the lost 20% is gradualism. It starts out at one beer. I mean, really, what is the big deal about 3 euro for a beer? Compared to the total fee it is nothing. Travel, after all, is a hardship; a drink is a small compensation.
“c’mon, you earned it”, and so on.
After I’ve used cash on trips like this I wonder how it is possible to drink that much beer, or whatever it was, because I don’t remember all those little things.
My goodness, though, they sure do add up to a lot.
Above: The pancake boat restaurant in Groningen, Netherlands. (Keep your receipt!)
The story here is not about my money – though by paying attention to it I have learned to manage it a little bit better.
The story here is about your time.
The Time Thief
The greatest real wealth is your time. Because time can not be saved, we are all spending it constantly. Sadly, like my money on a trip, we tend to spend time gradually, in little bits at a time. What starts as a two-minute funny youtube clip turns into an hour; what starts as watching a show on Netlix turns into an evening binge. Twitter and Skype can be helpful and wonderful … but have you analyzed how much time you spend on them?
RescueTime can analyze what you spend your time on at the computer. It’s also free; give it a try. Then, perhaps, consider what you could do it if you took that time back, if you chose to do something else. Perhaps a single day, or a Tuesday/Thursday website fast.
Looking at my time online I have come to realize something a little more sinister. When I don’t want to do a distasteful task, I tend to cycle through Twitter, Skype, Facebook, and a forum or two. Once I’ve finished reviewing the forum there will be something new on twitter — all because my brain does not want to make a tough decision, do a piece of work, or make a call. As a great deal of my work these days is piece-rate, I am not stealing hourly from someone else; it is more like I am stealing from myself, both opportunity to work and time that could have been spent with the family.
As I write this I am in a town car, on the way to the Amsterdam Airport. You could argue that I should stop and just look out the window, and I understand. I do take a little comfort in one thing.
When the driver asked if I needed wifi, I did say “no thanks.”
You see …
I’d rather be productive.
When I look through local software company lists and job advertisements, it’s easy to make a few generalizations. There are big companies that have been around a long time; they are stable and the people working there don’t have much to worry about. And then on the other side, there are very small, very new companies, start-ups. Working at a start up is a bit of a roller coaster, projects change faster that we can keep up with and the jobs are unstable.
The reality is that there is a spectrum. Where you land in the spectrum will effect your pay, the technology you’re working with, the culture, and what you get out of the deal.
Lets take a closer look.
More than a decade ago, at the cubicle to my right, I heard an argument between a project manager and a programmer. The project manager was saying that “the steering committee had decided” that new functionality “needed to be in this release” and the programmer had to figure out how to do it without moving the date. I believe the conversation ended with the PM saying “deal with it” and walking away.
Fast-forward two or three years, and I am a newly minted project manager. I’m the powerful one now right? At least I had a different attitude that our PM from the other story – I wanted to fix things, to do right by the technical staff. Have been one something like fifteen minutes ago, having a personal hand in the process documents for the IT department, I could do a lot more than push people around. Pushing people around was not my way, anyway, I had credibility, and knew if a request would take five minutes, five weeks, or wasn’t defined well enough to estimate.
On one of my earliest projects, I am paired with the same programmer. As that project starts to wind down, the programmer comes to my desk and explains that his team is late. “We’re not going to hit the deadline”, he says “likely miss it by two weeks, maybe four. You’ll have to explain this to the steering committee. Good luck.”
What. Just. Happened. Here? Continued »
Feburary 20th of 2014, HP published a patent (originally filed in 2012) for implementing performance tests in an environment using continuous delivery. The content of the patent is pretty general, there are definitions of benchmarking, explanations of tests being run in parallel against multiple systems, as well as mentions of test repositories and an engine that will drive everything.
Software patents are controversial, especially the patents that don’t specifically describe implementation and integration.
Let’s see how far reaching, and maybe overbearing this one is.
One of my daily frustrations is reading through technical documentation. Sometimes it is for my own product (and thus, internal). Much of the time, it also involves materials on the web, i.e. researching an open source tool. There is a brisk trade in the book market today for technology titles, especially those related to tools, to help us make sense of what we use each day. A lot the technical documentation available is written by programmers or engineers. I don’t mean to criticize, but the fact is, much of what is written is, at best, challenging to understand.
I am often called upon to write technical documentation, so I find that I become the person I complain about. It’s easy to put commands or instructions together as though it were a script, and leave it as is. After all, the people who will be reading my docs are smart people. They’ll figure it out, right?
ITWorld recently published an article about a study claiming refactoring usually doesn’t result in improved code quality. The authors of the study say “Even though some of those studies claim that refactoring improves the quality of software, most of them did not provide quantitative evidence”
There are other claims in the study that are a little concerning — refactoring doesn’t make code easier to change, doesn’t make code run faster, and refactored code isn’t more resource efficient.
My first instinct is to question the premise and techniques of the study.
But, does the study even matter?