When I first started to learn programming, about 15 years ago, I remember being surprised at how easy it was for me to get focused and stay focused. I loved (and still love) the feeling of getting lost in a project, and could easily spend hours upon hours "in the zone". No procrastination, no resistance, only focus and enjoyment. It was easy for me to find Flow. Part of why this surprised me so much is that I had always struggled to achieve (and still do) a similar state when writing. Dating back to the first paper I ever wrote (maybe 4th grade? Certainly 6th grade), the feeling I most associated with writing a paper was terror, dread, resistance, and avoidance. Procrastination station. Programming and writing are pretty similar activities, so I often think about what makes programming such a joy and writing such a chore (for me at least). Recently, the answer has been revealing itself to me, as I've been seeing a mindfulness therapist. Mindfulness centers around the practice of noticing your thoughts -- developing a kind of "meta awareness" -- so that you can then develop more control over how you react to your thoughts. In other words, often times, the thing that troubles us isn't our direct experience, but rather our reaction to that experience. Mindfulness (at least at the stage I'm at) helps you distinguish between the two. So, as I've been working on the mindfulness practice, and at the same time working on a few long-form writing projects, I've been paying a lot of attention to that moment when I find myself resisting the task. When that feeling rises up in my belly that pushes me to turn away, break focus, check my email, snap out of whatever Flow I may have achieved. And each time that happens, I've been trying to take a second and examine that feeling, try and figure out why I'm pulling away -- trying to notice what, exactly, is going on. It's a really odd thing to do, and is pretty illuminating. As far as I can tell so far, the difference between writing (where I feel the constant pull of avoidance) and coding (where I easily melt into Flow) is a certain form of terror, of not knowing "the answer" -- whether that's a certain wording, and idea, a structure, etc. Whereas with coding, I don't expect to know the answer, and bring wrong (try, break, repeat, repeat) is just part of the process. Also, I often get intimidated by the scope of a writing project, whereas it's easier for me to tackle programming work in pieces, so no one piece feels looming and huge. Recently, I've been trying to focus my time on smaller pieces (now I'm going to focus on the outline, now I'm going to flesh out the second section, etc), and have had some success. I am curious if others see this the same way, and/have techniques that work for them? The thing is: writing is powerful, exciting and fun, if I can just get over the hump, and then stay in the zone. So this is something I'm going to keep working on. P.S.: other places I've found flow: skiing, cooking, doing carpentry/construction work, singing, playing drums, building powerpoint decks, talking on panels at conferences. It sure is a good feeling.
Yesterday I spent part of the afternoon at a US Patent & Trademark Office roundtable discussion on using crowdsourcing to improve the patent examination process. Thanks to Chris Wong for looping me in and helping to organize the event. If you're interested, you can watch the whole video here. I was there not as an expert in patents, but as someone who represents lots of small startup internet companies facing patent issues, and as someone who spends a lot of time on the problem of how to solve challenges through collaborative processes (basically everything USV invests in). Here are my slides: And I'll just highlight two important points: First: why do we care about this? Because (generally speaking) small internet companies typically see more harm than benefit from the patent system:
And second, there are many ways to contemplate "crowdsourcing" with regard to patent examinations. In the most straightforward sense, the PTO could construct a way for outsiders to submit prior art on pending patent applications -- this is the model pioneered by Peer to Patent, and built upon by Stack Exchange's Ask Patents community. The challenge with this approach is that while structured crowdsourcing around complex problems is proven to work, it's really hard to get right. A big risk facing the PTO is investing a lot in a web interface for this, in a "big bang" sort of way (a la healthcare.gov), not getting it right, and then seeing the whole thing as a failure. To that end, I posed the ideas that getting "crowdsourcing" right is really a cultural issue, not a technical issue. In other words, making it work is not just about building the right website and hoping people will come. Getting it right will mean changing the way you connect with and engage with "the crowd". As Micah Siegel from Ask Patents put it, "you can't do crowdsourcing without a crowd". We also talked about the importance of APIs and open data in all of this, so that people can build applications (simple ones, like notifications or tweets, or complex ones involving workflow) around the exam process. Tying those three ideas together (changing culture, going where "the crowd" already is, and taking an API-first approach), it seems like there is a super clear path to getting started:
Set up a simple, public "uspto-developers" google group and invite interested developers to join the discussion there.
Stand up a basic API for patent search that sites like Ask Patents and others could use (they specifically asked for this, and already have an active community).
That would be a really simple way to start, would be guaranteed to bear fruit in the near term, and would also help guide subsequent steps Or, to put it in more buzzwordy terms:
It felt like a productive discussion -- I appreciate how hard it is to approach an old problem in a new way, and get the sense that the PTO is taking a real stab at it.
Over the course of the past year, I've been interviewed a bunch of times about the "peer economy" or the "sharing economy" (Fastco, Wired, NY Times, PBS Newshour), with most of the focus on the public policy considerations of all this, specifically public safety regulations and the impact on labor. A question that comes up every time is: "aren't all of these new independent workers missing out on the stability provided by full-time employment?" (e.g., healthcare, steady work, etc). My answer has been: yes, for the moment. BUT, there is an emerging wave of networked services which will provide this stability to independent workers, albeit in a different form than we're used to seeing. My colleague Albert describes this as the "unbundling of a job" -- the idea that many of the things that have traditionally been part of a job (not just steady money and healthcare, but also sense of purpose, camaraderie, etc.), will in the future be offered by a combination of other organizations, services and communities. Albert takes the idea a lot farther than I will here, where I just want to focus on some of the more immediately practical developments. Thus far, this idea hasn't gotten a lot of press attention, as the number of visible services providing this kind of support has been small. But it is growing, and I expect we'll see at least a small handful of these kinds of services gain traction in the next year. The oldest and most venerable organization doing this is the Freelancers Union. New Yorkers will recognize their subway ads that have run for decades, advertising their programs and member benefits. Freelancers Union's roots are in the pre-networked era, focusing largely on independent creative types in NYC, and their scope has grown dramatically over time, growing nationwide and adding services like insurance and medical plans. What we expect to see a lot more of are services that are tailor-made to support independent workers who reach customers and deliver their work through web and mobile platforms. For example, Peers, which is essentially Freelancers Union for the peer economy. So, what kinds of services are we talking about exactly? Here are a few of the kinds of services we've been noticing and think we'll see more of:
Insurance: One of the biggest challenges in this space has been how to insure it. We're seeing established firms consider how to address the space, as well as brand new insurers that are tailor-made for it.
Job discovery & optimization: Many networked, independent workers make real-time decisions about what kind of work to do (e.g., driving vs. assembling furniture), as well as which platforms to use (uber vs lyft). This is currently a manual, non-optimized process. Increasing discoverability and lowering switching costs will also be an important competitive vector to ensure workers' interests are being met by platforms. (e.g., sherpashare)
"Back office" - taxes, accounting, analytics: Dealing with paperwork is a huge headache for busy independent workers, and we're seeing a bunch of saas-type offerings to help people manage it all (e.g., 1099.is, Zen99, Benny)
Healthcare: Gotta have it. This is a topic in its own right, and not expressly specific to the indie economy, but we are seeing massive experimentation and innovation in how independent actors can buy healthcare (e.g., teladoc, medigo to name 2 of many)
I suspect that by the end of 2015 we will not only have a much longer list of example issues and services, we'll see that some of these have gotten traction and started to make a difference for independent workers. So, if you're a reporter covering this beat, I think this is an interesting angle to pursue. If you're a lawmaker or policymaker, I'd think about this as an important and growing part of the ecosystem. And if you're an entrepreneur working in this space, we'd love to meet you :-)