I’d like to present you the book I am trying to finish reading for some time now; a very dense book, with good practices and interesting details on how to keep planet-wide systems up & running with a bunch of very well prepared people.
What are the lessons one needs to walk away with, from this book? A few bullets:
About a year ago, during a time when I was barely aware about Cloud Computing or Amazon Web Services, I got assigned, along with a couple of colleagues from this consulting company I was working for, to bring an existing codebase from “alpha” to “production” and then ensure its smooth deployment to Amazon Cloud.
The customer wanted to go “live” in less than 3 months; they also wanted to be able to handle tens of thousands of visitors that would obviously click on banners and make them money. What it’s actually more probable is that they were hoping for a good exit, that is passing the hot potato to somebody else while walking out with a proft. On a side note, there is a term that could be used for these people, but this is not a meme-text so I won’t go more on that route.
Starting on a new project
With this project, things initially went to some direction: we had to incrementally deal with quite a few functionality issues and in the end we were able to put fixes for more than 100 bugs and glitches. Actually, this was all that we could do, along with the long hours required to get things done.
We could not be bothered by any setup issues with the “Cloud” configuration: we knew near to nothing on the topic and the customer fiercely guarded the “keys to the kingdom”; they would only agree on instance and resource set-ups on a case-by-case basis anyway. They were probably thinking they were paying way too much for those pesky Eastern European contractors (us), so I kind of get the “why” on keeping a close eye over the Amazon bill. It was fine by us; at the end of the day it was their home, with their needs and their rules.
Trying to start a career in a Computer Sciences field is a challenge by itself; starting with a good company is, most of the time, a matter of luck. I’m not trying to provide an alternate view to this – yes, one needs a ton of luck in order to get on with a good start. I’m just trying to show you where the train you just boarded may lead you – or where it may not. Switching trains is by any means possible, but it becomes harder as one gets older.
Without looking in depth, companies may be divided in 2 main categories:
-
Product Owners: companies that build products for an actual market; they either sell software or provide services to private or business users through their internally managed infrastructure.
-
Outsourcers: companies that sell “work units” directly or indirectly to either companies from the first category or to other businesses.
There are nuances to this classification; government contractors and start-ups may actually deserve categories of their own.
What can a fresh graduate expect out of each company type?