"Design critique is not a place to be mean, but it’s also not the place to be kind. You’re not critiquing to make friends. Kind designers don’t say what they mean. ‘Kind’ is not about the work, and design critique exists to make us better, but mostly, it’s to make the work better." Mark Boulton talks about the value of crits. I was introduced to the vocabulary and tone of the design/art-school crit at Berg, and find it useful, though I daren't think what 18-year-old me would have made of it. Stressing that it's not personal, it's about the work, and that that is contained within a magic circle, is really difficult, and it's really important.

"The process of going back and forth from painting to the computer became a continuous cycle. Midway through as I became more and more familiar with the outcome of how the actual texture would appear on the screen when tiled, my painting process became more specific to achieve the desired texture, color, darkness, stroke, range of value that I wanted for each feature on the map." Lovely stuff from Geraldine on painting, textures, and process.

"Skateboarding, metal work, solitude, machining, precision, and practicality. That's where Roy began." Lovely interview with a chap who makes custom jeans, on his own, simply because he decided one day he wanted to - and then he got good at it. The photographs of his workshop at the end are lovely.

Not a bad list, especially for sites needing hardcore, tight, front-end work, and that are going to face load.

"Consider the process of writing the Readme for your project as the true act of creation. This is where all your brilliant ideas should be expressed. This document should stand on its own as a testament to your creativity and expressiveness. The Readme should be the single most important document in your codebase; writing it first is the proper thing to do." I like this: after all, a README is basically the story you tell about your software. Why not write it before the software exists?

"This information describes how Free Range operates, both as a business and as a culture.

We're open-sourcing our business, from the site to the contracts to the philosopy. Value does not come from these things, but from putting these ideas into practice. These ideas are not assets - we, the people, are.

Fork this." Free Range have put their manifesto and operating principles onto Github.

"Is writing ever NOT collaboration? Doesn’t one collaborate with oneself, in a sense? Don’t we access different aspects of ourselves, different characters and attitudes and then, when they’ve had their say, switch hats and take a more distanced and critical view — editing and structuring our other half’s outpourings? Isn’t the end product sort of the result of two sides collaborating? Surely I’m not the only one who does this?" Something else that's been on the pile (to link) for a while now.

"By decoupling their data to minimize exporting, they said their polish actually became fun, not to mention efficient. I think many projects would benefit from finding a way to similarly decouple their tunable data." Yup.

"Get an accountant, abstain from sex and similes, cut, rewrite, then cut and rewrite again – if all else fails, pray. Inspired by Elmore Leonard's 10 Rules of Writing, we asked authors for their personal dos and don'ts." Huge, two-part article (presumably from Saturday's Review) with a great deal of advice - some sensible, some common sense, some insightful, some entertaining - on writing. And: much of it applies to other creative disciplines, too.

"The pattern we see here is to keep crises small and frequent, as Ed Catmull of Pixar says in an excellent recent talk. When describing the difficulty Pixar's artists had with reviews ("it's not ready for you to look at"), he realized that the only way to break through resistance to reviews was to increase the frequency until no one could reasonably expect to be finished in time for theirs. The point was to gauge work in motion, not work at rest." I liked this quotation, but as usual, the rest of Mike's post is great.

"The next time you see an application you like, think very long and hard about all the user-oriented details that went into making it a pleasure to use, before decrying how you could trivially reimplement the entire damn thing in a weekend. Nine times out of ten, when you think an application was ridiculously easy to implement, you’re completely missing the user side of the story." Yes. Similarly: what you don't see is the decision-making, everything that was thrown away.

"There was a point a few years ago whenever somebody called a meeting that I had to attend, then whoever called the meeting had to pay me a dollar. And I got a lot of dollars that way. It did make them think twice about calling the meeting, even though it was only a dollar." Will Wright has a good point.

"Design is about risk. We all fear authentic public response to our work, but we have to be brave enough to overcome." Jack gets interviewed by Jennifer over on the Kicker blog. And: "Always have nice pens".

"Apple is creating an ecosystem of the kind of customers I don’t want. With the ridiculous approval process leaving bugfixes to take over a week to show up, with prices being driven down to nothing by farting apps… it just feels hostile to me. While I have plenty of great customers who have been raving about the app, all it takes is one little issue and it all comes crashing down." Sad, really.

This is great: a 25-minute video from Blurst looking at a short prototype they built. During the retrospective, other members of the team question the designers/developers about their intentions, their goals, and examine ways to make the prototype into a better game. There's some good questioning, some nice explanation, and it's a great insight into a process built around rapid prototyping and execution on top of Unity. Interesting to see how another company work on rapid prototypes and then try to "find the fun". Also: making the prototype public is another great piece of explanatory work.

"Agile is like teen sex: Everyone wants to do it, many say they're doing it, only some actually are, and very few are doing it right." Yup.

"for a while now we’ve been meaning to post some early childhood snapshots of world of goo, to dig deep into our code repository and remember the good ol’ days. the early part of a game’s development is often very enjoyable because things evolve rapidly and there’s a great sense of accomplishment. it’s also a lot of fun to look back at those early days and laugh at what the game use to look and feel like." First in a seven part series, in which 2D Boy walk us through the - playable - origins of World of Goo. Game devs: more like this, please.

Matt's talk (in English) from Lift 09 is on this page , on scientific fiction, stories, and the design process. Good stuff - not too long - and wonderfully filmed: the cameraman focuses on his hands as much as his face, which is just perfect. Unfortunately, you can't link directly to videos which is, frankly, rubbish.

"I mentioned I’ve learned some rules of how database apps change over time, now that I’ve done a few dozen. They are:" Some interesting thoughts on how cruft builds up over time in database-backed web apps; I can't say I disagree entirely.

"On June 17th, every year, the family goes through a private ritual: we photograph ourselves to stop, for a fleeting moment, the arrow of time passing by." Perfectly executed.

"The US auto industry is on the verge of imploding. People are losing their homes to foreclosure. And, on the off chance that you had the nerve to try to buy something, credit is almost impossible to come by. It is against that backdrop that I would like to talk about working for free. Why? Because I think it is one of the fastest ways to make yourself a better photographer, whether you are a pro or an amateur."

"An almost-real-time, behind-the-scenes look at the assigning, writing, editing, and designing of a Wired feature."

"So we decided to treat Availabot as a world probe: it was decided that we would take Availabot through to the position of being factory ready, and in the process learn as much as possible about the processes of manufacture, and how to develop these kind of complex products with so many moving parts." And, best news of all: Availabot will be coming to market. Excellent.

"The idea of there being these two separate things has to be forced away from our thinking. They are one team, which produce one product. Stick their desks together and see what happens." Yes, yes, yes, yes, yes.

"If you aren't building, you aren't learning. Rather than agonizing over whether you're building the right thing, just build it. And if that one doesn't work, keep building until you get one that does."

"Our challenge now is to keep a very close eye on the mise en place, because if one cook changes even a little detail of one of the key ingredients—the width of the tomato slices, the amount of mustard on the bun—the harmony of these burgers is lost."

"Too often, developers only test their features and don’t go outside that box. [...] when you are in scoring mode, you’ll take the time to check out all the new features to see what you can break to score big." Rules for turning QA into a game.

Raph's presentation from GDC 2007. Very good stuff.

"I’ve reproduced the list [of rules from Lockheed’s Skunk Works] here with an identification of a modern software development rule or business practice that it corresponds to." Good stuff from Matt J. Can't wait to see his book.

"...they need to keep thinking creatively about how they work together and continuously try to improve their process. This mindset is the key to high performing, self-organizing teams."

"Every day, we have our team meeting and on one of the walls is a white board containing the heading 'Scary List'. When someone catches whiff of a problem or rumor that could potentially sink the projects, we jot it on the list."

"When faced with a roblem you want to solve, or even to find out where the real problems are in the first place, try what the native americans called the Medicine Walk." I've been doing this a lot recently, and the pairing tip is spot-on.

"When he has mastered tone, and with it exposure and development, he knows the most difficult part of his technique and practice, let him then proceed to picture-making." Emerson's Naturalistic Photography for Students of the Art, 1889.

"...a user interface design conceived by someone without detailed understanding of the tools used to construct it often suggests good, but expensive to implement designs. There's a sweet-spot between good, and expensive to build..."

Great write-up and series of notes on Bill Buxton's book, by Michal Migurski

"Games create conceptual touchstones - shared references that bridge different points of view and provide a common platform for conversation. That’s what most design deliverables try to do, with varying degrees of success."

The best products came from those odd teams that managed to compromise. The technology was clumsy and the emotional benefits of the software shaky. But it was better than the crap that customer had to put up with before.

Photographs of the rooms writers work in, accompanied with short editorials.

Phil kept pretty detailed notes on moving hosts. Worth bearing in mind, as I think about doing the same...

Andy weighs in on the UCD/Agile clash. Am really thinking about this a lot at the moment.

Resolving the conflicts between UCD and Agile processes. It's not necessarily as hard as it might seem...

Agile Work consists of seven core practices. These practices form a solid starting point for any person, team or community that wishes to follow the Middle Way to Excellence.

People love mysteries and myths so much that they create them when an explanation seems too simple or straightforward.

Todd Williams from Adaptive Path looks at a new (mental/process) framework for design. Really good article - even if you don't ascribe to it, there's loads to think on in there.

The team, and even the immediate layer above the team may be following Agile practices, but once it reaches out into the rest of the organization, leakage occurs in both directions: development needs frequent input from the field on what's valuable to imp

What defines a project? Sometimes there are small projects. Google News took a team of 3-5 people. If you take a pool of engineers and put them in teams of three, you can actually do 100 projects.

Building companies from the ground. Really good writing.