Work

After all the great feedback on the previous post on Burnout, and Randy Fay's excellent talk (video included) and blog posts.

A few things that I can say for sure:

• I'm suffering from all three of Randy's signs of burnout: Exhaustion, Cynicism, and feelings of Ineffectiveness. This is partly due to external (to the community) influences, and partly because of a laundry list of things I think are wrong with the docs system and how hard they are to fix.
• I have been managing this by completely scaling back my involvement for the last couple months to "take a break", but that is not sustainable. I either need to find a way to be effective and optimistic again (not to mention balance my own mental/physical health needs), or step down either temporarily or permanently.
• There is change needed for the documentation and Docs Team to remain sustainable and prodcutive regardless of how long I maintain the role.

Signs of Burnout

When it comes to Exhaustion, I think that for me it comes from two things: 1) chronic health issues leading to legitimate energy constraints, and 2) also being burnt out on the combination of work and Drupal work. I don't feel like I have any energy left over for the things that recharge me like moderate exercise, socializing, and creative time. I don't feel like there's any way to further offload responsibilities to regain this energy without actually cutting more work hours or docs responsibilities.

I didn't really realize this until this week, but I am also feeling very high levels of Cynicism, especially related to what can potentially be accomplished, and whether anyone would want to help. This comes mostly from a feeling that not much has been accomplished since the D7 launch, and that the docs team is too transient and small at present to effectively engage or mentor people who could help.

With regards to Ineffectiveness, the lack of resources (people + time) makes it difficult if not impossible to delegate the tasks I'm currently responsible for, and also to make any overarching changes, for eg. to the infrastructure. In the meantime, my time is spent issue queue gardening, and making little headway on those pieces I feel are important (or writing, which is what I actually enjoy and no longer do).

What could change

Now, I don't just want to be one of those people who complains and doesn't propose anything to fix the situation (sidenote, is it possible to tax people an hour of docs work for each minute they complain about the docs?) Ahem. :) I've been thinking hard and discussing with others about what could help, and following are the main options that have come up to this point.

Personally

For my own personal concerns, I see a few options:

1. Step down temporarily/permanently: Probably not the most appealing option to the community or myself, but a real one none the less. This would help by relieving any stress and time lost to management resulting from being in a "leadership" role, and free up time for me to actually do the work of writing/planning infra, and also fun stuff like patch reviews, research, etc.
2. Further scale back paid work time: This would be a good way to make room for more Drupal work, but let's face it, income is important. Additionally, try and find a way to not do the exact same thing in Drupal as at work (ie. mostly managing issues, people, and QA) - it's too much of the same with no outlet.
3. Figure out how to become effective again: The most useful option to the community, and the most difficult option for me to figure out. This would probably go a long way towards reducing cynicism, but may or may not alter exhaustion levels.

Docs (Team)

As far as general changes that I think could make the Docs Team and documentation function better, here are some options (some pie-in-the sky, some more realistic):

1. Stop micromanaging: Make Docs Team (not Docs leads) responsible for day-to-day work in the issue queue. Rejig Docs lead role to focus only on larger goals/planning.
2. Separate docs projects: I believe Randy originally suggested this - make each docs "guide" into a separate project, with its own issue queue so people can more easily work on specific guides (and even have per-guide coordinators). We currently just use issue tags to track different topics
3. Improve infrastructure: This ranges from medium sized tasks like implementing node-reference fields and configuring blocks of related content, to an enormous overhaul of the structure of the docs into a system using XML or RDFa for example to make content reusable/structured.
4. Turf the "handbook": Another idea presented to me recently was to move the existing documentation into a "community wiki" type area, and write a curated central guide from scratch which is then maintained by a small core group of Docs Team members.
5. Recruit a TON more people: Through some kind of marketing (?) recruit and retain more and more active Docs Team members.

How to make this work

That is where this gets tricky, and where I need input. The personal side, of course is really up to me to decide and figure out. But on the documentation/Docs Team side, I'd really like feedback on what approaches could be useful and realistic to implement, and suggestions on how to make them happen. Once I have wrapped my brain further around these options (and we've discussed them Friday at the Docs Sprint), I'd like to post some ideas to groups.drupal.org more officially.

Randy Fay is doing a session at DrupalCon on Burnout:

We have an incredible group of people who invest deeply in our common project. Some significant portion of this group is near burnout at any given time, and we've lost important contributors, some famously, as a result of this.

The more general problem is: How can we help our contributors to manage their work so they don't get so close to burnout? How can we help people find (or regain) balance while dealing with the technical and social problems of contributing to our great project?

Proposed solution:
- Begin a concentrated initiative to grow and keep our contributors, and to keep them happy.
- Make this a goal a key project responsibility.

He just posted a blog post, on defining burnout and signs of it, this week as well.

My Thoughts...

Burnout among community leaders is real and damaging, not just to those who are burnt out, but the greater community who rely on these people. I have seen friends burn out, and I have been teetering on the brink of full on burnout for a while. Now I'm going to be blatantly honest about why I think it happens and what we could do about it. Please take my complaints as fodder for improving, and not slights on the community!

Factors

I think that personally, and as Co-lead of Docs, my increasing burnout can be attributed to a few factors:

1. Work. Of course, I have my non-volunteer work to do as well, and that takes precedence over my volunteer position. Work has been really busy for the last year, and that's taken away a lot of the time and energy I was previously dedicating to Docs and core.
2. Life. General stuff going on in life has also distracted me from working on Docs. It's a fact of life that personal factors will come into play, good or bad. Last year when I was sick a lot, I actually had more time at home on my own to be online.
3. Health. I have chronic health problems and my energy levels fluctuate wildly from week to week. Some weeks I can keep up, others I can't. But the issue queue doesn't care about my health!
4. Lack of community support. Let's face it, docs can be the ugly duckling of development work. Lots of people write code and don't put docs online for it, or update code and don't update docs. There are a TON of docs. There are a TON of redundant docs. There are a TON of missing docs. It's a real beast, and the amount of material to write, format, and maintain is hugely disproportionate to the amount of time the community puts into docs. Which brings me to...
5. Lack of resources. There are not many people who write and maintain the docs, and this group is often transient, moving onto development, or working in short bursts. That is not helpful in keeping up on the amount of work to be done. This could be a fulltime paid job, and there is virtually no funding for docs. Managing people is a big job, I think I actually got way more done for docs before becoming Co-lead as none of my time goes to writing docs now, it all goes to managing the issue queue and responding to questions/requests, leaving no time to do more overarching tasks.
6. It's often a thankless job. Sure other avid contributors are often extremely thankful for the work the Docs Team does. But sometimes I feel like the project's documentation is taken for granted, and there is a tone of entitlement to good documentation (contrib maintainers surely see this as well). Issues in the queue complaining about the state of the docs or demanding documentation on a particular topic are disheartening - I see the same thing in the queues for popular contrib projects. Maintaining the docs is like treading quicksand, and it's a losing battle with the current resources.
7. Expectations. I can't even imagine doing the job of Docs Lead on my own! OMG. I have no idea how Addi survived it as long as she did. This position is not realistic! Even with Jennifer managing docs infra and API docs, and me just managing the online docs, it's a hefty job. It's not enough. We have a few a few topic coordinators listed, but we really need more, as well as team members who can help with docs for the ever growing library of contrib, and help maintain the docs queues. Additionally, this is an under-resourced volunteer position and people need to adjust their expectations accordingly. For me, the expectation that I will attend a DrupalCon, and submit sessions, as well as lead the docs sprint is even a large one. My health doesn't often allow me to even attend full days of the conference, nevermind those added responsibilities. 
8. Give some, want more. It seems when someone volunteers to give some of their time and energy to the community, there is always a want for more. I understand that it's a compliment that the community thinks a volunteer does good work. But it's important not to overburden people who already have huge responsibilities. I've been learning the hard way to say no more, but as much as I appreciate being given additional opportunities, don't care for any kind of "oh, you're missing out" attitude when I turn down opportunities that would take up even more of my time/energy/finances.

Maybe I'm not cut out for this! But maybe "this" just needs to change for all leaders in the community...  Enough about what is going wrong, what can be done to improve?!

Solutions

1. More, smaller leadership positions. The community and amount of docs and code we maintain is constantly growing. Co-leads and more coordinators are essential for the continued health and sanity of our contributors. Topic coordinators in docs, and things like the Views bug squad are good starts, but we need more people helping, and we need to work on enabling them to be more self sufficient so they're not always waiting on feedback. (If you want to be a topic coordinator for docs, let me know! More are listed on g.d.o.)
2. Respect the time of community leaders. If someone doesn't respond immediately, don't get angry. If a leader needs to take a break, for instance going on hiatus for a couple months, respect that. We are doing our best. That said...
3. We need to accommodate time off! Leads shouldn't have to be on duty 365 days a year. Every person in a leadership position that is fairly critical should have either a co-lead and/or an understudy. Someone who can help out and when needed take over for a while. Just the existence of this structure would take a lot of pressure of leaders to not have to be available all the time.
4. More people need to help. I know, this is an ongoing issue for open source projects. But we need to get more Drupal users and community members to participate, especially in some of the less popular tasks. They still need to be done! Maybe we need a marketing campaign of some sort? Some people, like me, even enjoy these kinds of tasks, so we should also...
5. Revere "gruntwork"! Things like support and documentation aren't just gruntwork - they are really important tasks for all levels of community members. They shouldn't just be looked at as a stepping stone to development work. Support and Docs Team members should be nurtured just like developers are, and given the same respect so that they aren't perceived as lesser positions in the community. Not saying everyone has this attitude, but it's important, especially as the community grows to recognize these tasks as critical parts of the ecosystem.
6. Funding for docs? I don't know if it's realistic to get funding for documentation work. It sounds like it'd be possible for a huge infra project, but isn't so much for day to day needs. Not sure how to get more help with our infra from the larger community so that we can help our processes become more efficient.
7. Reset expectations. When interacting with anyone in a major leadership position, remember how much we are responsible for. Try not to be impatient with us, or demanding of our time. Don't put pressure on leaders to contribute more. We're volunteering to help, but that doesn't mean we are solely responsible. Which reminds me, we need to find a way to...
8. Make contributors more self-sufficient. Documenting how to help doesn't seem to be enough. I would love to see a more structured mentorship system in place that would take some of the weight off of the shoulders of people already in leadership positions. There are many community members who could answer simple questions and help onboard new contributors. And yet it always tends to be the already overburdened leaders who take this on.
9. Rethink things. Finally, I think that we could really rethink some of the more burdensome parts of the community task list. For instance the documentation. Should Docs Team really be responsible for this massive amount of community contributed docs? Should we just manage some "official" core docs and end user tutorials? Maybe there are other approaches that would work better with the growing community. Open to suggestions!

Preventing Volunteer Burnout

And now, some tips from our dear friend, the internet, for preventing volunteer burnout:

In my experience, burnout can happen for a number of reasons: the work I’m doing isn’t challenging, the work I’m doing has little meaning, I’m not learning anything new, I’m doing something I’m not passionate about, or the workload I’m shouldering is overwhelming. - Tom Johnson, 'Avoiding Burnout as a Technical Writer'

Moderation is key...aying no is difficult, especially if you think your answer is going to disappoint someone. But it's necessary since spreading yourself too thin can be a bad thing for you and the recipient(s) of your volunteer efforts. It's best to be sensible about your time so that you're able to maintain the energy and desire to honor the commitments you make. - John Barrymore, 'How Volunteer Burnout Works'

As the saying goes, "if you want something done, ask a busy person." ...in Canada. Interestingly, a small minority of volunteers accounted for the bulk of the hours. The top 25% of volunteers accounted for 78% of total hours of volunteer support... If they do not get the balance they will get burnt out...The problem is that we do not notice the burnout coming until it is too late and what you are left with is either a very unhappy volunteer or a great volunteer who quits. 

Tips:
- Connect to purpose
- Create an achievable position description
- Give volunteers holidays
- Set guidelines at the start
- Create an environment that is welcoming
- Thank volunteers

- Lori Gotlieb, 'The road to volunteer burnout: How to avoid it and how to manage it' 

Slideshare, takes a while to load - the slides are pretty self-explanatory...

- Meredith Kennedy 'Preventing and Addressing Volunteer Burnout'

In my volunteer management work, I see and hear about volunteer burnout. Volunteer 'burnout' was the term coined years ago to mean asking those faithful volunteers to do more and more to the extent that they actually burned out, left the organization, and likely stopped volunteering altogether. This was likely the beginning of serious recruitment issues: instead of recruiting new volunteers, those who could be depended on were asked for more 'time'.

"Volunteers who are committed continue to be asked to give more time. We are also expected to give more money to the causes we volunteer for. We are also expected to sell more, promote more, and show up at fundraisers." - Donna Lockhart, 'Volunteer Fatigue: What impact on the future of volunteerism?' 

Finally, a great post from my favourite Project Management author, Michael Lopp, on bordom and burnout (not directly related to volunteering): 'Bored People Quit'. I think this is also important because doing repetitive tasks and being constantly overburdened can also be boring - it strips away the creativity that keeps people engaged. We need to try and make sure that smart, engaged contributors have that creative time so they don't get bored!

This one's all Drupal folks, cause that's pretty much all I've done for the last two and a half weeks. This is what happened when I asked the question, "Is there some reason we don't just fix it all?" I did not know then what I was getting myself into...

A small inconsistency

It all started in late summer, when I was testing some Drupal 7 core patches for moving fields and image handling into core, and at some point clicked my way into the Help pages. There was a blatant typo on the Node module help, and then a change in language that needed to be made, so on August 1st, 2009 I created an issue for it.

Then someone posted a patch to update the text. And Emma Jane Hogbin posted another...and then she and I started talking on IRC about how it would be much better to have some more clear formatting that could be applied across the board, fans of consistency that we are.  And we went back and forth for a while making little improvements. Thanks to having learned how to apply and create patches several months back, I had just enough experience to make changes and roll new patches.

The patch was marked RTBC (reviewed and tested by the community). Yay! But wait... then Angie, who is the Drupal 7 core maintainer saw the issue (as she is the one who does final reviews of issues marked RTBC before they are committed to the core codebase). And she was like WHOA, this is a major change! A good change, but a major one, which would need to be applied across the board to all the core modules (and eventually all the contributed modules). She also made us aware that if we wanted to make such an overarching change that we would need to be able to prove a higher level of discussion and consensus on the issue and then complete the change in time for the string freeze deadline.

A much bigger task at hand

Various documentation team members went back and for for a while about whether the new standard would be supported, and kept updating the patch getting closer and closer to a format we were happy with. By now it was the end of October, and the patch was finally set back to RTBC. This is when it popped back up on Angie's radar, who was like (paraphrasing)... "So, you guys haven't really addressed the question of whether you are going to make a massive across the board change here." Oh, right, that.

A new patch was created that reverted the format updates, and just updated the text to match Drupal 7 functionality. There was nothing wrong with this patch, and it could have just been applied and nothing else said about it.

But I didn't feel right about it... So I thought to myself, is there an actual reason that we are not making this massive change? It's not exactly challenging, it's just a lot of grunt work. And at the end of it, we would have some much more helpful and readable help references for the core modules in Drupal 7 rather than the difficult to read and horribly out of date information that was currently on the help pages.

Accepting the challenge

I posted back on the issue and asked this very question, and said that I thought it was really important to improve the help. Jennifer Hodgdon, who was another initial supporter, started a thread on the Documentation team mailing list, and it turned out that people agreed on one thing: the help text sucked and we ought to fix it. Happy birthday to me, on November 13th, 18 days before the Drupal 7 string freeze deadline, we made the final decision to overhaul the help pages, and Jennifer posted the template for the change.

Since Jennifer is a more experienced member of the Documentation team, as well as a much more advanced programmer than me, she got us off on the right foot and lead the charge for the first half, with the agreement that when she was going to be away for most of the homestretch I would take over and steer the ship. We'd been working well together and I felt like I was competent enough (and had enough other support available) to take on this responsibility.

The standard was signed off on, and on November 20th (ten days to the deadline), a list of modules was posted so people could start signing up for which updates they would take on. And then the real work began. And oh my...was there a lot of it.

Nose to the grindstone

I had no idea starting this out how much there really was to do. I was only thinking about the template change. But there was also a major need to update the content of the text, and those changes had to be reviewed and tweaked, and reviewed and tweaked some more. And then some more... I learned more about Drupal, the contribution workflow, and writing docs in PHP in that week and a half, than probably in the previous six months. Slowly but surely, myself and the others who were helping out got into a groove, and started cranking out some great updated help text patches. I got a couple of hours of "fun hour" at work to work away at this, but otherwise it was all afterhours; it basically devoured my free-time for almost two weeks.

Maybe it was the timing with American Thanksgiving, or having Jennifer away (thank goodness she was back for about a day and a half before the deadline!), but we definitely lost some momentum after the first five or six days. Feeling a certain level of responsibility, I basically crammed like a crazyperson most evenings and all through the final weekend, reviewing and updating patches. Thankfully a couple other dedicated people stuck with it, tag teaming on patches and reviews. Yes, I totally burnt myself out, but with the help of those great people who stuck it out, we miraculously got all of the patches for the 39 help texts done (44 if you count the Field submodules), updated to Drupal 7 content-wise, reviewed until within an inch of their lives, and marked RTBC (many of them already committed) by the December 1st, 2009 deadline.

The result?

Here is an example of the old help text for the node module:

And here is the updated version:

It might not look like much, but particularly for new site admins, and even more so with some of the more complicated modules, this is going to provide a truly useful resource (rather than a slightly confusing bunch of text that mainly just forces people to click through to the handbook). It was one of those highly neglected and unloved parts of Drupal, and it makes me extremely happy that is got a little much-needed love. On top of that, the first one of my help patches that was committed was my FIRST CORE PATCH! In Drupal-land, this is a momentous event, and I was thrilled to see that two of the others who were helping out both had their first core patches shortly after me while working on this.

(For anyone interested, the help doc standard is here, the main thread for the issue is here and there are several more branched off of it, all tagged with d7help.)

What I learned

This can be summed up in three points.

1. How much work really goes into Drupal. This was the most time I'd ever spent actually working on Drupal (core), not online documentation, not event organizing. I had done some patch reviews before, but this was the most concentrated amount of time spent in the issue queue, and on IRC, working away alongside all of the developers who have also been cramming for this deadline. Countless hours and energy by people around the world goes into making this an amazing open-source web platform. It's pretty mind-blowing to see how it all comes together.
2. Technical skills. I can now roll patches in my sleep. The whole process of tracking issues, downloading and applying patches, reviewing and making changes, and posting updates is something I now am completely comfortable with. I also learned some basic PHP coding, and also some of the associated coding standards that the Drupal development community uses. Prior to this, I could at best cut and past PHP into the right place. Now I am beginning to cross the line from memorizing to actually understanding what I am looking at. That is a huge accomplishment for someone who three short years ago was finishing off a Masters in Health Geography, and looking at her first CSS code.
3. A few determined people can make a big change. The crazy part of this was that despite having to gather a lot of feedback and get consensus on the change, it was really just a handful of dedicated people who made this come to fruition. Several people helped out with reviews, but I have to give extra-special props to the people who did the bulk of the work with me: Jennifer Hodgdon (aka. jhodgdon) from Poplarware, Lisa Rex (aka. lisarex) who is a Freelancer specializing in usability, and Boris Doesborg (aka. batigolix) who from what I could gather works at Erasmus Hogeschool in Brussels. Last but not least Drupal 7 core maintainer, Angie Byron (aka. webchick) from Lullabot, who by golly is one of the most patient and dedicated people I know. Angie fielded a ton of questions about module functionality and what should or shouldn't be included, as well as doing a ton of final reviews and giving great, useful feedback to everyone who was working on this. We never would have made it without her help, and it was great fun some of those late nights on IRC.

All in all, a great learning experience, a great result, and my goodness am I glad it's done (at least until issues start turning up for contrib modules)!

And.... the busiest of months has come to an end. Exhales.

October was a great if not overbooked month. Between BarCamp Vancouver, the Drupal 7 Conrib Sprint, and the big PNW Drupal Summit in Seattle last weekend, I had only one weekend off the entire month (on which there was also Drupal Camp Portland, but I decided that would be pushing it).  I made up for the past month in a big way this weekend, going out to socialize only once (last night for Halloween), sleeping in till 10am both mornings, doing laundry, cleaning my bathroom, cooking, reading, chatting with my folks on the phone, and generally being a homebody.

The PNW Drupal Summit in Seattle last weekend was something I'd been looking forward to for quite a while. My coworker Shawn and I drove down a day early, and Shiraz (another one of our coworkers who lives on the island) took the ferry over and met us that night. We managed to do a little exploring of the Pioneer Square area Friday, where I bought a bunch of cool books, and drove through Capitol Hill and up the waterfront before tiring out and going back to the hotel for naps. Everyone else arrived by bus or train Friday night; we had quite the crew amassed over the weekend, with 5 people from AB, 2 others who have been doing contract work with us, and then my friend Katherine who works at another company and has been a conference roomie before.

It was great catching up with the Seattle crew, as well as lots of people who I'd met at previous Camps and Cons, and also getting to know some new people. It's such a great group, I never tire of hanging out with everyone from the PNW plus a few others who came in from Idaho, and even Montana.  I learned a few new things including, a new (to me) tool for managing content deployment using Deploy module [slides/vid here], and my Agile project management/development BOF was actually one of the highlights of the weekend for me. It was well attended, and there were some really great conversations and sharing of experiences from other PM's and devs who have been (or want to start) using Agile methods. I think that the session may have been videotaped, and am crossing my fingers that footage will surface at some point! Thanks again a million to the great Drupallers in Seattle for all their hard work making that come together.

To abruptly change topics, I got this crazy white pumpkin to carve last night (the photo Rachael took really shows how white it was); I thought it was some strange tough inedible gourd, but it really was this fantastic pumpkin. Probably some kind of heirloom variety, as it had not had all the amazing squash-iness bred out of it. Very thick and meaty, huge seeds, and so orange inside that my hands were completely stained after I was done.  Rachael and Boris used some of it for soup, so I am hoping that it was as tasty as it was entertaining (I hate to waste them, even if they are just grown to be decorative veggies).  It was a quiet Halloween, but I think that's ok. I am up for some quiet times.

ps. For the record, I still think daylight savings is bunk. Saskatchewan has it right (disclaimer: I am biased).

pps. People I know are raising money for cancer research, and you should donate!

• Jo Biggar (my friend's brother) is going to cut off his amazing dreadlocks, which he's been growing for nearly a decade to reach his goal of raising $10,000 - he's over 2/3 to his goal, so help him out!
• Also today marks the first day of Movember (ie. the month where boys grow 'staches to raise money for prostate cancer), and my coworker Shawn is participating - you can pledge on his mo growing here (if the link doesn't work, go to http://ca.movember.com/ and search for "Shawn Price").

This blog post comes to you in two parts: 1) Drupal 2) Everything else

Drupal7 Codesprint

This weekend was the Drupal7 Contrib Upgrade Sprint that Károly Négyesi (aka chx) organized at the NowPublic offices. I spent a good part of yesterday there, helped out with coaching the one beginner who turned up to learn some of the tools for helping out in the community.  Otherwise, after a bit of a rough start, the devs all hunkered down and have been making some Drupal magic, upgrading super important things like Views, Panels, database stuff, and various other bits and pieces of modules and themes.

A good number of people came in from out of town and they've all been working  their butts off.  Sam Boyer came in from Chicago and was working on panels, Jakob Perry was up from Bellingham (I think?) and was working with some others to get Coder module functional for D7. David Strauss was in from Austin, TX, and I think he was working on some DBTNG stuff (?), and Josh Brauer came up from Idaho and Amye Scavarda (who I'd met at the Project Management BOF in DC) was in from Portland as well... I lost track what everyone was doing (and ended up staying home today thanks to a tummyache) but trust me you want to thank your lucky starts there are all these amazing dedicated people around.

Highfives to all the Vancouverites who came out and helped and showed their support! Rick, Dale, Katherine, Francis, Hubert, Richard, Catherine, and a brave "newb" (more new to the community than new to development) Chris.  And also to the others who joined remotely, Damien Tournoud, Dmitri G., Larry Garfield, Daniel Wehne, and Mike Prasuhn spent the better part of their weekends helping out from their respective homes.  I'm sure others stopped in that I missed, but I just feel like it's the least I can do to say a collective thanks to everyone who spends so much of their time and energy keeping this ship afloat.  Open source communities are a pretty amazing thing when you think about it, it just gives me the warm fuzzies.

Everything Else

Had a great Thanksgiving dinner last weekend, with a few friends and a lot of strangers out in East Van.  Makes me happy knowing the kinds of people in my life are the kind where a mish-mash of their friends can turn up at a dinner party, many who know only one or two people there, and chit chat all evening and have a great time. There were several people who worked in urban planning, resource management, non-profits, tech, and social media, so there was a lot of really passionate, interesting conversations.

I've been on holiday this past week, recharging in order to get through the end of the month, October has been crazy packed full of tech events... the final one being the Pacific Northwest Drupal Summit which is in Seattle at the end of the month.  I'm excited and trying to keep my energy up so I don't totally burn out before getting through it!  One of my coworkers gave me some advice recently about prioritizing and energy levels, suggesting that maybe I ought to be a little more selfish (in a taking care of my self way, not a being a jerk way) about my priorities and not overdo it when it comes to extracurricular (ie. non-work) commitments.

That is a really hard thing for me to accept, there is so much that I want to do all of the time, and the reality is that I never have enough energy, and that is quite likely not going to change.  I realize maybe I haven't quite struck the optimal balance yet, but I can say with relative certainty that my life is always going to involve pushing myself, since I'm not willing to give up doing the things that keep me happy and keep me feeling motivated. It's more of refining exactly how much I can and should push myself so that I still get to do stuff that I want to, but don't feel totally drained all the time.  It sounds easy enough, but as anyone who deals with ongoing health challenges knows, it's not just that simple.

 I've no idea what I am talking about.  I'm trapped in this body and can't get out.
- Radiohead "Bodysnatchers"

I'd love to hear how you all balance your personal/health needs with your work and extracurricular passions if you feel like giving a little feedback.

A bunch of things have inspired me and lifted my spirit this past week, so I wanted to share:

An awesome A Softer World ... this one's pretty great too (remember to read the hover text!)

An awesome photo/paste-up by Basco5 (don't look if you're scared of barfing)

An awesome video by Oren Lavie (just watch it, it's amazing)

Ridiculously awesome beatboxing and flute-beatboxing (c/o @adrian_ng)

An awesome photo diptych by Rachael (read the poem she paired with it on her blog for extra awesome)

More random goodness:

1. Seeing The Weakerthans and The Constantines at the Commodore with Greg
2. The rain actually smelling like rain
3. Make It craft fair at the Roundhouse and free comic book day at Elfsar in Yaletown with Rachael and Boris
4. Second (and third?) chances
5. Work being awesome and working with rad people
6. So Delicious coconut ice cream (but why can't I find the yogurt in Canada???)
7. Getting my sewing machine un-jammed
8. Being reminded my friends love me unconditionally
9. Patting the awesome dog at my massage therapist's
10. Being okay at the end of the day