I’m not surprised that the best image to accompany any commentary about Richard Stallman’s rant about cloud computing from The Simpsons. Mathew Ingram (who had the best article title on the topic) pointed to Enomaly CTO Reuven Cohen’s blog ElasticVapor, where this gem can be found:
[This article also appears in my personal blog, The Adventures of Accordion Guy in the 21st Century.]
Hello. My name is Joey deVilla, and I am unemployed.
Hmmm. Let’s try that again.
Hello. My name is Joey deVilla, and I am between jobs.
That has a much better ring to it. An optimistic, “this too shall pass” kind of vibe. Maybe the third time will be the charm.
Hello, My name is Joey deVilla, and today is Day One of a new chapter in my career.
There we go.
Many people are in the same situation.
Even if you take only my industry — the software and web industry — into account, a lot of people are feeling the same pain. The unemployment rate in our hub, Silicon Valley, has gone up for the fourth consecutive month and hit 6.6%, its highest level in four years. People who follow the industry are writing articles warning us that it’s not if you’ll get laid off, but when. Even Robert Scoble, who’s probably one of the most sunny and optimistic tech bloggers out there has recently written articles with titles like Surviving the 2008 Recession and What to Do if You’re Laid Off in the 2008 Recession.
The “Bailout Protest” march on Wall Street.
It’s bad all ’round. As I write this, a Google News search for the term “financial crisis” yields just shy of 200,000 results. There are articles with titles like:
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.
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.
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.
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:
“Clippy” dialog created using imageGenerator.net’s Clippy Image Generator.
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.
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:
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”.
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.
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.
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”.
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.
And to the rest of you: this gun’s for hire!
(Here’s 
.)
![](http://globalnerdy.com/wordpress/wp-content/uploads/2008/07/laid_off.jpg "\\"Laid Off\\" slide from \\"CouchDB and Me\\"")
The “Laid Off” slide from Damian Katz’s presentation at RubyFringe.
This does not bode well: Kara Swisher, author of the BoomTown blog and co-producer of the “D: All Things Digital” conference says that while the current economic downturn is hitting bank employees now, it’ll spill over into other industries, and that includes ours:
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!
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.
Here’s the abstract for his presentation (from this entry from Corina’s blog):
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
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
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:
There are a few slots still open at tonight’s Ruby on Rails Project Night, which takes place in Accordion City’s Kensington Market Area. It’s happening tonight at 6 p.m. at the Rich Media Institute (156 Augusta Avenue). If you want to attend let organizer Corina Newby know at corecorina@hotmail.com.
Here’s what presenter Paul Doerwald has to say about his topic tonight:
“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’s what presenter James “Smalltalk Tidbits, Industry Rants” Robertson has to say about his presentation:
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!
“I’m a PC, and I’ve been turned into a stereotype,” says the John Hodgman lookalike at the start of Microsoft’s new Seinfeld-free commercials. Then they jump to all sorts of people saying “I’m a PC”.
The message is simple: PC users aren’t all nerdy puffy white guys in tweed suits — many different people use PCs and they leading interesting lives and do cool things with them. If the goal of Microsoft’s new ad campaign is to counter Apple’s “I’m a Mac/I’m a PC” ads and rehabilitate Microsoft’s and Windows’ sagging image, these ads are doing a much better job than the Seinfeld/Gates” ads (here’s the first ad, here’s the longer follow-up) about nothing.
Take a look:
What do you think?