7

Take me to your leader

 3 years ago
source link: http://rachelbythebay.com/w/2013/03/06/docs/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

Take me to your leader

I got an interesting reader comment a couple of weeks ago. It was from someone anonymous so I can't respond directly, but it definitely got me thinking. What they said was short but effective:

Have you considered becoming a tech writer in San Francisco? You're a good writer. And since there's never more than one San Francisco company with a tech writer at any given time, you don't lose time fretting over whether you should switch.

I don't think I'd go for it as literally defined (taking a tech writer job in SF) but there are some concepts buried in there which seem interesting. I like writing, obviously. I like writing about technical stuff, and I like helping people. I also like getting "inside" a system to figure out how it works... or, in some cases, why it works. Or, if it's broken, I figure out why. There are countless examples in my posts from the past two years.

There's something special about looking at a system you have never seen before. With "beginner's mind", you get to see things other people might miss because they have been using it all along, through all of its various stages, and they are used to how it behaves.

So, I am making a limited time offer to forward-thinking individuals or concerns in the Bay Area. I'll dig into one of your systems and build a technical document and/or report on it. If you like it, then we can figure out payment details and/or other projects for me to analyze.

Here's a real example from my life. A couple of years ago, I transferred jobs inside the bigger company and wound up on a team which did automated testing of the Linux kernel. My new manager asked me to install a new instance of this software on one of my machines to get familiar with it. While doing this, I documented all of the gunk I had to go through to get it working.

Later on, when it was time to set up more of these things, all of the weird little nuances, hurdles, pitfalls, and other anomalies were right there in my documentation. Anything I had encountered was listed, along with whatever I did to either resolve it or work around it. Some of these things wound up spawning bug reports or feature requests. Sometimes, we determined that some behavior was no longer necessary and certain dependencies could be removed to improve the install process. It took a fresh install and an outsider's perspective to catch that.

Happily, I can do that same thing for arbitrary projects. One of my friends pointed me at an iOS application a couple of months back and wanted my take on it from a UI/UX perspective. I fetched a copy from the app store and went to it. I caught a whole bunch of things that he probably saw at some point but had "lost" as time went by.

Essentially, I can behave like one of those users who takes everything literally even though I know better. Then I can turn around and report my findings along with recommendations on what to do about it based on my knowledge and experiences.

Give me two weeks and I'll give you a completely new perspective on your own systems. Just imagine the possibilities.

Linus's Law says that "Given enough eyeballs, all bugs are shallow".

My eyes are ready to step up and look at some new things.

Are you in?


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK