Back when I worked at Microsoft Canada, we’d often pay visits to the nearby city of Waterloo, home of the world-famous University of Waterloo and its killer computer science and engineering programs and RIM. We’d occasionally meet up with some of the RIM folks, either formally or casually, and at some point, one of the RIMmers would say “Someday, we shall be one”. This shouldn’t be news to anyone who hangs out in Waterloo; the “Microsoft should buy RIM” idea has been floating around since before the iPhone crashed the party and left with all the cool kids.
When the headline Microsoft Signs Licensing Agreement with Research in Motion appeared earlier today, sometechwriters had to make it very clear that this licensing deal “isn’t what you think”. It’s a licensing agreement for the exFAT file system, the successor to FAT, whose 32-bit file allocation table (from which the FAT acronym comes) limits filesizes to 4GB. exFAT-formatted storage will appear in “some BlackBerry models”. If you bounce files back and forth between Macs and Windows boxes on external drives or naked drives and “toasters”, exFAT’s a great way to format them, as the modern versions of those OSs read exFAT “right out of the box”. exFAT was designed with Flash drive technology in mind, requiring less processor power and memory.
This article’s been sitting in my “Drafts” folder for the past couple of weeks, and I thought it was time to set it free. While it’s not exactly new, it’s still valid, and Jaclyn’s story is a good one. Enjoy!
Jaclyn Konzelmann’s story is similar to mine: she joined Microsoft a couple of years ago, and after a couple of years, she left to join an ecommerce startup. A couple of years ago, she landed a job at The Empire working with the Office team on Outlook. An offer to work on one of the most-used pieces of software in the world was a golden opportunity, and after some deliberation, she moved from the Toronto area to Seattle. She enjoyed her time at the company for a while, but the job lost its lustre. To borrow a phrase that’s been making the rounds since the release of The Dark Knight Rises, the structures at work became shackles.
The wrong kind of meritocracy. “One of the pieces of feedback I received during my time at Microsoft was that I needed to send out more status updates,” writes Jaclyn. “It wasn’t that I wasn’t doing enough work; it was that I wasn’t being vocal enough about it.”
They want robots to build Office (which explains a lot of things about its design). “When I talked to skip level (my manager’s manager) about my frustrations and why I was having a hard time being excited and motivated, he understood where I was coming from, but there wasn’t much that could be done about it. I was told about the History of Office and how it had always attracted a certain personality type – particularly people that are not very warm, open or friendly, who can churn through processes and data and focus only on the bottom line. In short, he actually compared this optimal personality type to a robot.”
The annual review system. “I was told that as a new hire I would essentially be guaranteed ranking of 3. They understood that people need time to adjust so on our team, and in Office in general, it was common practice to rank new hires as 3s. Management liked to think that this would make new hires feel less intimidated by being, well, new. In reality all this did was stifle my desire to outperform and be great.”
She had a great team, but it was cannibalized. “The one thing that I did love about Microsoft was my team. I worked on a team that was full of people that were young, full of life, and were just generally fun to be around. I enjoyed going to lunch with them and many of them I hung out with after work. Then one day, one of them left. Then another one disappeared. And so the trend continued. Soon, the team that I once loved being on, had turned into a toxic environment. People were slowly being pulled from one project to start working on another secret more exciting project…I was one of the ones left behind to clean up the mess of the old project and it was terrible.”
Less rock, more talk. “While people were trying to solve ship-blocking issues, here I was in a never-ending debate over whether or not a string that would sometimes appear in the status bar of one of the Office Apps should be using Title Case, Capitols or Sentence Case. There were numerous arguments made for each of these designs, endless mockups were created and discussed over tediously long emails and meetings. People were brought in from several partner teams to weigh in on the issue, but never actually help drive to a final decision. Several weeks later I was finally able to close on it and get buy in from all the partner teams, only to have my Manager come in to my office and tell me he wasn’t quite sure about the final design direction. It was at this point that I had had enough.”
She stopped learning. “It became very apparent to me that the way to solve a problem at Microsoft was not to fix it; it was to develop a process on how to vocalize the issue so everyone around you knew that you were aware of it. The attitude wasn’t “get things done” it was “create a process”. Not learning has always been a deal breaker for me in life – the moment I stop learning I know something needs to change.”
What proved to be incredibly useful is the video above created by the people behind the “surviving a startup” site Working for Wonka. This video is the last of their “How to Write a Business Plan” series; while the executive summary is the first thing in a business plan, it should be the last part you write. They use the amusing example of Tom and Jerry Inc. and their better mousetrap to illustrate the plan’s various parts of the plan, and the series was both entertaining and helpful. If you’re looking for a guide on writing executive summaries or the entire business plan for your startup, the Working for Wonka videos are a great place to start.
The Go programming language has recently been getting some developer love. My former boss’ boss, Shopify CEO Tobias “Tobi” Lütke, tweeted on September 12th:
I have now completed two projects in Go. I predict that it’s going to be the dominant language for server work. #golang
A day after Tobi’s tweet, O’Reilly Radar posted Why We Need Go, an article featuring a video interview with Google developer, Canadian geek, co-creator of UTF-8 and one of the co-creators of Go, Rob Pike:
A couple of days after that, Jordan Orelli posted Why I Went From Python to Go (and Not Node.js) on his blog. As a Python programmer searching for a suitable way to write concurrent server-side code, he was disappointed with his options:
…concurrency is possible in Python, but it is an awkward affair that often feels bolted on, fractures the experienced Python programmers into different factions (Twisted is better! No, Tornado is better! Wait, you’re both dumb, use Brubeck!), and confuses the inexperienced Python programmers. To say that concurrency is possible in Python, but it is not idiomatic in Python, would be an understatement.
He also tried Node.js, but as he puts it, “I’m happy that the notion of concurrency is put front and center, but now parallelism feels bolted on.”
A recommendation from Patrick Crosby (former OKCupid CTO, founder of StatHat, which is built in Go) led Orelli to Go, and he writes “and I’ve never looked back.”
Why Go?
Go, a Jordan Orelli observed, has concurrency baked in. When written idiomatically, Go’s compiler creates applications that run concurrently and scale to various architectures. On single-core machines, the compiler time-slices; on multicore machines, it distributes jobs across threads.
Go features goroutines (a play of words on coroutines), which are like functions that complete asynchronously. Communications between goroutines is done explicitly via strongly-typed input and output channels that limit interactions between threads. Goroutines are also less memory-intensive than C threads by orders of magnitude, allowing your program to perform more parallel operations on the same architecture.
Go was designed to reduce the clutter that has crept into a number of programming languages with a simple syntax, lean keyword set, and the elimination of archaic things like header files, forward declarations and “stuttering” such as foo.Foo* myFoo = new(foo.Foo).
Go feels like the love-child of Python and C: high-level and rich enough so that you’re not doing so much yak-shaving, low-level enough for speed and control.
The starting place for all things Go is the Go programming language site, which features downloads for various OSs and architectures, documentation, the “Try Go” experimentation sandbox and other goodies such as this introductory video:
Addison-Wesley has a couple of books: Programming in Go and The Go Programming Language Phrasebook. I’ve got the Phrasebook, and it’s a great way for someone familiar with programming and C-syntax languages to quickly get up to speed with Go programming.
For your convenience and weekend viewing, here are videos for the recent Apple iPhone 5, Amazon Kindle Family and Nokia Lumia 920 announcements, all in one place. Enjoy!
Last night, I got this message from RT Lechow via Facebook:
“I no tech lunch” over the past few months was because I decided to go on summer vacation. Now that summer vacation’s over and I’m back at work making mobile software, it’s time to revive the monthly tech lunch. Ladies and gentlemen, I present to you the return of…
…the Toronto Techie Dim Sum! Here are the details:
When: Wednesday, September 19th, from noon until about 1:30 p.m.. Sometimes we get really deep into a conversational topic.
How much: We split the bill evenly, and no matter how much we’ve managed to gorge ourselves, I’ve never seen it go higher that $12 a person.
Why: Because I love doing the community-building thing and want to catch up with all of you.
As always, this is just a lunch gathering of Toronto-area people who either work in tech, hang out with people who work in tech, or who just simply like tech and techies. There’s no agenda, no set topics, no presentations – just good people, good conversation and good (and inexpensive) food.
Once again, you don’t have to be a developer to attend! If you take part in the activity of writing software, building web sites or cobbling together technologies, or if you just like hanging out with the very nice people who comprise Toronto’s active and vibrant tech scene, you’re more than welcome to join us for lunch!
Back when I worked at Microsoft Canada, we’d often pay visits to the nearby city of Waterloo, home of the world-famous University of Waterloo and its killer computer science and engineering programs and RIM. We’d occasionally meet up with some of the RIM folks, either formally or casually, and at some point, one of the RIMmers would say “Someday, we shall be one”. This shouldn’t be news to anyone who hangs out in Waterloo; the “Microsoft should buy RIM” idea has been floating around since before the iPhone crashed the party and left with all the cool kids.
A couple of days after that, Jordan Orelli posted 
