Shared posts

21 Jun 21:03

Sorcery 101 Writer Notes on Chapter 20

Originally published at Sorcery 101. Please leave any comments there.

You can read them on Patreon!

15 Jul 00:06

Saturday Morning Breakfast Cereal - The Village and the Tower


Hovertext: This comic is an allegory for, of course, the 1896 presidential elections.

New comic!
Today's News:
17 Nov 03:20

The time to think about middlemen is before there's only one

by Seth Godin

I grew up near a mall that had 42 shoe stores. If a store didn't carry what you wanted, it wasn't a big deal to walk 22 feet to a store that did.

The core issue of net neutrality isn't whether or not a big corporation ought to have the freedom to maximize profit by choosing what to feature. No, the key issue is: what happens when users are unable to choose a different middleman?

In a town with ten newspapers, finding a newspaper that brings you the truth you seek is not a challenge. But network effects and lock in mean that in more and more arenas, there's a natural monopoly arising.

The simple example is cable TV. It doesn't pay to wire a town with five or six competing cable companies, and so we end up with one middleman. The simple understanding of net neutrality: When there's only one middleman, who gets to decide what you see?

When local retailers disappear, who decides what you can buy? Do we want a middleman to be able to lock content out for their own reasons? I think it's reasonable to have the following principle in place: Promote what you approve of, but don't black out what you don't.

We can argue that it's smart branding and good business to let your users have what they want. But often, corporate short-term interests fly in the face of long-term customer satisfaction, and the race to profit gets in the way of our culture's need to hear and see and read work that might not fit those interests.

What if search engines or ISPs decide to 'disappear' content they don't like? When there are plenty of middlemen, it's not really an issue. But when there's lock-in, it's too late to have this discussion.

We make a deal with the natural monopolies in our lives. They get the privilege and the profit of being the only one, but in exchange, they accept the responsibility of being open middlemen, of being neutral, of not blacking out those that don't pay up or that don't agree.

If ConEd or your local power utility said, "sorry, our electricity can't be used on Maytag appliances because they didn't pay a slotting fee," you'd be appropriately incensed. But when it happens to ideas, I fear the cost is even greater.

We live in the connection economy, a world based on ideas. When a few corporate titans can control the flow of those ideas and the essence of that connection, we've given up far too much.

03 Nov 07:02

gettin real aggressive with the negative self-talk lately

gettin real aggressive with the negative self-talk lately

12 Sep 01:28

Comic for Thursday, September 11th, 2014

Comic for Thursday, September 11th, 2014 is located at
25 Aug 08:44

Nobody But Yourself

by Chris Guillebeau

“To be nobody-but-yourself—in a world which is doing its best, night and day, to make you everybody else—means to fight the hardest battle which any human being can fight; and never stop fighting.” -ee cummings

10 Jun 03:23

Docked and Unplugged

by dtate

Last year I went on my first cruise with my family. On the last night of the cruise my daughter got massively sick at 4 AM. Unable to go back to sleep after getting her settled I decided to take a walk around the ship; we would be de-boarding soon and I was sort of curious what the mini-floating-world would look like that early (especially on the last day). I was expecting a lot of tired children with Type A parents sitting at breakfast trying to stay awake so they could reach the car per their detailed schedule. Instead I found a closed breakfast buffet and a handful of men all sitting around looking at their cellphones.

I had noticed that my phone had chirped to life during the elevator ride to the 11th floor – finally within range of a cellphone tower and out of the deep interior of the ship it started its soft little symphony of text messages, work notifications, application updates, and social media “alerts”.

The men I found seated at tables (1 per table facing the same direction like an odd morning commute) didn’t have sick children who had awoken them at 4 AM like I had. They also didn’t have their families with them. They were all staring blankly at their phones and slowly scrolling through all those notifications. Not really knowing what to do since there were no pancakes to be eaten like I hoped I also sat down and pulled my phone out. Per usual whenever any modern person has a few spare moments I assumed the default behavior – slowly scrolling with my right hand.  News outside the network of things that actually affect me, work emails, photos and funny sayings, pictures of cats and babies – all scrolling past in a slow scroll.

I then stopped, stared blankly for a minute, and simply thought: What in the everlasting crap am I doing?

To want to leave the comfort of family and vacation a few hours early to catch up with work: this is the behavior of an addict.  I stood up and rode the elevator back to my softly sleeping family.

19 Mar 01:56


by Tom MacWright

Education means a lot of things: self-education, online classes, Pre-K. It’s as important as it is complicated, especially in technology. Many programmers learned their first lessons on a family computer, not in a classroom. That’s where I started, and without deeper consideration, it could be “the way”: formal education in the backseat, adolescent hacking at center stage.

But self-starting doesn’t scale like we want it to. There are kids with home computers who have time and will write scripts and hacks for fun and have a supportive peer group who will think that’s cool. But they look a lot like I did at the time: white boys with parents who can afford a real computer, and people around them who understand or accept their interests.

I don’t think this will change on its own. Computers are cheaper and more powerful than they were in my youth, but they are poorer gateways to experimentation and learning. Gender stereotypes are still strong and destructive, as are many other lines upon which people are group- and self-discouraged to experiment.

Educational resources are one escape hatch: with a little technical knowledge and a reason to learn, you can dial up sites like Codecademy and advance up the rungs of knowledge. But those qualifications are brutal. What seems like an iota of prerequisites to me is a mountain. The spark, the motivation, to take the leap, is huge, and without it few have reason to trudge through the painful initial learning curve.

Teaching can help. It’s hard and time-intensive and can be draining, but it’s uniquely able to inspire and inform.

So I decided to try: I spent a week co-teaching a class with Sarah MacWright at Millbrook School in upstate New York. With ten high schoolers, for five days of five hours a day, and we learned how to make the web. Here’s how it went.

Building the web with HTML, JavaScript, and CSS.

The choice of topic wasn’t obvious or easy. As _why astutely said in his Art && Code talk, why would anyone choose to teach a just-starting programmer three languages at the same time? You could use a single language and a single environment, like Python or Ruby. But the end product matters: on the web, kids can share and brag about their creations. And they can connect to websites they already use in a new, fascinating way: view-source feels like understanding deeply.

Then, the question of abstraction: should we teach HTML or Wordpress, or another CMS? Wordpress quickly makes real-looking websites, and spares kids the worst parts of the learning curve.

But our intent was to create deeper understanding and creative urges, not just to make websites. The pain of HTML, CSS, and JavaScript lets way to a different way of thinking about the web and a cheat code to understanding it in a universal light.

The First Lesson

The order of languages taught follows their difficulty level and distance to the ‘basic webpage’: HTML for content, then CSS for style, and finally JavaScript for behavior.

I didn’t want to start the class with a ‘framework’ or Hello, world on a white page. We need a better onramp: something that connects and entertains.

We used ‘Inspect Element’. Everyone opens the school homepage, and right-clicks on a title. They see their first pageful of confusing HTML, but have a clear mission: vandalism. In practice, it was gentle trolling: changing the name of the school to ‘My School’ and redesigning the page in fashionable shades of pink, amongst other tweaks.

Then we moved on to start changing behaviors and animations, by learning our first bits of JavaScript. Given a Flappy Birds Clone, students typed their first lines of JavaScript, changing gravity, acceleration, the gap between pipes, and everything else.

This wasn’t a lesson to teach the nitty-gritty. We imparted the hacker mentality, that we can change the stuff in computers, and braved the first sight of intimidating software code while ensuring kids felt positive and were having fun.

The Nitty Gritty

The second day, we started building from scratch. I gave a short, simple presentation on the basics of HTML, and students followed along. Setting up text editors and learning how to save & refresh would have cost time, so we used jsbin to edit our first bits of HTML.1 First, Hello, world, and then Hello, <strong>world</strong>. Then tinkering with tags and typing. In this early stage it’s vital to have instant updates so kids can try variations quickly: this attempt-fail-succeed loop is where you learn.

Then, a presentation about CSS and similar tinkering.

Words Help Us Learn

Around this point I noticed that my style of teaching didn’t use terms effectively.

Words contain and define concepts, and they structure learning. Mine had blended together in day-to-day work, so I wasn’t nearly discrete or precise enough in my language.

For instance, I should have taught the concept of matching HTML start tags to end tags as ‘balancing’, with exercises and analogies, not as a detail or peculiarity of language. Then you can talk about balancing, and kids can grasp why it’s a common characteristic to the languages they learn. I needed to create words and mnemonics for when to use which brackets in which language. Familiar metaphors for syntax like ; in JavaScript - “it’s like the end of a sentence” helped students in a way that tens of mistakes wouldn’t.

First Bite of JavaScript

Then, the final language: JavaScript. I ran through a quick presentation and encouraged the class to try out examples in

As expected, teaching JavaScript is significantly harder than HTML or CSS. These lessons, more than any others, identified disconnects between the world of code and the language of English.

  • People are sentence-case by default. HTML is permissive, CSS is less, and JavaScript is even less.
  • Balancing brackets like method({}) requires a mental queue of what you still have to end. The ability to do this varied widely.
  • It was remarkably easy to avoid an in-depth explanation of objects and JavaScript ‘warts’ like this.
  • Explaining ‘what happens when’ in JavaScript is extremely hard.
  • JavaScript error reporting in browsers, while great and improving, could always be better and friendlier.

Only two students decided to grapple with JavaScript for the rest of the class, and they constructed incredible games. For the rest of the class, this was just a glimmer, and a lesson I was divided on: the amount of knowledge you need to start using JavaScript is significant and its usefulness your first HTML/CSS websites is limited. But, conversely, as the only imperative programming language, it has creative and academic potential greater than any markup language.


The first lessons used online programming environments that imitated live-coding, but to move forward, we needed to start building websites - that means files, editing, and servers. We set up Sublime Text 2 for each student, and I ran a Terminal window with python -m SimpleHTTPServer running from the ~/Sites directory. Instead of just typing, students needed to save and click ‘refresh’ to see changes.2

In usage, Sublime Text had a number of issues that made it feel like a sub-optimal choice.1 In hindsight, I might have used TextWrangler instead, if an even-simpler text editor doesn’t crop up.

Exercises & Handouts

Sarah wisely added exercises to intermittently help kids solidify their learning and check that they understood what we were talking about. After each lesson, we would make a quick ‘about me’ page or a <table> of our favorite foods: tasks that encourage students to use their skills creatively.

Then we created ‘cheatsheets’ with examples of HTML elements and tips for writing new pages. These were quickly and persistently adopted by the class.

Student Projects

On day three, students began their projects: four students built photo portfolios, two built games, and four worked in a group creating a student blog with Tumblr.


In an afternoon, I built a simple template for photo galleries, with concise HTML & CSS markup. By link-dropping a ZIP file of it on Dropbox, I gave students a running start on their projects: quickly we went towards Google Fonts for customization, switched to auto-advancing slides, tweaked colors and other details.

Seeing the students use the web as their medium was fascinating, especially in those who had experience in photography and framing. There grew new logical questions: how should a carousel work with different aspect ratios? Given infinite options for backgrounds, which complements their photography and style?


Though many expressed interest, only two students ended up building games. A freshman and senior, they started with the Coquette framework which provides fundamentals like collision detection and a canvas to draw on. The game above, called The Maze Raze, features an awesome hand-drawn player and this student’s first use of trigonometry in the real world.

Another game, called Flying Mario, evolved from a side-scroller to a helicopter-like game with Mario-inspired graphics and style.

The games were far different in scope and skills than the other projects - there was an awesome moment where a student used trigonometry in the real world for the first time, making little pixel rectangle targets move in a video game. But we also bumped into some of the hard problems of games, like collision detection and how have different entities in the game exhibit different behavior.

I was fascinated by the ‘tuning’ tasks that students quickly mastered, like adjusting the ratio between gravity and jump height to make a game tricky, or designing a maze with nothing more than pixel coordinates and sizes of rectangles.

Coquette was fantastic for this purpose and let us focus mostly on actual topics and behavior of the games. For the small issues we found, I’m making notes to create examples or patches to make things even better.


At lunch on Thursday, I was talking with the math teacher about class, and reported that two of my students had used math: not just arithmetic, but multiplication, trigonometry, algebra.

I realized something I never had as a student: schools have multiple subjects that are independent. In each subject area, students can be two or more years ahead or behind, or can even opt-out.

The difference between how I barely learned in school and how I learn today is that I now jump subjects through combination. For instance, I wanted to learn statistics, so I wrote simple statistics, bootstrapping my non-existent stats skills with my decent coding skills. This way you learn by application and avoid the knowledge vacuum. And you have the fun experience of finding new subjects within your range.

But when you don’t know if students have taken tech class or art class, you can’t teach this way. And ideally, that’s how you teach coding: you teach fundamentals, and then apply them everywhere, in math, in art, in English. Coding is a lever, and could be effectively learned as one. You could think of it as writing or reading - skills than you use for the whole journey.

School Blog

The final project was a school blog, We chose to host it on Tumblr, since it permitted HTML & CSS editing, but also made the upkeep of a blog-like website less tricky. The places students took the site were interesting and awesome - after the have an understanding of HTML & CSS, they start asking more of ‘custom’: can we change layouts and design part of the site from scratch? And the mix of technical and non-technical tasks let students teach each other.

Let’s Talk URLs

Once the websites were in motion, I realized that we were missing an element of knowledge: URLs. How to link to pages, the difference between relative and absolute, and the different parts from http:// to .html, are essential bits of learning that make the web make sense, and are often abstracted away. Chrome has experimented with hiding http:// in the address bar, and students spend much of their time on singular websites, like Facebook. I never had the time to teach this, but I should have.*

Going Live

The final step was going live: putting portfolios & games on the internet, where students could pass around URLs or even put them on college applications. This was a surprising challenge to source: where, on the internet, can you just drag & drop files, for free, simply? It’s easy to find application hosting like or more advanced tools like GitHub’s gh-pages functionality, but the low end is scarce.

The answer came from an unexpected place:, a volunteer project that captures the spirit of now-shuttered GeoCities, worked perfectly. Registering for an account is simple, and uploading a site is just drag & drop. Since photos in portfolios were hosted on Flickr, all of the student projects were well under the 10MB storage limit. And in a moment that made my oldness visible, no-one in the class had heard of the once-popular GeoCities, so the name had no connotations.


The class was a few weeks ago, and it’s still sinking in. When I write code or try to explain a topic, there’s a much greater range of considerations and possibilities, thanks to my sister and these students. Like any sort of teaching, the results will come in time - I hope that we inspired people to think creatively and feel like they can change and make more kinds of things.

Teachers reading this post will probably wince at my newbie mistakes.5 Without my sister’s teaching ability, I would have only confused and bored this class. Like many non-teachers, I didn’t know how to teach. But this is a new area, and is still a little mysterious to everyone. There’s a blossoming of adult tech education, like, and Hacker School and its clones, but we’re still looking for a good way to start earlier. Teachers and tech people alike are still finding what works and what doesn’t.

And so, just like coding, I’m hoping to iterate. The things that didn’t work, I have guesses for what would work better but they’re only guesses. The variables of time, location, and demographics would all massively influence content & style.

The full class materials are in a Github repository and are CC0 licensed. If you’re interested in trying out teaching, there are plenty of places to start, like CoderDojo, TEALS, Citizen Schools, and


  • It was hard to choose a HTML editor that would work great: Mozilla Thimble was a first choice because of its great HTML error reporting, but I was expecting to need to save the output, and the Persona requirement was a deal-breaker. JSBin did well, but exhibited a few bugs and oddities: sometimes the cursor would jump to an incorrect spot, external links don’t work in the right pane, and refreshing the right pane is somewhat unreliable. In the end, we didn’t actually need to save output often in this stage, so Thimble would have fared well.
  • For the most part this was successful, but it made me realize that an even-simpler might be useful - something that slims it down to a single line of JavaScript and explains what that JS does in painstaking detail. You type var foo = 4; and it explains what every token means - you’re creating a variable, called foo, assigning it to 4, which is a number, and ending the line with ;. And it would give fantastic guidance for incorrect or incomplete input.
  • Unlicensed Sublime nags you for a license every few saves. Automatic bracket insertion was, in the vast majority of cases, counterproductive. I think that bracket insertion is an example of overoptimizing for writing code while crippling the experience of editing and rewriting code, which is very much the majority task. The ‘tabs + sidebar’ navigation was confusing. Disappearing tabs are poorly communicated by the interface, and tabs don’t convey the difference between files with the same name in different folders. And by default, Sublime doesn’t have JavaScript formatting and I didn’t have enough time to configure a plugin for it (or find some hidden preference).
  • Autorefresh code does exist, of course, but given the time constraints and the limited ability of students to debug software, I went for the simplest route.
  • Incidentally, the school is also trying to find a teacher who could do technology, and it’s a tough hunt. Resources that would help teachers cross over into technology seem pretty slim, and there aren’t a lot of experienced educators who can or will cross-over. Perhaps this is an area where teacher fellowship programs can contribute.
  • This was inspired by Eric Mill, who previously presented on URLs at Open Data Day and discusses how using URLs is a skill that needs to be explained and taught.
15 Dec 07:46

Quality Assurance

by Michael Berger

Back in March of 2009 I joined 37signals as Signal #13 and the other half of our two person support team. At the time we relied mostly on bug reports from customers to identify rough spots in our software. This required the full time attention of one or more “on call programmers”– firefighters who tamed quirks as they arose. The approach worked for a while but we weren’t making software quality a priority.

I had a chat with Jason Fried in late 2011 about how my critical tendencies could help improve our products. Out of that, the QA department was born. Kind of. I didn’t know much about QA and it wasn’t part of the development process at 37signals. So my first move was to order a stack of books about QA to help figure out what the hell I was supposed to be doing.

It’s been almost two years since our first project “with QA” back in 2012. Ann Goliak (another support team alumnus) recently joined me at the stead. Our QA process isn’t traditional and goes a bit different for every feature. Here’s a look at how QA fits into our development process, using the recent phone verification project as an example.

Step 1. I sat down with Sam Stephenson back in early July for our first walkthrough of phone verification. Hearing Sam talk about “creating a verification profile” or “completing a verification challenge” familiarized me with the terminology and flows that would be helpful descriptors in my bug reports. Here’s what the notes look like from that first conversation with Sam.
Step 2. After the introduction I’ll dive right into clicking around in a staging or beta environment to get a feel for the feature and what other parts of the app it touches. This is often the first time that someone not designing/coding the feature has a chance to give it a spin, and the fresh perspective always produces some new insights.
Step 3. There are lots of variables to consider when testing. Here are some of the things we keep in mind when putting together a test plan:

  • Does the API need to be updated to support this?
  • Does this feature affect Project templates?
  • Does this feature affect Basecamp Personal?
  • Does our iPhone app support it?
  • Do our mobile web views need to be updated?
  • Does this impact email-in?
  • Does this impact loop-in?
  • Does this impact moving and copying content?
  • Does this impact project imports from Basecamp Classic?
  • Test at various BCX plan levels
  • Test at various content limits (storage, projects)

Project states

  • Active project, Archived project, Project template, Draft (unpublished) project, Trashed project.

Types of content

  • To-do lists, To-do items (assigned + unassigned + dated), Messages, Files, Google docs, Text documents, Events (one time + recurring).


  • Progress screen, In-project latest activity block, History blocks (for each type of content), Calendar, Person pages, Trash, Digest emails.

When these variables are combined you end up with a script of tasks like this one to guide the testing. These lists are unique for each project.
Step 4. In Basecamp we make a few QA-specific to-do lists in each project: the first for unsorted discoveries, a second for tasks that have been allocated, and a third for rough spots support should know about (essentially “known issues”).

When I find a bug I’ll make a new to-do item that describes it including: 1) A thorough description of what I’m seeing, often with a suggested fix; 2) Specific steps to recreate the behavior; 3) The browser(s) and/or platform(s) where this was observed; and 4) Relevant URLs, screenshots, or a screen recording.

We use ScreenFlow to capture screen recordings on the Mac, and Reflector to do the same in iOS. We’re fans of LittleSnapper (now Ember) for annotating and organizing still screenshots.
Step 5. The designer and programmer on the project will periodically sift through the unsorted QA inbox. Some items get moved to the QA allocated list and fixed, then reassigned to QA for verification. Other “bugs” will trigger a conversation about why a decision was intentional, or outside the scope of the iteration.
Step 6. Before each new feature launch, QA hosts a video walkthrough for the support team. We’ll highlight any potential areas of confusion and other things to be on the lookout for. After the walkthrough, a member of support will spend some time putting together a help section page that covers the new feature.
Step 7. Within a couple weeks after a feature launch the team will usually have a retrospective phone call. We talk the highs and lows of the iteration and I use the chance to ask how QA can be better next time around.
At the end of a project there are usually some “nice to haves” and edge-cases that didn’t make the pre-launch cut. These bugs get moved into a different Basecamp project used for tracking long standing issues, then every few months we’ll eradicate some of them during a company-wide “bug mash”.
So that’s a general overview of how QA works at 37signals. We find anywhere from 30-80 bugs per project. Having QA has helped reduce the size of our on-call team to one. The best compliment: After trying it out, no one at the company was interested in shipping features without dedicated QA.

05 Oct 08:46

Avoiding Burnout

by Robert

Mozilla has lost some good people due to burnout. I suspect working for Mozilla carries greater risk of burnout that working for "normal" organizations. A lot of people are motivated to work for Mozilla because of our mission. This motivation is powerful and persists through unhappiness. Thus, people drive themselves to work hard at the expense of their happiness and mental health. This is a recipe for burnout.

That is very true for me. There have been long periods of time when I have been frustrated with my work, feeling I would be happier doing some other work, and in fact feeling that I'm struggling to cope. But I've survived in this job a long time, I don't currently have those feelings, and in fact I feel pretty good even though I'm currently going through some travel madness. Here's a few things that have helped.

Acknowledging the ebb and flow. When I'm feeling burned out, I slack off. I think that is OK as long as it's temporary --- and as long as I'm not using it as an excuse to be lazy. For me, it's natural to have periods of time when I'm energized, followed by periods when I'm tired and I need to back off while I rest and rekindle my enthusiasm. Per my earlier post, this is not a sign I need to change jobs.

A sense of perspective. When I feel my job sucks, it's important to take a step back and think about what I'm comparing it to. Objectively, my worst weeks at Mozilla have been worldly bliss compared to most weeks of most people over most of human history. It is critically important to never lose sight of this fact. (There are a few Mozilla people for whom this is not true; you know who you are and I tip my hat to you.) Whenever I feel like a heroic martyr, it's simply ridiculous.

Changing focus. When I'm sick and tired of working on something, it's very helpful to work on something different --- "a change is as good as a rest" (which is mostly but not entirely true). Mozilla does a lot of important things and there are a lot of very different ways to contribute to Mozilla's mission, so it's not a problem to rotate people in and out of particular roles.

Family. My wife and children are a vital anchor for my mental health. My commitments to them --- and their policing of those commitments --- prevent me from going too far overboard with work. Spending time with them, giving and receiving love, is the best tonic I have.

The Sabbath. I often struggle to rest and relax because I feel burdened with work projects and guilty for not working; this contributes to burnout. I find that compulsory downtime, decreed and ideally enforced by an external source, is extremely helpful in dealing with that guilt: I don't need to feel guilty about not working when someone is making me do it. My family is one source of that compulsion, and my Christian convictions about not working on Sunday (not always observed :-( ) are another.

Relinquish responsibility. Feelings of being irreplaceable can be extremely draining and contribute to guilt, anxiety and the difficulty of resting. Therefore it's very important to break those feelings --- forcing oneself to step aside, at least temporarily, and see what happens. It's usually not as bad as you think. We also need to keep in mind that we are only responsible for what we do; as individuals we are not responsible for Mozilla's ultimate success or failure. We have to let go and not worry about what we, as individuals or as a group, do not control. Over the years I've developed a little bit of apathy, which has been valuable.

Remember the mission. Sometimes, when enthusiasm fails, I must ask myself whether there's any work I could be doing that's more important than my work at Mozilla. So far, the honest answer has always been no, and so I know what I must do. As I suggested above, this can be a scourge, but it can also be liberating. There's a certain exhilaration in knowing what one should do, and throwing yourself into it with nothing but grim determination.

Jesus. Sorry to my irreligious readers, but this true and important. Many times I have felt myself to be running on empty, and my only recourse has been to pray to the Lord for strength to do what I know I should do. Many of those times I have been quickly refreshed in a way that feels miraculous. Apart from that immediate relief, my identity in Christ provides logical and emotional support to many of the items above: my commitment to my family, my sense of duty, my sense of perspective, my sense that God is ultimately in control, and the obligation to periodically disengage from work. Had I not been a Christian, I don't think I would have survived.

11 Sep 07:26

Share everything

by Emily Wilder

Last December, Sam posted the following in our “37signals Newsroom” Basecamp project:

I’ve been trying out an experiment over the past few workdays: when someone asks me for help with something, I show them how it’s done.

In an on-call case, it means copying and pasting the console transcript, cleaning it up a bit, and adding some descriptive comments. ... Other situations call for a different approach. Jamie came to me with a JavaScript problem this afternoon, so we took an hour and paired together on a solution via screen sharing.

Now, the other party might not fully understand the explanation, but I think it’s a positive change to assume that everyone is curious to learn how things work rather than too busy to care. Repeated exposure to these explanations might spark an interest that would otherwise go unexplored.

And obviously there is a practical limit to the amount of time and effort we can put into such explanations. In theory, though, spreading the knowledge means the people who ask you for help are more likely to be able to solve those problems themselves.

So I invite you to try the experiment with me. The next time someone asks you to do something, walk them through your process, or write it up for them to read.

Jason chimed in:

Yes please. This is a great initiative. Whenever someone does something for someone else, let’s make sure it’s taught, too. It’ll be slower in the short term, but faster and better in the long term. 

Since then, we’ve all gotten a little more conscious about teaching one another to fish. Recently, I was frustrated I lacked the skills to update Mig jumped in and offered to show me some HTML and CSS basics. It’s “one of the most empowering things anyone here at the company could learn,” he told me. “I’d be more than happy to show you the ways.” Rad. Thanks, Mig.

Everyone in the company works at least one day a month answering support tickets, and the support team buddies up with non-support folks to share solutions for the more complex cases. Programmers often share the code they used to solve a problem with support, which encourages support to try to solve similar issues themselves next time. Designers and programmers swap intel all the time. Here’s what Jonas has to say about working with Trevor:

He’s continually helping me get better at programming, and has been super patient and encouraging. He frequently suggests that I tackle certain problems, takes time to help me out when I have questions, and reviews my code when I’m done.

I’ve tried to return the favor a bit by helping him work through some design problems and CSS.

I think this mutual learning approach and easy back-and-forth has had real benefits to the app, too. Even though it seems like it would be counterproductive to take the extra time, I think we’re ultimately more productive because we can work on different projects simultaneously, then chat a few times a day to figure out the remaining tricky stuff.

We weren’t not working this way before, but it wasn’t an institutionalized value or anything. Making a conscious, enthusiastic effort to work with, not for, each other, has expanded our horizons, empowered us with new skills, and made us a more well-rounded company.

22 Aug 06:34

Repetitive Process

by Tom MacWright

  1. Find an open need1
  2. Google & search GitHub to find prior art, if any.
    • Someone got 80% of the way there: write a pull request instead
    • Read through their source and there’s room for something else: do it
    • If it’s going to be a module, check for namespace conflicts: npm search modulename
  3. cd src
  4. mkdir project. Do not name your project yet.2
  5. cp ~/bin/index.html .
  6. v .
  7. Split the window in iTerm 2 and run serve in the other pane to preview
  8. Write enough of index.js to get things running
  9. If there are dependencies:
    • npm init leads you through creating a package.json file for npm
    • npm install --save dependency both installs a dependency and saves it in your package.json file.
    • If this is a browser-based project with dependencies, write a Makefile that runs browserify (example) and then run watch make in a tab in iTerm. The watch command will run it every 2 seconds and make will noop unless there are changes
  10. git init .
  11. If the repository is something that lives on the web, git checkout -b gh-pages and only use the gh-pages branch for everything3
  12. Create a README. A good readme has:
    • A 2-4 sentence English description of what the thing can do for you and why you would want it. Note: not how it does what it does or, what it is, but what it does for you. Software is a thing you use.
    • An example that steps through requiring the thing, doing something useful with it, and integrating this with the outside world. Examples are not random examples of how you would use functions: they are examples of how things fit together.
    • API documentation for all public methods, which describes inputs, outputs, expectations, and behaviors.
    • A ‘See Also’ section if this project has open-source brothers and sisters, or took heavy inspiration from some other project or paper.
    • READMEs do not need to include the software license (this can be in LICENSE), nor the name of authors (this is in package.json and the commit history), nor TODOs (this is in your issue tracker or code). READMEs are about present code, not people, laws, or plans.
  13. Add files and a message for the first commit with vim-fugitive
  14. git create
    • Creates the repository tmcw/project with the hub utility
  15. npm publish to publish the first version of the module
  16. When you’ve gotten to fixing issues, create an issue for every problem, and create commits in vim-fugitive, using vim-rhubarb to reference and close those issues from commit messages.
  17. Once the thing works, read over everything, install it and test it. If it’s a library that isn’t totally self-explanatory don’t release it without releasing something that demonstrates why it is interesting, whether that’s another piece of software or just something in examples/. Do not fall into the trap of undemonstrated potential: connect the dots and prove worth.

  1. an open need: a finite need that people have. People can be just you, but it should not be just you just right now: the impact of technology is people × time.
  2. do not name your project yet: registering domain names for projects before they have code on the ground has cursed every single one. and if your project is code, you do not know what it will be yet: it could be one piece, a lot of parts, or just documentation and a blog post.
  3. use gh-pages for everything: you don’t need a master branch. If something else is default, people will clone that by default, automatically. gh-pages is just like master, except with perks: automatic, free web hosting.
19 Aug 05:31

nautical-constructs: killa-kelly: emilet: 1los: Bees are...





Bees are nature’s 3D printer

Fucking bees are the best.

Fuck yes they are.

what the actual fuck bees. why are you engineering geniuses

15 Aug 06:39

Fun for Kids of All Ages

Fun for Kids of All Ages

Submitted by: Unknown (via Know Your Meme)

Tagged: playtime , yarn , funny , g rated , win
14 Aug 03:27

28 June 2013, baked by Mat Marquis

My old man taught me to cook back when I was a kid. I’ve been a vegetarian my whole life, so it was largely a matter of survival in my household. Plus, Ma can’t cook to save her life. Sorry, Ma.

My father, though, was a great cook. I figured he was just naturally good at it; I mean, the guy could do a lot of things. I never questioned it until a couple of years ago, watching a French cooking show; they “finished” a sauce by swirling in a few pats of butter. “Beurre monté,” they called it. I’d done that—the butter acts as an emulsifier, when you get it right. I knew that the butter had to be added cold, and I knew the temperature had to be hot enough that it melted fast, but low enough that it wouldn’t “break.” I did not know that it was, like, a thing with accent marks and whatnot.

It turned out that my father had learned how to cook from my great-grandmother’s boyfriend of decades, Tom. Tom was a classically trained French chef—I guess he was pretty famous around Boston, back in the day. My father never really learned the vocab or it just never stuck with him, but he didn’t teach it to me because he didn’t know it himself. He just knew how cooking worked.

They say you don’t really know something unless you can explain it, but I’m not sure that’s always completely true. Then again, I’m a vegetarian, so I can’t eat most of what I make anyway. For all I know, I’m a lousy cook.

13 Aug 07:25

My observations about teaching and learning programming

by Dan Kim

Over the past 6 months, I’ve had the unique opportunity to observe a wide range of programmers – students, teachers, and world-class experts.

I was curious if there were any patterns and characteristics that made for successful programming teachers and students. My goal was simple: to make myself a better teacher and a better student, so I could help others too.

Here’s what I’ve found so far.

Great programming teachers…

…point students in the right direction, but don’t give out all the answers.

They coach students to be curious and independent – to search for their own answers. They let students stumble and rewrite code a few times. They let students discover valuable patterns, problem solving techniques, and the sheer joy of shipping something that works.

…are encouraging, but never critical.

They give praise when students write great code, and offer suggestions for refactoring clunky code. They give pointers and offer direction, but never criticize a line of thinking.

…promote writing as little code as possible.

They will direct students away from complexities and toward simple, elegant solutions. The fewer lines of code, the better.

…are patient and remember what it’s like to be a beginner.

They remember that everyone was a really bad programmer at some point and needed help (including themselves).

Great programming students…

…learn how to learn.

They don’t just look for answers, but look for patterns and techniques. They search for root causes by breaking down problems. They use Google and Stack Overflow constantly.

…talk less, listen more, and observe.

They realize they can learn a ton by just watching how their teacher solves problems, communicates, and teaches others. They literally watch and learn.

…tend to move more slowly, and are thoughtful in their analysis.

They take the time to think about a problem, craft smart questions and succinctly explain the issues they’re running into. They get better and better at embracing slow time.

…keep their code tidy.

Messy code is often the result of messy thinking. Having neat code makes it easier for others to help them, and as a result, they learn faster and understand more deeply.

…are persistent.

They are absolutely relentless in the belief that they can solve any problem (and usually do). Hours or days can go by with little or no progress, so it’s crucial to have this mindset.

…have a “ship it” attitude.

They set reasonable goals against relatively short time frames. They recognize that momentum is critically important because it provides the feeling of accomplishment and energy to keep pushing forward.

…start coding when all else fails.

There are so many places to get stuck – syntax, concepts, gems, libraries, tools, books, tutorials – the list is endless. They realize the sooner there’s real code, the sooner they’ll have something to react to, adjust, and make better.

And great programmers…

…never stop learning or teaching.

11 Jun 23:36

11 June 2013, baked by Angelina Fabbro

Impostor Phenomenon

If you write code, if you participate in the act of programming, then you are a programmer. We can add a clause to this that suggests regularity — someone who programs often is a programmer. That’s all it takes to be a programmer. It doesn’t matter if you’ve just started and worked your way through the fundamentals like control structures and taming functions. It doesn’t matter if for some reason you don’t feel like a programmer. It doesn’t matter if someone pays you or not, unless you really find it important to be a professional programmer. If you program and you do it over and over, you become a programmer.

Last week I had the privilege of being amongst the speakers at JSConf 2013. The best part about this particular speaking opportunity was that I was able to give a non-technical talk about programming that I’d wanted to give for a long time. It was a culmination of all the things regarding learning to program that I’ve talked about here on The Pastry Box stitched together with further anecdotes and advice. It talked about cognitive biases and tried to convince people to get their biases out of the way so they could realize their potential. One of the slides in my presentation addressed impostor syndrome (known as impostor phenomenon in peer-reviewed, formal research) as it relates to the craft of programming, but really the point I was trying to make could be applied to anybody in any field.

Impostor phenomenon, explained simply, is the experience of feeling like a fraud (or impostor) while participating in communities of highly skilled participants even when you are of a level of competence to match those around you. Impostor phenomenon is highly correlated with individuals who are successful; arguably success here means success as perceived by others. The important thing to note is that this experience isn’t isolated to people we perceive as experts, only that it is a counterintuitive notion: one might assume that as they develop their skills in a craft further that their confidence should increase and their insecurity about whether they are good and whether they belong would fade away. It turns out that this is not the case for a lot of people.

I found myself wondering if my talk was going to be all that useful to the people I perceived as experts; I questioned whether or not the smart people I admired that I knew would see it were going to find value in this thing that I had made to share with everyone.

I gave the talk, and afterwards several of them thanked me for that slide. Some of them my heroes, they took me aside and confided their thanks. They confided their relief.

In the end I wasn’t shocked that the successful people I admired had experienced impostor phenomenon and talked to me about it — I was shocked that I somehow thought the people I see as heroes were somehow exempt from having it. I did the one thing I didn’t want to do: make that assumption about anyone.

We’re all just doing the best we know how to when it comes to programming, it’s just that some people have more practice coming across as confident than others do. Never mistake confidence for competence, though.

I’m just going to put this out there: to anyone of any skill level who reads this, if you’re ever feeling like you’re a fraud in your field; if you ever feel alone or if you worry that you’re not smart enough or good enough as the next programmer, just come talk to me. I’m a busy person by design because I can’t stand to be idle, but I’ll make time for you because feeling this way is isolating, lonely, and not constructive. I think of all the missed opportunities I let pass by all because I was worried about making mistakes, not being perceived as an equal by my peers, and all the code I never wrote just because I was intimidated by all the great code and smart programmers out there.

I want to listen to what you have to say, to tell you that you’re not alone, and that your heroes are human too just like you.

27 May 04:07

Stumbling Into the Cold Expanse of Real Programming

by James Hague
Robbie Mackay

I wonder if this difference now puts many kids off programming, thinking its boring or too hard. They have few options other than starting out in the 'cold expanse of real programming'.. rather than getting a chance to play and experiment with ideas first.

This is going to look like I'm wallowing in nostalgia, but that's not my intent. Or maybe it is. I started writing this without a final destination in mind. It begins with a question:

How did fast action games exist at all on 8-bit systems?

Those were the days of processors living below the 2 MHz threshold, with each instruction run to completion before even considering the next. No floating point math. Barely any integer math, come to think of it: no multiplication or division and sums of more than 255 required two additions.

But that kind of lively statistic slinging doesn't tell the whole story or else there wouldn't have been so many animated games running--usually at sixty frames-per-second--on what appears to be incapable hardware. I can't speak to all the systems that were available, but I can talk about the Atari 800 I learned to program on.

Most games didn't use memory-intensive bitmaps, but a gridded character mode. The graphics processor converted each byte to a character glyph as the display was scanned out. By default these glyphs looked like ASCII characters, but you could change them to whatever you wanted, so the display could be mazes or platforms or a landscape, and with multiple colors per character, too. Modify one of the character definitions and all the references to it would be drawn differently next frame, no CPU work involved.

Each row of characters could be pixel-shifted horizontally or vertically via two memory-mapped hardware registers, so you could smoothly scroll through levels without moving any data.

Sprites, which were admittedly only a single color each, were merged with the tiled background as the video chip scanned out the frame. Nothing was ever drawn to a buffer, so nothing needed to be erased. The compositing happened as the image was sent to the monitor. A sprite could be moved by poking values in position registers.

The on-the-fly compositing also checked for overlap between sprites and background pixels, setting bits to indicate collisions. There was no need for even simple rectangle intersection tests in code, given pixel-perfect collision detection at the video processing level.

What I never realized when working with all of these wonderful capabilities, was that to a large extent I was merely scripting the hardware. The one sound and two video processors were doing the heavy lifting: flashing colors, drawing characters, positioning sprites, and reporting collisions. It was more than visuals and audio; I didn't even think about where random numbers came from. Well, that's not true: I know they came from reading memory location 53770 (it was a pseudo-random number generator that updated every cycle).

When I moved to newer systems I found I wasn't nearly the hotshot game coder I thought I was. I had taken for granted all the work that the dedicated hardware handled, allowing me to experiment with game design ideas.

On a pre-Windows PC of the early 1990s, I had to write my own sprite-drawing routines. Real ones, involving actual drawing and erasing. Clipping at the screen edges? There's something I never thought about. The Atari hardware silently took care of that. But before I could draw anything, I had to figure out what data format to use and how to preprocess source images into that format. I couldn't start a tone playing with two register settings; I had to write arcane sound mixing routines.

I had wandered out of the comfortable realm where I could design games in my head and make them play out on a TV at my parents' house and stumbled into the cold expanse of real programming.

(If you liked this, you might enjoy A Personal History of Compilation Speed.)
23 May 04:18


The great thing is, the sentence is really just a reminder to the listener to worry about whatever aspects of the technology they're already feeling alarmist about, which in their mind gives you credit for addressing their biggest anxieties.
19 May 21:31

10 things I love about being a Mum

by kelliefish13

Making its way around the blogs at the moment is 10 things I miss about life before kids and while I have quite a few of those,
Like going to the toilet by myself and not having tiny bits of food and toys all over the floor,
today I would rather focus on the things that are new and exciting about being a Mum.

1. Staying home when the weather is crappy.

2. Being able to sew and make stuff – Yes I could have done this before my son was born and I did a tiny bit and even had more time to do so, but no inclination.

3. Baking with Little Moo, its hilarious he tries everything that goes in the bowl. Watching him trying to catch and pick up the egg yolks and having them escape every time was priceless.

4. Getting down to his level and playing.

5. Robbie working from home 2/3′s of the time and him being willing to put everything down for a minute to give Little Moo a cuddle or attention just about every time he comes and asks for it.

6. Being a family.

7. Going to the playground and having an excellent excuse for playing on it. Though its a little different when all my siblings and partners come too, Don’t mind us 8 noisy adults playing and all the equipment we have a child with us… somewhere… oh look over there on the slide, we are with him.

8. Morning cuddles in bed, just wish they could start a little later, 7am would be good.

9. Watching him grow. A few weeks ago he could only walk a couple of steps and a time, now he can walk (wobble) across the room at great speeds holding two plastic golf clubs.

10. Being his Mum. You see that adorable smart little person over there, he is mine, I made him from myself. Now I get to watch him grow and show us more and more of his personality.

Just a note these things change month by month as he grows and changes, last month it was different things.

Filed under: Uncategorized
19 May 21:29

Sick days and days and days

by kelliefish13

Some days there is this moment, a moment in time when you know that the next 24 hours is going to be hard work.

Mine was last night around 8pm when Little Moo woke up for the second time after being put to bed. Normally once asleep he stays that way until we go to bed then wakes for a short feed (probably because we are noisy, whoops). See one wake is ok, usually he has wriggled out of the blankets and is cold or went to sleep too quickly and didn’t get his full feed of milk, but once we hit 2 wakes then we get a zillion wakes (Ok not quite a zillion but it feels like it).

Now normally a night of lots of wakes isn’t a big deal, they happen every now and then but most other nights I get enough (though my definition of enough has change dramatically since he was born).

But we have had a week of itchy chicken pox spots and about 4 days before that of fever and looks like now he has a cold as well as spots.

So not only have I had not much sleep and a grumpy toddler who needs full on attention ALL day, but we haven’t been able to go to all our usual groups and activities in all that time.

Turns out I NEED those groups because not only do they wear him out and he slows down and sleeps, but I get to talk to other parents! Other people whose world is also their child/ren.

I also NEED outside time and out of the house time which has been rather tricky since it’s been pouring with rain most of the week. Though we made it out on Tuesday when the sun came out for a beautiful day. Little Moo and I sat on top of North Head watching the boats and helicopters go past, then had a yummy bakery lunch on Takapuna beach (and hopefully didn’t manage to spreed too many bugs).

  Before becoming a Mummy I thought that sick days would come 1 or 2 days at a time, and they would mean snuggles on the couch watching movies all day long. Turns out I was very wrong. He may be sick but that does NOT mean he sits stills. But that’s ok, instead we have baked, cooked, made cardboard castles and tunnels, couch forts, painted, danced and sang. Although we have had our melt downs we have also had a lot of fun and had a really good couple of weeks



Filed under: Uncategorized
15 May 09:43

Transparency and Accountability

by Bruce Schneier

As part of the fallout of the Boston bombings, we're probably going to get some new laws that give the FBI additional investigative powers. As with the Patriot Act after 9/11, the debate over whether these new laws are helpful will be minimal, but the effects on civil liberties could be large. Even though most people are skeptical about sacrificing personal freedoms for security, it's hard for politicians to say no to the FBI right now, and it's politically expedient to demand that something be done.

If our leaders can't say no -- and there's no reason to believe they can -- there are two concepts that need to be part of any new counterterrorism laws, and investigative laws in general: transparency and accountability.

Long ago, we realized that simply trusting people and government agencies to always do the right thing doesn't work, so we need to check up on them. In a democracy, transparency and accountability are how we do that. It's how we ensure that we get both effective and cost-effective government. It's how we prevent those we trust from abusing that trust, and protect ourselves when they do. And it's especially important when security is concerned.

First, we need to ensure that the stuff we're paying money for actually works and has a measureable impact. Law-enforcement organizations regularly invest in technologies that don't make us any safer. The TSA, for example, could devote an entire museum to expensive but ineffective systems: puffer machines, body scanners, FAST behavioral screening, and so on. Local police departments have been wasting lots of post-9/11 money on unnecessary high-tech weaponry and equipment. The occasional high-profile success aside, police surveillance cameras have been shown to be a largely ineffective police tool.

Sometimes honest mistakes led organizations to invest in these technologies. Sometimes there's self-deception and mismanagement—and far too often lobbyists are involved. Given the enormous amount of security money post-9/11, you inevitably end up with an enormous amount of waste. Transparency and accountability are how we keep all of this in check.

Second, we need to ensure that law enforcement does what we expect it to do and nothing more. Police powers are invariably abused. Mission creep is inevitable, and it results in laws designed to combat one particular type of crime being used for an ever-widening array of crimes. Transparency is the only way we have of knowing when this is going on.

For example, that's how we learned that the FBI is abusing National Security Letters. Traditionally, we use the warrant process to protect ourselves from police overreach. It's not enough for the police to want to conduct a search; they also need to convince a neutral third party -- a judge -- that the search is in the public interest and will respect the rights of those searched. That's accountability, and it's the very mechanism that NSLs were exempted from.

When laws are broken, accountability is how we punish those who abused their power. It's how, for example, we correct racial profiling by police departments. And it's a lack of accountability that permits the FBI to get away with massive data collection until exposed by a whistleblower or noticed by a judge.

Third, transparency and accountability keep both law enforcement and politicians from lying to us. The Bush Administration lied about the extent of the NSA's warrantless wiretapping program. The TSA lied about the ability of full-body scanners to save naked images of people. We've been lied to about the lethality of tasers, when and how the FBI eavesdrops on cell-phone calls, and about the existence of surveillance records. Without transparency, we would never know.

A decade ago, the FBI was heavily lobbying Congress for a law to give it new wiretapping powers: a law known as CALEA. One of its key justifications was that existing law didn't allow it to perform speedy wiretaps during kidnapping investigations. It sounded plausible -- and who wouldn't feel sympathy for kidnapping victims? -- but when civil-liberties organizations analyzed the actual data, they found that it was just a story; there were no instances of wiretapping in kidnapping investigations. Without transparency, we would never have known that the FBI was making up stories to scare Congress.

If we're going to give the government any new powers, we need to ensure that there's oversight. Sometimes this oversight is before action occurs. Warrants are a great example. Sometimes they're after action occurs: public reporting, audits by inspector generals, open hearings, notice to those affected, or some other mechanism. Too often, law enforcement tries to exempt itself from this principle by supporting laws that are specifically excused from oversight...or by establishing secret courts that just rubber-stamp government wiretapping requests.

Furthermore, we need to ensure that mechanisms for accountability have teeth and are used.

As we respond to the threat of terrorism, we must remember that there are other threats as well. A society without transparency and accountability is the very definition of a police state. And while a police state might have a low crime rate -- especially if you don't define police corruption and other abuses of power as crime -- and an even lower terrorism rate, it's not a society that most of us would willingly choose to live in.

We already give law enforcement enormous power to intrude into our lives. We do this because we know they need this power to catch criminals, and we're all safer thereby. But because we recognize that a powerful police force is itself a danger to society, we must temper this power with transparency and accountability.

This essay previously appeared on

13 May 20:00

5 May 2013, baked by Josh Emerson


Along with Alastair Lockie, I run a Code Club at Queens Park Primary School, Brighton. Every Wednesday after school, the kids learn how to make games and more recently, how to make websites. It’s great to see them having fun and being creative on computers.

I originally decided to get involved with Code Club due to the lack of education in creative computing. Kids are taught how to use Microsoft Office products, but are not encouraged to explore and create within a digital space. That’s all changing now.

The UK Government have noticed that they aren’t doing enough to teach kids how to code in schools. In 2014, the new National Curriculum will come into play, and it makes one major change. A new course called “Computing” will replace “ICT”. Kids will begin learning how to program and create things on computers. What’s more, schools will make gifted and talented kids “Digital Leaders”, who will help teachers and pupils with computing within lessons. This makes me very happy!

So now I ask myself, will we still need Code Clubs, when kids have so many other opportunities to learn how to code? And my answer is yes, we still need them. Here’s why:

No matter where you get your stats from, the ratio of men to women in the digital industries is far from equal. According to the A List Apart Survey, 2011, just 18% of people in the web industry are women. There’s no reason why women can’t do just as well as men in these industries, and I believe our work suffers from this gross imbalance as diversity is important. It both brings out the best in people and better reflects the society we are designing for.

I haven’t personally noticed any considerable discrimination against women in our industry, and since women are just as fit for jobs as men in this line of work, I can only attribute this imbalance to stereotyping and self-perpetuation; many women don’t apply for these jobs because they don’t think it to be a job for women.

My Code Club has 26 kids who show up each week. 13 of them are boys, and 13 are girls. One of these girls says she will run a web development company when she grows up, and she’s very talented. Besides making Code Club seem exciting in an assembly I gave to the kids, I did nothing to encourage any demographic to join the club. The fact that we have a 50:50 split is testament to the unjust bias in our industry.

I hope that by showing kids coding is exciting, creative and engaging, we can slowly address this imbalance. These kids will grow up with the knowledge that you don’t have to be a geek to be a digital creative, and that the industry isn’t just for men. It might take a couple of generations before we see any meaningful change, but I’m prepared to wait.

—Josh Emerson

13 May 19:53

13 May 2013, baked by Erin Kissane

“How are you?”

“Great! Busy. Really good, though.”
“Oh, you know. Tired.”
“Not so well.”
“Fine, fine, how are you?”

We ask each other how we are, how we’re doing, sometimes how we’re “holding up.” When someone asks it in a formal, professional context, it means little more than “hello.” When our friends ask, they usually want to know a bit more, if not every single detail of recent lives. Weirdly, I suspect most of us aren’t in the habit of asking it of ourselves. We question extreme emotions, maybe—“why did that garden-variety comment troll make me so angry?”—but we mostly don’t have a culture of monitoring our well-being in any disciplined way.

This despite the fact that we know, thanks to scads of well-designed and -documented behavioral studies, that the many little, boring ways in which we’re “good” or “great” or “tired” or “fine” affect everything else we do: our judgment, our situational intelligence, our creative ability to synthesize, our emotional resilience.

I developed habits of checking in—of trying to regularly, honestly assess how I am—as a way to deal with being naturally twitchy. My hunger signals don’t keep up with my metabolism, and if I don’t have set reminders to eat every few hours, I get spacier and spacier till I’m useless. Sometime in my 20s, I finally figured out that I could work around the problem by adding checkpoints to my day: Do I have a headache or feel dizzy? Am I having trouble concentrating? Am I writing overlong emails?

That simple idea has gradually evolved into something more central as I’ve observed the differences in my interactions with colleagues who were “inexplicably” cross after a night of insomnia or “mysteriously” unable to make decisions when they skipped lunch. It’s not just me, it turns out—we all have bodies and they mess with us constantly. And it’s not just the physical stuff. Everything we experience affects our ability to focus, do our work, and react reasonably, whether we’ve been arguing with a family member or just refreshing Twitter too much.

So before starting a work session or going into a meeting or making a complex decision, I’ve been trying to check in. What’s going on in there, physically and mentally and emotionally? Is any of it something I can improve by eating a banana, or spending ten minutes reading, or taking a walk? It’s basic stuff, but helps—and it forces me to admit that just as I’m sometimes irritable only because allergies are making my head feel like a bag of bees, the same thing is true of everyone else, too.

How are you?

28 Apr 06:05

Tor Needs Bridges

by Bruce Schneier

The Internet anonymity service Tor needs people who are willing to run bridges. It's a goodness for the world; do it if you can.

27 Apr 00:42

Double Shot #1116

by Mike Gunderloy
Robbie Mackay

Pleased to see Devpressed launched.. this is something the dev community needs

  • Amazon Coins - If I had to bet, I'd bet on corporate-sponsored alternative currencies getting a lot more traction than BitCoin in the long run.
  • Feed the Fire - An RSS to Firebase sync service - Might be the bare bones of an alternative to Google Reader.
  • bluePen - "Online Visual CSS Editor" to let you tweak things right in the browser.
  • Devpressed - Discussion board for developers suffering from depression.
22 Apr 02:07

The Boston Marathon Bomber Manhunt

by Bruce Schneier

I generally give the police a lot of tactical leeway in times like this. The very armed and very dangerous suspects warranted extraordinary treatment. They were perfectly capable of killing again, taking hostages, planting more bombs -- and we didn't know the extent of the plot or the group. That's why I didn't object to the massive police dragnet, the city-wide lock down, and so on.

Ross Anderson has a different take:

...a million people were under virtual house arrest; the 19-year-old fugitive from justice happened to be a Muslim. Whatever happened to the doctrine that infringements of one liberty to protect another should be necessary and proportionate?

In the London bombings, four idiots killed themselves in the first incident with a few dozen bystanders, but the second four failed and ran for it when their bombs didn't go off. It didn't occur to anyone to lock down London. They were eventually tracked down and arrested, together with their support team. Digital forensics played a big role; the last bomber to be caught left the country and changed his SIM, but not his IMEI. It's next to impossible for anyone to escape nowadays if the authorities try hard.

He has a point, although I'm not sure I agree with it.


EDITED TO ADD (4/20): This makes the argument very well. On the other hand, readers are rightfully pointing out that the lock down was in response to the shooting of a campus police officer, a carjacking, a firefight, and a vehicle chase with thrown bombs: the sort of thing that pretty much only happens in the movies.

EDITED TO ADD (4/20): More commentary on this SlashDot thread.

10 Apr 23:39

The loneliness epidemic

by Seth Godin

The next time you feel lonely, disconnected or unappreciated, consider that unlike many other maladies, this one hits everyone. And unlike other challenges, this one is easily overcome by realizing that you can cure the problem by connecting, appreciating and leading.

The minute we realize that the person sitting next to us needs us (and our tribe, our forward motion and the value we create), we're able to extinguish their aloneness as well as ours.

When you shine a light, both of you can see better.

01 Apr 05:47

Software Inventory

by Joel Spolsky

Imagine, for a moment, that you came upon a bread factory for the first time. At first it just looks like a jumble of incomprehensible machinery with a few people buzzing around. As your eyes adjust you start to see little piles of things that you do understand. Buckets of sesame seeds. Big vats of dough. Little balls of dough. Baked loaves of bread.

Those things are inventory. Inventory tends to pile up between machines. Next to the machine where sesame seeds are applied to hamburger buns, there’s a big vat of...sesame seeds. At the very end of the assembly line, there are boxes and boxes of bread, waiting for trucks to drive them off to customers.

Keeping inventory costs money. Suppose your bakery has six 50-ton silos to store flour. Whenever they empty out, you fill them up. That means on the average day you have 150 metric tons of wheat flour in stock. At today’s prices, you’ve tied up $73,000. Forever.

Inventory may have other costs too, like spoilage. Flour lasts for months, but the minute bread comes out of the oven it starts dropping in value; after 24 hours it’s nearly worthless.

Why keep inventory at all? Because there are costs associated with running out of things, too. If sesame seeds take two days to order, and you run out of sesame seeds, you are out of the hamburger bun business for two days. Inventory provides a buffer that prevents any part of the process from stalling. There are modern algorithms to optimize how much buffer you need at every point (read up on Toyota’s lean production system and the Theory of Constraints to get started).

Why do I care about any of this? The software production process has several major “inventory” accumulation points, itself. Stuff accumulates at those points and ends up wasting a lot of time and money.

“What? How is software like a factory?” you ask.

Think of product ideas as the raw material. Depending on your process, product ideas may go through several assembly line points before they are delivered as finished features to the customer:

  1. A decision-making process (should we implement this feature?)
  2. A design process (specs, whiteboards, mockups, etc)
  3. An implementation process (writing code)
  4. A testing process (finding bugs)
  5. A debugging process (fixing bugs)
  6. A deployment process (sending code to customers, putting it on web server, etc)

(PS No, this is not “waterfall.” No it isn’t. Is not. Shut up.)

In between each of these stages, inventory can pile up. For example, when a programmer finishes implementing their code (stage 3) they give it to a tester to check (stage 4). At any given time, there is a certain amount of code waiting to be tested. That code is inventory.

The “cost” of code inventory is huge. It might add up to six or twelve months of work that is stuck in the assembly line and not yet in customers’ hands. This could be the difference between having a cutting-edge product (iPhone) or constantly playing catchup (Windows Phone). It’s nearly impossible to get people to buy Windows Phones, even if the iPhone is only six months better. A lot of markets have network effects, and being first has winner-take-all implications. So getting rid of inventory in the development process can make or break a product.

Let’s go over the three places most inventory accumulates.

Feature backlogs. Every product attracts new feature ideas, and you can’t implement ideas as fast as you can think them up, so you write them down, and this list is called the feature backlog. A lot of the ideas on the backlog are bad ideas, and you merely wrote them down to avoid hurting the feelings of the people who thought them up. Backlogs make everyone feel good.

The trouble is that 90% of the things in the feature backlog will never get implemented, ever. So every minute you spent writing down, designing, thinking about, or discussing features that are never going to get implemented is just time wasted. When I hear about product teams that regularly have “backlog grooming” sessions, in which they carefully waste a tiny amount of time and mental energy every day or every week thinking about every single feature which will never be implemented, I want to poke my eyes out.

  • Suggestion: Do not allow more than a month or two of work to get into the feature backlog list. Once the backlog is full, do not allow new items to be added unless you remove an item. Do not spend any time speccing, designing, or talking about backlog items: the backlog, in fact, should be seen as a list of things you are not allowed to talk about or work on.

The bug database is obviously a great thing to have. Bug reports should be complete, accurate, and actionable. But I have noticed that in many real-world companies, the desire never to miss any bug report leads to bug bankrupcy, where you wake up one day and discover that there are 3000 open bugs in the database, some of which are so old they may not apply any more, some of which can never be reproduced, and most of which are not even worth fixing because they’re so tiny. When you look closely you realize that months or years of work has gone into preparing those bug reports, and you ask yourself, how could we have 3000 bugs in the database while our product is delightful and customers love it and use it every day? At some point you realize that you’ve put too much work into the bug database and not quite enough work into the product.

  • Suggestion: use a triage system to decide if a bug is even worth recording.
  • Do not allow more than two weeks (in fix time) of bugs to get into the bug database.
  • If you have more than that, stop and fix bugs until you feel like you’re fixing stupid bugs. Then close as “won’t fix” everything left in the bug database. Don’t worry, the severe bugs will come back.

Undeployed features. There are still a lot of teams doing quarterly or annual releases, usually because their deployment process is expensive. Operating systems, or anything where software has to be installed by every user, is usually batched up.

This is one of the most expensive forms of inventory: unshipped feature inventory. It could be earning you money, but it’s sitting on the shipping dock of your factory, while the guy down the street already has a product that does that exact same thing.

Sometimes, perniciously, you don’t even feel the pain, because everyone on your team has been dogfooding the new version for months. I’m sure everyone at Microsoft has been happily using Windows 8 for a year now, so they don’t really feel, on a day to day basis, the pain of OEMs trying to sell Windows 7 in a Mac OS X Lion world.

  • Suggestion: Don’t let completed features pile up in ways that don’t make you money. Work on your deployment process so that you can get customers features in months rather than years. If you’re already shipping monthly, figure out how to ship weekly. Keep pushing the bar on more and more frequent deployment of smaller and smaller changes.

So, where am I going with this? We’ve had all three kinds of inventory at Fog Creek: crazy long backlogs, overambitious bug databases, and features which got stuck for a year waiting for the next release to go out. All of these snuck up on us. I realized that we needed a system to constrain inventory so it doesn’t build up. 

My original idea was to make a product called Five Things. It was going to be a project manager where everybody was allowed to have five things assigned to them: two things they were actively doing, one thing that was “up next”, and a couple more that they were planning. That exact design idea didn’t go anywhere (but if you want to build it, go for it), but it did evolve into Trello.

Trello works great for a reasonable amount of inventory, but it intentionally starts to get klunky if you have too many cards in one list. And that’s exactly the point: it makes inventory visible so that you know when it’s starting to pile up. (Click on the image at the right to see the Trello team’s own development board).

Every day you look at your Trello board and see that there are seventeen completed features that are totally ready to ship but which haven’t shipped for some reason, and you go find the bottleneck and eliminate it.

Every time somebody suggests a crazy feature idea, you look at the Feature Backlog and realize it’s just too long, so you don’t waste any time documenting or designing that crazy idea.

And hopefully, you’ll spend less effort working on things that never see the light of day. “Backlog grooming.” Sheeeesh.

Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.

23 Mar 19:46