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?
I’ve been working with technology professionally now for twenty-four years, and in all that time, there is one “killer app” that just will not go away. This app may, frankly, be causing stress that is bad for our overall health. I am, of course, talking about E-Mail.
I have E-mail for business, for personal endeavors, and for community activities. My apps send me email to tell me I’m being a slacker about something I should be doing. I have aspired to live the “Inbox Zero” life, and have made several attempts, yet somehow, it always comes back, layers of sediment, to the point where, some days, opening my Inbox fills me with dread.
I’m writing this post from a fresh installation of Windows 8.1 on a MacBook Pro. I spent about half of Saturday researching, and downloading files, installing things, and waiting. There was a lot of waiting.
Systems administration isn’t my idea of a good time, so this was a little tedious for me. There were some lessons learned, and if gathering all of this in one place helps one person, then that’s great.
Here we go.
When you consider that “fail fast” is a mantra of the lean startup movement, a silicon valley catchphrase, its own book, and thirty-six thousand google search results, the term must be right … right?
Well, sort of. To the extent that fail fast enables people to experiment, to try new things, to learn from them instead of continuing to bang their heads against the wall in the hope of getting through — sure. Fail fast is good.
And we can do better.
In the ITKE Discussion forums, a question was posed that I felt compelled to answer.
“Can someone explain the benefits of my life after completing my Java courses?”
I am no stranger to course work related to programming. In the mid 1990s, I earned a Certificate for UNIX Programming through the University of California at Santa Cruz. While I completed the Certificate program, much of the advanced C language work I focused on was never used again. The shell scripting I learned, however, I still use today. Why? The shell scripting skills had an immediate and tangible effect on my work.
It’s great to learn a new language, or get some time experimenting with a new framework, but experimenting with it alone isn’t going to help us keep those skills. In fact, the speed in which we lose skills that we develop but don’t use can be frighteningly fast. What can we do to make sure that we actually use what we are learning?