A new tech industry phrase, The Internet of Things, has been floating around the web for a few months now. The Internet of things is a loose term people are using to describe any number of devices that may or may not currently live in your house. It’s all so vague. Last week, I found myself reading the phrase yet again with no clue about what was actually meant.
I work in an open office at my day gig. After seeing that phrase for the hundredth time, I asked “Has anyone heard of the Internet of Things. Can you please explain to me what that means?” After chuckles and light ribbing for asking questions like their grandparents would ask, I got a few vague answers of “I think it’s a little like this” or “Its kinda like when you have blabla”.
Yeah, still pretty vague.
So, lets explore what The Internet of Things really is.
Just two weeks ago, I was in Portland, Oregon, with my family of five, about to pick up a rental car from Hertz. It was 9:00PM Pacific, about midnight back home; the rental area was nice and empty …
It was still nice and empty forty-five minutes later when we received our vehicle.
It turns out the computer system was down from 1:00AM that morning until 3:00PM that afternoon. During that time, people still returned (and checked out) automobiles, and the technical staff lost them.
That’s right, they lost cars — knowing the car is on the lot, in one of a few hundred places, but not exactly where.
Then things get weird.
“Collaborative tools” is a large bucket. Wikis, multi-edit documents, shared spaces, asynchronous editing, chat tools, video conferencing, terminal multiplexing, and a variety of other options can all be considered “collaborative tools”. The goal is to encourage people to actively work on things together, to make changes in real time, or where asynchronous edits can be versioned so that no information is lost. Below are some of my favorite ways to use collaboration tools, and what you can use to get similar results.
Developing and maintaining a pipeline of work, existing clients, and potential clients has been one of the more tricky aspects of doing freelance work so far. When I was starting out, all I had was a vision of how I wanted my career to progress. Unfortunately, that vision didn’t come with actual work built into it. Over time, my pipeline of work has improved a bit and I’ve of course learned a few lessons.
Harvard Business Review has data suggesting that freelance workers are getting up to 84% of their work from word of mouth, not advertising or recruiters or freelance sites.
The way HBR dissected the data is pretty specific of course, they classify based on number of hours worked and then again by age, but the study matches well with my experience.
Lets take a closer look at what is happening.
Agile has fostered a fair bit of change in how software development happens. Change in what people value, how people work together, and changes in openness and and candor. For a long time, software was a black box, or close to it at least. A business feeds in some sort of information about the problem they are trying to solve in the form of requirements, and maybe six months later they get something. That something may or may not have solved the problem. If the problem wasn’t solved, the cycle begins anew.
This post is, in a way, a response to Justin Rohrman’s post about “Ageism in the Tech World“. Does it exist? Yes. Is it detrimental? It certainly can be. Does it have to be? No.
Overcoming ageism, or any other “ism”, requires taking control of our own career trajectories. How do we do that? We make choices and invest our efforts in areas that will ultimately prove beneficial.
Yes, it’s that simple.
No, it’s not easy.
No, there is no one size fits all method to doing this, but here are some things that I have done to address this in my own career.
Ron Jeffries, signer of the Agile Manifesto and co-creator of Extreme Programming, has a new book (currently in beta) out titled The Nature of Software Development. The Nature of Software Development is an accumulation of experience and ideas Ron has collected over his past 50 years of software work. The work is divided into two segments, The Circle of Value which explains his ideas on how software work should be done, and Notes and Essays which are questions from readers and reviewers as well as anecdotes from his experience.
When I ask friends why they moved to a new company, the most common answer I get is they were “just looking for something different”. When salary, benefits and other side “perks” are not part of the equation, their answers tended to end up being one of these three things:
- To learn something new.
- To be challenged and do better.
- To be surprised.
That tells me those things aren’t happening in their old environment, and the person believes they couldn’t make those thing happen — the change is impossible given the work, or the politics, or something else. The answer that comes to mind may be to pull up stakes an start over elsewhere. Sometimes, that is the right answer, but I have to wonder – how far did they push before coming to that conclusion?
Software development hasn’t existed for all that long now, maybe 60 or so years. Things have changed a little during that time, and some things have come full circle. One significant shift that has occurred, is a change in how we think software work should be done. This shift can be seen in the way our development teams are put together.
Hello to everyone who reads “Uncharted Waters”. I am excited to be one of the writers to contribute to this space, and looking forward to collaborating with Matt and Justin on future posts. For those who do not know me, I’ve been a software tester for twenty years (a lot more about that below) and I have had a wide and varied career, touching many different industries and disciplines. Through them all, the primary theme has been to test software and devices, and to encourage other testers to learn more, do more and dare more. It’s my hope that I can continue that tradition here and in future posts.
I officially became a “software tester” in 1994, when I was working with Cisco Systems. Actually, the title I was given was “Development Test Engineer”. I’ve had a variety of job titles since then, such as Application Engineer, QA Engineer, QA Tester, Lead QA Engineer, and other variations that HR departments deemed necessary. I was given the choice of choosing my own title (within reason, of course) when I went to Sidereel. I asked them “Can my title be “Software Tester?” After a quizzical look, they said “Sure, if that’s what you want.” Only once in my career have I had my actual work discipline in my official title. By any other name, do we not still test software the same?