Because I was laid off and not fired from my former place of employment, they’re taking me out for a farewell dinner on Tuesday night. It’s a nice gesture on their part, and I appreciate it greatly.
I’m allowed to choose the restaurant, and I must let them know my choice by Monday, October 6th. The problem is that I’ve just got too much on the brain and need help picking a place. If you’ve got suggestions, I’d like to hear them!
Some parameters:
It should be within easy walking/transit travel of Queen and Spadina (that’s where the office is)
My guess is that there will be about 10 people total.
There will be drinking. A lot of it. At least 2 two rounds of “Irish Car Bombs”, too.
It can’t be terribly expensive (which means that Nota Bene is off the list).
The usual office after-work hangouts are Wayne Gretzky’s and Jack Astor’s. While perfectly serviceable, I’m looking for alternatives.
Provides a layperson-friendly, non-drowsy explanation of how the credit crisis came about
Suggests the single most important thing you can do to protect yourself and your interests during the credit crisis (and in fact, any crisis, including being laid off during a credit crisis)
Don’t let the article’s apparent length scare you off — read it! Yes, it’s ten screens, but it’s set in a narrow column. If you’re still skittish about reading that much, shame on you, and here’s the part on which I want to focus:
Whatever the case, the best thing you can do to protect yourself and your interests is to make friends. The more we are willing to do for each other on our own terms and for compensation that doesn’t necessarily involve the until-recently-almighty dollar, the less vulnerable we are to the movements of markets that, quite frankly, have nothing to do with us.
If you’re sourcing your garlic from your neighbor over the hill instead of the Big Ag conglomerate over the ocean, then shifts in the exchange rate won’t matter much. If you’re using a local currency to pay your mechanic to adjust your brakes, or your chiropractor to adjust your back, then a global liquidity crisis won’t affect your ability to pay for either. If you move to a place because you’re looking for smart people instead of a smart real estate investment, you’re less likely to be suckered by high costs of a “hot” city or neighborhood, and more likely to find the kinds of people willing to serve as a social network, if for no other reason than they’re less busy servicing their mortgages.
I think Rushkoff’s got the right idea, and I’d like to torque it a little further. Forget for a moment the more fanciful ideas of printing your own “Canadian Tire Money”; when he says “local currency”, I want you think of these things:
Reputation,
Goodwill,
and most importantly, Luck.
Among the many things that I’m churning in my brain right now — along with updating the resume, finding a place to put all the stuff that I used to keep at the office and getting that eye appointment with Dr. Heeney before my work-provided insurance coverage expires — is real-world testing an idea and writing about it here. That idea rests on two principles, namely:
Having friends and being friendly makes you lucky. I’ve always suspected it, and Marc Myers wrote a book on the topic.
I’d rather be lucky than smart. It’s the mantra of my all-time favourite financial planner, whom I shall refer to as “P. Kizzy”. If I get even a tenth of P. Kizzy’s business acumen, I will be a very happy man.
Watch this space, ’cause I’m going to expand on those ideas!
When the news is filled with talk of credit crunches, bank bailouts and poorly-thought-out metaphors, you can be certain that every business is adjusting their plans to ensure that it doesn’t go under. Cutting spending is one of the most important of these adjustments, and since employee salaries are expenses, companies are laying off the employees they believe they can do without and slowing down (if not stopping) their hiring.
This is not a good time to look for a job nor lose one.
What to Do?
Losing your job is a shaming, stress-inducing, heart-rending, and even frightening experience at the best of times. Losing your job at the start of what some people in the media are calling the New Great Depression is far worse, even if you think they’re exaggerating for effect.
In the time since I posted the article in which I announced that I had been let go, I’ve received about a dozen emails from people who’ve said that they’re in the same situation. They have no idea what to do and asked me what I was doing and if I had any advice.
I have some observations and suggestions, some of it from my layoff experience back in 2002 and some of it from the past few days’ experiences, and I’ve written them below.
You Will Know When You’re Called in for “The Meeting”
I knew I was being brought in for the “your services are no longer required” meeting the moment I was invited to it.
Many people dismiss intuition, but in experience, I have found that a well-trained intuitive sense will often serve you well in those situations where the situation is murky or when rationality is following the wrong path. I susbscribe to the theory that intiuition is your brain doing some massively parallel processing, subconsciously “filling in the missing pieces” when you are presented with incomplete information. That’s why Poincare said “It is through science that we prove, but through intuition that we discover.”
It might have been something in the Director of Tech’s voice or his body language. Perhaps it was that there’d been little for me to do in the past little while because of the overlap between our jobs. Maybe the fact that the meeting had been called up out of the blue with no explanation as to what it was about was the tip-off. All these hints would be clear to a detached observer, but to someone right in the middle of the situation, they might not be so apparent. Thanks (or no thanks, perhaps?) to a flash of intuition, I had a pretty good idea of what I was in for.
A quick aside: I believe that intuition is not independent of learning and experience, but enhanced by it. When intuition “fills in the missing pieces”, it has to get those pieces from somewhere. Without learning, and even more importantly, the regular application of that learning, intuition is no better than flipping a coin.
You Have Moments to Get a Grip
Armed with that intuitive flash, I had the twenty or so seconds’ travel time between my desk and the meeting room to collect myself. At this point, I only had a vague sense that this was my termination meeting; intuition isn’t a straight-forward thing like a warning light on your car’s dashboard or a pop-up window on your computer:
Do whatever it takes to steel yourself for the bad news. Whether it’s deep breathing, couting to ten, reciting your own personal mantra or firing up your “poker face”, you want to get ready to conduct yourself at the meeting with as much grace, aplomb and professionalism as you can muster.
The Second Most Important Meeting You Might Ever Have with Your Employer
I’ll admit that my termination meeting wasn’t as uncomfortable as this one.
(In case you were wondering, the most important one is the job interview.)
I used to work as a DJ at a popular campus pub at Crazy Go Nuts University. Both the atmosphere and the vantage point offered by the DJ booth gave me the opportunities to witness many breakups from a detached third-party point of view, whether I want to see them or not. Even at their best, breakups are pretty rough; when they get ugly, you can’t help but feel shame for the couple.
No matter what you’re feeling at the meeting, you want your termination to be as good a breakup as possible. This means that you must handle the meeting professionally. The way you behave at this meeting will set the tone for your termination. If it is full of freak-outs and acrimony, they won’t be inclined to do you any favors. On the other hand, if you conduct yourself in a professional manner, you may gain some goodies such as extra negotiating leverage and a willingness on their part to do what they can for you.
If you can remember these questions through the stress of the meeting, you should ask questions like:
When is my last day?
What is my severance package?
How long will my company insurance coverage last?
When do I have to return the company laptop and Blackberry?
How long do I have to collect my stuff from the office?
What do you want me to do with my current projects and files?
Can I get a letter of recommendation and use you as a reference? (Naturally, if you’re being fired rather than laid off, don’t bother asking this question.)
Don’t worry about memorizing these questions — just remember that you should leave the meeting with a clear idea of what they expect from you and what you can expect from them.
If they’ve given you papers to sign, do not sign them yet. Ask for some time to “look them over”.
Take a Walk as Soon as Possible
This is going to sound terribly touchy-feely new-agey, but I’m going to say it because it’s an important step: at your first opportunity, take a break, get out of the office and go for a walk.
When this first opportunity comes depends on the sort of place where you were and the conditions under which you’re being let go. In some cases, you’ll be asked to pack your things and leave immediately, sometimes with a minder assigned to you so that you don’t go pilfering office supplies. In my case, I was asked to say on for a few days to be debriefed and help with the transfer of responsibilities.
Since I was at the office for a few more days and since it was the sort of place where they’re pretty cool about going out for a break, I went for that walk at the first opportunity. (Besides, what were they going to do, fire me?)
The walk is important because it gets you away from the office and to clear your head. Regular readers of this blog know that I’m usually an easy-going, “go with the flow” kind of guy who’s seen and done some pretty crazy things, and even I needed that walk. I felt twitchy and drained at the same time.
The walk gives you a chance to come down from one of the most stressful experiences you’ll ever face in your working life and come to terms with what’s happened. It is not the time for figuring out what your immediate next steps are; it is the time to collect yourself for figuring out what your next steps are.
Don’t do the walk in a fugue state. Take note of your surroundings. Chances are you’ll see things that you passed by every day but never noticed before. This is good, because it’s preparation for what you’re going to be doing for the next little while: seeing things differently.
Deal with the Shame
No matter how good a job your were doing or how well you served the company, being let go will make you feel like thie cat pictured below:
It will feel as if you had been weighed in the balance and found wanting. In fact, that’s what probably happened. Perhaps you weren’t found wanting as a person or an employee, but when the bean-counters did the books, either you went or the company did.
Thanks to evolution, being let go feels terrible. It feels like getting dumped, which feels terrible because it means that you are failing your biological imperative to keep the species going. Without this feeling, we don’t have the drive to reproduce and thrive, and it’s “goodbye species”.
You deal with the shame, using whatever constructive coping mechanisms work best for you. In my case, I hit the gym, did a little writing, played a little music on the ol’ squeezebox and got involved in some very severe rocket-launcher-assisted altercations in Grand Theft Auto IV.
If you must, have a drink or two but don’t go beyond that. You want to take the edge off, not go on a binge.
You Must Come to this Realization
Crank up your computer’s speakers and enjoy the video below. It’s the Soup Dragons’ 1990 cover of the Rolling Stones’ I’m Free. Don’t be afraid to shake your booty if you feel the urge:
If you need to, play the video a couple of times just to make sure the song’s point soaks in: you’re free.
Once the initial shock of losing your job has worn off, consider this: the future has suddenly become a blank slate. That may sound scary, but you should think of it as liberating.
Think about it. That end-of-the-week progress report that management expects? Not your problem anymore! Getting a response from that contractor for the 50-page spec for that increasingly complicated e-commerce website that you’re responsible for? Somebody else has to deal with it now! Hunting down the bug in the credit card payment gateway? Rubbing an irate client’s belly? Putting new covers on the TPS reports? You’re free of all those responsibilities.
All the day-to-day stuff that you’ve been doing at work has just vanished. This frees you to stop worrying about the doing things for the company and start doing things for you. Without those things taking up your time and thoughts, both your calendar and your mind are free to concentrate on “You, Incorporated”.
In the Next Installment
The next steps, including what you can do with all that spare time.
Life in a startup is full of adventures with its fair share of ups and downs. Budgets shrink and grow, teams shrink and grow and strategies constantly evolve. During these challenging economic times, it’s the companies who maintain their focus while controlling their spending discipline that will survive.
b5media lives and dies by these same rules, and those of us in the ad-driven internet business expect no less. In this current market environment, it is the mandate of a responsible business to look at ways to stretch their dollar and cut their costs.
My role at b5media as Nerd Wrangler, a.k.a. Technical Project Manager, overlaps too closely with the Director of Technology, and there just isn’t enough work to go between the two of us. The Powers That Be at b5 had to make a tough call, but they made the right one for the company: they had to let me go. My final day at the company will be Friday, October 3rd.
I’d like to thank Jeremy Wright and the rest of b5media for taking me on and for the experience at b5 over the past seven months.
With the economic situation obviously worsening – don’t say you weren’t warned – BoomTown has no doubt now that Internet companies are in the midst of reevaluating their troop numbers to streamline themselves for the coming few months of financial winter.
There’s general agreement among advertising-supported internet companies that a slowdown in the ad market is coming, and they’re tightening their belts accordingly. This belt-tightening usually takes the form of a double-whammy: layoffs and hiring freezes, and this has led to unemployment in Silicon Valley hitting its highest rate (6.5%) in four years last month, the fourth month in a row it’s increased.
It might not be a bad idea to work on some contingency plans, just in case.
Last Friday marked the return of Ruby on Rails Project Night, a Toronto-based event where developers who worked on Ruby and Rails projects could do in-depth presentations on their current projects or ideas. It was on hiatus for the past couple of months (you can see this entry for the definition of “on hiatus”), but thanks to the efforts of Corina Newby, who helped put together the event at its old venue, it’s back, and judging from the attendance, it was missed. Thanks, Corina, for all your work!
James Robertson
The first speaker was also the special guest (and the reason the event was held on a Friday, as opposed to the typical Monday or Tuesday): James Robertson, whom you may know from his blog Smalltalk Tidbits, Industry Rants. He was on a “Canadian tour”, during which he was talking about the Smalltalk-based web app framework Seaside as well as Webvelocity, which puts the Smalltalk development experience within the browser.
WebVelocity is a new Smalltalk Development Environment that is oriented around Seaside for Web Development and Glorp for Object/Relatonal Mapping. Come and see how WebVelocity re-targets the Smalltalk development experience into the Web Browser and simplifies the challenge of learning a new environment for newcomers. We’ll even build an entire application using Active Record and Scaffolding during the presentation, with minimal programming. If you’re a fan of Ruby on Rails, you need to come out and see this presentation!
Here are my notes from his presentation:
- Seaside is open source, but Smalltalk ain't
- Seaside is maintained in Squeak, which you could call "the open source Smalltalk"
- Ruby on Rails is opinionated
- "Seaside is also opinated; it just has different opinions"
- When building Seaside, Avi Bryant asked "What if I took all the assumptions about web apps...
and ignored them?"
- Some of what I show you is what happens when you blow those assumptions
- The canonical Seaside example -- the number increment/decrement button
(now we know where that disastrous DemoCamp Seaside presentation came from!)
- Seaside uses continuations to remember state
- They enable "proper" support for the backbutton
- Session state info is keyed via a cryptographically secure key in the URL
- With Rails, you're dealing with two different worlds: templates and code
- Seaside is just one world: You don't write any HTML at all, you write all Smalltalk
- It's all in one place
- Support for debugger -- you can debug web apps as if they were desktop apps, with breakpoints and resumes
- In Seaside, the "html" argument is a "brush" that knows how to "paint" HTML
- You can debug in the middle of a page hit
- In beta: Seaside totally within the browser
- Editing code within a webpage, including tooltips and color hinting
- Every time a method is entered and it is syntactically correct, it is auto-saved -- no need to manual save!
- [Shows a Smalltalk debugger with an Ajax front end]
- "In some ways, it's even more productive than the real Smalltalk environment is"
- [Smalltalk console within the browser]
- [Auto-indenting within the browser]
- [Auto-generates a scaffolding-like page]
- The "call" method lets you write web app code very much like writing GUI stuff
Paul Doerwald
The second speaker was Paul Doerwald, who changed his topic from the more Ruby/Rails-specific “insights gained from working with ActiveRecord validation” to a more general (but still interesting) topic: Agile Documentation. He figured that it might be a better fit with James’ presentation, and it was — it was also quite interesting.
Here’s the abstract for his presentation:
“Programmers generally hate writing documentation. That’s because most documentation is kept separate from the code and becomes hard to keep up-to-date. Besides violating the DRY principle… it can lead to misleading documentation, which is generally worse than none at all.” [Subramaniam/Hunt ’06]. Why do developers hate writing documentation, and why do stakeholders and managers keep requiring it? Is there agile documentation beyond inline API documentation (JavaDoc, RDoc, etc.) and comments in the code? What parts of a project deserve separate-from-code documentation? How do we identify them, capture them, and keep them relevant?
Tonight’s Toronto Ruby on Rails Project Night presentation discusses the problem of documentation, explores some key aspects to consider when writing effective documentation, and dreams of a future of testable, executable documentation, where non-code knowledge could be integrated into your code.“
And here are my notes from his talk:
- My original presentation was going to be about insights gained from ActiveRecord validation
- But I've decided to change it -- it's now on Agile Documentation
- It's my M.Sc. Thesis!
- "You'll find this talk a bit heavy on problem and not so heavy on solution"
- Think of this as an introduction -- I want to frame things and ask:
what is Agile Documentation?
- By "documentation", I mean by the kind that's by programmers for programmers
- It's not a particularly sexy area
- Frameworks are sexy:
- Rails is sexy
- Django is sexy
- CakePHP is sexy...(for PHP)
- Languages are sexy
- Ruby is sexy
- Objective-C is..."strangely alluring"
- Even databases are sexy! Consider CouchDB and AWS
- What's not sexy?
- Documentation
- Backup -- at least not until Apple's Time Machine
- Both are viewed as a waste of time
- We're developers. We may grudgingly accept the presence of non-developer things,
but we don't want to do them
- Documentation is hard to write
- It seems so much easier to program rather than write
- Writing -- the non code-type -- is not our core competency
- We say "Our code is the authoritative documentation!"
- Consider what DHH said in a "Signal vs. Noise" blog entry in February 2006
- When asked "How do you document your projects?", he replied "We don't."
- He also said:
- "Never worked consistently or successfully"
- "Not necessary for our work"
- "Most Rails developers can walk in and find out"
- "We use Ruby"
- "Method docs only for non-obvious behaviour"
- "Docs mean BDUF"
- "Appropriate only for onerous enviroments with complex policies"
- "Focus on code quality instead"
- Like backups, docs are important
- We're not the only people who'll be working on a project, especially if it's a success
- We don't want to feel like we're wasting time when we're working
- Running a documentation tool and taking its output and pasting it into a Word doc is not DRY
- Why are we writing highly-coupled docs?
- Is there such a thing as agile documentation? I'm going to say yes
- Look at the Agile Manifesto
- "We value working software over comprehensive documentation"
- But it doesn't say that comprehensive documentation isn't valued!
- What's the state of the Art
- For API Documentation, it's JavaDoc
- In Rails, the outer classes are well documented, but not the inner ones
- The JDK is extremely well-documented
- You could say that RSpec is a form of agile documentation
- It's a stretch, but Domain-Specific Languages could also be agile documentation
- After all these, I can only think of process
- When do we do docs? At the beginning of the process? At the end?
- What could agile documentation look like? What does it feel like?
- I borrowed principle from Alastair Cockburn's "Agile Software Development:
The Cooperative Game, 2nd ed."
- The goals set out in the book:
- Finish the game (i.e. finish development and launch the product)
- Set up the game for the next team
- Think of pool: maybe you take the hard shot first to set yourself up later for the easy shot
- Coburn calls this "residue": the stuff that one team leaves behind for the next team
- Residue includes:
- Code
- Process in place
- Documentation
- I would argue that DHH/37signals has an oral form of documentation
- It works if the company doesn't grow too quickly
- What are we really asking for when we ask for the documentation: Tacit Knowledge
- "That which is seen but not noticed"
- It is information that is understood and implied but not stated
- If you've ever brought someone else onto a team, you spend a lot of time
explaining things that are obvious to you
- You might not explain that stuff if you're doing it on paper
- You don't want to end up in a situtation where there's too much documentation
- What can we borrow from software engineering principles?
- Orthogonality
- A good thing in software development
- Intersect at a clear and obvious point and do not influence each other at any other point
- Cohesion
- All attributes and methods are related to the essence of the class
- Don't have people look in 5 different places to get the answer to a single question
- Coupling
- The extent to which one thing is dependent on each other
- To the future
- 5 years ago, unit testing was unheard of in the web development world
- Rails and similar projects have helped popularize unit testing
- We've moved from the point to where we say "testing is awesome"
- Testing is now a core value
- Can we make documentation a core value?
- Agile documentation processes
- Large companies are good at this; open source people not so good
- Looking to Rails:
- Documentaton conventions?
- What if we had 5 steps for writing documentation that did 70% of the work?
- Can we integrate documentation with code?
- In many cases, the docs exist as a Word document
- A step up is to use a Wiki -- support for multiple authors, versioning, linking
- Can we put docs right in the codebase?
- Every Rails app has a doc directory -- can we use that?
- We test code -- is there a way to make testable documentation?
- What if we could tag a method and class with a keyword and make that keyword appear in the docs?
-- We could generate an alert when changes happen
Checking Out the Rich Media Institute
After the presentation, which was held in the Rich Media Institute’s basement-level lecture room, a number of us headed upstairs to check out its main floor. If you’re a techie with a creative bent, this place is like a candy store. The front part is a store full of books, t-shirts, music and other goodies that new media creators and aficionados would love, while the back is a gallery for local interactive artists’ works.
I took some photos of the place and posted them in the gallery below. Click on any of the thumbnails to see a larger version of the picture:
The Tech Bookshelf at the Rich Media Institute
Some of the books available at the Rich Media Institute’s “store” section
The music area of the Rich Media Institute’s “store” section
Another shot of the music area of the Rich Media Institute’s “store” section
“Far from Equilibrium: Essays on Technology and Design Culture”
“Interact or Die!”
Cardboard robot in the “gallery” part of the Rich Media Institute
A wide shot of the “store” part of the Rich Media Institute, taken from the back.
A wide shot of the “store” part of the Rich Media Institute, taken from the front
![](http://globalnerdy.com/wordpress/wp-content/uploads/2008/07/laid_off.jpg "\\"Laid Off\\" slide from \\"CouchDB and Me\\"")
Last Friday marked the return of Ruby on Rails Project Night, a Toronto-based event where developers who worked on Ruby and Rails projects could do in-depth presentations on their current projects or ideas. It was on hiatus for the past couple of months (you can see 
