It’s a tough world out there. Unemployment runs at 9%, but if you count the under-employed, part-time, or those out of work more than two years, the percentage could be twice that.
Then you have employers, a fickle lot, that like to require a very specific skill set, down to the level of sifting out people who have experience administering the wrong point-release of specific operating systems.
Then along comes Andy Lester, author of “Land The Tech Job You Love.”
Let’s be frank: The first part, “land the tech job” is hard enough, and here Andy comes promising the second.
I thought it was time to talk to the gentleman, man-to-man. (Plus I’d let you watch, because I’m that kind of guy.)
More seriously, Andy wrote a book about developing habits to get, and keep, a job suited to your skills and temperament — and offered to talk to us about it.
In Part I of this interview, we’ll talk about the experiences and motivations that Andy drew on to write the book.
Matt: You’ve been a programmer, manager, and technology evangelist. What inspired you to write a book such a human-resources-y topic?
Andy: Years of hiring programmers. I’ve had so many people interview for programmer positions with two big failures. First, tech people tend to not like to talk about themselves, and you have to sell yourself to get a job, because if you don’t, someone else is going to beat you to it. That’s not the entire problem, but it’s the tip of the iceberg. Second, I talked to many people who didn’t seem to especially care what job they got. They just wanted to come in and write some code and go home. This seemed like such a shame, because I figure that life is too short to spend working in a job that you don’t love. You spend as much time at the office as you spend waking hours with your spouse, so why not love what you’re doing?
Matt: You’ve been a hiring manager since about the time we first met, in 2003. Of all the candidates you’ve seen, what would you say is the #1 mistake you’ve seen?
Andy: I always ask for printed code samples before an interview. I want them printed so that the candidate and I can look at them in the interview together, and I can get a feel for the candidate’s design and coding decisions.
So this guy comes in at 9:10 for a 9:00 interview, which is Strikes #1 and 2 against him right there.
He doesn’t apologize for being late, and hands me an orange 3.5″ floppy disk and says “Here’s my code samples, my printer ran out of ink this morning.”
Never mind that I didn’t have a drive capable of reading a floppy, even years back when this happened, but he told me quite a lot about himself.
First, he was unable to complete his first assignment as directed. I said to do X, and he didn’t.
Matt: Let me guess — second — it told you that he was comfortable transferring his problems to you?
Andy: Exactly. Third, he waited until the morning of this important meeting to do the assignment. Fourth, he didn’t have the presence of mind to go to a Kinko’s and print off copies.
Matt: Can I ask, what were the top two or three things you’ve seen as a hiring manager that impressed you? What were the good things?
Andy: I’m always impressed when a candidate has clearly done his or her homework and researched the company or me. I always give my name when I’m going to interview someone, giving them ample opportunity to find out about me on the web. If you can find blog posts or mailing list messages from your interviewer, it can give you insight into what he and the company need. This isn’t creepy. I’ve already Googled the candidate before calling them in for an interview, and they should have the foresight to do the same in return.
At the very least, everyone should find out as much about the company with which they’re interviewing before going in for the meeting. I wish it weren’t so uncommon that it impresses me when people do it.
Candidates who are well-prepared for the interview and work to tell about their value to their companies in past positions always make a solid impression. It shows that they know I’m hiring them for a job, not just for the heck of it.
So far, we’ve signed up for a personal Amazon Web Services Account, learned a little bit about the Amazon Management Console, and, yes, even created a server in the cloud. Now if only we could actually do something with it …
Suddenly I have an idea for a follow-up post.
Today I’ll show you how to connect to that server in the cloud, accessing it through Remote Desktop, run software on it, and finally, so your credit card does not get dinged, how to shut the server down.
First, you need to follow the instructions in the previous tutorial; you should end up looking at the Amazon Web Services Console, something like this:
Now things get interesting.
The green light there indicates that the server is booted, but it may not yet have all services running … especially the services we need to connect. The easiest way to get to our server is to wait, about a half-hour, for Amazon to make sure the server is ‘clean.’
In the mean time, we need something: Remote Desktop software to connect to our server. Remote desktop comes standard on Windows Vista and newer machines, but is you have XP or a Mac, you’ll need to download it. You can get that software for free online; both the WindowsXP Version and the Macintosh Version have a free download.
Once we have Remote Desktop, you’ll have to wait; my recommendation is a half-hour, for all the services to be up.
Now Get The Windows Password
Once the services are up, we’ll need to retrieve the the administrative password for the machine. To do this, check the checkbox to the left of the instance to indicate it, then click on instance actions and “Get Windows Password”. (See example below)
Once you click retrieve, you’ll be asked for a private key, in order to decrypt the password from the server:
Do this this you will need that .pem key file you created earlier. Once you upload the file you will get a windows password. Save that to a file, or at least copy it to your clipboard with control-V.
Whew. Now we can actually connect to the machine.
It’s time to Log in to our cloud-based server. Yay!
One more time — use instance management again and click connect. This should bring up another dialog box, and you’ll have the opportunity to download a shortcut file , with the extension .rdp. If remote desktop is configured correctly, you can open the file with remote desktop. (Otherwise, save the file to your hard drive, open remote desktop, and tell it to open the file.)
Once remote desktop has the file loaded, Click Connect on remote desktop and you’ll come to a login screen:
Paste the password, leave domain blank, and click ok; ignore any certificate warnings.
Congratulations — you are in your server!
But … what can we do with it?
Of course, the value of any server is limited to the application we had in mind. Our goal today was to have a server, which isn’t saying much.
Three things we could do with this server are to test in internet explorer 8, to test installing applications on Windows Server 2008 (if we didn’t have a box handy), or to use the server as a storage place for files.
And that;s the real rub of cloud computing. Without an application, ‘give us some of the cloud stuffs’ doesn’t really mean anything.
More on cloud-based apps to come, but today promised to keep things under an hour. Today we wanted to get a real, live server up and running in the cloud, and I do believe we’ve done that.
With this foundation in place, we can add more in the future. For now, though …
Off — Off — Turn it Off!!!
In control panel, select Instance Management->Terminate, then Yes, Terminate. Please do, this, you must do this. If you do not do this, expect a ding from your credit card in a year.
Closing the loop – what we’ve learned
If you followed the instructions in this tutorial, you create an AWS personal account, created a server, and got into it with remote desktop.
Congratulations; suddenly the “cloud” is a less mystical and magical place, and more a think you can touch and feel, or at least a little bit more of a thing.
You’ve also probably recognized that feeling of “my goodness, this doesn’t actually do anything”, and you’re right. That’s what those cloud application vendors I introduced you to earlier have been saying for years: Building applications on top of the cloud is expensive and time consuming, why build when you can rent?
Why build indeed?
More to come.]]>
In the first blog entry I wrote about how to dip your feet into the cloud, mostly by using someone else’s cloud-based application. In the second I talked about how to move the cloud discussion from one of emotion to something a little more nuanced, just a little bit more based on reason.
One thing those techniques can buy you is time; time to go figure out how we are going to do this thing called the cloud, or CRM, or whatever else is the buzzword of the moment.
Let’s say it’s the cloud — what next?
In this article, I’ll walk you through creating a free server in the cloud in about an hour.
No really, we’re going stop talking about Amazon Web Services and start using them. To do this, we’ll create an Amazon Web Services (AWS) account, create a server in the cloud, then connect to it.
Whew. Here Goes.
What You Will Need (And A Warning)
All you need to get started with Amazon Web Services (AWS) is an Amazon.com classic account. That’s right; we’ll be super-charging our Amazon Account to become an Amazon Web Service personal account.
Notice that word personal. In order to encourage adoption, AWS gives away 750 CPU hours per month free for twelve months. That means you as long as Amazon doesn’t need to spool up additional servers, and as long as you turn off your instances when you are done testing, the service will be free.
Note: That’s a really, really important if. In the event that you follow this tutorial and forget to turn your instances off, you will see a bill in the mail, likely in the area of 8-10 cents per CPU hour, for as much as a month.
Don’t forget to turn off your machines. If you do forget, IT Knowledge Exchange nor Matthew Heusser are responsible for blah blah blah legal stuff here.
Step One: 90% of everything is Signing Up
First log into Amazon with your regular old account, then point your web browser to this URL:
1. Click sign up now then follow the instructions to create an Amazon Web Services Account.
2. Amazon will need to verify your identity by phone. To do this, Amazon will give you a special code and the call the phone number on your account. You’ll need to enter that code, then press continue.
3. Next AWS will email you a confirmation; check your email.
Once you have that email, we can move on to actually creating your first server.
Step Two: Create Your First EC2 Server
EC2 is the “Elastic Compute Cloud” (One ‘E’ and two ‘C’s)
The word elastic is important; the number of servers we are using will spool up and down with demand, kind of like your strechy pants that get wider around thanksgiving time if need be. (Okay, my strechy pants. Sheesh.)
For the most part, signing up is easy, it is in creating the servers that people get stuck.
It’s not just the command-line tools. It’s also the orchestration of the servers, the connecting them to a web-page, and, yes, the security issues involved in setting up key-value pairs.
For this time, let’s skip all that, and use remote server administration through a control panel.
To do this, go to this URL:
Select EC2 in the drop down and check the box — like in the example above — then sign if. (If you;d like, you could explore S3, Amazon’s file storage in the cloud option; more about that some other time.)
Once you log in to the console, you should see something like this:
This is the basic management console; the list of Amazon Cloud Services as tabs at the top.
Click launch instance.
You will see a large number of choices; select “Microsoft Windows Server 2008 Base.”
At this point you will work through a five step wizard. You can get by with the defaults for the first and second step (‘Instance Details’); we don’t need to worry about getting a large server or deal with integrated security issues.
When you get to step three ‘Create Key Pair’, you will need to create a key and save it to your computer’s hard drive. I will call this file a .PEM file — This is important. We will need our end of that key (the ‘private key’) to log into our server in the cloud. Note: Matt had problems doing this in Chrome; best browser is probably FireFox.
For firewall you can accept the defaults, then click ‘Launch.’
Ta-Da. Your instance is launching. Wait five minutes and click “close.”
You’ll come back to the Command Console page, but what’s that at right … it says one running instance! Click that.
You’ll come back to the EC2 Management Console Page, for your running instances.
Congratulations! You’ve got a windows-based server up in the cloud.
Oh course, we don’t know how to do anything with it yet, or even shut it down.
I’ll cover that in the next blog post.]]>
Last time I talked about how to respond when the big boss walks into your office and says something like “What are we doing about the cloud? We need some of that cloud stuff.”
I tried to make that advice hold true for most teams — but if your organization has data privacy and security concerns, the question becomes a lot more complex.
Or does it?
Think about both of those statements:
“We need some of that cloud stuffs”
“We can’t possibly go to the cloud, because of regulations and data security issues”
In neither case do we have any data; we don’t what kind of uptime or service level agreements we could get. We don’t know what the applicable regulations are, we don’t know the cost of the conversion or ongoing operations.
In both of these cases, we’ve jumped to conclusions based on some sort of faith.
In other words, what looks like a conclusion is really more of an emotional response.
It turns out that is kind of a big deal.
In “Switch: How to Change Things When Change is Hard“, authors Chip and Dan Heath argue that the brain is constantly fighting between the emotional side and reason — and emotions frequently win. (Those of us who have vowed to get up in the morning and exercise, or give up fatty foods, and failed, likely know what they mean.)
Likewise, if you’ve ever responded to an challenge like “prove it” by brining all your data to the next meeting — all your pie charts, graphs, and powerpoints, only to be faced with complete apathy and unresponsiveness, well, you’ve seen the power of emotion in the boardroom too. Again, Chip and Dan Heath suggest that reason might win the meeting, but without an emotional response, the actual action items to make the change will keep being rescheduled, over-looked, and ignored, until they eventually go away.
Another way to put it: You might win intellectual assent for your idea, but without hitting someone’s emotions, it’s unlikely that the project will get to be your priority, or get funding, or get on the corporate projects list. It’s kind of hard to move to the cloud at night, for free, in your spare time. If you somehow pulled it off, though, I expect you might get brought into a meeting to talk about “Governance”, don’t you think?
Defeating the Lizard Brain
Seth Godin calls this emotive side the “Lizard Brain“, because it is the kind of brain that chickens and reptiles have — a brain driven by fear, greed, and the desire to continue the species. Yet we can trick our lizard brain. Chip and Dan Heath use the example of an alarm clock with wheels, that forces you to get up and chase it in order to press the snooze button; once you’ve pressed snooze, you’re up anyway.
We can do this in the IT Department.
Matt’s Hasty, Generally, Possibly Incorrect Guess
I’m going to take a guess here, based entirely on intuition.
If your organization feels some compelling need to go to the cloud right now, then the corporate culture is likely one of innovation, or at least early adoption.
As the saying goes, you can tell the early adopters, because they’ll stand in line four twelve hours to get a new iPad, just to be the first people to have it. Of course, in a week, everyone else will have one too, but for that week … wow. They’re ahead of the curve.
Likewise, if the company is fighting tooth and nail to find reasons not to change, you’re likely in the early majority, if not the late majority, on the technology adoption lifecycle.
As my friend Eugene Lee recently said about these two groups: ”If you come to early adopters with an 80% solution, they’ll work with you to figure it out. If you come to the late majority with that 80% solution, they’ll response ‘call me back when you’ve got it all figured out.’
Right now, today, cloud technologies are in the early adopter phase.
Now if you agree with the big boss — no problem. If he’s worried about security and so are you, hey, great, you’ve got some time to figure it out. Likewise, if the company wants to throw time and money at the issue and you’d like to get experience with the news tools — hey, cool. You might need to put some effort into setting expectations, but for the most part, you’re good.
It’s when things are different that you’ve got a problem.
Encouraging Late Adopters
The lizard brain is motivated by fear, but fear can cut both ways; you can implement buggy systems or be left behind, trying to sell an MS-DOS based application to Windows Users.
Most late adopters do one thing: Follow the Herd. Or, as I’m sure you’ve heard “No one ever got fired for buying Microsoft.”
The Early Majority needs to know the problem has been solved before, and solved well, by other companies. You can do this through Lunches, Case Studies, References in Magazines, Interviews, or Articles. Once someone else has done the work, there is precedence – and that precedence can overcome a host of objections about regulations, audits, and standards.
The Late Majority, on other hand, adopts technologies when it looks like they are about to be left behind. You might not be able to drag a Late Majority-Culture to the cloud today, but the time is coming. When cloud adoption approaches that of Social Media, which has an 86% adoption rate in US Global 100 companies, your company will want to have an answer. Likewise, Late Majority Companies tend to be risk averse, so the time to start the experiment that might be fully implemented later … that time is now, isn’t it?
If your company is an early adopter, you might get pressure from the other direction — no, it might not be a great idea to put exchange “in the cloud” next week (whatever that means.)
When you try to deal with unrealistic expectations, yes, you can use reason, but try to do it in a way that can create an emotive response. For example “Is it okay if our services go down for five business days? Because that just happened to Amazon’s Cloud in April.” You might also want to mention the risk of a customer-data breach, yes, but also point out that it happened to Sony’s Datacenter in April, entirely because Sony’s model required it’s systems to be available to general public outside the firewall … just like most public clouds.
By moving from a potential threat to a systems failure, one that happened to a real company, with real security, who’s name we recognize, we transform the problem from the realm of theory to one of practice.
A Final Thought
Now I’m not saying that IT should drive every business decision, nor am suggesting you manipulate your boss to get your way. Instead I tried to provide a few techniques to align emotions with the intellect, to help people come to the best possible decision, instead of allowing themselves to be driven entirely by fear and greed.
But what do you think? I look forward to your comments.]]>
Welcome to “Unchartered Waters”, my blog exploring new ideas and concepts in information technology.
Of course, if you have more than a few grey hairs in this game, you’ve likely seen “new ideas” before. Two years ago, Web Services were going to re-define the way we delivered services. Two years before that, it was Customer Relationship Management (CRM).
Before that, it was the Enterprise Service Bus (ESB), and, before that, Enterprise Resource Planning (ERP). Some readers might even have had the familiar experience of a manager or executive walking into the room, saying something like “We need XML. Can we get some XML? How can we use XML?”
Today, it’s Cloud Computing, “Governance”, “Portfolio Management”, Server Virtualization, or integrating Mobile Devices into the organization.
It’s easy for us to complain about these things. ”Oh, yes”, we say “We’ve seen this before. Everything old is new again. New paradigms and all that.”
And yet, every now and again, something does happen. Personal Computers did enter into the IT shop, and things did shift, and companies that took advantage of these new technologies gained advantage in the marketplace. Also note: The IT Departments that tried to block these innovations didn’t just slow the company down and eventually fail in that blockage — no, in many cases, those department went away.
Further Note: If your organization is more than a few hundred people, it’s very likely that somewhere, down the hall, someone is checking email using an iPad he bought out of pocket because “those darn IT guys” wouldn’t supply him one.
If we are to be successful in technology long-term, we’re going to have to separate the true opportunities from the fads — and know how to respond with grace and skill.
That’s what this blog is about.
Say, for example, the big boss walks in your office in 2011, trade magazine in-hand, saying something like “Why aren’t we using Cloud Technologies? What’s our plan for adoption.”
We need an answer, and it’d better be good.
Dipping our Feet In The Cloud Waters
To get started, let me suggest that you consider using some cloud services (“renting” cpus), instead of creating cloud servers. Here are some ideas:
* Cloud Backup. Several companies offer to backup data offsite, in the cloud, automatically, for a modest fee. You can generally find a nice “wrapper” product, like Zmanda, or, for the ambitious, do it yourself with something like Amazon’s Simple Story Service (S3). (You custom S3 tool might never see production, but that’s kind of the point: To experiment in a cheap way that doesn’t blow anyone’s budget.)
* File Synchronization. Between laptop, phone, home computer, and iPad, today’s power user is going to have a lot of places to store files … and emailing them to himself will get old fast. Apple’s iCloud Service may have the most buzz, but it’s certainly not the first in that space. There are a half-dozen iCloud competitors, most of whom work with windows natively. Running under native windows can be as simply as saving files to a specific location — and yes, DropBox has a free version.
* Cloud Performance Test. Vendors like SOASTA, LoadStorm, and BrowserMob all offer cloud-based performance test tools. Give these tools some URLs and instructions and they can send a hundred, a thousand, or ten thousand simultaneous requests to a website and return with the pretty performance metrics management likes to see.
Beyond “pure” cloud, there are Software As a Service Alternatives as well:
* Collaboration. Does your company have anything to improve within the business in the same way that twitter and facebook has done outside of it? Jive, Socialtext, and Confluence all offer web-based collaboration software, for a fraction of the cost (and none of the admin hassle!) of Microsoft Sharepoint.
* Project Management. Both BaseCamp and Gnatter are two web-based tools for project management. With these type of tools there is nothing to install, nothing to synchronize, no emailing of word documents back and forth or re-typing of status into ten or fifteen systems. Best of all, you can run a project or two, and, if you don’t like it, drop the tool, without having to worry about “porting” anything back or forth.
The Bottom Line
It’s hard to respond to a vague mandate like “move to the cloud”; yet such an idea does represent real opportunity. Yes, I’ll have more to say about setting up an adiministering cloud-based systems yourself, and plenty to say about security, privacy, and other issues of corporate risk. For now, if you have projects that are not classified, consider getting your feet wet by using someone else’e cloud-based service. Most of these services are free for thirty days, or have one-to-five user “freemium” models. Even the pay plans tend to start at reasonable prices, in the $50/month range.
So check out a product with a freemium model; find your most early-adopting project team and offer them a pilot project. Write up the results, and ask for some funding to do a real test. If you get the funding, great; rinse, lather and repeat.
If not, well, you’ve got an answer to the question. The reason we aren’t doing “this cloud thing” is because corporate chose not to fund the project.
Question asked and answered.