CAT | Developers
Depending on who you talk to, the bubble is either already here, or it’s not coming at all.
I say screw the Tech Bubble, it doesn’t matter if you have a plan.
No, I’m not living in some fantasy world where my life is somehow insulated from the realities of the stock market, Moore’s Law, and the social networking phenomena that now have every VC scrambling to file their S-1 before the public figures it out. But having lived through the last tech bubble, I realized something incredibly important a number of years ago.
You are the manager of you.
Not the company you work for. Not the school you’re at. Not the career you’re stuck in. You are in control of whatever you want to do.
Your reaction to that statement says a lot about your personality. If you thought that’s laughingly obvious, then you probably manage your career fairly aggressively already. That’s awesome. You can skip a few paragraphs.
For some people, this is a terrifying possibility and they’d rather remain safely in their cubicles, hoping they still have a job in 6 months after the next round of layoffs happens. The very act of having to make hard choices on a recurring basis really scares folks. The economic uncertainty of a tech bubble brings these sorts of fears to the surface and you’ll either look at them long and hard, or bury them quickly and get back to your job.
I’m definitely not a cubicle hider. And after this post, I hope you won’t be either.
My good friend Ted once told me, “[Your current situation/the economy/the company] is what it is. Control what you can. Start with yourself.” And so I ask you this very critical question:
If the tech bubble happened today and you ended up losing your current job, what’s your Plan B?
Do you even have a Plan B? If not, don’t despair. I have some tried and true suggestions below you can explore to decide what best fits your personality. There’s no one-size-fits-all solution. But you ought to have something in your back pocket, just in case.
Plan B #1: Join a startup/Create a startup
What it is: Startups are small companies with aggressive product development and marketing timelines attempting to capitalize on new, untapped, or underdeveloped markets quickly using novel technologies or solutions where others have failed previously. A startup’s main aim is to “go big or go home”, meaning they want to have a major liquidity event that will make the founders and employees very wealthy.
The good: Startups offer really interesting experiences building products from scratch and often bringing them to markets where people didn’t know they needed something this badly. But if the company is successful, you’re in on the ground floor with shares and probably a very strong role in the company’s decision making process. Maybe even a three letter acronym after your name.
The bad: High failure rates. Long hours. Possible burnout. Startups are traditionally funded through venture capitalists, although this isn’t a strict requirement. Eventually, though, VCs become involved before the “big day” and that can lead to friction.
The ugly: The Dot Com Bust. Smoking craters of companies when the founders didn’t know how to bring a product to a market, or listen to their customers to find out what they really wanted. People who lose their last paychecks because the company went under.
What you need to prepare: If you’re coming from a “safer job”, you should keep a cash reserve (3-6 months if possible) to either front-load or back-load your landing, depending on the company, the timing and your risk tolerance.
Why it might not be for you: Startups are often heavily populated with young, single folks. There’s a reason for that. Make sure your personal situation is a good cultural fit before you start counting those shares up.
Plan B #2: Start a Micro Business (Lifestyle Entrepreneur)
What it is: A Micro Business is a small, one-person enterprise where you are in charge of everything: development, marketing, customer support and taking out the trash. The idea of a Micro Business is to grow large enough to support yourself, but not necessarily grow to excessive size for the sake of growth.
The good: Micro Businesses can scratch the itch of wanting to be on your own and make something, but without the need to get large amounts of outside funding from venture capitalists since the end goal is different. You can start a venture like this “on the side” without having to quit your job outright and possibly continue to manage it while working the “day job”. Patrick McKenzie is a famous example of how to run a business on 5 hours a week.
The bad: Possible burnout. Long hours if you have a day job plus a side venture. If you try to do it all without some kind of plan, like outsourcing some tasks, you can get overwhelmed quickly.
The ugly: If you fail to validate your ideas properly, you can waste tons of time and money on a “pet project” with nothing to show for it.
What you need to prepare: You’ll need three things–an idea (or product), some cash and time to build it, and some very careful vetting of whether that product/idea has any traction with a market. The third item is the hardest and the most overlooked of the three. Some resources like the Micropreneur Academy or Bob Walsh’s 47 Hats can help you tremendously.
Why it might not be for you: If you have a hard time motivating yourself to work on things at home or are easily distracted, you may not be successful with it. If you don’t want to learn all aspects of the business (sales, marketing, support, development), then you’ll have a hard time getting to paid customers.
Plan B #3: Become a Consultant
What it is: Consulting is basically selling your technical abilities on a per-hour/per-day/per-job basis. Most people who get into it find their first customer from a previous job who needs their services when they’ve left to work for someone else. I’ve talked about the challenge in becoming a good consultant in a previous post.
The good: Consulting is very lucrative. If you want to see an instant jump in your income, research comparable rates for your planned skill set and find some customers willing to pay it.
The bad: The first customer is usually what hooks people into the consulting gig. But finding that second customer always proves harder than you think it is. You need to constantly network and be on the lookout for the next gig. If you leverage headhunters, be prepared to take a cut in your rate.
The ugly: Everything is now in your lap: estimated taxes, health insurance, business licenses, managing payroll, buying equipment. That first year can be a big sticker shock for tax penalties if you haven’t planned ahead.
What you need to prepare: A solid marketable skill set, a positive attitude, a potential first and maybe second customer, confidence and a willingness to get things done where no one else succeeds before you. Have a 3-6 month cash reserve when you start out so you have a runway between paying gigs if you need it.
Why it might not be for you: If you hate to network, market yourself, or constantly stay on the lookout for a new opportunity, consulting might be a difficult nut for you to crack beyond that first gig. If you lack a solid network, the time between gigs may be long and very unprofitable. If you don’t like negotiating contracts, you may be taken advantage of at some point.
Those are three suggestions I’d make and clearly I gave them very light treatment here. But the real question is, what’s YOUR plan now? What are you going to do to realize that plan?
The tech bubble may be real, but you don’t need to let you future happen to you, make it happen for yourself.
Did I miss something? Sound out below!
I’ve been doing a considerable amount of candidate interviewing lately and after some serious impedance mismatch on what we got over what was advertised, I decided to browse the general software developer job listings to see if there was a better way to ask for resumes.
Turns out this is a hard problem to get right…but there is a host of subtle double-speak and hidden agendas in the job listings that I thought amusing upon analysis.
So without further ado, I present the Lessons of Failure Translation Guide for Software Job Listings (taken from actual phrases of real job listings):
“Must be facile in multiple languages“: You’d better know everything from COBOL to Arc, and we’re gonna test out your knowledge of building encryption from scratch in FORTRAN as a coding test.
“Proficiency in at least one modern programming language such as C++, Java, or Perl“: Our idea of modern involves the band Nirvana, Netscape Browsers, and Bill Clinton as president. Wait until you hear about our stock option plan!
“We offer a fast-paced environment“: We’re running around in circles so fast, you aren’t going to be able to catch your breath between releases, requirements changes on the night before we push code out to the users, and last-minute-client-demands shoved in before we go to QA. Sleep? Life balance? Conjugal visits on the weekend? Hahahaha…
“Working with a mentor and a team of experienced test and industrial engineers“: Someone is going to stand over your shoulder and criticize every keystroke until you submit completely to their twisted notion of authority.
“To be successful in this role, you must be a motivated and enthusiastic engineer“: You’d damn well better be cheerful about that looking-over-the-shoulder thing.
“be someone who embraces challenges.”: You have no idea the kind of crap we’re waiting to pile on top of you, sucker!
“High energy/self starter with the ability to work independently within the firm’s demanding and highly focused environment.”: We’re a pressure cooker, so you’d better be like a good pot roast or this isn’t going to last long.
“Salary and benefits, commensurate with experience“: We will do everything in our power to pay you the bare minimum to get you in the door.
“Must understand Software analysis, code analysis, requirements analysis, software review, identification of code metrics, system risk analysis, software reliability analysis“: …until we get tired of analysis and demand that you start coding because the release is running late already.
“Maintain standards compliance“: …as long as you deliver the release on time.
“We offer flexible schedules“: How are nights and weekends for you? They’re open? Not anymore…
“Team player“: Can you take orders without back mouthing us?
“Work for a start up“: It’s 2 guys, an espresso machine, and a shared Linux server from Craigslist in this other dude’s apartment. But we’re close to funding…no really!
But really, the crowning joy of this search was the following “Software Programmer Job Description” kept on an HR resource site. I’ll let the insanity speak for itself, which reads like something simultaneously out of the 1970s and 1990s. If you ever encounter such a listing, run my friend. Run away!
And in case you were poised to tear things up in the comment section, maybe this will help:
What phrases and translations have YOU found in your tenure as a developer? Sound out below!
Happy New Year to everyone, first of all. And second, I hope you managed to get your hands on an iPad in the past 6 months because if you haven’t, you’re going to want one.
Why? Because 2011 is definitely going to be the Year of the iPad. Not by an inch, more like a mile. Let me explain why…
Now that I own an iPad, I finally get the hoopla over these devices. I wasn’t impressed when they came out and wasn’t really planning on getting one for the holidays. Thanks to a generous visit from Santa, who despite my best efforts to the contrary with acerbic blog posts considered me worthy of one under the tree, I now own one along with my wife. And I’m impressed. Very impressed.
iPad: The Must-Have Intermediate Computing Device
I’ll coin a new term for tablets: intermediate computing devices, although I’m hoping someone comes up with a better one in the future. To me, the tablet represents a new class of device that isn’t quite in the same class as netbooks and mobile PCs, although categorically they tend to be lumped together. These devices fill a gap where a PC is too cumbersome, but a smartphone isn’t powerful enough, or even large enough. The iPad is clearly king of the tablets right now. I say that, not as an Apple Fanboi, but as a solid convert to the notion this device does actually have a place in your house when you already own a desktop, laptop, media computer (e.g. AppleTV), and smartphone.
Each platform has tremendous utility within its own domain (smartphones are great for keeping in touch on the go, but lousy for typing blog posts, and the laptop is strong where the smartphone is weak, etc). It wasn’t until I actually owned the iPad that I suddenly found places where I really wanted more than my smartphone but much less than my laptop.
Let’s look at a specific example: my wife and I both love Rummy Tile. Getting the boxed game out after the kids are in bed is a bit of a hassle, and we can’t play on anything except a very flat and hard surface. Enter the iPad: each of us downloaded an iPad version and can play against each other sitting in bed via Bluetooth. Comfort and convenience, meet marital competition (For the record, my wife continues to beat me overall, even at the electronic version).
Not satisfied with that? How about this: I leave my email open on my laptop downstairs all the time. Doing so prevents my iPhone from getting email, so I find myself having to run down 2 levels at night to shut down Outlook so I can see email in the morning when I get up. Not with my iPad! I installed Team Viewer and can now remotely login to my laptop, shut it down, or do anything I need on the computer (like grab an attachment from an old email, which I frequently need as well).
Of course, don’t forget the real estate improvement over the smartphone genre: web browsing is a treat by comparison. My wife and I need to lookup things all the time, and the iPad is the perfect device for on-demand, quick-and-easy web surfing. No waiting for boot time of the laptop, no struggle to read the data displayed on the smartphone.
And…The Competition Sucks
After I got the iPad, I thought I’d check out the competition and see how the lay of the land was looking by comparison. It’s not good for the Android folks right now:
- The Dell Streak requires a data plan from, yep, you guessed it, AT&T. It’s cheap if you get the two year data-only plan at $30/month, but as pricey as the iPad otherwise.
- The Google Android tablet has very mediocre reviews to date on Amazon. When the “best helpful review” for it says, “For the price it’s not bad…”, you know you’re in trouble.
- Two of the most promising contenders that generated huge buzz (Notion Ink and the Kno (aimed at college students)) just made the Wired Vaporware 2010 list. Oops.
- The Maylong $99 tablet sold at Walgreens got scathing reviews earlier this year, and continues to hold the distinction of “worst gadget ever“.
- Viewsonic’s G-tablet isn’t exactly burning up sales with comments like “With some sweat equity, you can get it to work…”, and “Next gen hardware, but software needs improvement”. At it’s current price, you can get a 3G iPad, and save on your Advil bills to offset the pain.
- And other low-end competitors are getting smacked around too, like the Augen NBA7800ATP.
- EDIT: For those wondering why I omitted the Samsung Galaxy, see the comments.
Out of the box, the iPad just works, which isn’t something you can say of most tablets mentioned above. At the current prices and capabilities, the Android tablets aren’t a clear win as a lower-end device. The experience is often so poor as to be unusable, and the higher end models are not significantly better than the iPad for nearly the same cash outlay. Never mind that engineers looking at the Android have discovered major issues with the compositing and view system which are primarily software-based, giving extremely poor responsiveness in the touch interface and the animation rates. Android has a ways to go here–either due to hubris or lack of experience.
And while Windows 7 mobile at least got that part right, they are still lagging heavily in this market and will likely remain so for the balance of the year. The market trends clearly favor Apple’s iPad as the hottest “mobile PC device” available, for 3 quarters running.
In short, no one else has a good handle on the market and user experience aside from Apple.
The Golden Last Frontier of Mobile App Development
Lastly, what about the developer community? Well, you can complain about the App Store all you want, but the Android Marketplace still isn’t a whole lot better than when I last wrote about it. Furthermore, the app selection for Android is still considerably worse than than for iPad.
But the real reason you want to get in on the action is that iPad apps aren’t cheap, and therefore command higher revenues from the App Store. The iPad versions of apps are often selling for several multiples (sometimes deserved, sometimes not) over their iPhone counterparts. Even though the average across all apps is only $1 higher for iPad apps, my experience looking at the top-selling apps is somewhat different. Here are a few examples that clearly show a difference if you get in the good graces of the world:
||iPhone Price||iPad Price|
|Plants vs. Zombies||$2.99||$9.99|
|Cut the Rope||$0.99||$1.99|
Some are the same in both (SlingPlayer, LogMeIn) but clearly the experience is vastly different.
In addition to the gaming possibilities of the device, the iPad opens up a whole new world for application development where the increased screen real estate makes a big difference (Netflix avoided the iPhone app for a long time and rightly so until the iPad came along…now it’s one of the top rated iPad apps in the store, and for good reason). And there are precious few decent iPad utility applications out there, making a rich market for those who have the know-how and willingness to surf the treacherous waters of Jobs & Co.
Unless a miracle happens, it looks like Apple has the tablet world by the tail for at least this year. In 2012, assuming the Mayan gods don’t come to punish all of us for bad John Cusack movies, the landscape may change dramatically but for now it’s Steve’s world and we’re just computing in it.
Have you ever tried going through a recruiter to get hired? Or even worse, have you had to use one to hire other people? If you did, you’ve been subject to what I call the Lack-Of-Value Middleman*.
Before you write this off as being too harsh on recruiters in general, consider the following math problem about buying real estate.
Suppose you’re trying to sell your house and you hire a real estate agent to broker the transaction. They tell you they’ll take 3% of the transaction for their efforts and you agree. After a grueling inspection, the agent tells you your house is worth $100,000 in this market climate. The agent suggests pricing the house right at the suggested market value for a quick sale. You, of course, would prefer to price the house at $115,000, because after all, you did that neat stereo upgrade in the basement, your hardwood floors are hand-installed cherry, and your flower garden is the envy of the neighborhood. And you’d like a little price negotiating room so you can actually get the “market value” out of it, right?
So let’s consider three scenarios, your profit and the relative commission generated for the real estate agent. For the sake of argument, let’s say you bought the house for $10,000 so we can factor net profit into the (highly oversimplified**) equation.
Scenario 1: Sell at the Agent’s price
- Sale Price: $100,000
- Agent commission: $3,000
- Your Profit: $87,000 ($100K – $10K -$3K)
Scenario 2: Sell at your price, minus negotiation
- Sale Price: $110,000 (after a $5K negotiation with the buyer)
- Agent commission: $3,300
- Your profit: $96,700 ($110K – $10K – $3.3K)
Scenario 3: Price is too high for market
- Sale Price: $0
- Agent commission: $0
- Your profit: $-10,000
The difference between these three scenarios highlights why real estate agents aren’t motivated to get you the best price, but only to sell your house at any price. If the agent pushes the house out at a “highly desirable price”, they get $3,000. If they push it at a less desirable price and it never sells, they get $0. If they push it at a slightly higher price, they get a measly $300 more than if they just got rid of it at a lower price, at the same amount of work. But your profit margin is HUGELY different, depending on the outcome.
This, my friends, is why you can’t trust real estate agents or recruiters. Because recruiters are under exactly the same set of motivations as real estate agents, but with far less to add into the deal.
A recruiter’s main job is to put you in front of any employer who will hire you. Not necessarily the best employer. Or the best company. Or even the right job. Any job will do, as long as the recruiter gets paid.
Your salary negotiation with a recruiter follows the same path as the house pricing scenario–the recruiter wants to make the deal happen at a reasonable price, but without upsetting the potential employer (scenario 3 is bad for everyone, so the recruiter will claim to be “on your side”). The reality is that anything that seals a deal between you and the employer is “good enough” for the recruiter. But good enough for the recruiter may be not be the best deal for you. This is why you can’t trust recruiters.
A good real estate agent can actually add some value to the house-buying transaction. They can suggest ways to help you dress up a house to get the best deal, negotiate tricky points of a contract when issues arise, and generally smooth the transaction over when things get rough. Bad real estate agents merely shove your house on the market to get it sold and ignore you (I’ve had both).
Recruiters–good or bad, on the other hand, rarely offer more value than the introduction itself. They play buzzword bingo with your resumes and the employers job description in an attempt to pawn you off quickly. They will almost never suggest any way to write your resume more “attractively” and will offer few, if any, tips for interviewing.
As a hiring manager, I can’t tell you how much sewage in the form of badly matched resumes crossed my desk (and continue to do so). As a contractor, I can’t name a single instance of a contract I ever got through a recruiter. Not for lack of trying, because they hound me and most of my developer friends via LinkedIn contact information or our marketing websites.
My message to recruiters is simple: The Dot Com days are long gone, so why are you still using the same tired tactics? Shoving resumes under people’s noses after playing buzzword bingo isn’t working and no one likes it. Why don’t you try to add some real value to the transaction? The hiring managers and contractors of the world are not buying it anymore.
* In all fairness, I get harassed by as many female recruiters as I do male. But Middleperson sounds like someone who might sell to Hobbits.
** If you’ve ever bought a house, you know my model is gratuitously oversimplified, but it serves as a reasonable example, even if it doesn’t take into account all the useless fees charged by the bank, the agents, and everyone in between.
Try this little exercise sometime. In Google, enter your favorite language, followed by the word “sucks”. And then do the same with a language that you just despise. If you can stomach the results for the first page in both cases, you’ll notice:
- Each language always has its strong Fan Boys (or Girls I suppose, but this seems to be primarily male dominated)
- No resolution ever comes of ANY flame war
…despite the fact there are no end to the results that are relevant to the war at hand. We all know flame wars are pointless, and yet we get some perverse satisfaction watching them in the same way people slow down on the highway when they see an accident with an ambulance present. Why is it you can’t seem to get away from them?
That would be the Blub Paradox. First posited by Paul Graham close to a decade ago, I came across it for the first time (yes, I live under a rock sometimes) recently and had an “Aha!” moment with it. Maybe you’ve known about it for years because you crawled out from the rock ages ago. I don’t think it’s all that well known, considering just how many flame wars continue to pop up on blogs, discussion threads and forums.
The Blub Paradox
If you’ve never heard of it before, here’s a brief summary:
(Paul) argues that some languages are more powerful than others and posits a hypothetical middle of the road language called Blub. He describes the gist of the paradox thus:
- As long as our hypothetical Blub programmer is looking down the power continuum, he knows he’s looking down. Languages less powerful than Blub are obviously less powerful, because they’re missing some feature he’s used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn’t realize he’s looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.
Most people without the experience of them can’t see language features as really useful things. I know an otherwise extremely talented programmer who can’t see the value of garbage collection and thinks it simply encourages “lazy programming” even as he struggles to find the right location to delete objects shared and referenced by many others. Are you claiming to be such a renaissance person as to be able instantly to recognize the value and worth of every new programming feature to which you are exposed?
Furthermore, I posit that the language developers spend the most time in becomes their Blub. Meaning that, after some magical point in your development career, switching languages becomes more difficult because you’re trapped in the Blub Paradox.
Flame On, When You’re Stuck with Blub
If you’re stuck on your Blub, you’re going to have that same cynic view of newer programming languages. And there are plenty around today that are getting press that, depending on your perspective, you may have that same “well, they’re probably powerful but they have all that hairy stuff in there I don’t understand” reaction. That’s Blub at work.
I’ve become painfully aware that Java is my Blub. You can see evidence of me stuck in the Blub Paradox in my posts about Google Go. The continuum viewing paradigm above is absolutely bang-on: Spotting a more powerful language is incredibly difficult once you have a long series of programming habits in a particular language. Maybe it’s just a consequence of a long programming career. Could be mental inertia. It doesn’t really matter where it comes from, as long as you are aware of the effect.
You can probably spot any programmer’s Blub, just by asking what he or she works in daily. Jeff Atwood’s is probably C# or ASP by now. Larry Wall’s is perl. Bjarne’s is C++.* The list goes on and on. If you’ve been programming more than 5-7 years in a language, you’ve probably got a Blub too.
What makes this even harder is that your day-to-day work totally absorbs your programming time, particularly as you get older with a family. Finding time for new programming projects on the side gets squeezed and you find yourself falling back on things you already know instead of digging into something you view as weird, but potentially useful. That squeeze may ultimately turn into, “Well, why bother with X when I already have Blub?” That’s the danger of Blub.
It’s OK to have a blind spot. But, you should be aware that it exists and avoid the prejudice filter that comes with it.
The next time you’re tempted to look down on a language because it’s weird, as opposed to just inferior, remember the Blub Paradox and maybe spend some time in it before you strike the match and grab the gasoline. You can bet that I will.
* I am completely guessing on these, based solely on the fact of what I read about their current exploits. I reserve the right to be wrong about any particular programmer’s Blub, while still retaining the right to assert that Blub Paradox is still in effect.
An experiment, posted on LessWrong.com that led to a further diatribe on rationality and rational thinking traps got me thinking too. Here’s the problem:
Once upon a time, there was an instructor who taught physics students. One day she called them into her class, and showed them a wide, square plate of metal, next to a hot radiator. The students each put their hand on the plate, and found the side next to the radiator cool, and the distant side warm. And the instructor said, Why do you think this happens? Some students guessed convection of air currents, and others guessed strange metals in the plate. They devised many creative explanations, none stooping so low as to say “I don’t know” or “This seems impossible.“
And the answer was that before the students entered the room, the instructor turned the plate around.
This is Occam’s Razor at its finest. But these unwitting physics students are no different than the average programmer out there when confronted with a bug report. Take this example of a guy who had a strange logic error in a core Linux package:
A few weeks ago, though, I encountered some bizarre behavior on my desktop, that honestly just didn’t make sense. I spent about half an hour digging to discover what had gone wrong, and eventually determined, conclusively, that my problem was a single undetected flipped bit in RAM.
This guy admirably spent a long, painful session tracking his error to a faulty location in RAM. But his most likely rationale for why?
For me, bitflips due to cosmic rays are one of those problems I always assumed happen to “other people”. I also assumed that even if I saw random cosmic-ray bitflips, my computer would probably just crash, and I’d never really be able to tell the difference from some random kernel bug.
Cosmic rays! Now, the possibility exists, that’s true. But is it the most likely explanation? No, not by a long shot. More likely: faulty RAM due to manufacturing defects. More RAM failures are documented as problems than cosmic ray defects.
Why do we have some perverse belief that all our problems are exotic, unusual and outside of normal?
When you discover a bug in your code, is your response:
- Hmmm, I wonder what simple thing I did wrong here?
- I wonder if there’s a kernel bug in Linux causing that?
Simplicity isn’t just a goal in optimization, but in finding the source of bugs too. Never let the truth interfere with a good story, I always say.
Recently, I was the happy recipient of some very condescending “advice” from the architecture group of a client. The tone, quality and delivery of the information completely overwhelmed the actual message (some of which was actually relevant, and some was off in left field). This pleasant experience reminding me why the term “software architect” has come to be synonymous in some circles with “arrogant jerk who forgot what it’s like to code on a real project”.
I realized that I’ve had that exact same attitude at times and it just didn’t pay off at all. My message was probably lost in the same manner I discarded this guy’s advice in favor of sticking it to The Man and doing whatever I was going to do anyway.
All of this is counterproductive in any development project. Reflecting on the situation a bit more, I realized that there are a handful of key points that all software architects ought to remember. Dispelling the “Ivory Tower” mentality can’t be anything but positive for everyone involved. With that in mind, I bring you the
Five Minute Guide to Avoid Being the Asshole Architect (FMGTABAA):
1) Eat your own dog food
Nothing screams “Ivory Tower” like handing down some code you cobbled together to a group of developers to “figure it all out”. If you write a library to perform common validations, write up a standard test page and post it for all to use. Consider this your uber-test case. Or better yet, write an application that uses that same library and see how it works out. Find out the pain points your consumers will actually feel by becoming one of them. Anyone who hands you code they just put together in a manner they thought “would be useful” shouldn’t be trusted.
2) Standards apply to you too
It’s fun (well, maybe to some people) to put together standards documents that lay out the coding conventions, code organization, source code nomenclature, build structures, and so on. But to publish those standards and fail to hold yourself to them is the highest form of hypocrisy imaginable. If you can’t follow a standard, why would you expect anyone else to follow it too?
By applying the standards to your work, you’re also eating your own dog food in another sense. You see what will be painful for others.
3) Communicate like you are a Teacher, not a Preacher
Architects are supposed to exist as a font of knowledge and experience. Failing to share that information is pretty much against your core job description. But how you communicate that experience is just as important as the information itself. Think of your best teachers in school—did they ever strut at the front of the classroom and tell you how damned smart they were? Doubtful. They found ways to express their knowledge that encouraged your learning and questioning.
That condescending tone I received on the architect’s email was the ultimate turn off. Whatever valid information was being delivered in the message was completely lost because there was no mutual respect.
Power politics kills development projects quicker than baby rattlesnake poison will take out your dog.
4) Lead by example in Documentation
What’s the Number One complaint about open source projects? Lack of, or poorly written documentation. Why is that? Documentation isn’t exactly the Crystal Meth of programming. More like Sominex. No one likes doing it. Especially those that are good at writing code.
Instead of whipping development teams saying, “You need to produce better documentation”, give them a concrete example of your work. That also helps with point #3 (Communication), as well as demonstrating point #2 (Standards Apply to You) and point #1 (Eat Your Dog Food). Push development teams to achieve the standard set by your team for quality.
5) Command from the trenches, not the Ivory Tower
If one idea generated the majority of contempt for software architects, I think this was it. Somewhere along the way, the notion of architecture outside of mainstream development took hold and the notion of the Architecture Group was born.
Not once, in any company I’ve ever worked with or for, did this idea bear positive fruit for the development teams involved. Instead, these segregated groups have generated one or more of the following:
- Contempt for the architecture because the developers had no say in it
- Rejection of the framework because it was impractical to apply to the project at hand
- Blatant disregard for the standards set by architects because the architects did not have to adhere to business needs and company deadlines as a result of the delays introduced by their work
Architects should be a member of the platoon, never a visiting dignitary to the army base. Teams respect the opinion of someone who lives their daily reality side-by-side with them, not someone who hands them the Ten Commandments and walks back to their posh tent.
6) Throwing your prototype/framework/design/UML documentation into the hands of the unwashed masses is not the end of your involvement
No sane building architect would throw their blueprints over to the foreman and expect it to be built in their vision. Related to point #5, architecture teams that believe their involvement is limited to the design phase don’t really understand what it means to be architects. When a building is being built, the architect is on site during the majority of the project, overseeing the effort at a high level, ensuring that little changes are not impacting the big picture. All the while, the architect assists in solving minor problems that arise from his or her design from a practical standpoint.
In short, the architect’s involvement is continuous, not discrete.
7) Attitude may work in the military for commanding respect, but it rarely succeeds in IT
Finally, acting superior, like a know-it-all, or someone who is above listening to others, is just asking to be ignored. Don’t do it. Ever. Not even on a bad hair day.
Friends don’t let friends act like asshole architects. The respect you save may be your own.
Quick! Answer the following question without thinking about it:
How would you rate your programming skills? (Below Average, Average, or Above Average)
Based on psychological studies across many different groups, about 90% of all programmers will answer “Above Average”.
Of course, that can’t possible be true. In a group of 100 people, 50 are above average, 50 are below average. This effect is known as Illusory Superiority. It’s been documented in many domains and even if you’re aware of it, you’ll probably still answer the question above as “Above Average”.
For even more fun, try asking that question to every programmer you know. Don’t ask them in a group, ask them one-on-one to get more ‘honest’ answers. You’ll get similar results, even from people who you know can’t program their way out of a wet paper bag (this is the Dunning-Kruger effect, but it’s related). It’s an epidemic in our profession.
Now, let’s suppose for a second that you’re right–you are actually above average. You are da man. A rock star. God like capacities amongst mere mortals. Keyboards bow in reverence to you as you approach. Trumpets sound on high when you commit on GitHub.
If you’re above average, then chances are you’re an expert at what you do. Calling yourself an expert sounds quite compelling–you get respect, deference, and prestige by being one.
Being an expert means you know it all about your subject. Unfortunately, it also means you’re going to get lazy. It means you’re going to eventually rest on your laurels and sit around thinking you’re better than everyone else instead of actually working to get there. Your expertise will become a liability because you stop trying to learn. Maybe not today, but soon enough.
Instead, why not consider the more likely possibility? You’re average, or heaven forbid, below average. Aside from the personal stigma you might suffer here, think for a second about the real benefits of doing this:
- By assuming you’re not at the top of the pack, you now have incentive to get there
- By assuming you’re not the smartest person in the group, you now have the opportunity to learn something
- By assuming you’re not the best at what you do, you’re going to work harder to improve yourself
Perhaps you’ve heard of beginner’s mind? Summed up by a zen master in classic koan-brevity:
In the beginner’s mind there are many possibilities, in the expert’s mind there are few.
The trap of calling yourself ‘expert’ at software development means that you pigeonhole yourself into some language (Java, Ruby, PHP), some industry (medical devices, social networking, games), or some specialty (embedded programming, enterprise software). Once you establish that expertise, fear of failure arises when you consider going outside that comfort sphere. With your golden hammer of experience, everything appears to you a nail. You stop thinking about screwdrivers and all other possible relevant tools because they’re no longer inside your ‘expertise’.
This is why starting out in software you wonder why “experienced programmers” can’t get X, when you just learned X in a matter of days. X could be anything: closures, object-oriented programming, Ruby on Rails framework, Haskell programming. It doesn’t matter in the end, the expert’s mind is cluttered with old knowledge. The beginner’s mind is open, free of hindrances.
It’s harder to learn when you’re an expert. And this is why being the ‘expert programmer’ is dangerous.
So what’s the number one thing you can do to be the best programmer out there? Start by considering yourself below average. Step out of your comfort zone. Be the averagest.
A master never stops learning, and neither should you.
So, think you’ve got what it takes to be a consultant? Feeling the itch because your current job isn’t motivating you like it used to?
The independence, prospect of better money and the potential for starting your own business make this idea very seductive. A million others have tread this path before you so you’d think it would be easy, right?
Nope. Not even close.
The path to success is littered with the rotting carcasses of those who went before you and failed. Sort of like the great gold rush of 1849 to San Francisco. If you really want to get into it, even after this stern warning, you have my pity. This is anything but an easy path to success, wealth or fame.
Still not daunted? That’s a decent start. Persistence is part of the key to success here. So is intelligence. And confidence. But those things just get you in the door, past the obnoxious bouncer so-to-speak. It’s early in the night, you have to order a drink and do karaoke before you can hit the dance floor. In other words, there’s a lot more to it than you think.
Rather than cover the business aspects of consulting, or even the how to make the jump article, I thought I’d share the secrets of successful consultants I’ve come in contact with over the years. These can make or break your career as an independent contractor. Ignore them at your own peril.
Secret #1: Your reputation is your livelihood. Protect it like your life depends on it.
Your career does actually depend on it. People hire contractors for two reasons: someone said they were worthwhile, or they thought you were the cheapest one available. You get far more jobs from the first recommendation than the second, and the quality of work is higher when they pick you for your reputation rather than your rate.
Secret #2: You are always looking for a new gig. Even when you have a current gig, keep your eyes open at all times.
Unless you’re lucky enough to get two year, iron-clad contracts, you’re always keeping an eye on the end date of your current gig, trying to figure out “What’s next?” If you get a job and think, “Oh, they’ll just keep extending me over and over”, you’re not a consultant, you’re thinking like an employee. You’ll be kicked out as soon as someone realizes it. Pay attention to new opportunities coming around, and have something in your back pocket if your current contract ends or is canceled early.
Secret #3: Assume that if you’re not adding value, you’re overhead and you’ll be fired. Constantly find ways to add value to a project.
This ought to be a rule for employees in general, but sadly, there are too many companies that allow for this sort of inertia to exist in their ranks indefinitely. Often times, this is why a company hires consultants (to get something done), so make sure you’re the person that “gets things done”. I’m already assuming that you’re smart, now you need to deliver on it.
Secret #4: You’re never an employee at the company you contract for, no matter how long you’re there. Maintain a certain distance.
Making friends at your contract jobs is good. Acting like you’re an employee and leaning against the water cooler, chatting with the gang mid-morning is not. Contractors are supposed to be billing every hour they’re on site. Managers tend to watch consultants more closely than employees because they pay top dollar for good contractors and are paranoid about wasting their money. Don’t be the reason you get tossed out.
Secret #5: Network constantly. Everyone is a potential new client.
You never know who is going to need a contractor at their company. You never know who will be promoted to a manager or executive and suddenly be looking for that certain person with some mad skillz to come in and take over some failing project. People end up in unexpected places, and making enemies is never a good idea. Leave companies gracefully, never burn bridges, don’t speak badly of others, even if you have some personal problems with them. These things always come back to haunt you at some later point, without exception. Don’t believe me? You won’t be the exception. Trust me.
While I don’t advocate the smarmy salesman approach, handing out business cards in the restroom at the local bar, you should stay connected. Make sure you keep in touch with people. LinkedIn is a great way to do that. Facebook is another. MySpace, maybe not so much.
Secret #6: Finish what you start. Deliver what you promise. Uphold rigorous ethical standards.
The four fastest ways to end your consulting career:
- Fail to finish a project you were given.
- Leave before your project is finished because you wanted a better, more lucrative job.
- Lack the expertise you claim to have and accept a job based on that premise.
- Do something unethical.
Did I mention your reputation was everything? Software is a small community wherever you practice it. You’ll run into the same folks again and again. If you make a bad impression because of those items above, you can bet they will be remembered somewhere down the line when you’re interviewing at another company, if those people already work there.
To confirm reputations, many managers will ask if anyone on their staff already knows this person (Yep, Secret #1 again). A negative reputation will give the manager a reason to move on to the next candidate. Don’t give them any ammunition.
You need to be cautious about finding new work while employed with another company. You want to maintain your reputation while still networking. It’s a tricky balance, but we’ve already established you’re smart, so this should be no problem.
As far as ethics goes, do I even need to talk about how unethical behavior has screwed pretty much everyone in the world in the last year? OK, good. Moving on.
Secret #7: Consultant is generally synonymous with expert. Make sure you qualify.
You shouldn’t just start consulting right out of school or with little experience. (Accenture, I’m looking at you here with your army of under trained and overpriced pretty boys and girls that you send into large companies like a virus where they try to spread all over the place without being able to tie their own shoes) There are notable exceptions, like where your field of study was highly specialized and you acquired expertise in school along the way from your professors, internships or colleagues. But for software development, you need a few solid projects under your belt to really be able to call yourself a serious consultant. If I had to put a number on it, maybe no less than 5 years experience prior to consulting. There’s no hard-and-fast rule to it, but you should actually know something, otherwise you can’t add value (Secret #3).
Secret #8: You can try to fake it before you make it, but you’ll only get so far. Represent yourself honestly.
There are folks out there that will tell you that a consultant is only 5 pages ahead of the customer in the same book. Sometimes that’s true. Most of the time, it’s not. You need to know your field well enough to be the expert (Secret #7). Not just sound like one, but really walk the walk here.
Secret #9: Consulting in a niche or a general field can be both good and bad. Choose your specialty carefully.
You may get two kinds of advice about entering consulting:
- Stick with something that is popular, but crowded (like Java, C++, .NET)
- Stick with something that is specialized, but has less competition (e.g. Delphi, Embedded C development, etc)
There are pluses and minuses in both sets and neither in my opinion really wins out.
- The popular fields mean you have more work available to you, but competition is much higher which pushes the overall rate for contractors lower in that skill. Java programmers are in this exact situation today.
- The less popular subject areas command much higher rates because of the skill rarity, but finding new projects is much harder and you might be out of work more often. Google Go programmers are in this situation today.
Ideally, you want to be the early adopter of a new technology that will take over the industry, like learning Java in 1995. Predicting those events is nearly impossible, so I’d suggest sticking with the things that interest you. After all, you’ll spend 30% of your life doing them. No sense in punishing yourself needlessly.
Secret #10: You are a professional. In every situation, make sure you act like one.
New contractors are tempted to act just like those around them in a consulting gig: playing politics, cracking jokes, drinking too much at social events, and the like.
The short answer is: Don’t. Not ever. Even when you’re off the clock, you’re still being judged on your behavior. Remember that reputation thing (Secret #1)? Yeah, it still applies at happy hour, or launch parties, or even casual conversation. What about office politics? Understand them but steer clear of participating as much as you can. You’re not an employee (see Secret #4), so stand above that. You’ve been hired to add value, not noise (Secret #3).
If by now, you’re yelling at the monitor saying, “Dave, these aren’t secrets! Everyone knows them!”, then I applaud you. You’re in the absolute minority and you have what it takes to succeed wildly in this field. So go forth and conquer the consulting world with your intuition.
The rest of us will just have to follow this list.
Software has long since lost its glory-days status. We’re not the go-to field anymore. Geeks are no longer revered as gods amongst humanity for our ability to manipulate computers. We get crappy jobs just like everyone else.
So, what is it that still motivates you to work as a software developer?
Is it your fat salary, great perks, and end-of-year bonuses? Unless you’ve been working on Mars for the past two years, I think Computerworld would disagree with you. We’ve been getting kicked in the nads just as hard as everyone else. Between budget cutbacks, layoffs and reductions in benefits or increases in hours, clearly our paychecks are not our primary source of satisfaction.
If money was our primary motive, right now we’d be seeing a mass exodus from the tech sector. So, if it’s not the money, then what is it that we hang on to when we get up each day? Are we really working for those options? That salary bonus?
Turns out, we’re kidding ourselves if we think that’s our real motive as developers.
The assumption: People perform better when given a tangible, and even substantial, reward for completing a task. Think bonuses, stock options, and huge booze-driven parties.
The reality: In a narrow band of actual cases, this is true. (And by narrow, I mean anything that isn’t a cognitive task, simple or complex, according to the research I quote below). By and large, the reward-based incentive actually creates poorer performance in any group of workers for cognitive tasks, regardless of economic background or complexity of the task involved. (Sorry, outsourcers…dangling the reward under your workers noses doesn’t help even when your home country is considerably poorer on average than Western economies. Yet another surprising finding of their research.)
I’m not making this up, nor am I just drawing on anecdotal experience. Watch this 18 minute video from TED and I’ll bet you’re convinced too:
Daniel Pink gave this lecture at the 2009 TED. It’s mind-blowing if you’re stuck in the carrot-and-stick mentality. And I’ll just bet, unless you work for Google, are self-employed, or extremely worldly, you probably are.
I’m not saying that to be mean or controversial. I’m saying that because this mentality has pervasively spread to every business, industry and country on the planet over the past 100 years. It’s not just software development, but we’re hardly immune from its effect.
While we’re not immune to the impact, we do have a lot going for us that gives us an advantage in stepping outside this mentality:
- Developers tend to be social oddballs and the normal conventions seem awkward to us. Social oddballs tend to question things. We don’t like what everyone else likes because, well, we’re nerds and we don’t think like sales people. Or accountants. Or athletes. We’re willing to try things others find weird because we’re weird too.
- Because we’re odd, we tend to be forward thinking and revolutionary in our approaches to workplace advancements. Think about the good aspects of the Dot Com era: pets in the workplace, recreation rooms with pool tables and ping pong, better chairs and desks for people, free lunches. Those innovations didn’t come out of Pepsi, Toyota, or Price Waterhouse Coopers, they came out of tech companies. Every one.
- In doing so, our weird becomes the new normal. Witness the output of the Dot Com era: Aside from the economic meltdown, how many companies now regularly practice some, if not all of those things we did back in the late 90s? (Albeit with more restraint, thankfully)
With that in mind, let’s take Daniel’s idea of the results-oriented work environment (ROWE) forward and create something new for the 21st century. It focuses on three important ideas, which developers already love and embrace:
Autonomy: What developer out there doesn’t like to be given the freedom to do their own thing, on their terms, with their preferred hours, using their tools, environment, IDE, language, operating system and favorite t-shirt? Find me a single developer anywhere that doesn’t crave this kind of freedom and I’ll pay you $10. Seriously. Drop me a contact above. I’m good for it. Of course, you’ll search for the rest of your life and won’t be able to do it.
Mastery: Every developer on the planet wants to get better at what they do. We crave new knowledge like some people quaff coffee after a hangover. Fortunately, the side effects of getting better at development are far more benign than caffeine binging.
Purpose: Nothing is more tedious, horrific, or uninspiring to developers to work on projects that lack any real meaning in the world. Or lack any real direction. Or lack any substantial need from the company. In fact, you can probably point to the brightest points of your career all stemming from those projects that had the deepest meaning to you personally. Maybe the darkest points are those soul-sucking projects that you waded through because you were glad to have a job but desperately waited for things to improve so you could find a better job elsewhere. Preferably where soul-vacuums didn’t exist.
Google gets it: They already advocate the 20% time concept and (near-)complete workplace freedom. Atlassian gets it: They have the Fedex challenge where everyone in the company gets 24 hours to work on something they are interested in, with the caveat you have to deliver it at the end of 24 hours and you must present it to the company. Think those don’t create passion for the company? How about the Nine Things Developers Want More than Money? These points all touch on the same three basic concepts: autonomy, mastery, and purpose.
Does your company “get it”? If the answer is NO, what can you do right now to change your workplace to “get it”? And if that is too Sisyphean a task for you, how about starting your own company instead, that does “get it”?
That’s my challenge for you in 2010. “Make software suck less in the 21st century”