Review: Winning isn't Normal: Meditations on the Art of Ass-Kicking by Jason Shen

Review: Winning isn't Normal: Meditations on the Art of Ass-Kicking by Jason Shen

Disclaimer: I have worked with Jason and consider him a friend.

All self-improvers and autodidacts out there will enjoy these well-written self-improvement essays. This is a good book. I would not recommend that someone read it until they have read some of the classics of self-improvement: The Meditations by Marcus Aurelius and The Seven Habits of Highly Effective People by Steven R. Covey, for example.

It is not a single, cohesive argument, which leaves you with the feeling that your life is permanently changed. But if you want a series of short, 10-minute articles each of which delivers a cogent, researched and personally evaluated punch, Shen's Winning isn't Normal is a good investment. I certainly learned a lot reading it. My favorite lesson from the book when willpower fails is: “don't try harder, try something different.” As someone who has spent 30 years promising to try harder each New Year's day, I learned something from this book.

WebRep

currentVote

noRating

noWeight

Uncle Sam wants YOU...to be a hero hacker

by Michelle Hertzfeld and Robert L. Read, illustrated by Rishi Sohoni

Update: Round 3 is now closed. However, there will be additional rounds; so this article still applies, but you may have to wait a few months for Round 4.

[Please use this link: http://michellehertzfeld.com/thoughts/uncle-sam-wants-you/ for additional promotion of this article.]

Round Three of the Presidential Innovation Fellows program is now accepting applications from creative, energetic policy hackers, entrepreneurs, user experience experts, designers, frontend developers, backend developers, system architecture wizards, data wranglers, and more to serve their tours of duty to radically improve the delivery of government digital services.

Why should you (yes, YOU) take time out of your busy schedule to apply? Three important reasons:

Uncle Sam Wants YOU...to Help Millions

Working with Innovation Partners inside government agencies Rounds One and Two of the Innovation Fellows program touched millions of lives in important ways (click for larger view):

Innovation Fellow Projects: Contributors and Beneficiaries

Here’s a taste of what these projects do:

• The Green Button initiative gives American families and businesses secure and easy access to their own utility energy information, giving them opportunities to save energy and money.
• The Blue Button initiative provides individuals with secure online access to their own health data.
• FBOpen gives small business owners with a new, easier way to learn about and compete for Federal contracts.
• Project Open Data unleashes freely-available data from the Federal Government that was previously difficult to find and use (think National Parks, climate, and government spending) back to the taxpayer.
• Disaster Response and Recovery leverages technology to provide with a helping hand (tools, apps, services and more) when they need it most.
• Work at the Smithsonian Institution gives Americans their own history, digitized.
• Adverse Drug Effects gives doctors the information they need to treat patients safely.

The Round 3 projects will build on this work and introduce great new projects.

Uncle Sam Wants YOU...to Work With Amazing People on Big Problems

Innovation Fellows come from many backgrounds and have a wide range of skills, but they share two characteristics: excellence and dedication. Do you long to work with a team that constantly challenges you? Do you long to work with peers who are all top-of-class problem solvers and creative minds?

And not only are the people you’ll work with extremely technically and creatively intelligent, but they’re also a group of people who have chosen to dedicate their precious time and energy in exchange to move their country forward. This is an opportunity to disrupt government and

truly transform how it works for the people it serves. You want a more participatory democracy?  Here’s your chance.

As an Innovation Fellow, you will have extraordinary leverage to solve big problems and implement game-changing solutions. Some of the projects in the diagram above were not planned, but discovered as opportunities in the course of other projects.

Uncle Sam Wants YOU...to Serve and Return

Becoming a Fellow is a commitment to work as hard as you can on behalf of the American people. It is a commitment to patiently run through walls that exist in the government bureaucracy. It is a commitment to spend a lot of time in DC.

But it is not a never-ending commitment. You are not signing up to become a permanent Federal employee. You will contribute your industry and entrepreneurial expertise to improve government and take what you have learned from other Fellows with you when you leave.

So What Are YOU Waiting for?

Apply by April 7, 2014. Throw your hat into the ring to make digital services in America an extension of the civic innovation that Franklin and  Jefferson pioneered while collaborating with some of the smartest, most dedicated people you will ever meet, solving some of the most important, challenging problems of this generation.

Even if you choose not to apply, please help spread the message

Please republish this article or the following links to promote the Presidential Innovation Fellow program:

• Read: a blog post by Todd Park, U.S. CTO and  GSA Administrator Dan Tangherlini.
• Watch: U.S. Deputy CTO Jen Pahlka issue a call to the innovation community to join the ranks of the Presidential Innovation Fellows and serve their country.
• Find: The list of Round 3 Presidential Innovation Fellows program projects here.

P.S. Consider saving the taxpayer money by contributing to our Open-Source projects…

The Fellows’ projects are in the public domain by default and can be found at github under the team Presidential Innovation Fellows.

Exploring Sewing: A different technology for me....

I have always wanted to learn to sew---somewhat inexplicably.  When I became a Presidential Innovation Fellow and started working 70 hours a week for the American people, I quite practicing viola, which has taught me something:  I cannot live for long without doing something when my hands.  I have to work with my hands.  I argue (I'm not the first) that the brain should really be thought of as including the retina and the fingertips.

Four years ago, my daughter was interested in being a fashion designer.  Being a supportive father, I bought her a sewing machine.  However, after a while, it sat unused in the closet---until last month.

My first project was a skirt from a pattern.  Skirts are the easiest garments to make.  The project was partially successful---the skirt is wearable, but has not yet been worn.

My second project was to address a need we have had in our house for some time: privacy drapes in our hot-tub/laundry/bath room.  These are barely needed because the geometry of our house doesn't let people see in---unless they are, for example, in a truck.

But nonetheless we wanted drapes, to cover the window shown in the first photo.  Note that this window is unusually wide and short.  Furthermore, I strongly wanted something translucent so as to not darken the room too much even when the drapes are drawn.   Finally, I wanted something to match the red hot-tub cover and the cedar paneling.

You can't find drapes like that at Wal-mart.  You can find drapes like that online---you can find anything online---but where is the fun in that?

I'm happy to say that Nancy Zieman's Sew with Confidence remained in the box with the Baby Loc Design Pro sewing machine, and that it includes an almost clear description of how to make tab drapes.  Having scraps and muslin available, I made a test work without purchasing any new material, which is shown in the fourth photo.  Hanging this on the curtain rod proved successful, and making it helped me understand how to make the drapes.

I purchased some burgundy poplin and yellow cotton gauze, and followed the same approach.  The result was mostly successful.  As The Dude would say, the drapes "really tie the room together."

I am much more confident in my use of my machine now.

Some things I learned:

1) Making the rough draft was a technique I will employ more often.

2) Gauze is so stretchy that it is almost impossible to measure and cut perfectly.  You will note the hem is uneven.  I worked a long time to get it that close!  Perhaps someone with a large table and rotary cutter could have done better.

I personally am always interested in home economics.  Here is the breakdown of this project:

Curtain Rod from Wal-mart: about $15

Gauze and poplin, (of which much remains): $45

Sewing notions and impulse buys : $10

Total input in terms of time: 12 hours

So in terms of cash, this project was slightly cheaper (arguably) than buying drapes, but it would have been hard to get the color and translucence and all-cotton construction that I valued.

At minimum wage, this would have been a financial loss over buying drapes.  At what I make as an expert computer programmer, it is a financial disaster.

In terms of education, however, it more than made up for the loss.  I value very highly leveling-up my sewing skill.  I can now honestly claim to be a rank beginner.

On top of that, my wife seems happy with the results, always an added bonus.

Once Upon a Time Inside the Federal Government, You Created a Startup

Once upon a time, you had a great idea for how to make things better for America. You thought it was something that people really needed, but you knew it was very different than what was being done right now. You were afraid that if you told your idea to the people around you, they would start explaining why it wouldn't work---and you were right.

So you found one friend that you could count on. You told your idea just to that friend and asked for their moral support, because you knew startups are almost never founded by individuals, but by great teams like Jobs and Wozniak, Hewlett and Packard, Orville and Wilbur. Your friend agreed to be there for you when the going got tough.

Then you read Lean Startup by Eric Ries and Extreme Programming Explained by Kent Beck. You printed out and hung on your wall the Twelve Principles of Agile Software (http://agilemanifesto.org/principles.html) because you believed those principles applied to any change, not just software, within government.

Then you started, and that was the most important thing you ever did.

The first week, you wrote down, on a real sheet of paper in your own hand, what you wanted to learn in order to make your improvement a reality.

Then you figured out a way you could talk to real people, which you thought of as customers even though they wouldn't actually be paying you in money, but in something more valuable---their time and support. You went to them and tested your idea. You wrote down the result, and decided how you would respond next week to what you had learned.

You did that every week, without fail. Sometimes your weekly evolution was clearly rejected by your customers, and you viewed this as a success, because you had learned something valuable. You listened really, really deeply to everyone who seriously thought about your idea and ignored the people who didn't.

As your idea turned into pictures and then prototypes, you became more confident, but as you reached out to more people you encountered more resistance and more naysayers. People started to be threatened by your idea.

Eventually, someone powerful confronted you and told you to stick to your “real work”. You didn't argue with them. Instead, you let the evidence you had gathered for weeks speak for itself. Your customers, or the people who would one day be your customers, were far more convincing than you could be.

A few times you made a “transformational pivot”. Something you learned was so significant that you had to give up your original idea---because the new idea was even better. Agile methods disallow slavishly sticking to the original vision when your process shows that there is a better one.

You reached out early and periodically to security officers and legal counsel because you were set on breaking habits, not rules. You worked creatively with them to get feedback without violating the Paperwork Reduction Act. Remember that week you lugged your laptop and a story board all over DC to show people things you couldn't put on the internet? You invited people to your office where you were on a local network. Working with security and legal, you got creative in building very realistic fake data sets that could let your customers give you good feedback without risking any sensitive data being revealed. How surprised they were to learn that health care data was really about the animals in the Smithsonian's National Zoo!

At every turn, you looked for opportunities to share credit with the people who helped you, but most especially with the people who opposed you. You had a bank account, but it had no money. Praise and opinion are the coin that moves the government. Your bank account was an emotional one, and you went deeply into debt in order to fill up other people's emotional bank accounts. If you spun the truth a little to overemphasize the accomplishments of your colleagues and to point out that that idea that you two had together was mostly his or her idea, well, it was all for the good of the American people, wasn't it?

You knew that a picture is worth a thousand words and a prototype is worth a million. So every week your idea become more and more real, more polished, more supported by evidence. Rather than re-inventing the wheel, you stood on the shoulders of giants. The technical part of your product leaned on open-source tools that were easy to use and leveraged decades, and sometimes centuries, of person-labor brainpower.

Your hard work was paying off as people began to understand your vision, which, admittedly, had gotten a lot better than when you first started---how could you have been so naïve back then? In your mind, it was no longer “your idea” but “our idea”.

You were now used to working and improving every single week. Some weeks the improvement was small, sometimes it was great. But you spoke to your customers every single week without fail. You had learned to resist the institutional perfectionism that is typical of government. You had shown by experience that a small improvement this week was worth any number of promises for next month.

Eventually it was time to reach a broader audience and gain more support, so you planned and executed a big event around your idea. You called it a Hackathon or a Conference or something else that fit your idea. You invited a group of people who weren't in your circle to help you. You were well organized, and had a list of what you wanted out of the Hackathon, and that helped, but you were flabbergasted but how much help you actually got. Your event not only directly improved your product, it also gained you valuable allies.

Every good Hollywood movie has a false victory, and here is how yours played out. You eventually presented your idea to a Very Important Person. Of course, the Very Important Person said you were very smart and they liked it, and, in fact, they thought it would be a success if would you only do one little thing, which, for security reasons, we'll call the McGuffin (http://en.wikipedia.org/wiki/MacGuffin).

You were thrilled! All you had to do was the McGuffin, so you started right away on it. Of course, as you thought about it, you realized the McGuffin was maybe a little bigger than a one-week project. In fact you realized that you had just spent three weeks working on the McGuffin, and you had not gone back to your customers. You had stopped delivering continuous improvement! The McGuffin was, in fact, a trap. It wasn't set by the V.I.P. or by malice, it was set by something far more insidious: the Force of Habit. Your greatest enemy! The entire organization, and everyone in it was, in fact, ruled and controlled by the Force of Habit. Even you.

But you had good habits and good friends, because you had worked for months to develop both around your product. It was true, of course, that the McGuffin would have to be accomplished, because after all, rules are rules, and in the government the rules are sometimes laws. You were out to break habits, not rules, so you went back to the Principles of Agile Development.

You asked the thinkers, testers, programmers, security experts and lawyers with whom you had built personal relationships: “How can we divide the McGuffin up into smaller problems toward which we can make gradual, measurable progress toward every week?” Going back to basics turned the tide in your favor, because an active, satisfied, growing user base asserts its own value and sweeps away all other hurdles eventually. It took longer than you expected, but now it is clear your startup has taken on a life of its own and will survive whether you continue driving it or not.

So now, a year later, here you are. You have created a successful startup within government, despite all the people who said it couldn't be done. The American people are better off in some small way, which of course is why you are in government service in the first place. You're taking a week off, and then next week you are going to go back to basics and review the Agile methods you have sharpened through practice and taught to others by example. Then you are going to start the next project, because you know that nothing is ever really done, and everything can be improved. Even Agile Software Development Methodologies.

Tips for Software Innovators Inside the Federal Government

This essay was first published at the Code for America Blog.

Tips for Software Innovators Inside the Federal Government

1. Change the game through prototypes,
2. Be a samurai: a loyal hacker,
3. Be fast rather than good,
4. Stand on the shoulders of giants,
5. Scrape, don’t bow, and
6. Be prepared to work outside the system.

1: Change the game through prototypes
A picture is worth a thousand words and a working prototype is worth a million. The federal government is used to suits coming in and talking about how great a system they are proposing to build will be two years from now if they are given millions of dollars to build it.

Shatter that paradigm by showing up with a working prototype, and talk about how great it will be if you get their cooperation in polishing it.

2: Be a samurai: a loyal hacker
The federal government has outsourced its technical brain and understaffed its technical know-how. It is not uncommon for one technically savvy person to be in charge of overseeing millions of dollars of labor without a staff. In short, the contractors have the administrators outnumbered about 30 to one. This is a recipe for chaos and confusion, and the result is terrible performance of contracts in many cases.

Say to the administrators: “I am a hacker, and I have no outside interests or loyalties. I am an expert who can’t be bluffed or intimidated or deceived. I will be your bodyguard, your gallowglass, your samurai. You can rely on me for brutally honest technical advice. With me at your side you will be able to negotiate a better contract and stay more in control.”

3: Be fast rather than good
Scientists need to study what happens inside government buildings, because I’m quite sure all processes are five times slower inside the federal government. Paper falls to the ground more slowly. When you switch on a light, it takes a while for it to reach the corners of the room. Getting a computer takes six weeks. Getting an Authority to Operate takes three months.

The government needs people with superpowers who are not affected by this timespace anomaly. Things that normally take a year need to be well underway within a week and ready for evaluation within a month.

Why? Because this is the best way to reduce risk. To make sure a two-year-long project matches the needs for which it was intended one must strive utterly to get as far as possible in the first month. In order to do that, programmers must be prepared to be sloppy and lock their inner perfectionists in the bathroom for a while.

An engineer who can build a prototype in a month can change the consciousness of an entire organization faster than the government can get a contract written to do the work. The methodologies that have been developed in the last 20 years to develop software quickly really work, and they work even better within government where speed is desperately needed. These are named Agile Methodologies, Extreme Programming, Lean Startup, and so on ad nauseum. Every few years the basic concepts are tuned a little and renamed, but the principle remains the same: learning something real right now is more important than fantasizing about something big a year from now. As Kent Beck has taught us, “You go fast by taking babysteps as rapidly as you possibly can.”
Demand the same speed and transparency from contractors that you demand from yourself.

4: Stand on the shoulders of giants
America invented the “Free as in Freedom” software movement. There is a silent army of intellectuals constantly adding to freely available software. Historians a century from now will look upon it as a great gift that the USA gave to the whole world.

The continuing explosion of off-the-shelf software capabilities is so tremendous that a software engineer now must think not so much about writing programs but about joining programs together. No one person can keep up with all of these capabilities. I love programming, but it is my duty not to program but rather to spend most of my time investigating what others have programmed in order to not reinvent the wheel.

5: Scrape, don’t bow
The biosphere of government software systems is a coral reef, each system built on the grotesquely shaped skeleton of its ancestors. These systems have inertia: users, rules, regulations, entry points, touch points, system interactions. Rather than try to change them, accept that whatever you build will have to be bolted on to the existing reef with as little disturbance as possible. By scraping existing websites, or by using extract-transfer-load tools, you can make something wonderful and beautiful even if what lies beneath it is ugly.

6: Be prepared to work outside the system
The government is risk-averse and highly responsive to outside pressure. It fears embarrassment. It loves praise.

If you can find one example of an agency doing something, it is much easier to convince other agencies to follow that example. Just as entrepreneurs must be prepared to go hat-in-hand to many different potential investors, be prepared to look for champions of change outside your own circle.

Finally, when you encounter resistance, ask yourself, “If I were not a government employee, what could I do to solve this problem?” Citizens want to help. Find them and utilize them to expand the bounds of possibility.

--Robert L. Read

PIFAM on hold because I am a Presidential Innovation Fellow

I'm honored to announce that I have the chance to serve my country as a Presidential Innovation Fellow (PIF).  Note that the abbreviation (PIF) and the name of this blog (PIFAM) is pure coincidence.

http://www.whitehouse.gov/innovationfellows/round-2-fellows

I plan to work with extraordinary dedication to try to save the government money, so I'm afraid my other invention and innovation work will be placed on hold for the rest of this year.  In fact, I have been working here in DC for the last week, having left Austin and my wife and daughter to be most effective here in DC.

This blog has never had much readership, and few comments.  Although my time is limited for this year, I plan to return to it in 2014.  Until then I am of course able to respond to comments if there are any.

New Project: Parallel Markup

Dear Fellow Inventors,

Elliot and I have decided to postpone working on the Fresnel lens until warmer, sunnier weather here in Austin.

In the meantime, I intend to create a new project, which I call "Sparmark", a human readable system for parallel markup.

Parallel markup is the idea of NOT modifying a document with markup but rather creating a separate, parallel document to hold markup which essentially represents a transformation of the original document.  When I studied this field some years ago, the research for it was not terribly advanced, and I thought it was a field in which amateurs such as ourselves could make a significant contribution.

I believe Ted Nelson has been the biggest contributor to this field with his idea of Transclusion.  I found this paper: Embedded Markup Considered Harmful http://www.xml.com/pub/a/w3j/s3.nelson.html to be a particular compelling and cogent expression of the problem.

In this post on New Year's Day I can't put down all of my ideas about this, but here is a summary:

• I think we should create an open-source project to create parallel markup standards and software tools that will make transclusion much easier.  I imagine Python to be a language particularly well-suited to this, although I have never used it. (My previous work on this was in LISP.)
• We must focus on creating a forgiving and human-editable markup.  In particular, I intend to draw inspiration from the markup that human copy editors do with a pencil.  The fact that we must deal with electronic texts should not prevent us from learning from the analog standards that copy editors have developed over decades.  XML is a terrible failure because it focused on software tools rather than human use.
• I'm going to go out on a limb and try to create some videos and other things to recruit others to be involved in this project.  This log is very lightly read.  I don't seem to be very good at affecting my fellow workers, but I intend to continue working on it.

Please contact me if you would like to help create a team to work on this project.