Jamie Kosoy

Jamie Kosoy is a technologist, coder, teacher, generalist, nerd and all-around nice guy based in Brooklyn. He's the founder of Arbitrary, an inventive new digital agency. Prior to that Jamie was Technology Director at Big Spaceship, where he helped lead a team of developers make crazy stuff on the web (and well beyond) for over eight years. Jamie’s work at Big Spaceship received a range of recognition including Cannes Lions, One Show Pencils and even a permanent exhibit in the Museum of the Moving Image in Queens, NY.

Jamie also teaches in the MFA Design + Technology program at Parsons and blogs about creativity with code on CreativeJS.com. He is a TechStars mentor and a former teacher at General Assembly. He has spoken and given workshops around the world on code, process, team building, whiskey and education.

He tweets, too, @jkosoy.

Published Thoughts

I love open source, of course, and I love being part of a community that helps each other succeed. But I’m torn about package managers.

The problem is that they’re great: So great that they’re often my first course of action. I find myself trying dozens of libraries to solve my problems, rather than coding myself. I spend as much time sorting out configuration files as anything. Often sifting through packages feels eerily reminiscent of combing through WordPress plugins.

Saddest of all, I sometimes feel like package managers make it harder in some ways for beginners to feel like they can contribute and make “real” stuff. This is especially true for the web, where one used to whip a file (or three) together and start making. Nowadays if you’re not using bower or npm or grunt or gulp it feels like you’re “doing it wrong.”

Sometimes I’ve just got to build things by hand, my way. My code has more character that way. Sure, it’ll probably be imperfect, but it’ll also be all mine. And while I might be reinventing the wheel, at least I’ll know what goes into making it.

There’s this legend I love of a famous chef visiting a top culinary academy. The chef, a stern, terrifying man commanded the attention of the room. “Today I will teach you the most important cooking lesson you’ll ever learn”, he growled as he stared down each student. The students stood tall, each in a cold sweat as he walked past them. “Pay close attention. This is the secret to all my success.” The students cowed with fear and excitement. One of the greatest chef in the world! Here in their classroom! Telling them his greatest secret! The chef turned away and picked up a broom. He proceeded to sweep the floor, never taking his eyes off each student as he cleaned. He finished sweeping, returned the broom to it’s home, then picked up an onion. He diced an onion, then put it in a small container at the top of his station. He did the same with garlic, placing it next to the onions. He repeated this for carrots and celery. He put his knife down, went across the kitchen, grabbed some linens and placed them to one side of his station. Then he turned to the students, nodded at them and left the class.

The story is about mise en place. If you haven’t heard of that before, it’s a French expression that means “putting in place”. It’s used a lot in professional kitchens. The idea is if you prepare yourself with all of the things you need for service, the actual cooking becomes much more automatic.

Mise en place. I try to apply the idea to my daily routine. For me, it means keeping my machine in order.

  • At the end of every day, I comb through my Desktop and Downloads directories. I place anything I might need later in an appropriate directory likely Dropbox or Documents. Otherwise they’re destroyed.
  • Trash is emptied daily. Again, my files are organized or obliterated.

Or, for email:

  • No labels. No filters. No automatic rules. I rely on search to dig up old conversations. Gmail is especially good at this.
  • Unread and Read are irrelevant. All that matters is that all emails are actionable.
    • If I get a mailing list email, I unsubscribe from it.
    • All other emails get an appropriate response, then get archived. A response could be:
    • Do I need to reply? If not, archive. Conversation over.
    • If yes, respond, then archive. Repeat process when I receive a reply.
    • Star/Favorite only extremely important conversations, or things you need to get back to.

Lately I’ve realized I’m terrible at bookmarking. I’d like to become better. I’ve started to think of rules for web browsing like my email rules. Having rules helps me stay organized.

If you’re not thinking about this kind of thing, give it a shot. It isn’t hard: Figure out where you’re a mess and come up with habits you can reasonably hope to follow through on. Getting the smaller things out of the way will let you concentrate on the things you want to be doing.

I've seen plenty of coders and designers despair over feeling not good enough - that the reason they'll never do what make what some other person does is because they are somehow "better" or more knowledgeable in a skill. Deep down we know that’s not true… or at least, it's only a part of it.

Syntax doesn't makes a great developer anymore than photoshop chops make a great designer. Process does.

Next time you're feeling discouraged, remember what's so cool about the web in the first place - the intersection of design and interactivity. Ask others for help. Send an email to someone who's work you look up to. Break a problem down into things you need to learn. Build a million little prototypes. Every time you feel intimidated by a technique or technology, find the time to jump in and teach yourself instead of excuses not to. Don't worry about being the best - worry about making yourself a little better. The worst that happens is that you learn and grow.

The Pastry Box Project is like a daily time capsule. Every opportunity I have to write reflects the day I wrote it. Many posts by past authors inspire me for months and years after their publish date. Today is a tricky day in my time capsule. I want to say something profound and important to commemorate #663399becca, the Twitter hashtag offering a memorial of sorts for Rebecca Meyer, Eric’s daughter. Next year, when our attention spans may have shifted to other things and we may have forgotten #663399becca, I’ll remember it like this: A Twitter hashtag trended for a daughter who died far too young. I’m sure many other daughters have been lost in similarly tragic circumstances, but this daughter moved so many people because her father gave so much to us, to help us make the web into what it is today. In some ways I owe my career to Eric. I’m sure many of us do. He’s one of the giants whose shoulders we stand upon.

#663399becca is a thing because Eric Meyer helped so many of us become who we are, whether he knew us or not. It’s our way of saying thanks.

Thank you, Eric. I’m so sorry for your loss. I don’t know you personally but I wish there was more I could do.

Actually, there is. Today I think I’ll send a few notes to friends thanking them — folks who I care about and whose shoulders I stand on. I don’t think I should wait for heartbreak to let them know.

The Meyer family requests charitable donations be made in Rebecca’s name to the Philadelphia Ronald McDonald House or the St. Baldrick’s Foundation.

There’s incredible momentum toward the notion that everyone (or at least kids in school) should learn to code. Take Code.org: Part of the vision is that “computer science should be part of the core curriculum in education, alongside other science, technology, engineering, and mathematics (STEM) courses, such as biology, physics, chemistry and algebra.”

I fundamentally disagree with that idea. Can everyone learn to code? Sure. Does everyone need to? Maybe… perhaps it’s too early to tell.

I think everyone should learn about art. Better still, everyone should learn about design. Imagine classes with emphasis on critical thinking, collaboration, inspiration, beauty, craftsmanship and creativity. Don’t those skills sound important? 

Those classes, rare as they are, seem to be going the other way. They’re the ones that disappear when a budget gets cut.

The Beautiful Default

When I think about web design, and for that matter digital designed anything in general, I often feel as though there are two forces pulling against one another.

The first force is all around innovation. We all want to design something new, disruptive, more efficient or otherwise more pleasing to use, after all. It’s obvious to talk about and something I believe we all strive to do as a part of our DNA.

The second is The Beautiful Default: Industry standards and well-defined paradigms permeating across all the different design disciplines. I first heard the phrase from my friend Branden Hall. He defined it as such: When you first start using a library, pattern or framework you get a certain set of things for free: Button styles, ways of laying things out, fonts, whatever. Those are the defaults. If you do nothing to them your site will look just like it’s original creator made — beautiful, but not yours. It’s like cooking boxed macaroni & cheese: It might be faster to eating dinner but you’ll never be wowed by the result.

Doesn’t matter if it’s a code library, a grid system or an icon set: Twitter Bootstrap, flat design, cards as a UI paradigm, share buttons are all Beautiful Defaults.

The web is filled with egregious overuse of Beautiful Defaults. It’s revered to some extent. Crack open Site Inspire and, if you’re anything like me, you’ll see an ocean of websites that manage to look exactly the same. Collectively the sum total of work feels terribly bereft of soul.

Living in Brooklyn, where there’s simultaneously a technology boom and a revival of artisanal craftsmanship, I can’t help but wonder why these two things don't seem to connect more often.

I’m not arguing that frameworks or patterns are evil. I use them myself, of course. I guess I’m begging you, dear reader, to try something more bespoke next time. Put away the boxed food, break out the fry pans and make something a little unique… even overcooked or a little burnt there’s flavor in the character. The Web is still a new medium. There’s still room to be playful and exploratory. Have fun out there.

Not more than 5 minutes ago a friend working for another agency asked me for help. He’s the CEO of his company — a much larger agency than mine and definitely not a programmer at all. He was concerned about integrating Tumblr posts onto the home page of a project his team was working on and they were having some issues pulling as much content as possible in. He and his team were curious as to how I would approach the problem.

Here’s what I wrote back:

I haven’t prototyped or tested with this but just going on what I’m reading here’s what I tried.

RSS Feed

The downside is it appears to be static: It only updates when there’s a new post. It’s probably limited to like… around 20 posts or so. I couldn’t find a way to say… get an RSS feed with 100 items, or the second page.




All seem to return the same data. ¡No bueno!

Tumblr API 

(doc page: http://www.tumblr.com/docs/en/api/v1#api_read)

This doesn’t seem to require an access token or an app, so there’s no real downside as far as I can see for loading stuff in. The format returned is different than RSS (XML or JSON), but then there’s more control. Examples:




You don’t need to be a code expert to tell you’re getting different data on each of those links. Different data means you can load in more stuff.

I haven’t prototyped or tested with this so I don’t know how far back the data goes — if you had 5 years worth of Tumblr posts it’s not out of the question that perhaps not all the data is accessible. I’d recommended the dev team over there do more thorough tests to discern that.


Sounds like the dev team is using the RSS feed. I’d switch to using the Tumblr API — there appears to be no con or penalty whatsoever — you don’t even need to create a Tumblr Developer account. If it were me, I’d load in the first X number of posts (let’s say 20). Then a user could trigger more via some kind of interaction — scrolling to the bottom of the page, clicking a “More” button, whatever.

Further I’d recommended caching responses for a week or so to reduce the # of requests sent to Tumblr, depending on how often the clients’ blog would update and assuming that’s not an outright violation of Tumblr TOS. That might result in the data getting slightly out of sync but also be far less stressful on Tumblr’s servers. I don’t know exactly what “caching strategy” I’d use because well, it’s not my project. :)


You might think this is more information than the CEO needs. You also might think that I spent an egregious amount of time researching all of this. And if you’ve ever gotten an email from a friend asking for a bit of help like this, you may have put off responding while you took care of other more important (read: paid) work. 

To that I say:

  • There are links for him to click and see for himself the differences between one approach and the other. There is research for his team to go off of and a recommendation or two to decide the best course of action.
  • The whole of this research took about 10 minutes. It may not be exhaustively researched but it’s an account of what I tried.
  • Unless I’m doing something that truly demands all of my time helping a friend out is always a worthy priority. Maybe I can’t respond to everybody the instant they need me but I can at least find the time to respond with something helpful. 

Last month Brad Frost wrote “Just” right here on this site. Brad’s right, and I’d add that explaining things well goes far beyond code and pixels. Helping others make sense of something you understand is extraordinarily valuable — maybe the most valuable skill of all. It’s the difference between the people around you feeling empowered to make decisions and being subjugated by what they don’t understand.

Designers should be teaching engineers more about color and typography and the decision making process. CEOs can always be more transparent about the business decisions driving the direction of a company. And coders… well, I think Brad covered that pretty well.

Take the time to explain stuff you understand to others that don’t. Empathize. Ask for better explanations for things you don’t understand yourself. Be helpful and allow yourself to be helped. Only good can come from that.

*Oh, and if anyone out there reading this better understands the Tumblr API feel free to ping me with your thoughts. I’d love to learn more.

“Sometimes knowing gets in the way.”

That’s what one of my deskmates said aloud while out to lunch a few weeks ago trying to brainstorm new project ideas. He’s a former student at NYU’s Interactive Telecommunications Program; I moonlight teaching at Parsons’ Design + Technology program. Both programs are difficult for me to describe in spite of how amazing they are. Graduates have gone on to found interactive installation agencies or created celebrated indy games. They’ve designed beautiful digital products for large agencies and told wonderful stories through interactivity. They are experimenters, artists, tinkerers, designers, curiosities.

Some students come in with existing experience in design, code, or electronics when they first enter their programs. Many do not. While both schools have esteemed faculty, the students’ interests are so wide and varied that the onus is on the individual to teach themselves whatever it is they need to learn to realize their ideas. These students haven’t put in enough raw hours to assess the difficulty of a challenge. Their vision isn’t clouded by expertise. They charge in headstrong, and the resulting output is often incredible and wonderful.

It’s rare when someone comes out of these programs magically incredible at anything specific. Two years of scrambling madly to learn how to build something from nothing is hardly going to generate rock-star designers or coders. Perhaps that’s not the point. Maybe knowing how to make everything makes it that much harder to make anything great.

I’m a generalist. And a programmer. And I’m also a generalist programmer. (Got that?)

In other words most of my work time is spent doing all sorts of intangible stuff, but a chunk of my code time is spent programming, and to go further a chunk of that time is specifically with web technologies… but I’ve also coded iPhone apps, interactive installations and robots. I’m also a collaborator, a designer (though not of the visual ilk), a project manager, a cheerleader, a teacher and inventor. Whew!

It probably goes without saying sometimes I struggle to articulate exactly what I do for a living.

In fact, I’ve come to realize that “field of expertise” is often more art than science, and that the goal of bringing on perfectly specialized people is often the wrong one. I believe everyone is equally creative and everything ever made is inherently creative. That’s doubly true for the world of software, technology and the web. I further believe that the creative process is the most essential thing to get right. Products with strong narrative, experience, UX and visual design are more compelling to use, talk about, share and return to, and making such products requires the right kind of people working together as creative equals. I built my company on this idea.

I feel more confident in my work collaborating with other people who elevate me to do my best. The irony is that those collaborators often feel the same way I do out on their own: Confident they’re valuable but unclear on exactly where, how and why they’re great. And we’re not the only ones out there. It’s easy to lose faith in oneself if you aren’t “good enough” at a particular trade… but maybe that’s not way we should be playing the game.

I thought I’d use my year on the Pastry Box project to talk about this.

There’s plenty out there written about core competencies. It’s time to celebrate the stuff that really matters.