Productivity 3.0

If you have been in one of my cloud talks you know that one of my predictions is Productivity 3.0. Basically through tools like elance, rent-a-coder, and ad-hoc teams build in and through coworking locations workers will work for multiple companies on a per project basis. This will lead to people managing their time more efficiently and thus becoming more productive.

This just got validated by the McKinsey Global Institute (see Slate):

"Jobs today are also becoming more "virtual" -- with broadband connections, cloud computing, and other technology, many interaction jobs can be conducted "anytime, anywhere," making it possible for employers to engage talent (full-time employees or contract workers) on an as-needed basis."

Safari Books Online

I always loved the idea of having access to the Safari library and I had recently another couple of months paired with some time to actually use it. Again despite trying to read as much as I could I only managed to read about three to four books in the last four months. I enjoyed it the most on my 24" LCD monitor followed by the laptop scree and last by my TouchPad. I was running the TouchPad on both WebOS and Android but the browser version just stinks. Make some dedicated reading app - That can't be too difficult. Another note on the TouchPad: I read the Economist (Safari doesn't have a usable offline mode) on an airplane ride and my eyes hurt after two hours.

The missing offline mode supposedly gets mitigated by earning tokens which you can use to download content (like one token per chapter) but after three months I didn't earn enough tokens to download any book which renders this feature completely useless.

The interface is borderline useless. The HTML interface is worse than the real one but I am still trying to figure out how to effectively get to the next page without using the scroll bar. A web browser does this with but that doesn't work seamlessly in Safari. As much as I like it when a book looks like a book - a screen doesn't have pages I need to turn. The chapter should just be a flow of text and NOT interrupted by footers and headers...

I actually did the math and if I would have to pay myself for books I might be better off just buying a Kindle version every month than subscribing to Safari. So as much as I like it and as much as I would want every company I work for to give me a subscription it isn't that valuable for me to get a subscription myself if the workplace doesn't offer it. In that case I would rather by the books outright...

Play on Heroku

Having some time on my hand I finally got to check out play on Heroku. I have been dabbling with play earlier when I was trying to run Scala on it but this time I was trying to do some barebone Java app. For a chance from usual dev environment eclipse I was taking IntelliJ for a spin.

As opposed to the description here you need to say under VM args

-Dapplication.path=“path to your app”

The "." is just wrong and wouldn't work for me -- I guess you would need to start IntelliJ in the same directory your play app is located?

Anyhow, development was pretty straight forward. I enjoyed that heroku was forcing you to use git and the deployment was also very easy (compared to GAE).

s+b Generation C

I recently noticed an article on s+b about "Generation C" - which highlights some of the ideas I have been teaching and speaking about. Though they came up with that independently from me it just shows that great minds think alike :-)

Speaking @ SoCalCodeCamp

The link to my presentation on Evernote.

Book Review: Career Game & Power

I have read a couple of career books before and they mostly were motivational or geared towards getting a job so I was intrigued to find some book which uses game theory ("Your Career Game") to help you advance and land a job. Unfortunately the book is written mostly for MBA students so the game theory part is surfacy at best and if you are used to at least engineering math kind of disappointing. Nevertheless they finish each chapter with interviews of real people and highlight what "career game moves" they did.

The essence of this book is basically to find a sponsor and mentor who takes you under his wing. In my career I was fortunate enough to have both when I started out at PwC after school. My boss was my mentor and he was great and put me in touch with other interesting people in the organization. Things just happened naturally without much thinking for me. I guess because the main goal was to bring in money (by billing hours or selling projects) there was no ambiguity and it was in my bosses best interest to expose me to many people to get me billing more hours up. Promoting was good again because then they could charge more for me. Needless to say the partnerships goal were pretty much aligned with my career.

When I came to the US I started working in software engineering and had a hard time finding bosses who acted as sponsors or mentors. Honestly I still thought things would just happen naturally but I guess in that case the first book ("Career Game") would recommend to do better homework if the company you are considering is "good for your career" having a reputation for great mentoring or sponsoring.

I liked the second book "Power" much more because it's lessons are far more applicable. They show research that for instance the performance rating is totally unrelated to your performance and more to how much your boss likes you. Consequently you should spend your time managing up and if you made a bad first impression just leave. Pfeffer also gives tips on building a power base (by choosing influential mentors) and cites surprising research like over-the-top flattery is not considered insincere by the recipient.

They are both pretty good books because they prompted me to some action. The first one ran in some open door with the mentoring: I totally need to increase the numbers of mentors in my life. But I think the "Power" book will be more helpful because I should probably focus more on building a "power base" and increasing my "likability".

Working with four continents

The last couple of months I have been working with a team out of Israel, a team out of Shanghai, an architect based in London, and me out of the US.

My job is to work under the guidance of the architect to develop a component which integrates tightly with what the team in Israel is doing but keeping the people in Shanghai in the loop so they can take over my piece. The easiest part is to keep Shanghai in the loop - I just do a presentation/training session every three weeks in the evening (usually 5 pm my time). They listen, ask a few questions -- but from colleagues having done such things I know that it might be good to give them homework and quizzes to assess the level of their understanding. But I kind of refuse (like I dow with my adult students) to drop people back to college level :-)

Working with the architect is awesome, too: I have him on IM and can drop him a note and he gets back to me really fast. But since he is like me new to the Israel team he does know the same amount as I do about how things should be done on this micro code level where teams differ. Do you use return codes for errors or exceptions? (Turns out they do both) and so on.

I am mostly working with a Senior Engineer and a manager in Israel and they are both really sharp people and a pleasure to work with. I send them e-mails and they usually get back the next day. I send them diffs and they tell me what to change and we have frequent screen sharing meetings (7 am my time) to discuss some of my more complicated changes.

That all sounds great until you discover at 9 am some pattern or detail in their code you don't understand but you probably need to to do your work. Then you have to wait until the next day for the answer. So I found it helpful to switch to some other thing to work on if I am blocked or do some speculative coding to show them how I think it should be done and send it to them to correct me. I have discovered quite some things that way which weren't apparent (to me) by reading their code.

Does it make sense to work that way? I am pretty convinced if I would be co-located at least with the Israel team I would avoid some rework, spent less time searching their source code, and ultimately get more done. On the downside I would probably slow them down a lot with me asking them stuff every 10 minutes or so.

On the other hand I know the piece I am supposed to code for them inside out so having them do it would probably take even longer. But all things equal having a Senior guy on site might be more productive.

I always advocate to fly people to actually meet each other for a few days to code together and get to know each other but with travel budgets tight that often isn't an option. Also often teams contain people from many continents so the way I work this though second best is probably more productive that other things.

The management of my coding is old school. So I don't call in to any daily stand-ups nor do I participate in planning or review meetings. I just keep a representative on each continent informed about my progress and they coordinate with QA and other parts on my behalf. Which let's me focus on coding and I don't have to get on the phone at crazy hours.

I know that this is frowned upon in the trade and we all should have one big scrum we all call in together but this works surprisingly well -- which I attribute to the fact that most of the people I interact with are quite senior and just know what to do.