We recently decided to the start a semi weekly written interview series of the humans behind programming, Loop Letters. What motivates these individuals? What sort of team culture are they working in? What hobbies are they good at? What hobbies are they terrible at? These are all things we decided the world needs to know. This first Loop Letters post will hopefully get us a little closer to feeling like we know the people in our community a bit better, while also talking a bit of shop along the way.

Lincoln Loop has forever been fans of &yet and Henrik Joreteg.

Henrik Joreteg avatar

Henrik is currently the President at &yet, the highly celebrated “people first” software company. We reached out to him to chat about &yet’s team culture and some of his personal projects, such as Human JavaScript. We also talk about hobbies and take a peek into his skier pro past and his recent shed turned sleek home office.

So without further delay let's get cozy and ask Henrik some burning questions.

&yet is known and respected in the community for its “people first” approach. Could you tell us a bit about how you all contribute to this type of culture on a daily basis?

I think it’s a mindset. We all make an intentional effort to see each other as whole people, not just "resources". That sounds a bit corny, perhaps, but it changes how we react to things that happen.
If someone has an issue with something or someone, they know they can voice those feelings and be heard. As a group we value people over productivity, and as it turns out, people do awesome things when they know they’re valued and heard.

With &yet being partially distributed how do you all regularly keep in touch? Do you predominantly utilize your own tools, such as Talky?

Roughly a third of our team is at the main office any given day, so we depend heavily on tools to keep in touch. We switched to Slack recently for team chat, and we rely very heavily on Talky for those times when text chat just doesn’t cut it. Especially the new beta version, beta.talky.io, because it supports much larger groups so we can do our bigger team update meetings, etc.

In addition to these we use:

  • GitHub for letting people file "issues" on the organization or file requests for help they need. If I need some design help for an open source project, for example, I create a new issue on the andyet/design repo explaining what I need.
  • We use Ginger for "check-ins" where people can talk about how they’re feeling about things.
  • Hackpad for writing things collaboratively.

The &yet team used to do a lot of Python/Django work. What do you miss about Python? What could Python learn from the JS world?

I’ve always liked the general cleanliness of most Python code. The PEP8 style is considered idiomatic so there seemed to be less "bikeshedding" about styles, etc.

I think JS has an inherent advantage in that it’s simply an easier place to start. Anybody can open a console in a browser and already have an "interactive interpreter" as Python folks refer to it. Plus, you can interact with the page directly and see the results of your actions.

Then when you add Node.js into the mix with stuff like browserify/webpack, now you can write code the same way no matter where you’re going to run it so there’s less context switching.

As someone who worked as a web developer for several years before I even knew there was such a thing as "backend" and "frontend" using similar tools in both places fits my mindset.

In addition, the ease with which you can write little command line applications and utilities with Node.js is pretty amazing. I think that’s a big reason why it’s become the defacto tooling for creating frontend applications, (a.k.a. Native Web Apps) even in cases where the app isn’t ultimately running on Node.js in production.

It has been a year and a half since you released Human JavaScript. How do you manage to work and keep this type of learning material up-to-date (like with your latest Human JavaScript video course) on such a fast-changing ecosystem like JavaScript’s?

It’s challenging, for sure, there’s so much to keep up with. I’ve developed a few coping mechanisms:

First, I try very hard to isolate mental processes so I can work on a single task at a time. It seems like I can get a week’s worth of progress done on a project in a day if I’m focused and I know I have zero distractions. So I’m quite protective of what gets my attention and try to isolate long blocks of time where I can ignore everything else without feeling guilty about it.

One recent example is I made some rather drastic changes to my work schedule. I now only work at &yet 3 days per week. The other two days are spent completely on personal projects from my home office that I built in my backyard. This is where I now work on stuff like the book and video tutorials.
I’m also notoriously bad at responding to email in a timely fashion. Not that I’m irresponsible about it–I’ll always eventually get to it, but in many cases it won’t be the same day or even the same week. I always batch those kinds of efforts.

Second, I try to do things that serve multiple purposes. A client project can be a great reason to improve or create an open source tool. I first recorded the video tutorials as a way to practice for an upcoming two-day, in-person, workshop I was going to lead. A good portion of the content for my book came from blog posts and project README.md’s that I had already written. Finding ways to align interests like that can have a nice multiplier effect.

In terms of dealing with the rapidly changing landscape in JS, much of that has been driven by my dissatisfaction with tools and workflows while actually trying to build things.

My blog posts, open source projects, and even several products we’ve built like Talky and AndBang are often born out of "scratching my own itch", if you will. As it turns out, often times I’ve discovered that other people had the same "itches".

This is also where working with a team is invaluable. The frontend devs on our team all share the best stuff we find and the tools we create.

What do you feel has changed the most concerning your workflow since you released the book and Ampersand.js?

I’ve recently become completely obsessed with going back to building frontend applications as completely "static" sites. I don’t mean static in terms of user experience, quite the contrary actually, but I mean that the app is being served to the browser as a set of static files. I pre-render all known HTML structure to static HTML files at build time, then all the dynamic or user-specific data is fetched by the JS at runtime.

With a few simple routing rules that you can do in NGINX, or using a service like Surge.sh or Divshot you can get clean, proper URLs, without needing to run something like Node.js, Rails, or Django in production at all for the frontend.

All the dynamic data then gets fetched from JSON APIs that you either rent or write. This forces you to architect your systems with proper separation of concerns. Your frontend web app becomes no different, conceptually, than building a native mobile app, its only concern is presentation of data. It has to fetch and intelligently cache all of its data from external APIs or services.

This makes operations a dream. To quote Jason Rose from Shutterfly who built their last app with Ampersand.js as static files: "Our deployment tool is rsync".

During development, I run a dev server that live-reloads styles and even view components on the fly as I save them in my editor, but then when it’s time to ship, I run a build step that produces a set of static files, including multiple HTML files with pre-rendered HTML structure. I then use React to "take over" the DOM once the JS has downloaded. The result is fast initial page loads that seamlessly transition to being entirely controlled by the client side JavaScript.

A working demo app using this approach is online at Hubtags. You can load the homepage with JS turned off, but once the app itself has downloaded, it takes over all rendering, navigation, etc. That source for that app is on Github and my specific dev-to-production-build setup is open source too.

These techniques are what I cover in my most recent video tutorials and what I’ll talk about in the second edition of my book.

But having switched to building this way, I’m never going back. In fact, I think we’re going to see a massive resurgence of static web apps.

A couple months ago you tweeted a picture of a shed and mentioned you were working towards transforming this into a home office. How are these efforts going? Could we see some pics?

I got it mostly finished and have been using it a ton! I totally love it. I also built a big, beefy desk to go in it. Here’s a few pics, it’s also got a rug and more furniture now, but you get the idea. I still need to do a bit more finish work, but I’m quite happy with the result:



We watched this video where you are are pulling off some amazing lincoln loops (nice!), do you still ski? Any other hobbies you are amazing at? Any that you are terrible at?

Oh sheesh, you found that, eh? Yes, that’s my younger, before-becoming-a-responsible-adult self. I love skiing and still do it, but not 5 days a week like I was when that was filmed. I’ve definitely eased up on the inverted tricks since discovering that my body can break.

But, I was very excited to take my daughter skiing at Mt. Bachelor this season and hope to make it a family thing for us. My wife, Holly, can definitely hold her own on a pair of skis, so hopefully we’ll be doing it a lot more in coming years as my son gets to be of skiing age (he’s almost 2).

Other hobbies? Mountain biking, traveling, guitar, piano, but mostly playing with my kids.

Things I’m terrible at?! LOL, well, I love traveling but I have a completely broken geographical sense of direction, I accidentally take the long way to pretty much anywhere I’m trying to go.

What is one technical and one non-technical book you would recommend everyone start reading right now?

Technical: JavaScript Allongé is pretty great for giving you a much deeper understanding of JS. Reg is brilliant but manages to explain things in terms that us mere mortals can understand.

Non-technical: I’m always embarrassed to recommend this because it has such a bizarre title, it’s also super old. But I think everyone should read Dale Carnegie’s "How to Win Friends and Influence People". You just can’t read it without becoming a better people person.

We often make conscious efforts to improve other skills, but so much of life can be improved by making an effort to improve our people skills and better understanding and empathizing with the people around us. Despite it’s seemingly self-serving title, that’s what this book actually helps you do.

I think as developers we’d be wise to sometimes read stuff like that, instead of reaching for another programming book.

Finally, do you have any advice on how to keep teams energized and in good spirits?

Empower, encourage, and get out of the way.

Follow @HenrikJoreteg on Twitter to keep up with what he’s doing next.