Tag Archives: thinking skills

Setting myself up on Fiverr

So I just created a gig on Fiverr. Usually, I’m the one who reads every scrap of instruction and advice I can find, and constructs a giant decision tree, trying to anticipate everything that could possibly happen as I work up front. Not this time–I was so eager to get my listing up that I jumped in feet first. It turned out fine, because although it was a bit time and labor intensive, it was simple.

They wanted me to create an account before I got a good look around, so I just went ahead and did it. They wouldn’t let me use an email alias. I’d rather filter my email on an alias than on a keyword, so now I’m crossing my fingers that I don’t lose a message.

I already had a clear, workable idea for a service, and so when they told me I’d be up and running in five minutes, I believed them. I should know better. On the Pricing screen, I was offered the option of creating three tiers for my service. I could have gone ahead with just the tiny test service I had in mind, but I knew this was my opportunity to invent a genuine, serious product, and I should take it.

The hardest part about the Description and FAQ page was paring my sales pitch down to fit the 1200 character limit. Cutting is a fact of life, and I’m finally getting used to it.

Then there was the Gallery page. For as much as I’ve struggled with the Gimp, you’d think I’d have some skills by now. Oh well, I can always polish and improve later.


For reference, the steps are:

1) Overview – tagline and category
2) Pricing – simple product or three tiered system, with the option to offer add-ons (such as expedited delivery and extra re-dos)
3) Description and FAQ – your marketing copy, 1200 chars plus the FAQ
4) Requirements – what you need from the client to do the job (in my case, I needed a video or audio file of the speech I’m to evaluate, plus an optional text description of the client’s goals and objectives)
5) Gallery – one (required) to three still images, and optionally, a video
6) Publish

BTW, if you’d like some coaching on your speech, come see me.


From a Ramble to a Story

Earlier today, an aspiring speaker asked how to turn a 25 minute ramble, which he had already created, into a 10 minute story. By the way he asked, I could tell he knew it was about much more than shortening it; it was about giving it structure. He had a formless collection of ideas, and he wanted a work of art that could plug into the human mind and evoke change in the listener.

He may not have realized it, but he had actually taken the proper first step to write a story from scratch. Brainstorming is a useful first step in writing, no matter the project. His brainstorming just happened to be in spoken form. His intuition for the craft was excellent; he just needed a little information.

Here’s what I told him:

Decide what you message you want your story to have – what enemy you defeated, what lesson you learned, what change you made, or what have you. Choose the event from your ramble that serves as the hinge point of the conflict, lesson or change; that will be the turning point or climax of your story. Everything else in your story will support it.

Now choose the event in which you first meet the enemy or see the need for change, and put it first. Finally, choose several events between these two to illustrate the rising conflict, and make a mini-story from each one, relating them all to each other as you go along. This will be your basic story structure.

Once that is done, choose some descriptive elements to illustrate what life was like before the story begins and put those in an introduction, and likewise, choose some from after it ends for the wrap-up. This will show how the change has been fought for and achieved.

Now you have a hero’s journey, with stasis at the beginning, initiation into the “other” world with the first conflict, rising action building to a climax, resolution, and a higher level of stasis at the end. To see more, google “hero cycle” or “freytag’s pyramid.” Best of luck.

NSA Workshop With Patricia Fripp

Would it intrigue you to know that, today at lunch, one of the world’s greatest public speakers sat next to me? It was the result of my putting myself in the company of high quality people for several years. There were times when I had to push myself, and times when I’ve made social mistakes; but I knew that if I kept immersing myself in positive environments, eventually I would grow.

A public speaking friend (Thanks, Elaine!) brought me to Patricia Fripp’s workshop “How to Prepare and Present Powerful Presentations” as a guest. I was already familiar with the Fripp speech model, but since “Learning requires repetition and reinforcement,” as she says, it was helpful to hear it again. Today, she gave a more interactive version of the workshop, with more audience questions, mini-coaching, and of course, general audience interaction. I’ve heard of people who are so adept at reading others that it’s almost as if they can read minds. I now know that they’re not just urban legends. She could tell just from watching the audience that I was star struck and nervous around her, and she wasn’t going to let me stay that way–she made sure I got a big dose of Fripp! I’ll definitely be more at ease the next time I meet a celebrity.

This is the third time I’ve seen Fripp live. Her presentations are so content rich that they give me that light-headed buzz after about an hour, yet I push myself to stay focused and absorb all I can. Several times during the presentation she asks the audience “What have you learned so far?” I can’t remember, but then I’ll hear myself quoting her over the next several days. “It’s hard to be creative in isolation,” I told my lunch mates, as we recounted how much we value face to face meetings.

That was when she came to our table and helped an NSA member hone an upcoming presentation. I had no well-formed questions, so I just observed. There’s value in the presence of high-achieving people above their words. Beyond listening to them, modeling them is an indispensable way to learn from them; and mindset is contagious.

Thank you, Patricia Fripp, for sharing your time and attention with us. I hope to see you again soon, and when I do, I’ll have some progress to show you.

Spinning Gears

During the OPW application period, I was running on nervous energy. I had a lot of reasons to be nervous: I had quit my job, with no assurance of finding another; I was hiding the fact from certain important people, on whom I was dependent; and I had never truly tested myself as a coder before. The terror of it would jolt me out of bed and into the computer chair. I was aware of what I was doing, and I knew that it was not sustainable, not for the internship or for a permanent job. It’s just for now, I told myself, and once the application period is over I’ll change.

I was not aware of how deeply ingrained the habit was and is. Well into the internship, I’m still relying on my dysfunctional patterns to get myself into a coding frame of mind. I haven’t yet found another way to do it. It’s not a simple matter of “I’ll get to bed on time tonight, and start work early tomorrow.” That leads to a half day of Sudoku and gray fog.

The habit becomes obvious when I look back over the history of my Toastmasters speeches. Time after time, even if I had an outline for the speech weeks in advance, I’ve put off practice until the eleventh hour. I needed that pressure to get the creative juices flowing. Once I even stayed up all night watching the BND logo trying to get wired up (not the screaming version, I haven’t gone that far down the rabbit hole yet), and finally shifted into gear at 3:30am for the 7am meeting. The speech rocked. The rest of the day was a waste.

If there was an emotion that I could ascribe to the swapoff system call, it would be nervousness. It digs into its work at the most obvious point, instead of the most logical one, and flails about covering the same ground over and over until it finally finishes the job out of sheer effort. It’s my job to break it down, see how it’s spinning its gears, and use my knowledge of the big picture to create for it a new life of order and peace. The kernel isn’t the only thing I’ll be updating in these three months.

You Think You Know Something

…but then you try to explain it to someone else. If, like me, you find yourself in that moment with your mouth hanging open and nothing coming out, you know you have some studying to do.

Early on, my mentor made a page for me at linux-mm.org (look only if you dare) and suggested I post my observations and questions there for discussion. Once I had amassed enough, he gave me the goahead to spin off chunks into standalone articles that, hopefully (at least as far as I’m concerned), will become part of the site’s content. Half hour job, I thought. Just a matter of cutting, pasting and polishing, I thought.

Well, I knew for example that the swapin code fetched some pages in a loop and pre-loaded them into the page cache before it fetched the page that is to be swapped in, and I knew it called a function called read_swap_cache_async() to fetch each one. I knew read_swap_cache_async had a bunch of steps in it, that it double checked the swap cache, allocated a page for the page, and stuff. I couldn’t put “and stuff” in the article. I went back over my notes to find the explanation, so I could copy and paste it in, even though I already knew it wouldn’t be there.

It was now time to sit down and think about the problem clearly. As I reconstructed the call stack bit by bit, I not only filled in the missing parts, I took note of the patterns to them. I’d know the order of the function calls and roughly what each function did, but I couldn’t remember their parameters or return types, meaning I wasn’t clear on their relationships. I found the same function called as part of both the swapout and swapin chains, meaning that while I was aware of the function’s actions, its purpose was lost on me. Lines that I overlooked the first time, but which were actually the most important ones, jumped out at me.

It was tedious and time consuming, but I’m glad to have done it. I’m always glad to improve my understanding of the kernel, but especially, I’m glad I exposed my learning process to myself so that I can restructure it. I had, without being aware of it, been expecting my subconscious to integrate the information I took in. That worked back when the problems I faced were simpler. To go to the next level, I need to be able to consciously control the process.

I see exactly why my mentor wants me to write all this out. It’s the same rationale behind rubber ducking, keeping a journal, and working every step of a math problem with pencil and paper. True knowledge has structure, and the structure is the same whether it’s inside or outside your head. Inside your head, it can get lost in darkness and fog. Taking it outside your head shines the sunlight on it.

Where The Time Goes

I’ve made a decent effort toward my OPW application for the kernel. The patch submission circus continues, but I’m on to my second application. A former intern advised me to apply to at least two organizations, to increase my chances of acceptance, so that’s what I will do.

The patch submission process for my second project is pretty much the same as it was for the kernel, but I want to be sure I’m doing it right. So, I just spent an hour getting git send-email to work the way I want it to, without my having to think about it. (Heads up: passwords entered with git config --global sendemail.smtppass will be ignored. Edit ~/.gitconfig directly.) I didn’t plan that; I just wanted to be extra sure I was sending my patches correctly, and once I had it all configured, tested and understood, I realized an hour had gone by. There’s still time to finish my application, since I have about 23 hours, and my first patches have already been sent. It’s time well spent, too, because I will use that skill no matter which project I’m accepted for. I’m just always surprised at how much effort (that I don’t give myself credit for) goes into little odds and ends such as this.

The Apple at the Top of the Tree

I’m still just an applicant to the Gnome Outreach Program for Women Linux kernel project, but I’ve already gotten myself into a two bosses situation. This is entirely my own doing–they’re not demanding anything of me, just watching to see if I do what I say I’m going to do. The mentor in charge of driver cleanups suggested a next step, a simple change of constants, and I said I’d submit it that afternoon.

Well, I should have learned my lesson. Messing with these two files is like cleaning behind the kitchen stove in some people’s houses–just breathe on it, and the roaches come flying out in all directions. At minutes before six, I gave up and wrote “does not correct whitespace issues” in the patch description. At least I was leaving the code better than I’d found it.

There was also my relationship with my other “boss.” I needed to actually submit some code for BTRFS, not just talk about it, or he’d have reason to believe I wasn’t serious. He’d been making a list of entry level tasks, and he posted it at about the same time as another mentor briefly froze the OPW working tree; and coincidentally, at about the same time as I needed to move. Other applicants submitted most of those tasks literally while I was driving. By six, practically all of them had been taken.

All but one.

After I finished assuming I’d just shown myself for a flake, I realized that the list was almost entirely low hanging fruit, except for the “more advanced” task at the bottom–the challenge–which had not yet shown up on the mailing list. If I was going to prove myself, this was the task to complete. The tastiest, juiciest apple was left, and dammit, it was going to be mine.

I drank some kava, listened to some binaural beats, took a deep breath, read the task description and the area of concern in the code until the fog went away, and chased down every function, struct and macro in the area of concern until I knew exactly what it did and how. The mentor spent some time with me on IRC, helping me be sure that my understanding of what he expected and how I should approach it was clear. I drew up a plan in a text file. Then I spent the rest of the afternoon and evening carrying out the plan line by line.

This task was particularly hard because it took judgment. I wasn’t just regurgitating my knowledge of Fowler, I was putting my own decisions out there as to how this new functionality could be expected to evolve and mature. A lot of it was subjective; it could suck, or it could just not be what the team wanted. I told myself that the important thing for the application was that I finished it, and did my best.

At the stroke of midnight, at exactly the original application deadline, the last patch of the set went on its way. When it did, the world suddenly became a beautiful place. The last time I tingled like that was when the first version of Xtra Screen Hacks, my first real piece of software ever, went up on Freshmeat. I was a huge relief to be able to hope I was still in the running. But whatever does become of my application, I’m proud to have done this.