Last October I talked about how I think of The Internet of Things. Today I want to explore what happens when something goes wrong in technology we depend on.
My first post mentioned a few attributes and a way to define these things that for the most part, have become a part of our everyday lives. Right now, IoT is mostly a consumer novelty section full of watches that will tell you how far you’ve waked in a day and web connected refrigerators. Plenty of people use the devices, but the functionality isn’t exactly mission critical. Lots of other, more complex things are in the works though – medical devices, and cars.
My parents dropped my wife and I at Hobby airport in Houston after spending Christmas week visiting with them. The baggage ticketing line and the security lines were pretty long as you’d expect for the holiday. TSA agents kept our skies safe by patting down the 80 year old lady in a wheel chair in front of us and me before we made it to our gate. She was clearly menacing. My pants were a little loose.
We eventually made it to our gate and after some reading, people watching, and waiting lined up to board when our group was called. But we never made it on that plane.
After waiting about 45 minutes past the board time, the Southwest person at our gate announced that the autopilot system on our plane was broken and we would be taking a different plane from a different gate.
Figuring out a career path is tough work. From a very early age, in the US at least, we are all asked what we want to be when we grow up. At family gatherings, aunts, uncles, and grandparents will prompt you about being an astronaut, or a police, or even the president.
It’s just small talk really, one generation trying to relate to another. But, it does start an important thought process. What do you want to be when you grow up, and how do you get there?
My career has meandered quite a bit so far. I’ve been a grocery checker, life guard, clerk in a photo lab, pulled cable on a construction crew, and now I’m a software tester and a writer.
There is no manual for what your career will or should be. Planning can help though.
Let’s try a thought experiment. Imagine that any reference to any credential, work history or licensing body you or I might have was housed on a central server. Now imagine that server suffered an irreparable meltdown. Boom! In one instance, all the proof of our schooling, our work history, any certificate we ever earned, any certification or credential we may have ever held, is now irretrievably gone. Oh, and we are both looking for work.
What would you do?
Matt Heusser posted a well rounded commentary of “Zero to One” last week, and in it, he asked us to consider and discuss “a counter-intuitive truth” that we know or believe to be true, but flies in the face of convention or current practice. I’ve determined that my counter-intuitive truth fits in with the above thought experiment; those of us who forgo traditional resumes will do better than those who relentlessly polish theirs.
The company I was working for had traditional cubicles and was considering an office redesign. “Extreme Programming” was all the rage; people were talking about war rooms with no walls. I was much more interested in the private office, likely due to PeopleWare, which I read very early in my career. I even suggested to my manager that we ask our design firm to read PeopleWare, too.
The next five minutes blew my mind. Continued »
Certifications can be found in every niche corner of the high tech industry: networking, hardware, programming languages, process models, auditing models, software testing, and so on. This is a big business and it seems to only grow as time passes.
There is a spectrum of certifications to chose from. At one extreme, you sign into an account online, take a test, and get a PDF in your inbox a little later with your name on it to show at your next interview or performance review.
Are you sure you need to be certified?
Last year I suggested a stocking stuff in Cubu, a strategy game with a politics angle.
I’d like this years gift to say something about my company, Excelon Development, in what we are trying to do, and what it means. Eventually I landed on a book by Peter Thiel, co-founder of paypal and an early investor in Facebook and Twitter. Zero To One: Notes on Startups, or How To Build the Future covers a great deal of ground, including different kinds of change and what a startup needs to succeed. Perhaps most insightful, I found Thiel explaining the why behind the thinking in Silicon Valley, including the Lean Startup thinking that is so common today, and where it came from.
Tech jobs are often steeped in ego contests and political games. Matt wrote about a scenario he calls ‘Faking it‘, where some people will navigate their way to the top of a company by doing anything except work that directly adds value. Telling the difference between bad and good and great work is difficult for folks that have been out of the game for a while. People still in the game, I mean the technical contributors, often want to advance through the ranks. The obvious route to that is sometimes self-promotion. I mean working specifically so that each thing you do is a strategic step toward a raise or promotion.
There is also a more difficult route of humility and service. I’d like to talk about both.
During the latter part of November, I had the pleasure of attending EuroSTAR 2014 in Dublin, Ireland. Many of the talks delivered at this conference focused on diversity in the workplace. I think it is imperative we endeavor to engage the the creative talents of as many people as possible, and that we do so without regard to gender, ethnic background, sexual orientation, or factors related to physical mobility and information processing. These are areas frequently used to describe diversity. They are the most visible, and therefore, should rightly be considered examples of “external diversity”. That’s important, but it’s only part of the story.
Things almost never take the amount of time we initially think they will, do they?
Programming is no exception. We can sorta kinda figure out how long a task will take to complete using yesterdays weather, but todays weather is complicated.
Here is the dirty secret. Well, it isn’t all that secret.
Developers work long hours, often late into the night toward the end of a development cycle, to get things done. Done as in something that can be shipped. This isn’t because of estimate problems, though they certainly don’t help. This usually isn’t because of misunderstanding scope, there are many ways to solve that problem.
The work never gets done on time because the programmers can’t get it done on time. There are too many impediments for them to do the work.
Let’s talk about that.