A few highlights from "My job went to India"

In my previous post (Productivity for Programmers, #2: Efficient vs. Effective) I gushed about Chad Fowler's book My Job Went to India: And All I Got Was This Lousy Book.

As I said earlier, I wish I had read this book as a programmer years ago. Why? Not because it's about coding (it's not), but because it addresses how to think about being valuable to your organization. Yes, it's set in the context of the current outsourcing/offshoring issue, but it's a good read for everyone, esp. as more jobs than programming are moving to India.

As promised, here here are a few of my favorite ideas from it. Highly recommended!

• 3. Lead or Bleed?: I haven't been given the opportunity...? Seize the opportunity!
  
• 4. Invest in Your Intelligence
  
• 5. Be a Generalist: Generalists are rare ... and, therefore, precious.
  
• 7. Don't Put All Your Eggs in Someone Else's Basket, which talks about the "professional services barrier" (more on this later).
  
• 8. Be the Worst:
  • be the worst guy in every band you're in. a) you fit in, b) your playing gets transformed. works in the downward direction too!
    
  • The people around you affect your own performance. Choose your crowd wisely.
• 9. Love It or Leave It:
  
  • You have to be passionate about your work if you want to be great at your work.
    
  • Work because you couldn't not work.
• 12. Find a Mentor
  
• 13. Be a Mentor: To find out if you really know something, try teaching it to someone else. Also, mentors tend not to get laid off.
  
• 21. Remember Who You Work For: Your manager's successes are your successes. Solve your manager's problems.
  
• 24. How Much Are You Worth? Ask "Was I worth it today?"
  
• 28. Learn How to Fail:
  • Every wrong note is but one step away from a right one.
    
  • Stressful times offer the best opportunities to build loyalty.
    
  • A craftsperson is really put to the test when the errors arise. learning to deal with mistakes is a skill that is both highly valuable and difficult to teach.
    
  • Rules: 1) Raise the issue as early as you know about it. 2) Take the blame. 3) Offer a solution. 4) Ask for help.
• 33. Me Rite Reel Nice: You are what you can explain.
  
• 35. Suit Speak: Market your accomplishments in the language of your business, and always have your elevator speech ready, just in case. Answer: "What are you working on?" and "What is the benefit of that?"
  
• 36. Change the World: Have a mission. Make sure people know it.
  
• 37. Let Your Voice Be Heard. With respect to the musician metaphor:
  • The best saxophonist doesn't always get the gig.
    
  • Who you've played with is at least as important as how well you play; musicians are cool by association.
    
  • Sometimes, the better musicians are overlooked for work because everyone assumes they won't be available or because they are too intimidated to ask.
    
  • Music works via a network effect. If your social/music network terminates before reaching someone, it's not likely you'll ever be asked to perform with that person until an intermediary connection is made.
• 38. Build Your Brand: Your name is your brand, and Google never forgets (don't be a jerk).
  
• 42. Already Obsolete: Your shiny new skills are already obsolete. Investigate the bleeding edge.
  
• 43. You've Already Lost Your Job: You are not your job.
  
• 44. Path with No Destination:
  • Focus on doing, not on being done.
    
  • Bad processes create bad products.
    
  • It's how you traverse the path that's important - not the destination.
• 46. Watch the Market: Watch the alpha geeks, and try to be one, or at least "make the hang" with one. (Applies to research as well?)
  
• 47. That Fat Man in the Mirror: Developer, review thyself; do a 360 review: ask trusted people for feedback, using 10 characteristics you feel are important, get constructive info.
  
• 52. Think Global: If I have to depend on someone...I'm going to have better luck if that person feels that I respect them.

Productivity for Programmers, #2: Efficient vs. Effective

Bob Walsh and I are writing a series on Productivity for Programmers, which started with his article Productivity for Programmers, #1: Trusted Systems. In it he identified five trusted systems every programmer should have: Tasks, Decisions, Version Control, Code Snippets, and Bugs. I like Bob's break down (no, not the psychological one resulting from writing "Clear Blogging" - different story), so I want to talk about a related characteristic - Efficiency vs. Effectiveness.


Efficiency

The trusted systems are important, and they are about doing things right, what Drucker called "efficiency" (see David J. Anderson's article Drucker on Effectiveness for a bit more).

In this sense, doing things right means not making people (or yourself) angry because something bad and preventable happened. This is like the The Joel Test applied - You use a source control system (otherwise you could loose your precious baby), you have nightly builds (otherwise you won't know you've broken the build until much later), you have unit tests (otherwise you won't know you've hosed something accidentally), etc.

Similarly for actions/commitments - you should use something like Getting Things Done (otherwise you won't know what you should be working on, and something will fall through the cracks).

Also, your actions/commitments tracking should be integrated with your code-writing and bug-tracking processes. For the former, I strongly suggest an agile methodology like Extreme Programming, which uses stories (further broken down into tasks) to organize programming work. (A great starting point is chromatic's Extreme Programming Pocket Guide - short and concise.) To integrate the two, either block out regular time daily for coding and bug bashing, or transfer story tasks and bug fixing activities to your actions/commitments system - paper, digital, what have you. (I like paper, in spite of my technical bent, but with GTD it doesn't matter. Do pick a self-management system that works with your tools.)

For code snippets use whatever tool you like. I use my patented semi-structured Big-Arse Text File, but wikis and spreadsheets work fine too. In my file I have lots of tips, tricks, and hints, including how to start the database server in debug mode on windows, and the shell command to find text in files (I can never remember the syntax for using find with grep. I can't help it - it's genetic, but marks me as the unwashed...)


In my last job, we set up all these, with great success. It was very comforting getting email at 2am from our cron job saying the build broke, or that a test unexpectedly failed. And having all those unit tests (yes, even the GUIs were test-driven) made my boss very happy. (Not to mention what a mind-blower it was switching to writing tests first; you have to check out Test-driven development - really!)


Effectiveness

So if all that's about being efficient (an important aspect of productivity), where's effective come into play? Drucker's thought was working effectively meant doing the right job (vs. doing the job right - see above). In XP's terms, it starts with the stories being customer-driven. Customers are the ones who get to decide what's important (i.e., what has high business value), with us programmers providing what we know best (technical expertise that guides implementing the whole thing).

But beyond that, you should think about your greater contribution to the organization. You should spend some time every day connecting with the higher-level mission of your business, and thinking about the novel and innovative solutions and tools no one even knows they need yet. This is what moves us from vanilla programmers to more valued "knowledge workers." (The test: are you being told what to do, or are you figuring it out? The latter is what I understand knowledge work to be. The former is more in the "please outsource me" category![1])


So...

So how to do this? First, stop reading now, go out and buy My Job Went to India: And All I Got Was This Lousy Book by Chad Fowler, and read it. Don't let the title fool you - this is the book I wish I'd been handed when I started twenty years ago programming. It's a mind blower; highly recommended.

Second, start (or continue) to stay on top of technology, news, tools, and trends. These are a great source of ideas, and can get you asking those higher-level questions with high value.

Third, give yourself a 20% day [2] - little skunkworks programs (esp. tools that empower others, automate repetitive tasks, etc.) are healthy to work on - both for you and the organization.

Finally, consider starting your own little "Operation Bear Hug" (from Who Says Elephants Can't Dance? by Louis Gerstner - on-line here): visit or call five of your customers, listen carefully to what they love and what they hate about your program, show them you care, then think about whether there's a small change you could make that would implement one of those things, i.e., either add something they'd love, or fix something they hate.


That's about it for now. In the next few posts I'll continue the Productivity for Programmer theme with some highlights from My Job Went to India, then a post about networking tips for geeks. Cheers!


References

• [1] For more on making yourself "untouchable," check out these ideas from The World Is Flat: A Brief History of the Twenty-first Century by Thomas Friedman: The four categories of people whose jobs cannot be outsourced:
  • special - (only a few people) CEOs, stars, sports
    
  • specialized - knowledge workers whose skills are always in demand and not fungible (fungible: work that can be easily digitized and transferred to lower-wage locations)
    
  • anchored - (most Americans) work that must be done in a specific location, involving face-to-face contact with a customer, client, patient, or audience. but there are fungible parts
    
  • really adaptable - constantly acquire new skills, knowledge, and expertise - must be able to constantly create value - make the latest thing in field. adapt as parts of work become fungible. knowing how to "learn how to learn" will be one of the most important assets any worker can have
• [2] From Google's employment page:

  Google engineers all have "20 percent time" in which they're free to pursue projects they're passionate about. This freedom has already produced Google News, Google Suggest, AdSense for Content, and Orkut - products which might otherwise have taken an entire start-up to launch.

  
  

Matt is Back!

OK, that was bad.

I was out sick for the past week. Not your "I feel a little cold coming on, I'm going to take it easy today," but more like "I know I should drink water, but I'm too weak to crawl." Fever of 104+ degrees Fahrenheit (gotta love US units), body wracked by coughing, etc. In other words, just the flu. Answers.com says it well:

An acute contagious viral infection characterized by inflammation of the respiratory tract and by fever, chills, muscular pain, and prostration.

Prostration - quite right.

Interesting facts about being sick:

• It's just like taking sick leave when you're employed, but without the pay.
  
• Be prepared to become seriously depressed once you do feel better. This was unexpected, and unwelcome.
  
• Tracking your actions on a master list GTD-style, instead of scheduling every single one, is great when you're sick. Instead of pushing a ton of them back a week or two, I just had to contact those people on my calendar to reschedule.
  
• Every day I was sick I had anxiety about two pressing projects I had promised to get out. I was finally able to convince myself it was better to be late with them (letting people know, of course), than to kill myself trying to work on them, making mistakes, and generally doing myself and my clients a disservice.
  
• I continued to capture thoughts, ideas, and (more likely) rabid ramblings via my trusty bed-side pad of paper and pen. Those notes are in the Smithsonian now, so I'm glad I did!
  
• I missed my exercise! I do 30 minutes a day, 7 days a week, and being out for a week was nasty. Probably contributed to the depression.
  
• Getting out of the routine - it's hard to get back into the swing. I'm doing exercise, and I'm using the "at least one significant action a day" approach to ensure I am productive again. Even a little thing like rescheduling all my canceled appointments is good.
  
• People didn't mind my canceling their appointments, esp. when I explained I did not want to get them sick. Funny, that.

Anyway, next up: My long-delayed second part on Productivity for Programmers, following Bob Walsh's great Productivity for Programmers, #1: Trusted Systems, the first in our series on the topic.

Stay well!

Congratulations to Bob Walsh on the release of his book "Clear Blogging"

I just wanted to give a public congrats to my multi-talented friend, blogger, and author Bob Walsh, who yesterday announced his book was released. I know Clear Blogging: How People Blogging Are Changing the World and How You Can Join Them will be a smash, and I'm really looking forward to my copy to arrive. Well done, Bob!

Notes from a conversation with writer and journalist Jaclyn Stevenson

Last week I had the pleasure of talking with local writer Jaclyn Stevenson (blog), a full-time journalist at Business West, and a freelance writer and photographer. I met her via multiple referrals from my local network, who all suggested I start getting my name in articles to establish brand and make a connection with an influential writer [1].

In her email response, Jaclyn didn't have plans for current career development stories, but offered to keep the idea on file, and kindly asked me to join her "trends" circle of contributors (yea!) I could have let it go at that, but I figured it'd be fun (and smart) to get to know Jaclyn better, and I was curious as a blogger about how a professional writer works. So I offered to interview her, a turning of the tables she appreciated and agreed to.

Following are some of her insights on the topics of writing, interviewing, managing many projects, and doing the work you love.

Her work

One reason it was such a pleasure talking with Jaclyn is that she loves her job (her emphasis). She wanted to be a writer as a kid, got an English degree, and did it. She likes being able to mix freelance work and a stable job [2] (something that's rare among writers - it's usually one or the other).

She spends 40 hours/week at BusinessWest, and writes about five stories every two weeks. They are a mixture of assigned stories and ones she pitches to her editor. For her free-lance work, she does travel writing ("not so much 'working' as fun"), and takes vacation time to do. She also covers other topics, including travel, sports, health, culture, and technology.

She likes BusinessWest because the people reading appreciate her stories, and especially not being bored to tears. Also, she gets reader feedback, which is rare in other venues, but gets about one note/week at this job.

Managing multiple projects

A writing project often has many contributors, quotes, photos, etc, which makes tracking the various moving parts important. She likes taking notes by hand in her reporter's notebook, but has to watch the risk of multiple pads (Getting Things Done practitioners will recognize the collection habit at work here). Here's a typical workflow for her:

• Pitches idea to many outlets,
  
• Waits,
  
• Gets into phone call mode (details, expectations, price),
  
• Travels (makes own arrangements),
  
• While there: gets her press pass and starts walking, and having conversations,
  
• Comes home with all kinds of stuff (notes, tiny pieces of paper) - "artifacts with character",
  
• Then: Must turn into a work!

Every story gets its own folder, and she's spread out while she's working - has a "sea of paper" - but gathers it up when done (a nice practice - but hey, I'm biased). During the process she gets about 30-40 emails/day and processes them daily at same time [4]. When she's done she quits the program (another great practice).

While writing the story there are 2-10 rounds of editing (every editor and publisher are different in their style, needs, ad how they work). She transcribes recordings [3] made in the field into her computer, adding value by not typing them verbatim. Then she sends it out with photos and waits for it to come out. A "solid end to many moving pieces."

Finally, she writes many thank-you notes to readers and contributors, something I've been working on doing more of [5].

Fees

On what to charge for her work [6], Jaclyn finds selling herself is hard, and brings to the forefront many issues, including self-esteem. She says that, for writing, fees vary widely according to many factors, depending on whom she's working with. Because prose structure varies, the fee might be per word, per inch, or flat, something that would make practicing vale-based fees a challenge.

Finally, for writers working free-lance (like any self-employed person) the work can be very up and down.

Interviewing

Having good questions is very important preparation for an interview, as is analytical listening. Doing the latter helps track where a person's passion is, which is very important for Jaclyn. If the interview isn't going anywhere and you get lost, you can ask a question like "Can you give me some history of the business?" which leads to passion. Another favorite is "What's next on the drawing board?"

She says letting go preconceived notions about the person and her job are scary (for example, you can look unintelligent), but a "teach me" attitude is powerful. However, you have to let go of the ego.

I asked for her top interviewing mistakes. Here they are:

• Not listening,
  
• Not managing nervousness (you can end up asking questions you didn't want to ask),
  
• Not asking a question if you don't understand (ask anyway - don't assume you can ask later),
  
• Not doing your research,
  
• Not following up with a fact-checker email, and
  
• Not using multiple pairs of eyes (use your editor - a good one will think of things you forgot or didn't think of).
  

Generally, Jaclyn says to "ask like you're two years old." This will allow you to understand well enough to explain the ideas/story to others.

Writing

She looks at writing as equal parts craft and art. The craft involves forming clear sentences, varying paragraph length, and the basic story structure. The art is around the story, and the poetry of language.

Writing in a daily newspaper format (which she doesn't do) is harder - it's structure-heavy, and tends to be more informative than entertaining.

Finally, she says "listen to your mentors." As with any practice that involves mastery [7], it's a key to learning and getting better.

Self-promotion/PR from readers

I asked Jaclyn about being contacted by people with story suggestions. She said that for the most part it's fine, and usually a win/win (she needs stories, people like press). It's best to come with a solid idea, and one that's in a niche is even better. Also, novelty is important - she needs a hook/motivator that answers "How is this different?"

Final points

Jaclyn suggests writing a variety of forms - i.e., to "no put all your eggs in one writing basket." She suggests trying poetry, fiction, and magazines for starters.

Because writing is such a broad skill, she thinks it will always be important, and she believes in her career. That said, she claims it's "her only weapon." I agree - being a programmer, I realize the power of language, and that natural language is the ultimate tool for building mental structures in others.

Finally, she says to internalize people you admire (in her case, she's "chilled" because of that), and to maintain perspective. "We're not building rocket ships."

Thanks Jaclyn!

Suggested writing references

Jaclyn says "The number one reference material I can suggest is the AP Stylebook (Wikipedia entry), updated every year." It's "a great desk staple that has answers to questions a lot of bloggers who hope to streamline their writing probably have."

She also suggests reading as much of the types of things we'd like to write as possible, and generally being "voracious" readers. She has a large personal library, and subscribes to many magazines (as she's a magazine writer). With echos of Steve Leveen's The Little Guide to Your Well-Read Life, she likes owning the books, what she calls "a tangible mini-Google," and likes the synchronicity of finding unrelated nuggets along the way.

Here are some of her other picks on writing:

• On Writing by Stephen King
  
• Families Writing by Peter Stillman: "Creative writing experiences for families: writing recollections, whims, stories, the troubling, sad, or silly things that together make your family different. He also wrote Write Away!, Planting by the Moon, and Writing Your Way."
  
• Zen in the Art of Writing: Essays on Creativity by Ray Bradbury
  
• How to Be Alone: Essays by Jonathan Franzen: "Not really a writing theory book per se, but personal essays by Franzen, so there's a lot to glean there."
  
• News Is a Verb by Pete Hamill: "A look at journalism at the end of the twentieth century - also an interesting source for bloggers, I bet."
  
• Lessons from a Lifetime of Writing: A Novelist Looks at His Craft by David Morrell

Footnotes

• [1] This is something my consulting peers have also suggested, with Merlin Mann arguably being the most successful at it. Though my friend Dan Markovitz is also impressive (The Boston Globe and TIME).
• [2] Use this query to see some of her BusinessWest articles.
  
• [3] See Notes on using a digital voice recorder for taking reading notes.
  
• [4] For more on email, check out these nice summaries: Chris Campbell's A Guide to Email Roundup and Merlin Mann's Recap: Becoming an Email Ninja.
  
• [5] Big thanks go to reader Don Gallagher, who sent me an excellent article on thank-you notes ("The power of a note" by Fred Bauer, Reader's Digest, Dec 1991 - check your library for it). The gist is the four S's: sincere, short, specific, and spontaneous. You may also enjoy Thank-You Notes.
  
• [6] See Matt's Idea Blog: Books, value, fees, and major changes in perspective for why I think basing fees on value, instead of a commodity (including your time) makes sense.
  
• [7] See George Leonard's book Mastery: The Keys to Success and Long-Term Fulfillment, in which Instruction is a fundamental key (along with Practice, Surrender, Intentionality, and The Edge). Great book...