One of my “must-read” blogs, Rands in Repose has a
post
seeking advice on keeping employees who work from home (or any other
remote location) in the loop.
I’m ready to learn and that’s today’s question, “How do you, as a remote employee, stay in the loop?” The converse, if you prefer, is, “How do you, as a co-worker or manager of a remote employee, keep everyone on the same page?” Work-from-home employees is becoming a bigger and bigger trend, and there are a lot of companies that seem to thrive in this environment. When it works, it seems to be a win-win for both the employer and employee. It does introduce a number of issues, particularly if only part of the team is working remotely.
There’s some good advice in the comments for the post, including advice
on tools, as well as cultural issues.
One of the things that impacted me the most about
GTD is lists. It’s such a
ridiculously simple concept, but it’s incredibly powerful. I was
reminded of this recently when I saw an article at Boxes and
Arrows called Check It Twice: The B&A
Staff Reveals the Way They Make
Lists.
It isn’t about GTD at all
really, but it’s useful nonetheless. It includes things like “Holiday
cookies”, “Refrigerator lists”, and even included a bit about
Backpack, but the one that I found most
interesting was called Mantras:
Simplify
Smaller, smaller
Do only what you love, love everything that you do
Embrace constraints
Less
Honor your mistake as a hidden intention
Disrupt business as usual
…And so on.
I like that, I think I’m going to add that to my lists.
Back to my original point, one of the first things I started doing when
I implemented GTD, was to start keeping reference lists. I use the
“Memos” section of my Palm T5 to store them. I was first inspired by
The David’s tip, but I’ve
gone on to create some of my own.
Here’s a sampling:
Fun Projects - Little programming things I may want to do some day.
Model numbers - This is a list of model numbers for much of what
I own. That way when I’m out shopping and I remember that I need to
buy furnace filters, I don’t have to try and remember what size I
have, it’s right there in my list.
Blog topics - Things I may want to write about here someday. *
Music - Various albums, songs, and artists I may want to buy.
Books - Books I want to read
Gift ideas - Throughout the year, when my wife mentions something
she’d like, I jot it down in a list with her name. When it comes
time to buy gifts, I’ve got a list to choose from. I have one of
these lists for everyone I buy gifts for. My kids, parents,
in-laws, etc.
Checklists - I keep checklists for certain things I have to do
regularly, like “Project startup”, “New employee”, etc.
This is only a few of my lists, I probably have 50 or so.
Do you have any lists like this? Share in the comments, I’m always
looking for new ideas.
Mark Cuban, whose writing style I really enjoy, posts a collection of
the articles he’s written over the last few years on how he got to where
he is today.
Steve Pavlina has updated one of his
older articles into a new one titled Do it
Now, in which he
describes the method he used to graduate college in three semesters
with a 3.9 GPA. From the article:
In order to accomplish this goal, I determined I’d have to take 30-40
units per semester, when the average student took 12-15 units. It became
immediately obvious that I’d have to manage my time extremely well if I
wanted to pull this off.
That’s an understatement. I’m not sure that just anyone could pull this
off, but Steve claims he did (and I really don’t have any way of proving
one way or the other).
Regardless, there are some really good time principles in this article.
Definitely worth a read.
His page on c2 has been
turned into a sort of memorial wiki page by the people who had met him.
Aside from the book, he has had a significant impact on a number of
people. I do wish I had gotten to meet him.
Over at the Creating Passionate
Users blog
(which has more useful information on it than any other blog I can think
of), there’s an excellent post called If your software was on a
date
which lays some ground rules for your applications:
How would your software (or product, service, book, cause, etc.) behave
on a date? Perhaps the best model for software developers is the singles
scene, so let’s see how this time-tested dating advice for men might be
applied to software:
The article goes on to give some excellent advice, including “Be
polite, be helpful”, and “Be forgiving”.
It’s an excellent article overall, but I couldn’t help but think there
was one thing missing: “Be easy to get to know”. Offer a free trial.
Show me a flash or Quicktime demo of what you can do (screenshots are a
copout - how many people started using Rails because of the 15 minute
video? I did.), and offer a forum for sharing information with other
users, and with the software’s developers.
37Signals gets this last point very well,
their product blogs are very useful.
Ship It! By Jared Richardson and William Gwaltney Jr.
Introduction
Ship It! is a book about basics. It’s an education in the fundamental practices that are needed to develop software successfully. This is the stuff they don’t teach you in college. Ship It
doesn’t espouse a particular methodology (such as Scrum or XP). Rather,
it is a set of practices. The advantage of this is that you don’t have
to adopt everything in an all-or-nothing fashin. In fact the authors
state explicitly that you should use the things that work and don’t use
the things that don’t work. This will work particularly well in
situations where someone works in an environment that has an entrenched
methodology. While management might not be willing to buy off on a
wholesale switch to a different methodology, many of the practices
outlined in this book don’t require you to spend any money. Therefore,
individual developers, leads, or managers can implement a couple of
practices (say “The List”, and daily meetings) without needing
management approval.
Let me start off by saying that I’m a huge fan of the Pragmatic
Programmers. The original book
completely changed the way I approached programming. I’ve bought several
books from them since then, and have been extremely happy with them all.
This is rare. Even O’Reilly has a few stinkers amongst all of their
great books. The point is, I started reading this book with high
expectations.
The book is divided into four basic sections:
Tools and Infrastructure
Pragmatic Project Techniques
Tracer Bullet Development
Common Problems and How to Solve Them
The first section, Tools and Infrastructure, covers the basics of
software development tools. It not only covers what you need, but how
you should use it. The tools covered here include source control (with
an emphasis on Subversion), build scripts (using tools like Ant and
NAnt), continuous integration, defect and feature tracking, and more.
The book obviously can’t go into each tool in great depth, but there is
enough there for you to get a good understanding of why you would want
to use these tools.
The section on Pragmatic Project Techniques is equally interesting.
As I said before, Jared and William don’t advocate any particular
methodology, but have acquired a collection of practices over their
years of software development that work. That said, there’s a fair
amount of overlap with traditional agile methods. It covers techniques
such as daily meetings (aka Daily Standups in XP), a shared list of work
referred to as “The List”, among others. I would imagine that this
section of the book would be the most useful to the majority of people
reading this book. Geeks tend to focus on tools (section 1), but often
ignore the processes that make a project successfull (or not).
Tracer Bullet Development was covered in the original Pragmatic
Programmers
book, though this book covers it in much greater depth. It’s very useful
in situations where the client doesn’t fully know what he/she wants. You
essentially build a prototype, and use it to draw out the requirements
from your customer. It’s more involved than that (it warranted its own
section in the book), you’ll need to read the book to gain a full
understanding.
Common Problems and How to Solve Them was probably my favorite
section of the book. It’s a collection of 18 recipes for how to handle a
given situation using the principles outlined previously in the book. It
covers situations like “The customers are unhappy” and “Features keep
creeping in” with practical advice for how to deal with them. All of us
find ourselves in these kind of situations from time to time, and this
book would come in very handy when they do arise.
Summary
In summary, I think this is an excellent book. It’s not billed as such,
but it could almost be considered a sequel to the original Pragmatic
Programmers
book. While the original focused on the tools and techniques of the
trade, this book elaborates on those and adds a lot of information on
processes. Combine this with the “Common Problems” section, and you have
a very useful book indeed. The writing style is somewhat casual, similar
to the other books from the Pragmatic Programmers, and the book is
filled with real-world examples from the authors. I would highly
recommend Ship
It!
to anyone interested in improving their software development skills.