DEV Community: Between the Wires

Between the Wires: An interview with open source developer Sindre Sorhus

Vivian Cromwell — Mon, 04 Sep 2017 21:01:48 +0000

Sindre at street food restaurant in Bangkok

Tell us a little bit about your childhood and where you grew up.

I grew up in suburban area outside Oslo, Norway. When I was little, I was really interested in Legos. Every year I would get Legos for birthday and Christmas. Legos really sparked my interests in building things early on. At one point, I had a huge Lego city built into my room and it almost occupied the entire room.

Building Lego as a child

How did you get into programming?

When I was seven, my family got our first computer Windows 95. I used to play a Map Blaster game where the character jumped around to solve math problems. A few years later we finally got internet access and it changed everything for me. I spent a lot of time writing in guestbooks on other people’s web pages and gathering gifs. One day, I got curious about how the website worked and discovered the “view source button in the browser.

On a family computer, Sindre was checking Microsoft Outlook Express

That was a mind blowing discovery for me. I could just right click, view the Source and then I could see how everything was made. I didn’t understand much in the beginning, but as I looked at the same thing over and over again I started to understand how it worked. This is how I started my programming journey. Ultimately, that was what sparked my interest in programming.

I made my first website when I was ten. It was after having looked at the source for a few years. It had all kinds of colors, a star patterned background, animated with media background music – it was one of those touches that everyone had on their websites back then. I used Microsoft FrontPage.

One time, I was bored so I created thousands of nested directories on my dad’s computer and it ended up crashing the computer. My dad had to reformat the computer; he was impressed and annoyed at the same time. That was also how I lost my first website.

Later during my school year, I got into Flash games and we would watch a lot of Flash movies during school breaks. I was curious how they were made but there was never any source button. So I decompiled the swiff files, that was easy because they were not obfuscated. That, again, gave me the opportunity to learn from other people’s work. I started to modify other people’s games and redid all characters, made new enemies, added high scores. It was a proud moment when I realized others could actually play a game that I had glued together.

You spent five years in military as a front end developer and photographer. What was the web development like at that time?

Sindre in the military

After graduating from high school, I was conscripted directly to the military in Norway. I got into the media unit where I spent most of my time in office working on the intranet. There wasn’t much to do in the evenings because we lived in the barracks so I decided to build stuff. But most of my experience had been copying and pasting other people’s PHP and JavaScript and I didn’t quite understand how they worked. One day, I stumbled upon Python and Django, it had great documentations and tutorials that PHP never had. I would read tutorials every day and started building things at work.

That is how my actual coding started. After the conscription, I planned to go traveling before college. But I got a job offer from a unit in the military named Cyber Defence Unit. It was intriguing so I took the offer, I ended up spending 5 years there.

The app that Sindre made in the military

How did you get involved with TodoMVC and Yeoman?

I started using GitHub around 2011 but mostly as a consumer. I would go around, looked at different repos and starred them because they looked fun. I fixed some typos in README.md files but that was about it.

One day I stumbled upon TodoMVC which helps you to select a JavaScript framework. It was a really awesome idea, although in hindsight we need a lot more advanced applications to actually solve the problems of performance testing and framework capabilities. The first thing I remembered about TodoMVC was that it had a nice logo. It seems very superficial, but that’s what got me started.

ToDoMVC logo

I liked the logo so much that I decided to look around a bit more. I noticed they didn’t really have a jQuery application so I decided to create one. I submitted over the weekend and got a response back from Addy Osmani who is the maintainer of the project. He merged my PR quickly which was a super nice experience for a beginner like me. I felt good that my app is now included in this really popular project. I did this for a few weeks, and Addy added me to the project which was really cool.

This really got me interested in open source. Before this, I was just a passive consumer but with TodoMVC I got a taste of maintaining a big project which was a lot of work. But I learned a lot from that experience.

A few months later, Addy went to work for Google. His first project at Google was Yeoman, scaffolding tool for modern web apps. Because we worked so well together on TodoMVC so he decided to invite me as an external contributor.

Yeoman Logo

Our initial goal with Yeoman was to create a set of tools that everyone can use to create great web apps. What we didn’t realize is that it is impossible to solve everyone’s problem in one tool because on the web there are just too many use cases. Yeoman became a popular configuration that many developers created generators to extend Yeoman that suit their own use cases.

History repeats itself as well if you look at Create React App or Webpack. It starts out making this product that is supposed to solve one problem, but because everyone has different needs, problems arise. When you realize this tool can not cover everything so you add the configuration. The key is to have a balanced approach. You have to say “No and you need to know when to say “no”. You may disappoint some users because they have obscure use cases. That is the hard part of making tools, and it’s even more difficult in open source projects because there is so much feedback.

Why are you passionate about open source?

I love open source and I think it goes back to the “View Source button in the browser. In my opinion, open source is the most effective way to build software because it enables us to build on top of each other’s work. Everyone benefits if any one person solves a hard problem. Open source lets me work with incredible people from around the globe that I would never have been able to work with otherwise. We get to work on what matters to us and focus on what’s needed by the community instead of focusing on generating revenue.

Paul Irish has a great video on YouTube titled “Ten Things I learned from the jQuery Source. That’s what got me interested in reading the jQuery source code. Paul Irish was right, you learn a lot by actually doing whatever it is you want to learn how to do.

How about open source sustainability?

That’s definitely a point of conflict that I’ve been thinking about a lot recently. I’ve done open source full time for about three years now. I don’t earn any money but it would be nice to do this full time as a paid job. Vue.js by Evan You is a great example of how open source sustainability can work, though. He created a framework that everyone wanted and it has been used by quite a few companies. Other companies and individuals have incentive to invest in his project because it is useful in production. The key is to make your project dependable. I personally don’t think contributions from individuals are enough to sustain a project.

I’ve been thinking about using Open Collective so we can collect money to reward contributors and event promotions. Webpack has done a great job there. I was actually against this for a long time because I was worried that there were going to be expectations for us to make a move whenever someone put money towards the project. Usually if a company invests in a project, they want the work prioritized and the issues fixed quickly.

I am currently living in Thailand and I think I would be fine with less than 1500 dollars.

You have over 1000 npm packages. How do you stay so productive?

That’s a misconception. People see the number 1000 packages and they think I’m insanely productive, but what they don’t realize is that most of those packages are small and modular. They’re pretty much done when they are published. I like to compare programming to building with Lego: I create lots of Lego bricks which can be assembled to build larger constructions. I use them with other packages before publishing to ensure they solve the problems. That is also why users would not submit a lot of feature requests because they are so small. If they need something more they can just build another module. 90% of my time is spent on my biggest 10 projects.

What is one advice you can give to new OSS contributors when dealing with demanding and toxic people?

I have been doing open source for six years now so I’ve developed a thick skin. I don’t think anything bothers me anymore because I like to think that I’ve experienced it all. I talk to a lot of beginners who experience some toxicity and quit. Open source is supposed to be a fun thing you do, not a cause of stress in your life.

My advice to new developers is that you shouldn’t let strangers on the internet negatively affect your mood or your drive. It isn’t worth it. If you have the option to walk away, take it – utilize the unsubscribe button. Open source maintainers need to remember that users are not paying customers. We’re providing something to them for free, on our own free time

With toxic people, you need to always be the bigger person. It sounds wrong, but what I try to do is to kill them with kindness. Somehow it’s worked for me for many years. For example, if someone is annoying, I’ll try to be as open and kind about the situation. I make sure never to be sarcastic or talk down to them. The trolls feed on your annoyance and discourse, so when it’s not there, they’ll leave you alone.

I utilize the muting option wherever it’s provided, especially on Twitter. It’s good to realize just when someone is bordering on toxic, and it’s much better to simply shut that voice and input out instead of causing unnecessary conflict.

You designed some logos for your own modules, they are awesome. How did you learn design?

XO project

I started by following online tutorials to make cool effects. I used to use Sketch, but now I use Adobe Illustrator.

It’s really fun for me to design, and I think more programmers should try it. After programming for hours, it’s nice to take a break to do some creative work in a different way.

It also benefits my projects by creating logos, because it gives the project more of a personality. Usually when you enter a repo on GitHub, you get the same text based things: a header, some introduction and README.md. It is nice to spice it up with some graphics.. It turns out people are more likely to use the project if there is a logo. For example, Vadim Demedes, a developer from Ukraine, submitted this pull request right after AVA’s release. Vadim later became an AVA team member. He told me he got interested in AVA because of its nice logo.

AVA project logo designed by Sindre

I didn’t really know much about Thailand at all. When I worked in the military obligatory service, I planned to travel. I got an offer and ended up staying for another four years. I just went with the flow, because life happens.

One day, I was actually preparing a phone interview with Google, I just decided that if I’m ever going to travel, it would be now, otherwise, it would never happen. So I canceled the interview and submitted my resignation at work the day after. I bought a one-way ticket to Thailand and that was it.

I did backpacking for half a year in South East Asia, and that’s where I met my girlfriend. I eventually settled in Thailand because it was my favorite. I love its rich culture, friendly locals, and food. I have been living in Thailand for two years now.

I work out of local coffee shops three days a week because I like the interaction with people. Otherwise, from nine to six I do a lot of open source coding and maintenance, sometimes my side projects. On most days, I get more than 20 pull requests and tons of issues to fix. In the evening, I spend time with my girlfriend Im; we both love the spicy street food at night markets. Sometimes duty calls and I find myself back in front of the computer late at night.

Sindre and his girlfriend Im at Koh Mak, Thailand

I didn’t learn the Thai language because while I am good at programming languages, spoken language is much harder than any programming language, and Thai is especially hard. My girlfriend, on the other hand, is fluent in Thai, Russian, English and Swedish. At some point, I want to learn Thai and other languages, but I’m not pressed for time.

What motivated you to start AVA project?

I was using Mocha a lot because I made a lot of modules that had to be tested. I wasn’t really happy with how it worked. Mocha injects some global objects but they are not defined anywhere. Because I was doing it in Node.js, I had a lot of async APIs and it was not very convenient to do with Mocha.

I wanted something simpler and more optimized for my use case. So one weekend, I decided to work on it, and by Sunday evening I published 0.0.1 version for AVA on npm. Even though JavaScript is single-threaded, IO in Node.js can happen in parallel due to its async nature. AVA takes advantage of this and runs your tests concurrently, which is especially beneficial for IO heavy tests. In addition, test files are run in parallel as separate processes, which allows for even better performance and an isolated environment for each test file.

AVA project

Because I didn’t have time to fix bugs and I only wanted to use it on my own projects, it was private. After a year and a half, I finally made a logo for AVA, cleaned up the repo, wrote lots of documentations. Then, I published the project. It has grown a lot, because I guess lots of developers ran into similar problems that I had.

Most of the users are really happy because we get tweets on the project all the time. They really like how simple the syntax is and how easy it is to get started. I just made it to scratch my own itch, but it turns out that other people had the same problem and liked my solution

Nowadays, I spend more time on managing the project because there are so many new issues and pull requests every week, which leaves me very little time to code.

Why did you decide to get into macOS development?

I did a little bit Objective-C programming but I didn’t have a great experience. So when Swift came out, I decided to give it a try. This January, I got an idea for a Mac application, and I had some free time so I jumped right in. That is how I usually learn new things. It’s very spontaneous. I begin with a desire to make a product, then I figure out what skills I need to make that product then I learn them. The idea comes before the planning.

Swift is a lot harder to learn initially than JavaScript, but Swift shines because it is strongly typed. When you compile, it is much more unlikely to crash if you use optionals correctly. The only thing I didn’t like about Swift is that you still sometimes have to interact with the old APIs in C.

Lungo project logo

I wrote a few productivity and utility apps. Lungo is a menu bar app that I wrote and you find it on the App Store. The other one I wrote is Battery Indicator.

What is your plan for next year? Are you planning to go full time or consider other ways to become financial sustainable?

I have been living off savings in the last three years and doing open source software. That’s a lot easier in Asia but it doesn’t last forever. Ideally, I would like to do open source in a financially sustainable way but that’s difficult, so I will probably do some contracting next year.

I have tried a few different things. One thing I did is to ask for support in GitHub README.md file. I wouldn’t call it an ad but more of a small banner. I made a little bit of money but it is far from being able to sustain me.

I might give Patreon a try.

What are some of the things you wish to improve in JavaScript ecosystem?

In my opinion, the JavaScript ecosystem is great already but we still have a lot of quirks to work around on browser side of things. There are so many projects with this giant build script just to get a simple app out there, that is why I love Node.js.

The problem with browsers is that they are very complex. You have the network to think about, you need to optimize for performance, you have lots of different use cases, frameworks to choose from. Everyone tries to simplify it, but then you end up being too opinionated, then you add configuration but there are too much boilerplate. I don’t see an easy path forward unless you fix the actual platform instead of creating lots of solutions on top of it. One thing I think will improve the situation is when we finally get modules in the browser. You may not need a build step for everything then.

Why are JavaScript developers obsessed with unicorns?

The whole pony movement started with Django community actually. When you started asking the features you want, developers would say “I want a faster HTTP parser, or “I want ORM that just works. One day, one of the core devs on Django mailing list responded to one of the feature requests with “no, you can’t have a pony! The whole unicorn movement started with that feature request denial.

There’s even a website dedicated to the lovable pony.

Django, the web framework for ponies with magical powers.

I don’t remember exactly how it spread to the JavaScript community. It was one of those things that just happened on its own. Having something as fun and silly as unicorns helps me work through programming and OSS and ups my morale. The same goes for silly gifs.

ESPN.com went magical with Konami code. (source: http://kotaku.com/5230185/the-konami-code-makes-espncom-magical)

Sindre’s website

Sindre’s laptop homescreen

This project is made possible with sponsorships from frontendmasters.com, egghead.io, Microsoft Edge and Google Developers.

This post was originally published on betweenthewires.org

Between the Wires: An interview with Dat Project Dir. of Engineering Karissa McKelvey

Vivian Cromwell — Fri, 25 Aug 2017 19:34:29 +0000

Karissa McKelvey

I am the Director of Engineering at Dat Project, a distributed data sharing tool that packages your data and shares it over a distributed network.

How did you get into programming?

I went to a public school. Like most 13-year-olds, I just wanted to pass my tests. At some point, I started programming on the TI-83 calculator. I would give it to my friends in exchange for extra lunch or Magic cards. That’s how I started getting into programming. After that, I started making websites in high school for video games I was playing .

I didn’t really think of it as programming then because all I was doing was just fixing the problems I needed to solve. I didn’t really choose Computer Science when I decided to go to college. I actually chose Political Science because I was really interested in politics and debates. At the time, I put programming on the side until I realized that it was something I wanted to do, so I ended up with dual-majors in college.

Later, I went into a PhD program in Informatics at Indiana University. The premise was to apply computer science to a particular domain. Between 2010 and 2014, I collected a lot of data from Twitter through my lab, Complex Networks and Systems Research. During social movements and big political events, we got to look into how news and ideas spread online. It was exciting to see the whole picture, and that’s how I started getting into data analysis.

How did you get involved with Dat Project?

You would think that researchers are really smart and have all the perfect systems that integrate data from all the different sources. You would assume it must be really easy to transfer data between people. But that totally wasn’t the case at all. It was really hard to work with data in the university. Some groups had developed in-house data warehouses and workflows, but most labs have had trouble collaborating and sharing data.

I found this to be a huge headache when I left my PhD program and started doing data visualization. I worked at Continuum Analytics and at Google, and then joined a startup called Datapad. A year later, I found Max Ogden and the Dat Project, I messaged Max on Twitter about data sharing, and now I’m here today.

What is Dat project?

Dat is a distributed data sharing tool that packages your data and shares it over a distributed network. That means that we take the best parts of BitTorrent, which is a distributed network, and the best parts of Git, where you have version history…

Logo for Dat Project

Dat is a distributed data sharing tool that packages your data and shares it over a distributed network. That means that we take the best parts of BitTorrent, which is a distributed network, and the best parts of Git, where you have version history, and you put them together. It doesn’t actually use Git or BitTorrent, but it’s inspired by these two projects to build something that’s more robust and more resilient to data outages.

We started working on this three and a half years ago. Max got a grant from the Knight Foundation to do a prototype. Since then, it has gone through three iterations of design, implementation and testing. At the moment, most of our users are scientists, because we’ve been marketing and working with them on scientist use cases. It’s also very useful for other kinds of things, which is the great part about having a versatile platform for general use.

The issue with BitTorrent is that users can’t update the data over time because the hash and the link to find the data will change every time. We found a way around that problem by creating a public key that doesn’t change, and the person who generated the key can add more data to it over the time by using the private key. The people who get access to the data can look at the history and go back in time, they can also look for a certain byte range in a file, which is a really powerful and useful tool.

How does the grant funding work for Dat?

The biggest and most important part about getting grants is getting approached by a grant officer and convincing them that your project is worth it. The grant officer’s job is to give money to projects that they believe in or the projects that they believe fulfill the mission of the foundation.

Max got the first grant of $50,000 from the Knight Foundation to work on the prototype. This lasted for 6-9 months and then someone from the Sloan Foundation who was interested in the project approached Max and said “Hey, let’s apply this to science. The Sloan Foundation funds tools that are useful for scientists and to advance research integrity and efficiency.

Knight Foundation

Max started building a team as we continued to get more grants from the Sloan and Knight Foundations. The entire project has been entirely funded by grants. The biggest and most important part about getting grants is getting approached by a grant officer and convincing them that your project is worth it. The grant officer’s job is to give money to projects that they believe in or the projects that they believe fulfill the mission of the foundation.

Sloan Foundation

Every funder is different. Sometimes they only want to give you $20,000 or $50,000, and then other times they want to give you half a million dollars. They’re always trying to push for the public and general good.

If a foundation gives you a set of grants, how is the expectation being set?

The first thing you do is write your proposal, which can range from 12 to 200 pages. In the proposal, you need to state what your milestones are. If it’s a year and a half grant, you could say, “By three months in we’ll have hired a team. By seven months in, we’ll have user testing done, have a nice set of designs and have the alpha version. Anything to give the funder a clear idea of what’s to come.

You want to set these milestones in the proposal as well as metrics, such as the number of users and downloads. At predefined intervals, like six months, you need to do a short report to inform where you are with the project and how well you are doing with the metrics. People who give away money want to make sure that their money is being used properly.

How do grant officers and engineers find each other to collaborate?

There are multiple ways that you can get introduced to a grant officer, but I personally like to stick to two.

The first way, in the context of a conference or convention, is to have a solid presentation that catches the eye of grant officers in the room. That way, they’ll approach you about the project. Another way is to get introduced to grant officers by someone you know, and that’s when you really have to put connections in place.

There is a another way, which is the most visible but probably least effective way to get the grant, and that’s to apply via online forms or competitions. Usually that’s their way of getting newcomers into the pool. If you haven’t been able to get your big break yet, participating in one of the online forums or challenges may help. But you need to have realistic expectation because there are a lot of people who apply and the competition is really fierce.

How do grant foundations perceive open source?

A lot of grant foundations strive to be altruistic, so open source falls into their strategy, because they just want to fund projects that will be useful for the public.

Open source is a way for people to have their projects continue succeeding even if they’re not funded and even if the project didn’t meet its goals. It is a good way to contribute to the community in long term. When you have something that’s closed source, it dies along with the idea, the company or the organization.

A lot of grant foundations strive to be altruistic, so open source falls into their strategy, because they just want to fund projects that will be useful for the public. This then allows a lot of other creators and entrepreneurs to get interested and involved with your mission.

Dat runs a very distributed team. Tell us your best practices when it comes to team productivity and communication. What tools do you use?

Doing everything in public helps get other people who aren’t on the team to collaborate with us as open source contributors. “Open source, in my mind, is synonymous with “distributed.”

GitHub has helped immensely with the distributed team – Mathias Buus, in Copenhagen; Max Ogden and Joe Hand in Portland; Yoshua Wuyts, Julian Gruber, and Kristina Schneider in Berlin, and Chia-liang Kao in Taiwan.. We try to avoid private communication in the team, so everything is done in the public IRC. We have daily stand-up to cover what we are doing that day and bi-weekly call to update each other on our current situation, and from there we plan out what happens next.

Doing everything in public helps get other people who aren’t on the team to collaborate with us as open source contributors. “Open source, in my mind, is synonymous with “distributed.”

It’s great that we don’t have a team that consists of more than three people. One of the keys is having a small and focused team. I think people work best in groups of two or three. More than that, and it gets difficult to come to conclusions. When people make ownership of their part of the project, they feel empowered to make decisions. At the same time, they can also get input from other people in a horizontal fashion.

What is Code for Science and Society?

Code for Science and Society is a nonprofit organization that fiscally sponsors people who want to get a grant based project.

Fiscal sponsoring is basically what happens is when you get a grant, and regardless the check size, you can’t just accept that money as an individual. You need an organization that’s going to take the liability for you. The foundation gives the money to a nonprofit, then the nonprofit gives the money to you as a contractor and takes care of legal and accounting.

We created Code for Science and Society to house the Dat Project and also to house a project called Stenci.la, and we’re also looking for other projects to house. Essentially, we’re helping people get funding and handle all of the process, so they can focus on the project and get paid as a contractor through the non-profit. We’re actively looking for people who are interested in trying to get a grant. If you have a big idea, maybe even a prototype, we want to help you get funded and be your fiscal sponsor.

What happens is that a lot of engineers have a great idea, and they might also have a connection to a grant officer, but they don’t know how to do accounting and they don’t always know how to hire people. There’s a lot of smaller details that engineers shouldn’t have to worry about, and we should be focusing on the bigger picture and mission we’re trying to accomplish. But it’s a hard subject for open source, because you just want to make the product but you don’t have a company that’s helping you out. We’re trying to be that umbrella organization.

Ideally, all the projects in our portfolio would be things that can work with each other. That includes coding for science, society, journalism, open government, activism, collaboration and in general across these domains.

Walk us through a day in the life of building Dat and Code for Science and Society?

I like being busy. I think that’s why I did a dual-major in political science and computer science because I like to change it up. I like to talk and I like to code.

While it’s entertaining and challenging to build, sustain and put out fires in an open-source project, it’s also tough because the tasks you have to do are constantly changing. One day I’m up writing a grant, the next hour I have to fix a bug, and then the next hour someone’s calling me on the phone about accounting. Because we’re a nonprofit, we’re always a little under-funded, which means everyone has to juggle a lot of different tasks.

There have been times where it’s quiet and I’m just coding for 40 hours a week, but then I start to get a little restless. I like being busy. I think that’s why I did a dual-major in political science and computer science because I like to change it up. I like to talk and I like to code.

Can you talk about a couple really difficult periods you’ve had to go through or are currently facing in building Dat and CSS? How do you overcome the struggle?

Letting go of our prototype and moving to a new version was a tough transition.

One of the hardest times was about a year and a half ago. I’d been on the team for a year, but Max and Mathias had been working on it for about two years by then. I had built all this stuff on top of Dat, but the internal design was not working for our target users. We had a realization that we had to essentially start from scratch.

We knew that it was going to be the best long term decision, but it was a challenging one to face. We realized that our users were unhappy, and we weren’t getting any new users, so we had to think about what they would want. What they wanted required a complete redesign from the ground up.

Letting go of our prototype and moving to a new version was a tough transition. We found users who would help us design the next phase and work through all of the kinks and details. What’s great about nonprofits is that you can do that, because you’re not on a shorter runway. You don’t have an intense need to get user or revenue, which gives you leeway. We knew how much time we had left, and we knew that we could rebuild the product in that amount of time. Being able to start from scratch offered refreshing change, and we got to connect with our users to see what needed to be different.

What’s next for Dat Project ?

It’s important to back up these data sets in a way that’s distributed so that even if one of them goes down, the data can still be available at another institution. That’s just one of the pieces, because what’s really important is that people can actually use that data.

We’re really excited about the data rescue efforts that have been going on.

We’ve been working with Data Refuge along with Library of Congress , Sunlight Foundation and DATA.GOV. We’re going to be figuring out how to efficiently back up all the data amongst different institutions that want to host the data. We’re also trying to make it easier to backup open data sets in a distributed way, so that as more institutions host big data sets, they’re able to take a slice of that data set. You can read more about this effort on New York Times.

Source: https://www.nytimes.com/2017/03/06/science/donald-trump-data-rescue-science.html?mcubz=3

For example, DATA.GOV is 60 terabytes of data. No one institution is going to want to host 60 terabytes themselves. What we want to do is use Dat to distribute the data sets across many different institutions, so institutions have only a slice that they’re willing to contribute.

It’s important to back up these data sets in a way that’s distributed so that even if one of them goes down, the data can still be available at another institution. That’s just one of the pieces, because what’s really important is that people can actually use that data. People all around the world use data that is generated by the United States’ funding apparatus, scientists and government.

We’re talking about climate data sets, astronomy datasets, anything. The versatility of the platform allows for an efficient way to spread information, which is why libraries are getting on board. We want to make it really easy for people to describe their data sets, and we want Dat to be a really good tool for doing this. That’s the goal for the next few months.

What we’re trying to do is collect data sets from all around the world to make it easy for anyone to publish them. We’ve implemented a new system with “infecting or “injecting Dats into existing repositories. You just have to have a series of metadata files. What we want to do is take data sets that already exist on a lot of these international data repositories and turn them into Dats.

People can download the data and access Dat from the website to get updates, access data history, and more – even if it’s in the old HTTP repository. We’ve got some pretty exciting stuff coming up, and we want to do that for repositories all over the world.

What other hobbies or interests do you have outside of programming?

I play trumpet. It’s a tough instrument to play, but I’m glad I stuck with it.

Karissa plays trumpet

Besides that, I work with the Debt Collective, a debtors’ union that fights against predatory lending in the United States. In terms of basic needs like education and healthcare, the debt financing system should definitely be changed. It is gratuitously difficult to live in this system without getting debt. I like their mission. They help people all over the country who are in dire situations in disputing their debt. I helped them build their website a little bit and did some technology consulting for them.

This project is made possible with sponsorships from frontendmasters.com, egghead.io and Microsoft Edge.

This post was originally published on betweenthewires.org

Between the Wires: An interview with entrepreneur and founder Charlie Cheever

Vivian Cromwell — Wed, 31 May 2017 03:53:58 +0000

Charlie Cheever, taken by Vivian Cromwell

I interviewed Charlie Cheever, who is the founder of expo.io. Expo’s mission is to let web developers build truly native apps that work across both iOS and Android by writing them once in just JavaScript. It’s open source, free and uses React Native. Previously, Charlie co-founded Quora and worked at Facebook on the platform team.

Tell us a little bit about your childhood, and where you grew up.

I grew up in Pittsburgh, Pennsylvania. I always liked computer games. One day my dad took me to the library when I was in 3rd grade, I grabbed a book named How to Make Your Own Computer Games. The first page said you have to know how to program in BASIC, so I went back and got another book about programming BASIC. I would go to school and type in the programs from the book on Apple II, slowly I started to make little changes to them.

I really liked making things with computers or calculators, and sharing them with people. It was pretty easy for me to know what I wanted to do with my life.

When I was in high school, I went to this summer program at Carnegie Mellon called Andrew’s Leap. It’s a free summer program that teaches you basic complexity theory and some programming. It was really fun. I really liked making things with computers or calculators, and sharing them with people. It was pretty easy for me to know what I wanted to do with my life.

Eventually, I went to Harvard and studied Computer Science. Then, I went to work at Amazon, one day I got a recruiting email from Facebook because I’d been a teaching assistant for a course that the founders had taken. I ran into two friends from school, David Fetterman and Andrew Bosworth, they told me they were leaving Microsoft to go work at Facebook. I thought if they were doing it, maybe it was a good idea. So, I emailed their recruiter, I got the job and started work in 2006 as a software engineer. At the time, Facebook was only about 10-12 engineers. I started the Facebook developer platform, which was a pretty successful gaming platform in a lot of ways.

I ended up leaving Facebook to start work at Quora. I really wanted to start a company. Even though Facebook was super fun and a great place to work, it felt like the moment was right for me to start something on my own.

Then, I started Expo about two years ago.

What’s Expo?

Expo logo

Expo is a free open source platform that enables web and mobile developers to quickly build and iterate on high quality native apps that work across both iOS and Android. Expo’s core is built around React Native, a technology invented at Facebook and used in parts of the main Facebook app, Instagram, and many more. React Native is also trusted by other large companies like Airbnb, Walmart, and Tesla.

With Expo you can write JavaScript for components and APIs that are available on iOS and Android with native performance. Expo SDK includes runtime, React Native APIs, and additional components such as audio, video, authentication, notifications and more. This means you can spend more time writing only JavaScript because of more code sharing between iOS and Android.

XDE (Expo Development Environment) takes care of React Native releases for you. You can stay on an old version if you like, or upgrade to a new one without worrying about breaking changes or rebuilding your app binary.

You can share an app you’re building with a simple URL, which can be opened from the Expo client app. When you’re ready to ship to the app store, just compile your app into binaries and deploy. You can also update your app in seconds “over the air (yes, this is allowed by Apple!)

Expo also provides a browser based tool called Snack, which is similar to JSFiddle but for React Native apps. You can go to snack.expo.io, and start prototyping. You can preview it in your browser or open on the phone. When you are ready, share with your friends and coworkers with a simple URL.

Snack in action

All of this is possible through the Expo client because the app built with Expo uses the same native runtime. Most of the time, you won’t need to install Xcode or Android Studio on your machine to use Expo. But, when you need to extend it with your own native libraries, you can always detach to ExpoKit and open your project in either iDE.

Expo project lifecycle.

We are passionate about making mobile development easier and accessible for everyone. You can find out more at expo.io.

What motivated you to create Expo?

Then React Native came out and it was almost exactly the same except further along and with a team of 20 behind it instead of two. We basically decided to stop working on Ion and started working on everything else we wanted to build off of React Native.

Our mission, at a high level, is to basically shorten the distance between the vision in someone’s head and their completed product.

When I was working at Quora on mobile apps, it took nine to ten months to complete an app even when we had great developers and designers working on them. We had to use webview to make everything cross platform, but they always felt a bit off. You can’t quite get the performance ace, and you can’t quite do the cool animations that native apps can do. That felt fundamentally backwards after doing web development for almost my entire life. Somebody had to fix that. So, I took some time off and started working with James Ide to explore ways we could make it better.

We started with HTML5 and web technologies, but it was inherently limited–we didn’t think it was good enough. But we believed deeply in the web paradigm, which was a big step forward in terms of productivity. We built this whole system called “Ion”, which was a stupid name because there was already Ionic framework.

But we didn’t launch Ion, we just used it to make a few apps. Then React Native came out and it was almost exactly the same except further along and with a team of 20 behind it instead of two. We basically decided to stop working on Ion and started working on everything else we wanted to build off of React Native.

Often one of the most rewarding moments for a startup founder is when your product is used in an unexpected or innovative way. Does that happen with Expo?

If you go to the Expo client app, there is a new project tab and it shows you the last ten items that

someone hit the “publish button on. It’s really cool, now that there are enough people using it you’ll usually see at least 1-2 interesting projects. It is exciting to find stuff that I had no idea people were building with Expo, like an electronics store in Thailand.

Walk us through a day in the life of building expo.io as the founder.

If you count me, we have ten people now. Most of them are in the Bay area except Brent up in Vancouver and Ben in Seattle. They come down to visit every couple weeks. They like where they are, and we like them, so we make it work.

Slack is the center of gravity for our team because we are distributed. We also ended up working a bit closer with people who are developers on our platform, some of them are contractors on specific projects. For example, Satyajit who lives in Bangalore, helped us out on Sketch. This means we have a lot of flexibility. Everyone works different hours and makes a lot of local decisions without having to consult a product manager.

Why is it difficult to make money with developer products? How does Expo approach this?

What makes sense for us is not to make money from the platform itself…If we can help people build sustainable businesses on top of our platform, then there are plenty of ways that we can sustain ourselves.

There are a few reasons why it’s hard to make money with developer products. One is that there are a lot of people motivated to make development processes or tools better. It’s similar to content, which is also hard to make money from, because a lot of people are willing to write it for other reasons like branding or reputation.

Developer tools often fall into that category. There are a lot of people who like to make them or make them in the open source way, perhaps some of them want to make open source tools to make a platform more popular or for recruiting reasons.

What makes sense for us is not to make money from the platform itself. It is really important that the tools are open source because the kinds of developers that we want to attract, and the kinds of tools that we want to use, are open source. You can figure out what’s going on in them and you can send patches if there are problems. You can do a security audit if you are worried. It would be weird to charge for any of that.

Part of our mission is to open up mobile software development to kids. Sometimes I think that if I were 13 or 14 right now, and my friends and I were all sitting around on our phones, I’d be thinking about ways I could build some cool stuff for us to play with. But if you’re charging money for that, you’re excluding kids who are eager to learn. They don’t have credit cards, and their parents are unlikely to give them money for something they may not understand.

In that way it makes sense for me, it’s a business model similar to Twitch and YouTube. YouTube doesn’t charge people to upload videos, and Twitch doesn’t charge people to stream. But if they help you make money, they can take a cut of it.

So, I hope if we can help developers monetize, then there will be a way for us to take a small cut. But for the most part I want it to be free and open source forever. If we can help people build sustainable businesses on top of our platform, then there are plenty of ways that we can sustain ourselves.

Can you talk about one or two really difficult periods you had to go through as you were building Expo?

The kind of people that work in the React Native repo, are the kind that care about how mobile apps get built, and the mobile development. It resonates with them when Expo’s vision is to make building mobile software easier, faster, and more accessible. They are often the most thoughtful ones about the way they do development.

I feel like there will be really difficult times ahead, but we are passionate about our mission so it just hasn’t felt that difficult so far. I knew this was gonna take a long time and there were going to be lots of challenges ahead, but over the last few months we have executed very well, and put out some good pieces of the puzzle that made our messaging more clear.

Part of this is because there are a lot of ways that developers get into different states, so we have answers to a lot of those questions, but then, it’s hard to explain everything we do. If you started a project with React Native, you get this like IOS and this Android folder with all of your JavaScript source, if you didn’t write any native IOS or Android code, and you just have JavaScript, we have a convergence script. It’s a little rickety because there are so many different ways you can make changes to your project.

Our big focus now is to help new people come on board.

We have a great team and we work together pretty well, so it has been fun. A lot of the people on our team are active contributors to React Native open source project, and working at Expo is a way to just be able to work in that space completely. The kind of people that work in the React Native repo, are the kind that care about how mobile apps get built, and the mobile development. It resonates with them when Expo’s vision is to make building mobile software easier, faster, and more accessible. They are often the most thoughtful ones about the way they do development.

What’s next for Expo?

We are going to work really hard to become the most standard, straightforward, and best way to start any new React Native project. We also want to add more native module capabilities.

I posted 10 reasons to use Expo in the React Native community group and one of them was that Expo is just regular React Native, plus some other stuff. For example, one of the biggest challenges for React Native developers is not only doing regular upgrades themselves, but a lot of the third party modules don’t get updated and stick on an older version, such as some really custom bluetooth or background locations. Because the React Native library actually puts out new releases every few weeks, it has been difficult for a lot of native libraries to keep up with the pace of the changes.

Another focus for us over the next year is to give people the building blocks they need for mobile. One thing I don’t love about the web, perhaps it’s because the web started as a way to make documents, is essentially text that flows, and maybe some images in there, plus rectangles to lay it out, and the forms. That’s great, but it was what the world needed in 1994.

If you think about what people love to do on their phones, it’s a lot of images, videos, streaming, swiping, likes, and playing sound. It’s a much more tactile and multimedia type of experience. We try and be the right building blocks for people who want to make mobile software. We may not have all of the answers today, but that is the direction we’re aiming for this upcoming year.

What are some of your hobbies or interests outside of your startup?

Literally, I’ve been listening to a lot of Ryan Adams non-stop for the past two years, and I think I’ve been getting a little more politically involved than I have in the past, just because it feels important this year in a way it hasn’t for most of my life.

I grew up in Pittsburgh, so I l am a Penguins, Steelers, Pirates fan. Penguins won the Stanley cup last year in San Jose and I got to see it happen, it was cool.

Pittsburgh Penguins

This project is made possible with sponsorships from frontendmasters.com, egghead.io and Microsoft Edge.

This post was originally published on betweenthewires.org

What’s New With Between the Wires

Vivian Cromwell — Tue, 30 May 2017 22:55:22 +0000

It has been seven months since Preethi and I launched “Between the Wires”, an interview series featuring makers of developer products. As we mentioned before, this is a passion project. We’ve loved every moment of talking to the founders and developers, and hope you’ve enjoyed the stories too!

Time to give a quick update:

So far we have conducted seven i nterviews and covered builders in the areas of cloud, JavaScript framework, Data Visualization, and web performance.
We have a total of 100K views with an average read ratio of 30% to 60%. Hacker News and Reddit are our most significant drivers of traffic.
We raised over $3,500 on OpenCollective to cover costs such as transcription and editing. Thanks to everyone who donated, and our amazing sponsors: Microsoft Edge team, Frontend Masters, and Egghead.io.
We have moved our content from the current Medium publishing platform to WordPress, self hosted and deployed on Google Cloud Platform. The articles are still syndicated to Medium, though! This is for SEO reasons which is explained well in this article.

Now here comes to some exciting announcements!

Between the Wires is partnering with Free Code Camp and The Practical Dev to bring our stories to their users. That means all Between the Wires interviews will be syndicated to all three publications and made available to their users. This makes sense to us–Preethi and I only have one goal: to inspire others through the stories of founders and builders. Free Code Camp and The Practical Dev have the right audience. We’d also like to include a special thanks to Quincy Larson and Ben Halpern for the amazing opportunities!
Secondly, we are also expanding the scope of the interviews to cover developers, designers, and everything in between. With new tools such as Zeit, Figma, and React Sketch App, which help lower the entry barriers for designers and developers, we feel strongly that the two fields are merging. Preethi and I have backgrounds in engineering work, and have both dabbled in the design world, so it seemed a natural fit to cover both.

As always, please send us feedback at twitter.com/betweenthewires and suggest a candidate.

Stay hungry, stay foolish. Keep on building.

Preethi and Vivian

This post was originally published on betweenthewires.org

Between the Wires: An interview with Microsoft Edge PM Nolan Lawson

Vivian Cromwell — Tue, 07 Mar 2017 05:01:34 +0000

Between the Wires: An interview with data visualization scientist Irene Ros

Vivian Cromwell — Wed, 22 Feb 2017 04:55:23 +0000

I am the founding Director of Data Visualization at Bocoup where I’ve led visualization projects with partners like Google, The Guardian, The World Economic Forum, and Harvard Medical School (HMS) LINCS Center. I am also the Founder and Program Co-Chair of OpenVis Conf, a 2-day single-track conference about data visualization on the Open Web, entering its 5th year.

website: http://ireneros.com

twitter: https://twitter.com/ireneros

Github: https://github.com/iros

Tell us a little bit about your childhood and where you grew up.

“I was the kind of kid who enjoyed building dollhouses but not really playing with the dolls.”

I was actually born in Kiev, Ukraine. When I was six, my parents moved to Israel where I then lived for the next ten years. It was a bit of an accidental move, but then I came to the States when I was 16. Both my parents always worked so I was very much on my own most of the time.

(Irene with Ded Moroz, Russian SantaÂ Claus)

I loved math and science from a very young age and did little science experiments when I was home alone. It’s amazing I didn’t burn the house down. I was the kind of kid who enjoyed building dollhouses but not really playing with the dolls.

Tell us a little bit about your first programming experience.

My first programming experience was when I was nine. I had a cousin who was really into computers and I’d always hover around him whenever we visited. My parents, bless their hearts for recognizing that computers were going to be something big, spent an awful lot of money they barely had buying me one. This was before Windows even existed. All I had was Norton Commander. My cousin gave me this “BASIC Programming” book, and that’s how it all started.

I remember one of the first programs I wrote in BASIC. It could output the words of the Happy Birthday song. I was really excited.

That was the first memorable project I can think of. My high school in Israel had a really wonderful science and technology program, so I started taking computer science classes as early as ninth grade. As a consequence of starting so early, programming became a way of thought, a way of problem-solving for me. It was just a tool. I was very happy to be exposed to that early on. I think it’s still why I really love certain aspects of programming such as code refactoring, architecture and organization.

How did you start data visualization work?

My interest in data visualization started before Bocoup.

I studied Computer Science at the University of Massachusetts, Amherst and afterwards joined IBM as an engineer. I really loved my college experience, but it was very heavy on theory and algorithms, and it didn’t occur to me that making something beautiful and engaging was part of being a computer scientist.

Then one day in 2007 I just happened to go and see a talk at IBM, by Martin Wattenbergand Fernanda Viegas, who ran the Visual Communication Lab at IBM Research’s Collaborative User Experience group. During the talk, they showed this project called Many Eyes, which was really ahead of its time. It was like YouTube for data visualization. You could just upload your data and pick a visualization method, then you could share it with people by sending them a link. It had everything we expect of a modern system like thatâ€Š–â€Šcommenting, remixing, saving and sharing a particular stateâ€Š–â€Š10 years ago.

Many Eyes project from IBM,Â 2017

I was blown away because it was something I had never seen before. I ended up working with Martin and Fernanda for three years at IBM research and that was my gateway to data visualization. I am self taught in this field, but with their support and the support of other colleagues, I’ve learned a lot and appreciate the time they’ve invested in me.

From the get-go, we were creating things for the web, but it was challenging to navigate open-source licensing process at IBM at that time (IBM has come a long way since). I became comfortable enough looking through open source libraries, fixing issues locally or writing extensions, but I wasn’t quite ready to make PRs yet (Github barely existed then). It seemed like a distant world that was reserved for experts. I wanted to become that expert and really fell in love with the importance of open sourceâ€Š–â€Šit allowed me to bring my ideas to life and I wanted to be more involved.

One day I Googled â€˜Open Source Boston’ and Bocoup came up. I applied and here I am.

(Fun fact: http://boazsender.com/2012-10-30-how-bocoup-got-its-name.html)

What was data visualization like five years ago?

“Even though â€˜data science’ is often used as a buzzword, it’s been great for raising awareness about the importance of thinking more critically of our data through applying techniques such as statistical analysis, predictive modeling and machine learning to name a few.”

When I started at Bocoup, the D3.js library didn’t exist. It was before every news publication was trying to make interactive content, except New York Times, who really led the charge on this front.

(NPM by numbers by Irene, using d3js. source: http://npmbynumbers.bocoup.com/)

D3.js is based on a seminal book in our field called the Grammar of Graphics, which provides a fundamental way of breaking down and assembling data visualization through primitive “components”. It’s been an underlying principle that many successful visualization libraries are built upon, such as ggplot in R. D3.js changed the field in a very fundamental wayâ€Š–â€Šit has enabled visualization creators to be incredibly creative in their work and make interactive content quickly.

When I started working with data visualization, the term “Data Science” didn’t exist either. That resulted in a lot of visualizations showing really basic aspects of the data: counts, averages etc. Even though “data science” is often used as a buzzword, it’s been great for raising awareness about the importance of thinking more critically of our data through applying techniques such as statistical analysis, predictive modeling and machine learning to name a few. Data Visualization has been an important part in this shift, both because it enables data exploration and improves the communication of final resultsâ€Š–â€Šthe more we understand our data, the better questions we can ask of it. The more interesting the questions, the more interesting the answers, and the more interesting our visualizations can be. I would say that no one should be creating data visualization without having some basic understanding of statistics at this point.

What is one of the most exciting data visualization projects you worked at Bocoup?

There are so many!

One of my favorites is a recent collaboration with Measurement Lab and Google Open Source Research team. Measurement Lab Visualizationsprovide a way to explore the largest collection of open Internet performance data on the planet. The data is open, free of charge, and comprises the largest open Internet performance dataset on the planet. Measurement Lab also offers visualization tools, so people can make sense of Internet performance across time and space. We partnered with them to build the next generation of their visualization tools.

(https://bocoup.com/work/measurement-lab)

I love their mission and their amazing dataset, which goes all the way back to 2009 and offers incredible international coverage. The way it works is that anybody can run a test through their website. If you are in the United States and a few other countries, if you search for “speed test”, you will actually get an interface that will let you run a Measurement Lab test right away. Their methodology is much more effective and accurate than most other speed tests at this point.

We were really excited because they came to us and said, “We have this huge dataset and we want people to explore it in a pretty dynamic way, they want to be able to look at different time spans, locations or service providers.” It is a really interesting design problem because there were so many different types of stakeholdersâ€Š–â€ŠMeasurement Lab’s data has been used by political advocates and internet researchers alike, with very different goals. Because it is so large, it’s really hard for people to work with the raw dataâ€Š–â€Šthey need infrastructure to process it and a lot of technical knowledge. We were grateful to Google who sponsored the project, and gave us unlimited access to their infrastructure to take these hundreds of millions of tests, and turn them into something useful and consumable on the web.

“I think it really captured a lot about our media culture, how we perceive gender and the way that we choose to represent it.”

The other project I have to mention is called Stereotropes. It was a team passion project that we did a few years ago. We were (and still are) really interested in text analysis and visualization. We came across a community called TV Tropes that catalogued and defined tropes in TV and film. Most interestingly, they had two list of tropes that were primarily associated with Male and Female characters, which we then used to try and gain a better understanding of how our culture defines male and female roles through adjective use in those tropes’ descriptions.

We built a really fun exploratory tool called Stereotropes that lets you explore those tropes. For example, people use words like â€˜pretty’ to describe a lot of female characters or â€˜strong’ to describe a lot of male characters. I think it really captured a lot about our media culture, how we perceive gender and the way that we choose to represent it.

(source: http://stereotropes.bocoup.com/)

I really love this project. We tried to encourage objective conversation on gender representation. I care a lot about the subject being a woman in engineering. We really wanted to provide our audience with a tool they could explore themselves to see some of these differences, and similarities!

We managed to engage a lot of people who were not related to engineering or data visualization. It’s something I always strive forâ€Š–â€Što get somebody who really does not understand technology, to care about what I’ve made.

You started OpenVis Conf 5 years ago, can you tell us about it?

OpenVis Conf was very much a response to my personal experience getting into this field. Because I was self-taught, I went through some struggles that I felt were unnecessary for other people to experience. For example, I saw a lot of beautiful work made by people I admired, but had no idea how to make it. I was inspired, but also unsure how to create similarly good work. I started OpenVis Conf with the goal of creating a community space that embodied a teaching spiritâ€Š–â€Ševery talk our speakers give is intended to teach our audience something. We want people to leave that conference with 100 ideas that they know how to pursue further. Our speakers have really embodied this value over the years and I’m really proud of the programs we’ve put together.

(Irene at OpenVisÂ Conf)

I’m also really proud of our diversity efforts every year. Myself, my program co-chair Lynn Cherny, and our Programming Committee spend dozens of hours soliciting and reviewing talks from our community. We try very hard to create a diverse cast across many definitions of diversity: age, gender, race and sexual orientation. It’s a challenging task, but five years in I can definitively say it has only made our programs stronger every year. When I see an all white & male line up at other conferences, I cringe because I know they just aren’t doing the work.

This year is our 5th anniversary and we’re putting together a huge celebration. We just released our program, and we really can’t wait for the incredible lineup.

https://openvisconf.com/

Can you talk about a difficult period you’ve had to go through, and how you overcame it?

“Overtime, especially now, I realize what a privilege that wasâ€Š–â€Što be able to throw your work away. I realize that sometimes building something is just another step towards making something else.”

One of the biggest struggles I’ve had as a young developer, is that I was very attached to my code. I felt like my code and the things I made were a reflection of me. I wasn’t able to evaluate objectively: “Is this thing good or is this thing bad?”

My team leads at the time did an amazing job of helping me navigate that question. I’d build some kind of prototype and I’d spend weeks doing it, and then they would say: “I don’t think this is working, let’s just try something else.” And I’d just be so hurt, I’d take it personally, and it felt like failure.

Overtime, especially now, I realize what a privilege that wasâ€Š–â€Što be able to throw your work away. I realize that sometimes building something is just another step towards making something else. There is nothing I love more than just prototyping something and having someone call out that it’s bad because they see something that I don’t. As a result, I get to go and improve it and make something better. As a developer, it’s hard to step out of your bubble and not treat your code as something precious, but code is just a tool to get somewhereâ€Š–â€Što build something useful or solve a problem. In and of itself, it’s nothing.

I really enjoy doing design activities as part of the projects we work on at Bocoup, because it’s really important to generate lots of ideas and then throw lots of them out. I constantly throw code away. I’ve developed a certain lack of attachment to the code that I produce. If someone comes to me and says, “There is a better way to do this.” I’ll just say, “Thank you,” and be very happy to start anew or refactor my code.

It was a painful lesson to learn but it really frees me from being locked into a set of tools and a set of practices. The moment I could let that go, I really grew as a developer, especially combined with asking for help and feedback.

It’s funny because I often find that folks who are newer to engineering ask a lot less questions than those who have been in the field much longer. Now I can ask five questions a day of my teammates as I’m working on something and it’ll take them two seconds to give me an answer and I can move on with my life. Newer engineers tend to take much longer to really work through something, often on their own. While it’s admirable, it’s not a good use of their time. It’s something I really watch out for during our interview process, for example.

I think that was a pretty big eureka moment for me. It wasn’t a moment, it was a long, long process.

How do you help junior developers overcome this?

“I’ve had a lot of failures just like everyone else, but we’ve built a company where failure is an important part of our culture.”

First, I think it’s really important to set up the team and our clients to understand that failure is an expectation. We strive to fail fast, but it’s really important that we iterate on an idea and find the right answer. To do that, we designate time specifically for design, brainstorming and prototyping. We meet often as a team to offer critiques of our work to each other, and we spend a lot of time discussing the work of others to learn what works and what doesn’t.

I think working as a team in this way has allowed us to create a safe space for failure. I don’t even think we notice it anymore. We might generate 30 ideas for a project and it’s obvious not all of them are going to make it, and there’s always some contention around refining a design, but the goal is always shared. We want to make something great and we’re in this together.

Establishing a culture of feedback is something we take very seriously at Bocoup. I’ve had a lot of failures just like everyone else, but we’ve built a company where failure is an important part of our culture. We work together to Identify it, move through it, and support each other in that process.

How do you balance between open-source and monetization for your data visualization projects at Bocoup?

Bocoup is primarily a consulting company. People come to us to help them solve their problems using open technology and practices. We build tools, websites, and applications. The same is true for my team, people come to us either because they need help understanding their data or they need help with designing and building the right visualizations to communicate something or enable and engage their audience.

(Bocoup teamÂ pic)

I would say modern software engineering requires the use of open source tools. There are rarely commercial equivalents of equal quality. Most of our clients understand this, and their engineering teams certainly do. To us, using an open source stack enables our clients to build systems that can be maintainable and extendable, that can have a community and allow their engineers to feel supported.

“I think open source isn’t just about open code. It also comes down to using more open practices around the way your team works.”

In terms of our own contributions, as an engineer you always have the drive to modularize your code and to be able to make reusable components. That naturally leads to being able to release some part of your work as separate open source components, or contribute some patches back to an open source project. My team has worked with D3 extensively in our visualization projects, contributed integral community tools, the current D3 logo, and have created a framework for organizing visualization code made in D3 with our d3.chart to demonstrate the importance of modularity.

I think open source isn’t just about open code. It also comes down to using more open practices around the way your team works. Many of us have worked on big open source or client projects at Bocoup. When you work in such a distributed way, with a lot of people across the world in different time zones, you have to become really good at planning, documentation, coordination and communication. We bring a lot of those practices to existing teams to try and help them be more effective.

What are the challenges today in data visualization field, both from the technology point of view as well as the community?

This isn’t a new problem, but a challenge we will always face: there is a tension between aesthetics and usability, and how to incorporate both is a challenging question. We have seen lots of examples of things being built that go too far one way or the other, but we have lots of conversations as a community about that. It’s a balance we will continue to navigate.

There is also a data literacy question. Everybody wants to make a new visualization style that’s never been used before, and it kind of blows everybody’s minds. That’s really cool, but you are probably going to impress 200 people in the field and then confuse everyone else who, as a consequence, won’t engage with what you’ve made. Are the things that we are creating working? Are people understanding what we are making? Are they actually engaged with what we are trying to say? Is what we’re making helpful to anyone?

We don’t have a great way of evaluating what’s working on a system level. We have lots of ideas on how to study small components (such as specific visualization styles etc.,) but not larger systems. I think that’s an interesting problem for us to solve as a community. We also don’t have a great way of determining when something we’ve made has failed. I think about that often and would love to see that debate.

what other hobbies or interests do you have after programming?

Actually I’m a singer; I’ve been singing for my whole life and I really enjoy it. I also paint some. I enjoy creative pursuits that may or may not have to do with computers. It’s good to recharge.

This project is made possible with sponsorships from frontendmasters.com, egghead.io and Microsoft Edge.

Our sponsors.

This post was originally published on betweenthewires.org

MooTools

Preethi Kasireddy — Thu, 02 Feb 2017 04:47:31 +0000

Introduction

If you were doing web development in 2009, MooTools might very well not need an introduction! MooTools was a well-known JavaScript utility library for building “powerful and flexible code with its elegant, well documented, and coherent APIs”. Its core contributing team was made up of a brilliant set of developers, and we’re lucky today to be speaking with three of them:

Formerly core contributors to MooTools, Sebastian MarkbÃ¥ge, Tom Occhinoand Christoph Pojer are active and vibrant contributors to the Reactcommunity today.

Can you tell us a bit about yourselves and how you each got into programming?

Sebastian: My dad used to code games for the Commodore 64, and I would watch him, and tweak them. I was only ten when I really got into programming. I started programming games and doing small lookup databases through Qbasic for MS-DOS.

Tom: When I first got a computer I was running Windows 3.1, and then Windows 95. I became obsessed with re-skinning windows. I wanted my computer to look different, so I figured out how to resource hack, and change the images. I started with MS Paint and made the buttons different colors. Then, there was this program called WindowBlinds that got me into creating my own skins. Eventually, I discovered HTML. It was so much easier, and better.

Christoph: So, I started programming when I was about 12 trying to learn how to make websites. And then, I think when I was 14 or so, when a friend in middle school was playing a game online and I bet him that I could make it, and make it better. After that, I spent basically every day for four weeks building an online game. It was motivating, building small games that a bunch of people played afterwards.

Interviewer: Interesting! Games seem to be the theme here, especially for people who got into programming early.

Tom: Yeah. You had to edit HTML in a Notepad and make a .html file. There was no syntax highlighting or anything like that. I didn’t know what valid markup was until Netscape came out in the 1990s, like 1997.

Netscape

Â Tom: I think it was probably ’98 for me if I had to guess because I was 13. It seems like it was earlier.Christoph: Exactly! I made websites and someone told me that a website I made didn’t work in Firefox. I didn’t even know what Firefox was. That was 2001.

Sebastian: Yeah, ’93 is when I started. I started withNetscape 2 I think. CSS didn’t exist at all. HTML existed, but JavaScript was not on the scene yet, so you couldn’t actually program much on the client. You had to do everything server-side. Everything was Perl and CGI.

Tom: You’re a dinosaur.

Going back to the origin, do you know why Valerio started MooTools, and how it got started?

MooTools inÂ 2007

Tom: Valerio always gets frustrated when he sees something that can be done better. He was using Prototype, and more specifically, script.aculo.us. There was a common issue where if you created a click event handler to start an animation, and you clicked it twice, it would start the animation overâ€Š–â€Šbasically firing off new animations every time without the ability to choose to either resume, enqueue another, or replace.

It actually wasn’t MooTools that he was creating at first. His whole premise for Moo.fx was just to be able to retain this instance, and be able to do something better than what Script.aculo.uswas doing by default. Prototype was pretty big at the time, so he created prototype.lite.js, which was basically just the class system plus a couple of utilities. Eventually, he built Moo.fx on top of that. It must still exist somewhere today, but that’s how it was born. From Moo.fx, there was a foundation for an alternativeâ€Š–â€ŠPrototype plus Script.aculo.usâ€Š–â€Šwhich became MooTools.

Tom (left) and Valerio (right), the original author of the MooToolsÂ library

How did each of you start contributing to MooTools?

Tom: I was creating a photo album app for a photography studio, and we needed a way to sort the photos. At the time, MySpace had a top eight grid. They implemented it as a one-off, and we wanted to build better support for that.

Script.aculo.us had something similar built in, but I basically expanded MooTools’ drag and drop library, and created Sortable.js. I showed it to Valerio, and he decided it should be in the core of MooTools.

Interviewer: How old were you? Since there was no Github back then, how did you even get to the repo?

Christoph: We used Trac and Subversion.

MooTools Trac

Tom: Gaining access to Trac and Subversion was a big deal. When Valerio asked me to contribute, there were no code reviews. You just checked it in.

Christoph: I had a similar experience as Valerio. I didn’t like Prototype and script.aculo.us. I saw Moo.Fx and then MooTools come out. It was in September of 2006â€Š–â€ŠI was 16 or 17.

Christoph with dread locksÂ ðŸ˜†

I was in my prime teenage years and I was kind of a rebel. I wanted my code to be perfect, and MooTools was just written so perfectly. It was so small but did everything I ever wanted. I was very idealistic.

Tom: Do you remember what your first contributions were? I don’t really remember.

Christoph: I started using it in early 2006 for games. I literally built a German version of Facebook for my friends, even though I didn’t know what Facebook or MySpace were. Then I built some other games with it. I wasn’t contributing much.

I didn’t know English very well, but was trying to learn. I became a core contributor in 2009, almost at the exact time Tom was hired by Facebook. He basically told us to take over after that. That’s when I started contributing to the core, and then we started doing a hack-a-thon in London, where we met up once a year. That was pretty cool.

Sebastian: I came in around the same time as Christoph, but my experience was different. It happened during my second pass into JavaScript. I started with JavaScript in the late ’90s, when it was pretty much useless. Then it had a resurgence around 2005 and I started moving back to the client after having spent five years on the server only. I was looking at all the frameworks, and I needed more help. I wanted to understand more, and MooTools helped me learn how the language worked. It was written in a very clean way, you could study the code base itself, but I was frustrated with some of the details. Unlike these guys, I was actually building pretty complex apps at the time. I was building this complex WYSIWYG editor.

Tom: I was building a CMS. It wasn’t that trivial, come on.

Sebastian: I made a rant on the public mailing list. There were two mailing listsâ€Š–â€Ša private internal list, only for developers, and the public one. On the public list, there was the guy named Aaron Newton, and he was kind of the dad of MooTools. He was the adult because he was actually building startups at the time, and was trying to create a community because he understood the value in that. He spent a lot of time in the public forums helping newcomers, and bringing them into the inner circle. I made these long rants on the public mailing list, and he invited me into the closed circle.

Tom: I think we all started out on the forums. The first step was getting moderator rights on forumsâ€Š–â€Što be able to close topics and answer questions authoritatively. We had little icons next to our names indicating we were moderators. My first contact with Valerio was when he reached out to thank me for helping out with the forums. From that point on, I started contributing to the code.

Christoph: That’s funny because I still have that email. My first interaction with Valerio was not actually about MooTools itself. He had built this bundler or compression thing that I really needed, and there wasn’t really anything else like it. We used to just ship like 30 JavaScript files, and this MooTools website had this bundler where you could concat your files together.

The MooTools builder. So before its time.

Tom: So before its time, man, the MooTools builder. So before its time. You selected the things you wanted, and it created a customized script for you. You would just save the file and put it on your web server. It was amazing.

Sebastian: It was ingenious because there was no common JS.

Tom: There was no nothing. It was all globals.

Sebastian: There was no way to tell from anyone’s code base what modules were required, so you had to check it yourself, but because it was just a website, you could do that easily without trying to get a standard around it.

MooTools has such a distinct and memorable brand around it. What were some of its core values that made it stand out initially, and why do you think people remember it so positively today?

Sebastian: We valued the readability of the code base a lot, because that’s how we learned.

We saw jQuery as the opposite, where everything was inline. There were no reusable abstractions, and they tried to support every use case there was. Ultimately that made the code more difficult to understand and maintain. That’s why we chose not to support as many use cases.

Christoph: It was interesting because we were all very like-minded. We were building something great, but we didn’t do any outreach. We attended maybe 3–5 conferences over the course of seven years. We didn’t really build it for other people. We were trying to build the perfect framework, something that we could use. It might not be the best way to grow an open source project, but we were just our own little community trying to build something perfect.

Sebastian: There was also the chaining. The chaining was very explicit, and everything was designed around readability and grammarâ€Š–â€Šthe chaining should mimic an English sentence.

Tom: We constantly iterated to refine and improve the API. One of the guiding principles was that code built on top of MooTools should be readable, easy to understand and easy to extend. We had a very strict style guide in our heads that we all followed. It was almost academic in a sense.

Christoph: I think academic is a really good description. We were so focused on the API design, rather than building something that people could actually use and adopt.

MooTools team hackingÂ away

What do you think was the most impactful or important thing that you learned while working on MooTools?

Collaboration, like we said, is really important to create a very tight teamâ€Š–â€Šone that shares the same values in terms of how you write code and what you should prioritize. That’s one thing we mastered that allowed us to move forward.

Sebastian: Collaboration, like we said, is really important to create a very tight teamâ€Š–â€Šone that shares the same values in terms of how you write code and what you should prioritize. That’s one thing we mastered that allowed us to move forward.

On the other hand, pragmatism is something we didn’t do well, but we’ve since learned.

Christoph: For me, because it was the first open source project I worked on, I learned a lot about being involved in the community and working on open source. That experience can burn you out. People hate on you for making changes to the API that they don’t understand, or you have to deal with people questioning you all the time. But, getting to know the community, meeting people I worked with everyday, that was one of the best things for me.

Tom: For me, learning JavaScript was huge. There was a ton of experimentation, trying to solve problems in a cross-browser way, and I felt like I almost carried too much weight about cross-browser incompatibilities. I feel like I really learned JavaScript and functional programming concepts in a way that I couldn’t in school.

We got hired because we could solve real business problems using JavaScript. JavaScript was looked down on in the beginning, and had stagnated, and had performance problems, but it let us build something productive.

Sebastian: I think that’s a really underestimated point in the last decade. There was a growing community of kids like us with no prior experience, and we got hired because we could solve real business problems using JavaScript. JavaScript was looked down on in the beginning, and had stagnated, and had performance problems, but it let us build something productive.

Meanwhile, there were a lot of academic projectsâ€Š–â€Šthe common wisdom was that they were going to succeed. That these business tools backed by big enterprises were going to replace JavaScript. But that’s not quite what happened. It goes to show, you have to pay attention to what people are drawn to. They’re drawn to it for a reason.

MooTools was probably one of your first large open source contributions and projects as well. How would you say it impacted your career?

Tom: For me, it was pretty easy, actually. Somebody was organizing a conference in the Netherlands called Fronteers and they used and loved MooTools. So they reached out to Valerio to see if he would speak about MooTools and object-oriented JavaScript. Valerio referred them to me. I was pretty young, in my early 20s, and I had never spoken at a conference. I didn’t really know what I was talking about. I thank my lucky stars everyday that it wasn’t recorded because it was so embarrassing. As a result, though, a recruiter from Facebook contacted me, and said they were trying to do more with JavaScript and asked me to come in for an interview.

Tom at React.jsÂ Conf

Christoph: My story is pretty similar to Tom’s. I also did a public talk. It was really difficult because while I was used to public speaking, I was not used to public speaking in English in a foreign country. I was not as lucky as Tom, my talk is still online. I used to have a really heavy, Austrian, Arnold-Schwarzenegger-like accent.

After the talk, a Facebook recruiter reached out, and I ended up doing an internship at Facebook. Tom was actually my intern manager, so that worked out pretty well. Then, I had to go back to University and finish my degree before I could join Facebook full-time. By the time I came back, there were all these MooTools people like Sebastian working full-time at Facebook.

Sebastian: I was working in Europe. Thomas Aylott was at Cloudera and then worked at Sencha in the Bay Area. He started talking to me about moving out here. At the time, I didn’t wanted to move to California, especially not the Bay Area. But, another MooTools guy referred me to Apple, so I interviewed there. I didn’t really like the attitude of the company. I honestly didn’t think I would move out here at all. Finally, though, Aylott left Sencha and started working for Facebook. After that, he referred me again, so I finally flew out, interviewed, and it had a different vibe. All my MooTools friends were there, so I decided to jump in.

People didn’t understand why I would want to work at Facebook. I had to convince them that we were doing interesting stuff. After a while that was part of what fueled our resurgence into the front-end, open source world. We wanted to share some of the stuff that we were thinking about and working on.

Tom: People didn’t understand why I would want to work at Facebook. I had to convince them that we were doing interesting stuff. After a while that was part of what fueled our resurgence into the front-end, open source world. We wanted to share some of the stuff that we were thinking about and working on. Even after 2011, we were still seen as a PHP company. Hack didn’t come around until 2013.

Christoph: People actually thought we didn’t know JavaScript.

Tom: It’s funny because all of the problems we were solving back then, became the top of our minds two, three years later. Systems like Bootloader and Primer. Primer was the precursor to progressive web apps, and Bootloader was a precursor to bundle splitting. People were solving very different problems than what we were solving at that time.

Can you talk about MooTools 2?

Christoph: Oh, man.

Sebastian: MooTools 2 was a rewrite that was supposed to be even cleaner.

Sebastian: I think the problem it created was that it tried to be so clean that everything had an abstraction associated with it. I think that influenced my JSConf EU talk about avoiding abstraction. Eventually it reaches a point where nobody can understand it.

Tom: In hindsight, it seems so not practical.

Christoph: It’s funny you refer to it as MooTools 2. That was actually something that was never attainable. It was always a hypothetical, aspirational goalâ€Š–â€Šthe actual, perfect, end-state of MooTools. MooTools 2 was basically shipped as 1.2, which broke everything.

Sebastian: That’s how we learned the importance of upgrade paths.

Incidentally, we were just idealists building a framework in a vacuum. We learned a lot from that, and we applied a lot of what we learned to React development.

Tom: That’s actually why React today is so incremental, and why every single release provides steps detailing how you got from the last one to this one. Create React App has instructions for upgrading from a previous version, because we didn’t provide a set back then, and it was a nightmare for everyone that used the framework. Incidentally, we were just idealists building a framework in a vacuum. We learned a lot from that, and we applied a lot of what we learned to React development.

Christoph: That’s maybe the takeaway. MooTools definitely taught us a ton of lessons that now help us with projects like React or whatever else we work on in open source.

Do you think that your learnings from MooTools is one of the reasons why open source has been so successful at Facebook?

Tom: Yeah, I started this project called Project Perception. I wanted to change the perception of Facebook in the front-end community, by talking more openly about what we were doing. James Pearce joined Facebook around that time, and started managing an open source team to work on it. We’ve been collaborating ever since.

Then, Jordan Walke handed us React. It was the solution to our problem. It was a very different way of building web apps.

Open source also helps you be intellectually honest with yourself. If you’re putting ideas out there, people will find flaws, they will have other ideas. You can’t just say there are better solutions internally. You can compare it to other solutions in the ecosystem. It forces you to be honest with yourself, and it helps the company as well.

Sebastian: Open source also helps you be intellectually honest with yourself. If you’re putting ideas out there, people will find flaws, they will have other ideas. You can’t just say there are better solutions internally. You can compare it to other solutions in the ecosystem. It forces you to be honest with yourself, and it helps the company as well.

For some reason like twenty years ago games went one way with immediate mode rendering and functional programming, and apps went the other way with imperative, object oriented programming. Then we were starting to see, like with React, a shift back to the direction of declarative, asynchronous, functional programming

Tom: There was actually a lot of push back against open sourcing React. Many could enumerate the costs, but they didn’t really understand the benefits. Even if we tried to sell recruiting as a benefit, it was always an intangible, immeasurable thing. I don’t think we took into account that we would have the ability to push the entire industry forwardâ€Š–â€Što watch the ideas and concepts from React bleed into other frameworks.

I don’t think React was directly competing with any other JavaScript library at the time. I think it was competing with a traditional way of building user interfaces. For some reason like twenty years ago games went one way with immediate mode rendering and functional programming, and apps went the other way with imperative, object oriented programming. Then we were starting to see, like with React, a shift back to the direction of declarative, asynchronous, functional programming, and now, every framework, every view system on every platform has taken these ideas into account. I think we’ll start to see that more and more, over time.

Christoph: It’s also tied back to MooTools, it was something we learned the hard way. The downfall of MooTools if you want to call it that, was because we didn’t collaborate with many people outside of our team. In jQuery they adopted some of our animation code, and we were actually offended by it. Even though it was open source, we thought we knew how to build the perfect system by ourselves. I think the benefit of open sourcing a project, is that it starts with a level of competition, and eventually leads to collaboration.

Compared to MooTools, or just your experience with open source initially compared to today, what’s changed?

Sebastian: I’ve been on the outskirts of a couple of open source communities, and I think there’s a lot of varied management structures. With React, we foster certain people we can trust to stick around by working closely with them. It’s mainly driven by a core team rather than RFCs for example.

But, it’s a process we’re constantly evaluating, like looking at how Ember does it with RFCs.

Tom: I think we all really like Ember’s RFC process. We talk about it internally all the time, and we’ve applied it to the GraphQL project and a few other projects.

Christoph: Yarn as well.

Tom: Also, for MooTools, funding was handled on our own. With React it’s different because Facebook is relying heavily on React. We have something like 36,000 React components checked into our code base, and we’re supporting dozens of existing app in production. We can’t just make huge, sweeping changes like MooTools 2. We have to think about things incrementally. We have to think about upgrade paths.

You can be somewhat assured that if React continues to work well for us, it will continue to work well for you. We have to upgrade ourselves at the same time as you. If we stop using it, if we stop investing in it, you’re going to know early on, and we’re going to have to have a path forward. It’s a bit of a security blanket.

So I think now, we’re hesitant of being a fork in the ecosystem. We see it over and over in open source, everyone has to work together because otherwise you create a much smaller, bifurcating ecosystem.

Sebastian: With MooTools, a lot of big companies relied on it, but we weren’t working for them. People kept contributing to the older versions because they couldn’t upgradeâ€Š–â€Šthere was no sane upgrade path at the time. So I think now, we’re hesitant of being a fork in the ecosystem. We see it over and over in open source, everyone has to work together because otherwise you create a much smaller, bifurcating ecosystem.

What about from the contributor point of view? Do you feel it’s any easier or more difficult?

There is still, for every project, one person associated with it. The creator. On Twitter, they always refer to that one person. I feel like that’s what burns people out. The only reason these projects are so great is because there’s a whole team of people contributing to it, not just one person.

Christoph: There is still, for every project, one person associated with it. The creator. On Twitter, they always refer to that one person. I feel like that’s what burns people out. The only reason these projects are so great is because there’s a whole team of people contributing to it, not just one person. As the one person though, there are still a lot of people who will attack you, or create issues that are difficult if not impossible to deal with. I feel like that hasn’t changed. I honestly also just wish people were nicer in general. That’s something that is difficult to deal with. Maybe that’s just me putting so much of my heart into this open source project.

…you can’t take the emotion out of open source because open source, and this community, is driven by passion, it is a lot of emotion.

Sebastian: I think Dan Abramov put it best when he said, you can’t take the emotion out of open source because open source, and this community, is driven by passion, it is a lot of emotion. My biggest recommendation to those just starting out in open source is to not be tricked by the founder status. Start out by making yourself replaceable. You’re building an ecosystem, it should be able to function without you, otherwise you’ll burn out. That’s one thing John Resig did really well. He was able to grow jQuery to the point where he wasn’t contributing much.

My biggest recommendation to those just starting out in open source is to not be tricked by the founder status. Start out by making yourself replaceable.

Tom: jQuery, in my opinion, did significantly better than MooTools in this regard, and better than React is currently doing. There were so many core contributors to jQuery that all could have taken it in the right direction for the long haul. That’s why I think it’s still so prevalent. Most websites still have jQuery, and it’s still the go-to for all the cross-browser issues.

As far as the emotional side, you have to be able to separate yourself. Separate yourself from the feedback, and from the community, so you can actually do the work. Dan Abramov does this the best. Any time there is any angst, or anger, or negativity, he just combats it with vicious niceness. He’s just so overwhelmingly nice that he wants to get to the root of why you feel a certain way. He has thicker skin than most, certainly thicker than mine.

Separate yourself from the feedback, and from the community, so you can actually do the work.

Christoph: This has totally turned into a group therapy session. Thank you for that.

For someone who is maybe a year into programming, or two years into programming, and they’re just getting into open source today, what is one piece of advice you’d give to them?

Everyone feels intimidated when they first approach a project. […] All you need to do is ask how you can help, and find the project. […] Just stay humble, and start small.

Tom: Everyone feels intimidated when they first approach a project. They don’t know how they can help, but they want to be involved. All you need to do is ask how you can help, and find the project.

Find something that’s a burden for the maintainers. It can be something simple, like closing out duplicate issues, or responding to questions, or helping to prioritize items. Don’t show up wanting to rewrite everything. Just stay humble, and start small.

Sebastian: Don’t get discouraged.

Tom: Yeah, don’t get discouraged.

Always know that maintainers and core teams see almost everything and will remember you. You’re not invisible, so the more you keep contributing, even if they never respond to your issue, they’ll know who you are.

Sebastian: Because there’s often a lot of context, especially on longer-living projects, and not everything is documented.

There may also be very few maintainers to look at issues or port requests. That’s something we’re actively working on. We have metrics tracking that, and are trying to be better, but there are still issues. Always know that maintainers and core teams see almost everything and will remember you. You’re not invisible, so the more you keep contributing, even if they never respond to your issue, they’ll know who you are. When they do need your help, they’ll know what you’ve contributed on, and what context you have. Don’t get discouraged early on.

Christoph: Yeah, I mean I guess people being intimidated goes back to the hero founder status that some people have or perceive. Often it helps to just meet people at conferences. You’ll realize they’re just real people, they’re not the smartest people in the world. They’re just normal people that happened to work on this project. You can start contributing, and get to that point as well.

All of us are here today because we’re very passionate about the web, so we’re curious to hear what keeps you on your toes and excited to keep contributing to making the web better?

I don’t think you should have to learn 3,000 different technologies in order to build a simple app. The web is how I got into software, and I think it’s ultimately how most people could and should get into software.

Tom: For me, I really want to make it easier to build software. I think it’s just extraordinarily difficult to build software in any capacity. I don’t think you should have to learn 3,000 different technologies in order to build a simple app. The web is how I got into software, and I think it’s ultimately how most people could and should get into software. The best thing about web technology is the very low barrier to entry. That feeling of high productivity and rapid iteration with all software development, whether you’re building an image decoder backend service, or you’re building a simple game or app, or a complex VR game. I think the complexities of a particular platform that you want to build for, should be disclosed over time as you encounter them.

Christoph: Yeah, that’s why we are all here, right?

We all know that with too much fragmentation, you can’t do anything, and eventually you end up joining back in. I hope that we’re able to join back in as quickly as possible. We don’t want to lose track of the next layer because technology is fundamentally about building layers, on top of layers, on top of layers of abstraction. We might be focused on the top layer, but someone’s building the next layer, and they can’t do that if our layer is too fragmented. We have to be able to unify, and collaborate.

Sebastian: I’d add that one of the reasons I’m excited about the web in general, is because there’s a tendency for our community to diverge when we have new ideas, but we have to unify at some point. We all know that with too much fragmentation, you can’t do anything, and eventually you end up joining back in. I hope that we’re able to join back in as quickly as possible. We don’t want to lose track of the next layer because technology is fundamentally about building layers, on top of layers, on top of layers of abstraction. We might be focused on the top layer, but someone’s building the next layer, and they can’t too that if our layer is too fragmented. We have to be able to unify, and collaborate.

Christoph: I guess one great thing is that all of this tooling is also written in JavaScript. So, while it’s great that we’re trying to make it easier to build software, the barrier to entry in general is much lower. Everything is written in JavaScript, so whatever you want to work on, you can go and work on that piece and improve it. The prospect that everything could be written in one language is actually really cool. Your React framework, your user code, your test framework, your JavaScript bundler, your package managerâ€Š–â€Šthey’re all written in the same language. So, if you have a problem with one, it’s pretty easy to solve. That’s what excites me.

This project is made possible with sponsorships from frontendmasters.com, egghead.io and Microsoft Edge.

Our sponsors.

This post was originally published on betweenthewires.org

Our OpenCollective Campaign

Vivian Cromwell — Tue, 29 Nov 2016 00:27:33 +0000

Today, Between the Wires is launching an OpenCollective campaign to raise $5000 for continued content in 2017.

Four Weeks In

It is exactly four weeks since we launched Between the Wires on Medium! In honor of this milestone, we thought it would be fun to share some of the initial data from the first three stories (Guillermo Rauch, Evan You and Chris Coyier ):

Medium: 68K total minutes read, 25K views and a read ratio of between 35% to 57%
Social media followers: 391 on Medium, 255 on Twitter
More than 15 candidates suggested via the online form by our readers

When Preethi and I began this project, we didn’t know if the community would be as enthusiastic as we were. We used the three initial interviews as a way to gauge community interest, and given the early positive feedback, we’ve decided to continue with Between the Wires!

Launching Our OpenCollective Campaign

In order to continue with Between the Wires, we need your support .

Today, we are launching a Between the Wires Campaign on OpenCollective. Our goal is to raise $5,000 to do 20–25 additional interviews in 2017. We welcome both community contributions and corporate sponsorships.

Developing these highly-polished interviews is a labor of love, and requires a good deal of time as well as cost. For each interview, we spend about 12 hours studying the candidate, completing the interview, taking the picture, editing and polishing the transcript, and finally publishing and promoting.

Our labor is free because it is a passion project, but we do need to look for community contribution to cover expenses such as transcribing, copy editing, camera equipment rental, and a few miscellaneous fees. All of our expenses will be submitted on OpenCollective to ensure 100% transparency.

How Can You Help

Between the Wires is made possible thanks to both community contributions and corporate sponsorships. Every dollar raised helps us reach our goal, and no contribution is too small.

If you’re eager to read more interviews from Between the Wires, please support us today!

Our Corporate Sponsorships

At the start of our OpenCollective campaign we reached out to a few organizations about the possibility of sponsorship. We’re excited to announce that we raised $2,000 from our first two sponsors:

Frontend Master

Frontend Masteroffers online front-end training by experts. The founder Marc Grabanski sponsored $1000. Thank you, Marc!

Egghead.io

Egghead.io offers bite-size video tutorials for web developers. They have also generously offered $1000. Thank you!

Microsoft Edge

[Update: 2/1/2017] Microsoft Edge joined and became our 3rd sponsor. Thank you!

Again, if you are interested in supporting Between the Wires with a corporate sponsorship please feel free to contact us on Twitter. Otherwise, we welcome all contributions, every level of support is greatly appreciated.

â¤.

Vivian and Preethi

This post was originally published on betweenthewires.org

Chris Coyier

Preethi Kasireddy — Thu, 17 Nov 2016 00:31:29 +0000

I am the co-founder of CodePen.io, a well-known collaboration “playground for the front-end, creator of CSS-Tricks, a site dedicated to teaching all things web design and development, and the co-host of Shop Talk Show, a live podcast about front end web design, development, and UX.

Tell us a little bit about yourselfâ€Š–â€Šwhere did you grow up and what was your childhood like?

I’m a pure Midwesternerâ€Š–â€Šas I sit now, I’m in Milwaukee, Wisconsin which isn’t too far from where I grew up in Madison, Wisconsin.

I had a super normal (at least my version of normal_)_ upbringingâ€Š–â€Ša middle class family just living in a small town. I got a computer at a young age, my ideas were encouraged, I had an opportunity to get a good education and took it. I feel like the cards lined up for me in an interesting way. In high school, I took a programming class that excited me, and eventually I went to college for it.

Tell us about your first programming experience.

It took until a high school elective for me to get legitimate programming experience. I had a teacher named Mr. Scott, who was such a positive influence. In his class, the language that I took to the most was called Turbo Pascal. Mr. Scott taught us the basics of course, but he encouraged us to get into real projects right away. I remember the very first significant product that I worked on was just a Pascal version of the Game of Life.

The game ended up being published in a little magazine and I was totally hooked after that.

In your podcast you mention later pursuing a computer science degree in college, but ultimately switching to some kind of art major. Can you tell us about that transition, and how your skills, interests, and career evolved?

Laziness, selfishness, and jealousy made me switch to art, but it actually turned out to be the right choice.

After all the positive experiences I had in high school, when I went to college I knew immediately that I wanted to major in Computer Science. The degree was called Management Computer Systems, which should have been a red flag. Not surprisingly, it turned out to be more about the business-side of programming.

I was learning languages that I wasn’t interested in, and the teachers weren’t especially engaging. It was a bummer. It didn’t slaughter my dream of becoming a programmer, but I was definitely a little disenchanted with the idea. I was still a full-blown computer nerd on the side, though.

In the meantime, I was living with a ceramics major and he had this great community of art students. I’d tag along with him to art parties, and I’d go hang out with him in the studio at the art building. I truly believed that his life in college was way more awesome than mine. He had found a real passion, he had found a better community. Honestly, I was pretty jealous of his college life.

Eventually, I made the decision to switch from computer science to art. I had a feeling that what I studied in college didn’t matter that much, and that life would ultimately work out.

My parents are usually very supportive of me, but when I told them I dropped Computer Science they were mad. They were worried that I was throwing away my college career. But, I just marched right into the administrative office and told them I was switching.

The good news is that I took to it right away. I loved it. It was the best thing I ever did. I graduated with a BA in ceramics from the University of Wisconsin-Whitewater.

Chris graduated with a BA inÂ Ceramics

After majoring in art, what did you do between graduation and starting CodePen? Did you have a bunch of jobs in between or did you have an idea of what you wanted to do?

It turned out to be a hard to just jump in and get hired as a designer. I didn’t have enough confidence.

Kind of. There is a decent span in there.

When I left college, my fears were realized. I had no idea what I was actually going to do. I was motivated to get a job right away, and I applied to a bunch of places, but I didn’t have any experience.

It turned out to be a hard to just jump in and get hired as a designer. I didn’t have enough confidence.

Luckily, my mom was in the printing industry and knew a lot of people around town. So I ended up going into the digital printing press after college. It was pretty technical work, and it was interesting in its own way. I’d take designs and turn them into metal plates to go on the presses. It’s a kind of artâ€Š–â€Šyou can think of it like the CSS of print, where you take a design and turn it into reality. So, there’s actually a connection there, between printing and programming.

But it wasn’t that interestingâ€Š–â€ŠI knew I wasn’t going to make a career out of the printing press, because I wasn’t entirely happy doing it. There isn’t a fun community around it. It was really just a job.

On the side, I was into music. I was playing in a Bluegrass band. One day I decided our band needed a website, and that became an excuse to make a website. That was when I began to realize how cool the web is. I wanted to jump in. Then, just through a stroke of luck, there was an opening at a really small shop for an inexperienced web designer and I snatched it up. That’s how I became a professional web designer overnight.

You were also at a company that was acquired by SurveyMonkey. Was that when you decided to move away from Wisconsin?

Right. That was the part that I skipped over. After working at the agency in Madison I ended up working for a company called Wufoo in Tampa, Florida. I moved down there to work with them, which is probably one of the best decisions I ever made.

It was a great team. I’m still friends with everyone. They were building something great, they thought deeply about what they were doing and how they were working. They were good to the people they worked with and their customers. They were eventually acquired by SurveyMonkey, which turned out to be a positive outcome.

In fact, I met my two co-founders, Alex Vazquez, and Tim Sabat at Wufoo. We worked there together, and then at SurveyMonkey, and now they’re my co-founders at CodePen. We’ve been working together for a long time.

The foundingÂ team

How did you end up discovering the problem that you wanted to solve with CodePen?

Well, it was right at that time actually. I worked as a web developer for the agency for many years. In 2007, I decided to launch CSS-Tricks. I was learning it quickly, and I was really into it, and I just wrote down what I was learning using CSS-Tricks as the medium. It’s still around today. In fact, I published an article on CSS-Tricks this morning.

For most of my work with CSS-Tricks, I would make a demo, put it in a folder, and FTP it up to the CSS-Tricks server. Then, when I wanted to show a demo, I would just link to the folder on my server. It worked fine, but it requires the person reading to view source, or use the dev tools, and dig around and find out what’s going on.

Eventually, tools like JSbin and JSFiddle made it possible to see the demo, look at the code, and change the code while the demo plays and changes. It was genius.

So at a point I thought I could do that too. It was a project that I could wrap my head around. I wanted to make my own version of those apps, and I wanted to host it myself and have control over features. That was the idea and the spark behind CodePen.

A common fear when it comes to starting something, is a fear of being financially unsustainable. We’re curious to hear how you managed to become financially sustainable with CodePen, and how long that took?

Even if what you do fails, you learn a lot […]

CSS-Tricks was making some money, and I had written a book about WordPress that was doing okay. So, it was easier for me to get started. My other two founders, Tim and Alex, also had some savings to lean back on.

To me, tech doesn’t seem particularly risky. Even if what you do fails, you learn a lot, which makes it easier to get snapped up by some other company down the line.

So, we launched CodePen totally bootstrapped. Our only expenses were server costsâ€Š–â€Šso that’s another advantage of tech, your cost are pretty low compared to other businesses.

When you first starting building the product, was the idea of monetization on your mind? If not, at what point did it become important to your strategy?

The whole idea was to make some money at some point. So, our plan was to build it, make it super cool, and then have PRO accounts.

We launched CodePen out of beta in June 2012, starting with a freemium model and then had PRO plans by December of that year. The majority of it right now is still selling PRO plans.

We also do some advertising as well, because of how many views we get. We have a job board tool too. We fully intend to continue to monetize CodePen, but hopefully it’ll remain a cool freemium product that people pay for because it provides value.

How do you decide which features should be free versus PRO? How do you get that balance right?

Monetization is the hardest stuff to think about, period. […] In the end, how do I know for sure that we made the right choice? I don’t.

Monetization is the hardest stuff to think about, period. You get so much conflicting advice too. It’s crazy.

The PRO features we decided to offer are the features that we felt the users needed.

One of our PRO features is collaboration mode. It’s similar to Google Docs where you get multiple cursors with up to six people on higher plans and you can all code simultaneously. People use it for interviewing, for working together, to teach, etc. It took a lot of effort to build and so to us, it seemed like a very obvious thing to charge for.

With some of our PRO features we look around and see what other people are charging for. With something like GitHub they charge you the minute you want something private. They figured out that privacy matters to some people, and probably validated that in some way, so that’s a feature we decided to charge for on CodePen.

About a year ago, we did take money for CodePen. We had talked to some VCs prior to that as well a few years back. One of them was just brimming with advice and told us to forget everything, and make all PRO features free. He told us that what matters most is making CodePen the best at what it doesâ€Š–â€Ša premium service that everybody uses.

It actually seemed smart at the time. We figured he was rightâ€Š–â€Šif we gave away all the PRO features we could gain some serious momentum. We thought that people would use it and think about it differently.

We had a branch ready to make private pens a free product. We were about to release it, but we got cold feet. We felt we were cannibalizing ourselves in a way. We were considering taking away one of the reasons users had to upgrade, one of the only ways we were making money.

So, we sent out a survey to gauge why people upgraded. A lot of people said privacy.

Our cold feet turned into killing that branch completely. If we had done it, we would have removed one of the top reasons people pay us at all.

In the end, how do I know for sure that we made the right choice? I don’t. I’m sure there are choices that would have made us more successful than we are right now. There are probably just as many that could have screwed it all up too. Who knows?

But, the VCs idea was to build it to sell it. But we were excited about building it. None of us had even really considered selling it.

It’s a difficult part of business, especially freemium businesses. Freemium businesses are either a complete hit or a complete miss. It’s all about whether or not you can figure out what customers care about most, and what you should charge for. Very few businesses could strike the right balance between giving too much value to the customer and too little.

Yeah, exactly. In a sense one of the cool parts of CodePen is that it’s a community. There are a million members of CodePen and they talk to each other and meet each other. We even had a couple get engaged through CodePen! We have real life meet-ups all around the world. There are freelance groups that started on CodePen, and have teams that work together, meet, and operate together on CodePen.

It’s a community that gives us value. If somebody makes something really cool and puts it on CodePen, it’s basically free advertising for CodePen. They are proud of their work and they’re sharing it. That’s why our marketing budget is zero because people market for us.

But if there are features that we work really hard on, then it just feels right to charge to for them.

We recently hired four people after we took funding. We’re all working really hard on a new feature that will probably be locked under PRO. There’s just too much work going into it. It requires a lot of ongoing maintenance, more servers, real costs that necessitate charging for it.

Can you walk us through a day in the life of building CodePen?

We’re always working to do right by our existing customers.

Sure. I’m sure both of you know from your own interesting backgrounds that everyday, we have no idea what’s going to happen. The only consistent thing is communication. We live in Slack, there’s always a lot of talking.

We also have to make sure we’re listening to our customers. Listening to them means reporting bugs, fixing bugs, that kind of work.

We have to balance our time between building new things, and maintaining what’s already there. We’re always working to do right by our existing customers.

I do it all. I actively work on the product. The people that we hired probably spend a lot more time in the code base than I do, but I’m in it everyday. We’re too small to have any structure. There aren’t any managers or anything, so everybody is in the code base working, talking, writing emails,writing blog posts and doing support. That’s a day in the life.

What’s one mistake you’ve made in building CodePen that you hope to never make again?

It’s hard to know if the decisions you’ve made are the right decisions. Maybe there was a decision that I made that was entirely wrong, and I don’t even know it yet.

A lot of people struggle with this. I’m struggling with it right now, and we talked about it earlier, but it’s hard to know if the decisions you’ve made are the right decisions. Maybe there was a decision that I made that was entirely wrong, and I don’t even know it yet. You can’t A/B test the past.

That near miss of making all of our PRO features free, that feels like something I’m glad we didn’t do. But it’s hard to say.

We took VC, but maybe we’ll just be a lifestyle business, which seems like the last thing VCs want to hear. No VC one wants to hear that. Lucky for us we took money from the original two founders of Wufoo. They’re friends and we’re trying to do right by them, but they’re not down our throats pushing for epic growth.

When we talked to actual VCs, we could tell they were turned off by our trajectory. We want to grow, but we’re not interested in taking buckets of money, making everything free, and trying to be bought by a company like Adobe.

But is that a mistake? Maybe we should have taken a bunch of VC, maybe we are well poised to do that and I’m screwing everything up by not. I don’t know.

Can you talk about one or two difficult periods that you had to go through in building CodePen and how you overcome those struggles?

You have to build a company that people care about. I think that’s important to the people we hire, work with, and like to work with. They need more than just a punch card and a promise of some options.

The struggle is real. One of our early struggles was deciding to do this at all. Some of us had families, we all had responsibilities. It’s not easy to leave a comfortable job like SurveyMonkey, especially when the company is doing so well, and the stock options are good. You roll in at 10 o’clock, and eat gummy worms all day. Why would you want to leave that?

But, we’re well passed that now.

If I’m being totally honest, we’re going through a hard time right now. We grew to nine people, and that’s been a big change. I’m not a manager, but I’m trying to steer the ship. It requires a very different skill set. It requires understanding our employees, and giving them what they need. Some need a lot more feedback than others, some need to be left alone. I know I’m dropping the ball on some of that stuff.

You have to build a company that people care about. I think that’s important to the people we hire, work with, and like to work with. They need more than just a punch card and a promise of some options. We’re trying to figure out how to give them more purpose.

I’ve alluded to this big feature that’s coming out, but I can’t promise anything, or tell you anything. I don’t like to bum people out if it takes forever or doesn’t go as planned. No good comes from promising things you can’t deliver.

This feature though, is a big one. It’s taken a long time to figure out and there have been blockers right and left. I think, occasionally, some moral issues have come up when we’re not making as much progress as we should. There’ve been a couple of dates that we’ve set and not made that I know have bummed people out.

We’re not failing, people aren’t quitting. But it’s been a tough period. I suspect it’s going to work out, though.

What would you consider a successful outcome for CodePen?

I’m absolutely stoked to keep working here, and honestly I hope we can do it forever. If it’s the last job I ever have, that’s fine by me.

I hope we just get to keep on going. We don’t have the startup dream of shooting for incredible growth and selling. Typically, that doesn’t end well for the people who use the product. We’d rather keep building the product we want to exist, and adding to the community we want to be a part of.

I can imagine still working here a decade from now. I really like it. I think it’s a great idea, and we have a list of exciting ideas for the future. I like the community around CodePen too. I’m absolutely stoked to keep working here, and honestly I hope we can do it forever. If it’s the last job I ever have, that’s fine by me. That’s what I’d consider a success.

But, if we could sky rocket right now I’d be down with that. I wish we were killing it harder than we are, because I’d love to keep hiring. We just don’t have the money for that, though. I’d love to eventually double or triple our team. I want to be a manager. I’ve never had that opportunity, and I would love to have it one day.

Have you ever experienced burnout as a founder?

The community helps me, the people around me help me…I have hobbies, I go on vacation. I have enough of a well-rounded life that I don’t think I’m a high risk for burnout.

Not as extreme as some people have. Burnout is a hot topic these days. True burnout would be to just quit, you just don’t do anything anymore. I’ve never totally burned out.

I think I’m lucky in that way. The community helps me, the people around me help me. I’m lucky that I have multiple projects. I have CodePen but I also work on CSS-Tricks, I have a podcast where I talk to people.

Chris enjoys working on his podcast CodePenÂ Radio

I have hobbies, I go on vacation. I have enough of a well-rounded life that I don’t think I’m a high risk for burnout.

How do you build a culture with remote teams?

Positivity is also really important to CodePen and our team embraces it. […] It feels safe here, comfortable, and that’s how good communities are born.

I probably think about this a little too much. I like to shower people with praise. I like to talk things out as a team and find those small teaching moments. Culture comes from thatâ€Š–â€Šfrom moments where you think about how to approach a situation and why, as a team. I also encourage people to pay attention to industry news, and throw their two cents in. Those are culture-building moments.

The CodePen team hard atÂ work

Positivity is also really important to CodePen and our team embraces it. We never let off a negative vibe, we never discourage each other, especially not publicly. We have an inclusive spirit. That’s just vital to me. It feels safe here, comfortable, and that’s how good communities are born.

Who are your programming heroes?

It’s hard for me to look at random people in the industry and consider them programming heroes. […] My heroes are the the people I work with directly.

When you work directly with someone and experience their genius on a day-to-day basis, they feel like the best programmer in the world, and that’s how I feel all the time.

It’s hard for me to look at random people in the industry and consider them programming heroes. Certainly they’re heroes in some sense. I can look at their accomplishments and be impressed, but it’s not as personal. They don’t feel as real to me as the people I work with everyday.

Tim Holman, who we hired, came to us from Tumblr. He did amazing stuff while he was there, but was kind of CodePen famous before he even started working with us. He’s such a smart guy. He doesn’t care about technology, he just cares that the thing he builds works well. He doesn’t care if we suddenly switch to React, he just cares that what we make is cool.

Rachel Smith, another recent hire, was at an incredible advertising agency. She’s just a genius. She’s like VIP on our team. It’s amazing the productivity and the struggles she can battle through. It’s admirable. She’s just an absolutely incredible programmer and person.

Another fellow we hired named Jake Albaugh, also genius. I wish my brain worked the way his brain works.

I struggle with that actually. Sometimes I feel like the least useful person at CodePen. I still add value in other ways, but I’m not useful in the same sense as they are.

So yeah, my heroes are the the people I work with directly. They’re my heroes.

CodePen team

This project is made possible with sponsorships from frontendmasters.com, egghead.io and Microsoft Edge.

Our sponsors.

This post was originally published on betweenthewires.org

Between the Wires: An Interview with Vue.js creator Evan You

Vivian Cromwell — Thu, 03 Nov 2016 00:22:30 +0000

I am the creator of vuejs.org, a popular progressive JavaScript framework. I work on Vue full time with the funding from the Patreon campaign. Previously, I worked at Google and Meteor.

Tell us a little bit about your childhood and where you grew up.

Okay, so I was born in China, my hometown is called Wuxi. It’s a medium-sized city, which is right next to Shanghai. Actually, I went to Shanghai for high school for three years and commuted back and forth. After high school I went to the US for college. I guess I got early access to computers, but I didn’t really get into programming too much. I was more interested in games, and I did play a lot with Flash when I was in high school, because I really enjoyed making those interactive storytelling experiences.

Evan with his first computer, 1996

What was your first programming experience?

“I was attracted to JavaScript because of the ability to just build something and share it instantly with the world. You put it on the web, and you get a URL, you can send it to anyone with a browser. That was the part that just attracted me to the web and to JavaScript.”

When I went to college in the US, honestly I didn’t know what I wanted to do and I was majoring in studio art and art history. When I was about to graduate, I realized it was pretty hard to find a job doing studio art and art history.

I figured maybe I could go to a master’s program that fit my interests better and developed more skills. I went to Parsons and studied the Master of Fine Arts for Design and Technology. It was a really cool program because everyone was half designer and half developer. They taught you things like openFrameworks, processing, algorithmic animations, and you also had to design apps and interfaces.

Parsons didn’t really teach a lot of JavaScript, but I was attracted to JavaScript because of the ability to just build something and share it instantly with the world. You put it on the web, and you get a URL, you can send it to anyone with a browser. That was the part that just attracted me to the web and to JavaScript.

At the time, Chrome experiments had just been released, and I was totally blown away. I immediately jumped into JavaScript and started learning it myself, and began building things similar to Chrome experiments. I put those things in my portfolio and then it somehow got picked up by the recruiter at Google Creative Lab. I joined as part of the Five program. Every year Creative Lab recruits five new graduates. It’s basically a small team with a copywriter, a creative technologist, a graphic designer, a strategist, and a wildcard.

Okay, when or how did you discover the current problem that you’re trying to solve with Vue.js?

My job at Google involved a lot of prototyping in the browser. We had this idea and we wanted to get something tangible as fast as possible. Some of the projects used Angular at that time. For me, Angular offered something cool which is data binding and a data driven way of dealing with a DOM, so you don’t have to touch the DOM yourself. It also brought in all these extra concepts that forced you to structure the code the way it wanted you to. It just felt too heavy for the use case that I had at that time.

I figured, what if I could just extract the part that I really liked about Angular and build something really lightweight without all the extra concepts involved? I was also curious as to how its internal implementation worked. I started this experiment just trying to replicate this minimal feature set, like declarative data binding. That was basically how Vue started.

I worked on it, and felt it had potential, because I enjoyed using it myself. I put a little bit more time into it and packed up properly, gave it a name, called it Vue.js. That was in 2013. Later on I thought, “Hey, I put so much time into this. Maybe I should share it with others so they could at least benefit from it, or maybe they will find it interesting.”

In February 2014, that was how I first released it as an actual project. I put it out on Github and sent a link to Hacker News, and it actually got voted to the front page. It stayed there for a few hours. Later, I wrote an article to share the first week usage data and what I learned.

That was my first experience seeing people going to Github and starring a project. I think I got several hundred stars in the first week. I was super excited back then.

If you had to list a few core things that defined Vue compared to other frameworks, what would you say?

I think, in terms of all the frameworks out there, Vue is probably the most similar to React, but on a broader sense, among all the frameworks, the term that I coined myself is a progressive framework. The idea is that Vue is made up of this core which is just data binding and components, similar to React. It solves a very focused, limited set of problems. Compared to React, Vue puts a bit more focus on approachability. Making sure people who know basics such as: HTML, JavaScript, and CSS can pick it up as fast as possible.

On a framework level, we tried to build it with a very lean and minimal core, but as you build more complex applications, you naturally need to solve additional problems. For example routing, or how you handle cross component communication, share states in a bigger application, and then you also need these build tools to modularize your code base. How do you organize styles, and the different assets of your app? Many of the more complete frameworks like Emberor Angular, they try to be opinionated on all the problems you are going to run into and try to make everything built into the framework.

It’s a bit of a trade off. The more assumptions you make about the user’s use case then the less flexibility the framework will eventually be able to afford. Or leave everything to the ecosystem such as Reactâ€Š–â€Šthe React ecosystem is very, very vibrant. There are a lot of great ideas coming out, but there is also a lot of churn. Vue tries to pick the middle ground where the core is still exposed as a very minimal feature set, but we also offer these incrementally adoptable pieces, like a routing solution, a state management solution, a build toolchain, and the CLI. They are all officially maintained, well documented, designed to work together, but you don’t have to use them all. I think that’s probably the biggest thing that makes Vue as a framework, different from others.

How did you manage to become financially sustainable with Vue.js?

“I’m creating value for these people, so theoretically if I can somehow collect these values in a financial form, then I should be able to sustain myself.”

I’m creating value for these people, so theoretically if I can somehow collect these values in a financial form, then I should be able to sustain myself. This gets complicated because JavaScript framework is relatively hard for people to pay upfront, given how the JavaScript ecosystem has been working.

Vue has a very vibrant user base. Many of Vue users are from the Laravelcommunity and they are also really enthusiastic and nice people. I thought, would crowdfunding work? I just wanted to try this idea on Patreon. Actually Dan Abramov, the creator of React-Hot-Loader and Redux, also did a small campaign on Patreon before. That’s actually what interests me. I have a rough idea of how many people are using Vue. Let’s say there are 10,000 users. If maybe 1% of them is willing to give me ten bucks a month, that is something.

Evan’s PatreonÂ campaign

In February, I started a Patreon campaign, and it is a two-part thing. One part is targeted towards individuals who are using Vue. Typically they’re just willing to give up a small sum, kind of like buying me coffee. Then there’s the other camp with actual business entities, like start-ups or consultancy shops, who’ve built stuff with Vue. It’s important for them to see that Vue is maintained in the long run. It affords them peace of mind knowing that their financial support will make Vue more sustainable and they can feel safe using it for the long run.

Another aspect of it is Patreon rewards. If companies are willing to sponsor us, then I could put their logo up on a sponsor page on vuejs.org. It raises the awareness of the community. Half the Patreon funds are coming from individuals and one of them sponsored $2000 a month. I had no idea if it would work out when I tried it, but it turns out it’s kind of working. I think I made the full-time jump when I had $4000 a month on Patreon, and now it’s grown to over $9800 a month.

Did it take a long time to convince them to sponsor you? Were they skeptical at all, like, you’re just a young framework, you might not last six months?

When I started the Patreon campaign Vue was already showing really strong growth. In early 2015, Vue was largely still just a random open source project, but the Laravel community started going full on with Vue. I felt like if I couldn’t actually make any money out of it, it wouldn’t make sense.

I have to give a special thanks toStrikingly, which is a start-up based in Shanghai. They are really actively involved in JavaScript and Ruby communities in China. They don’t actually use Vue a lot, but they have this monthly fund that they use to sponsor open source projects. They were the first $2000 a month sponsor for six months.

That helped significantly in the early phase. Also, Taylor Otwell, creator of Laravel, is also sponsoring Vue. He started with 100, and bumped it up to 200, and 500 over time.

You mentioned that you were able to get sponsored because it grew so quickly. Did you have to do any marketing? Or did it grow organically?

I would say there isn’t any real money involved in marketing. I didn’t buy ads or anything. It’s mostly, just writing some blog posts. A lot of times I was just managing the Twitter account. I think that’s pretty much it. Occasionally I’d write a post on Medium.

You ended up getting great traction in international markets, which is probably pretty unique. We’d love to hear how it happened and some of the challenges and best practices for engaging developers outside of the US.

JSConf China,Â 2015

The Chinese market is unique. I’m Chinese and I’m pretty involved in the Chinese JavaScript community. A lot of people knew Vue because they knew me. We had this whole translation of Vue documentation into really well written Chinese, so that helped a lot with Vue’s adoption in China. A lot of users also know, “Hey, the author of this library is Chinese.” They just naturally feel inclined to at least check it out, but I think that helped quite a bit in the early phases. Vue just started being used by more and more companies in China, including teams at Alibaba, Tencent and Baidu. Those are all billion-dollar valued companies in China. React also has a really big mindshare in China.

There is a Quora clone in China named Zhihu, people ask all kinds of random questions on there and I answer a lot of JavaScript and Vue.js-related questions for them.

Do you have any suggestions for companies, startups, or open source projects that aren’t easily able to engage or communicate with international communities?

I guess the language barrier is probably the hardest part. The idea is if you don’t really put dedicated effort into pushing something in China, then no one’s going to notice it, unless you’re as big as React. You need someone who can speak Chinese, someone who can speak native Chinese to actually do it.

Another interesting thing is that there are actually many other users from other regions of the world such as Italy, Spain, Portugal and Japan. Some of the most active contributors are from Japan. They are really, really meticulous in translating the documentations.

Did you make any mistakes while building Vue that you hope to never make again?

“I have to completely rethink the problem in a certain way, but I think that’s just how software development goes because you would never get anything right just from the first try.”

Hm, I know, there are probably quite a few. To date, Vue has been rewritten from the ground up twice. Obviously, I rewrote it because the original implementation had problems that just could not be solved by gradually refractory. It’s like every six months I look at the code base from six months ago. I’ll be like, wow. How did this even work?

I have to completely rethink the problem in a certain way, but I think that’s just how software development goes because you would never get anything right just from the first try.

The journey of building Vue is also a journey of just growing as a developer, because over time I had to add new features, maintain it, fix bugs and ensure the whole ecosystem worked correctly together. It just naturally exposes you to all the problems you would run into as a software engineer. It’s just a learning process.

Have there been emotional, or non-technical hardships that you’ve faced with Vue?

“There is not going to be this one true framework that just makes everyone happy. The more important part is, make it better for the people who actually enjoy your framework. Focus on what you believe is the most valuable thing in your framework and just make sure you’re doing a great job, rather than worrying about how you compare to others.”

There definitely have been. There’s a lot of pressure in terms of competition. When Vue was still relatively unknown, that pressure isn’t there because any exposure is good. People aren’t going to hold you up to a certain standard. But as Vue has grown bigger and bigger, naturally people started comparing Vue to things like Angular or React, and they point out things like, “hey, React does this better. Angular does this better.”

That puts a lot of pressure on you and it can be stressful having to compete with all the big guys. Especially now that I’m doing this full-time. The viability of Vue in the ecosystem basically is directly related to how well I am doing.

But recently I just watched a talk by Evan Czaplicki, the author of Elm, where he talked about how he had a similar pressure when he was working on Elm. There was Om, the ClojureScript interface on top of React. There was PureScript, there’s other functional compiling to JavaScript languages out there, he was also worried how Elm could compete with those libraries.

Later on, he talked to Guido, author of Python, and Guido gave him advice, he said, “just do a good job.” The idea behind that is that Python also had this problem. It competes with a lot of dynamic languages, like Ruby, JavaScript, Perl, and it’s also in the same problem domain. It ends up all of these languages that are successful in their own right, and they have their own dedicated community using them, enjoying those languages.

People prefer different languages for a reason. Similar to JavaScript frameworks, people would prefer different frameworks for a reason. There is not going to be this one true framework that just makes everyone happy. The more important part is, make it better for the people who actually enjoy your framework. Focus on what you believe is the most valuable thing in your framework and just make sure you’re doing a great job, rather than worrying about how you compare to others.

What would you consider a successful outcome for Vue.js?

That’s a hard question because the scope of Vue.js has definitely increased over time. We now have this whole framework ecosystem, and we’re also expanding to explore things like Weex which is rendering Vue components to a native UI.

I also really care about the approachability part of Vue, which is rooted in the belief that technology should be enabling more people to build things.

The next few are just fun questions outside of programming. What are some other hobbies or interests that you have outside of programming?

Anime, I read a lot of manga. In case you haven’t noticed, Vue’s releases are code-named with anime names. It started in .09, every big release code-name is incrementing with a letter. 2.0 is G which is Ghost in the Shell. F is actually reserved for 1.1. 1.0 was Evangelion.

Illustration drawn by a Japanese Vue user to celebrate the 1.0 release (codenamed Evangelion)

Celebration illustration for Vue 2.0 (codenamed Ghost in theÂ Shell)

I really enjoy karaoke.

What are some top technologies or trends that you’re most excited about?

General technology. It’s weird because I’m not super excited about AR or VR stuff. I really want to talk about something that’s closer to developers. Something like what Guillermo is doing with Now. Developers build tools for developers, and the developer experience of these tools, that is also user experience but for developer tools.

Who are some of your programming heroes? If you have any.

Obviously TJ Holowaychuckand Guillermo Rauch. I’m not a computer science major. I basically learned programming through just random online resources and books, but an important way that I learned was just by reading other people’s code. When I read TJ’s code, I always feel like it’s really elegant. That’s the word that comes to mind and that affected me a lot. TJ is definitely a hero me.

This project is made possible with sponsorships from frontendmasters.com, egghead.io and Microsoft Edge.

Our sponsors.

This post was originally published on betweenthewires.org

Between the Wires: An interview with developer and entrepreneur Guillermo Rauch

Vivian Cromwell — Wed, 02 Nov 2016 00:10:05 +0000

I am the founder of zeit.co. Our mission is to make cloud deployment simple, global and real time. I also built socket.io and founded two startups previously: LearnBoost and CloudUp.

Tell us a little bit about your childhood, and where you grew up.

I grew up in a little town in Argentina right outside of Buenos Aires. It’s a small residential community with very little internet access and very little in the way of acquiring a computer.

My dad was really into engineering in general and Star Trek, so he always wanted to buy new, cool things for the family. We got a computer when I was about seven. I actually still remember the first day we got it and I remember Windows 95 booting up. That’s when it all started.

What specifically got you into programming?

There were a couple things that happened early on. One was the early exposure to alternative operating systems. When I first heard of Linux, for example, it was very difficult to use.

Guillermo, 12, explaining to Richard Stallman that vi >Â emacs

Programming really clicked for me due to my exposure to the terminals, and the very few number of steps that it took from writing a file, and then running GCC and getting the binary out.

There’s this idea that the shell itself is sort of a programming language as well, right? It all fits together very nicely.

“I could actually extract so much excitement from these few characters on a black screen.”

I think that was like my first moment where I knew that programming was extremely exciting to me. I could actually extract so much excitement from these few characters on a black screen. Excitement with programming has a lot to do with that, because there’s so much negative feedback involved in the process, that the victories have to get you extremely excited. It’s the little thingsâ€Š–â€Šlike a test passing with a bunch of green dots on the screenâ€Š–â€Šthat got me really excited.

That seems to be the influence of Hyper.app, right?

Definitely. Hyper.app to me is sort of a continuation of that idea.

Also, sometime early on I discovered open source through a lot of projects that were written in PHP MySQL. With PHP, I first got a taste of what it was like to get gigantic code base written by people that were far more experienced than me. When I was able to edit that work and get immediate feedback, I was fascinated.

Was MooTools your first major Open Source project that you contributed to in a significant way?

MooTools is a collection of JavaScript utilities designed for the intermediate to advanced JavaScript developer.

I remember this really simple website that I was building for a music catalog. There were a bunch of rows each with three buttons on the right hand side: Inspect, Edit, and Remove. I wanted that remove button to just remove that row on the client side. I didn’t want to fetch the entire website again. So we ended up using a hidden iFrame that we could post to and then detect the iFrame call back event. Later on I discovered that this iFrame thing is hack. That is what got me really into MooTools.

That was my first really important open source role which led to my first job. I was 16 years old at this point, when I was named a core developer for MooTools.

Then, the following year, I got invited to Switzerland because a startup company had decided to bet on MooTools for all their front end applications code. One of the other core developers consulting for this firm, his name’s Aaron Newton, recommended me. I think this is why it’s so important to have people that bet on you early on.

A week later, they flew me out to Switzerland. I remember meeting the CEO at the train station. He was like, “wait a second. Is this kid lost? Are you really our new engineer?” I was like “yep, let’s go. Let’s get this done.”

Then, they opened an office here in San Francisco, and that’s when I decided to move on and start my own company, because why not?

Your first startup LearnBoost, produced so many open source projects and helped push the Node JS adoption in the early days, how did you do that, or was that a side effect?

Learnboost was my first startup, we wanted to help teachers manage their classroom in one place using digital grade book.

It’s interesting, because it is a side effect, but then a lot of side effects in start-ups become your main effects. This is a classic story you hear, where one of the features of the company became the biggest business in the company.

I think we started off with the intent of using Node. When we first started writing the code base, it was a mesh of one language for the backend and JavaScript in the front end. Then when Node came out, we decided to bet 100% of every line of code in JavaScript. Why not?

The caveat was that it involved using a lot of stuff that was just being developed, like one of the very first few versions of Express. Sometimes we would use early versions of software and find they were not good enough so then would build our own and open source it.

Open source was the only way that we could do that, because we were using a lot of open source internally. We were recruiting from the people that were creating these open source projects, and then we were giving back as a way to sort of fuel growth on that platform.

That’s also what we became known for, open source.

We’ve talked a lot about the good side with LearnBoost and Cloudup, do you want to share a little bit about the challenges you have faced?

Lots of challenges. To start, I was really passionate about building an education product, but as I just narrated my own story, I didn’t finish high school and I didn’t go to college.

So I think we were building a product that didn’t really embody the very way that I had built my career up to that point. If I had to build or recommend an education tool again, I’d actually recommend the ones that made me successful.

I learned almost everything from the internet. How I learned English is a great example. I learned by reading through a lot of the documentation that I found online, which was often only in English. So I had no choice but to learn to read it.

Learning to code is another example. You can learn to code on your own at home. You can get immediate feedback if you use the right tools. That’s the sort of the thing that I wish we had tried to build with the product for others. Not just make a general education tool.

Early on, we were asking teachers, “okay, what do you think about this seating chart? What do you think about this?” As opposed to I think the best start-ups have a way of telling everyone else, “okay, why don’t you try this? It’s a new way of doing things,” and sort of taking a risk with that, as well.

Going back to “how could I have made that better back then?” I would also try to encourage people that are learning to ask questions like: What do you do with all these things that you learned? How do you get paid and do this full time in the future?

I think for a lot of things that have to do with knowledge acquisition, you make a better return for yourself if you try to get it for free, and then you put your creativity on top, and then you put that back into the market. That’s basically 100% profit.

I think we can do a lot of this with open source too. We have to continue to find ways that people can learn and contribute to open source, and then make that a complete system. Not a system that’s based on hoping for a donation that might not actually ever come, but something that really gives that power back to the creator, based on its usage.

“That is one of the things that we’re missing right now in the open source community. There have been people that have made vast contributions to the world that we’ve built everything on, but because of a certain set of decisions that they made, they haven’t been able to maintain.”

This actually ended up being the case for Open SSL. Open SSL, one of the most widespread, and most important pieces of infrastructure in the entire world. It was under funded, and full of security vulnerabilities.

Besides product-related challenges, were there any team or emotionally-driven challenges?

I think there are two kinds of emotional challenges. One is which you face directlyâ€Š–â€Šmaybe you were trying to sell your product and you got denied because they went with your competitor, or maybe you got turned down by an investor. This type of challenge is very direct feedback of “oh, that went wrong.”

The other less subtle one, when you’re taking on these multi-year projects, is that there is no end in sight.

It could happen that tomorrow you get acquired for something that your peers would consider a ridiculous amount of money. It could happen that you have to spend twenty years solidly building a business, and then finding some sort of retribution for your co-workers and employees in the end.

It’s subtle and you’re carrying this emotional baggage as you’re constantly fighting an uphill battle, every single day. I think that’s what I sort of referred to when, maybe the idea that you were pursuing, is not completely aligned with your identity or vision of the world, but you feel it’s too late to change it.

I think for us, the great thing we did is, we didn’t feel it was too late to change it. We sort of said from one day to the next, this is our new focus. It’s difficult, and then you face a lot of the direct negative feedback, because all of your employees are like, “why? Why are we changing everything? I kind of liked what I was working on before. We were doing well.”

I think it’s all about trying to align the mission of the company and your view of it. This is also why it’s important to not be too attached to bad ideas. Sometimes it’s tricky, because there’s money involved. There’s other people’s money involved.

I think this is one of the big lessons for open source as well. You invest a lot in a certain solution, but you have to realize at some point it’ll exhaust its evolution, and it can’t grow any further. The smart thing to do is leave it alone, and start anew, start fresh.

Interesting. Obviously you were right back at it with ZEIT and HyperTerm so the first startup didn’t put you down in any way. I’m curious to hear, now that you’re in the middle of building it, what do you consider a successful long term outcome for ZEIT and HyperTerm?

“One of my dreams is that the next Facebook or the next Snapchat will be created by someone that has not have to gone through all this education or has had to develop all these connections and hire all these bright people. Really, it can be one girl in Africa. It can be a boy in Bangladesh.”

Our mission is to enable everyone in the world to deploy applications and services very easily. We think that the entire fabric of the internet is very, very difficult to grasp. There are so many layers and so many technologies and so much lingo involved from DNS to SSL to IP to TCP to HTTP to different ways of achieving performance. The way that we measure our success is obviously getting more people to put their work out there and be more productive by changing that stuff more frequently.

Our vision is that anyone in a company will be able to complete an entire product or experience and deploy by themselves. You give the power to one person, what otherwise would’ve taken an entire team of people. You give them the feedback within 100 milliseconds as opposed to something that used to take minutes or hours or weeks.

It took one person to create Facebook, and it was a fairly-educated man in a Harvard dorm, and then they took a certain number of years to achieve their first million users. You can see how that’s changing very quickly, right? The level of education of people that started the next big revolutions is not necessarily as high and the time it takes for them to get to a million users is lower each time. One of the things that we do particularly well is we take your deployment and we scale it on your behalf.

One of my dreams is that the next Facebook or the next Snapchat will be created by someone that has not have to gone through all this education or has had to develop all these connections and hire all these bright people to help scale the business or the technology for them. Really, it can be one girl in Africa. It can be a boy in Bangladesh.

That would be the dream scenario for us, giving that amount of power to the individual. It’s a power I think our industry and this technology have given us. Because it’s so hard to start from scratch and build the Trump tower.

Zeit has a very distributed team including your co-founders. Can you talk about your best practices when it comes to team productivity and communication? What tools do you use?

“Distributed teams in my opinion are the only way forward because otherwise you’re missing out on all this amazing creativity and all this diversity that comes from people that are not with you in that same physical space.”

Zeit team and their largest customer inÂ Europe

I’ll give you an example of what I think is the biggest advantage of distributed teams: We launched Hyper.app, which I primarily worked on myself for about two weeks. Then I opened it to the world. What happened next will blow your mind. A week after we launched it, we already had 50 contributors that had landed pull requests. We had 100 plugins written on top of it.

I think something that helped with that was we made themes very simple to create. It was very rewarding to see that response because you’re creating the platform on top of which we will contribute a combination of Lego blocks.

Imagine the physical or in-person counterpart to such an endeavor? How do you coordinate 50 human beings around a project, around an office space? How do you recruit them so quickly? How do you even talk to them one-on-one or settle details of how they’re going to work and so on?

I think open source is showing us what this dramatic exponential rise in productivity can be. There’s no other way than doing it over the internet because physical collaboration is slow.

We also set up Slack, where everyone joined and started to exchange ideas. Again, this massive workforce of strangers assembled almost spontaneously and had all these tools to collaborate. To me it felt like it happened overnight. For me, I want to replicate that with my own company. I don’t want my ability to make really great products to be constrained by physicality. I don’t want to burden people with unnecessary protocols, and unnecessary routines that may be inconvenient to them.

Distributed teams in my opinion are the only way forward because otherwise you’re missing out on all this amazing creativity and all this diversity that comes from people that are not with you in that same physical space.

What is the biggest challenge your startup is facing at the moment?

I think there are a lot of challenges that have to do with the product education. The best thing to do is to not create a product that has every single feature for every single type of workflow out there. Instead we want to educate users on how to use the product in the best way possible.

Sometimes you get enthusiastic customers, perhaps really large customers, that maybe have different ideas about how to use the product or platform. For us, it’s about striking a fine balance between adding features over time, but retaining the simplicity and retaining the belief on what the best model is for API development. It comes back to saying no to a lot of things, even when it’s extremely tempting from a financial perspective.

Who are some of your programming heroes?

Leslie Lamport, number one. He is a computer science hero because the breadth and depth of his contributions is unmatched by anyone in our field. In my mind he is comparable to Alan Turing, in that he opened a completely new field, namely of distributed systems. We are still working on grasping the size of his contributions and continue to study his ideas, specifically with recent works like Raft and Flexible Paxos . Ironically for this question, he thinks we put too much emphasis on programming languages when simple mathematical tools (sets, functions and basic logic) are sufficient to express any program.

Dan Bernstein is unmatched in the field of cryptography and security. Extensive theoretical and low-level systems contributions, yet also known for tasteful, practical, approachable and widely-used software like Qmail.

I’m also a big fan of lesser-talked-about heroes behind software we use every day. Junio Hamano, lead maintainer of git, comes to mind. Git was a very short term project by Linus which has been masterfully conducted ever since.

Moving to more general questions, what are some of your hobbies or interests outside of programming?

Programming is my main hobby. Besides that, I enjoy bodyweight fitness, also known as calisthenics, which is the exercise of your own body without body weights or gyms or things of that matter. It’s a form of meditation for me. It’s also a way of setting up almost unachievable challenges.

I have a Shiba Inu. Yeah, I learned a lot from my dog because he has this amazing life figured out for himself. He’s very zen. He’s a dog from Japan that has an amazing personality. I think there’s a lot that we do for them, but there’s a lot that we get from them as well, like a great appreciation for different life, I think.

Dei, soÂ zen.

I’m also passionate about design, I’m always thinking about what little applications or projects I can create on the side that can have a tremendous amount of impact.

This project is made possible with sponsorships from frontendmasters.com, egghead.io and Microsoft Edge.

Our sponsors.

This post was originally published on betweenthewires.org

What is Between the Wires

Preethi Kasireddy — Tue, 01 Nov 2016 10:55:39 +0000

Between the Wires is an interview series featuring those who are building developer products. Here we hope to spread ideas, encourage innovation, and offer a behind the scenes glance at the creation of developer products.

Who we are

Vivian Cromwell

For eight years Vivian Cromwell worked on developer products at Google including Chrome, Cloud, and Social, focusing on developer experience and tools. While at Google, she built several teams from the ground up, alongside world-class engineers. She recently left Google to start a mobile commerce startup (getchop.io) where she is learning first hand what it takes to build something from scratch — both the good and the bad. As a passion project, she also works as an adviser for startups in the developer space as a way to pass along what she has learned. Through her various experiences, she has become increasingly interested in understanding how developer products and projects are built. From this interest came Between the Wires, an interview series to share maker stories with like-minded individuals.

Preethi Kasireddy

Preethi Kasireddy is currently a software engineer at Coinbase, though her path to this point has been circuitous. After studying Industrial and Systems engineering in college, Preethi went into investment banking at Goldman Sachs, and later became a venture capitalist at Andreessen Horowitz. While there, she interacted with thousands of developers and founders on an array of products. She was fascinated by what they did, and how they did it. After watching their products change the world, she began to study code so that she too could build something that mattered. What started as a pastime quickly grew into a deep passion for programming. Soon after, she left Andreessen Horowitz to become a full-time coder, and to build the foundation needed to be a maker. Between the Wires is a natural extension of her fascination with makers, and offers a place to collect some of the developer stories she initially found so inspiring.

Why we care

We felt that what the community was missing were the raw details and inside scoop on what it takes to be a maker and build a valuable product from ground-up. We care about questions like:

What motivates makers to build developer products?
What lead them to the path they are on today?
What was their first experience with coding?
What are the various ways to get funding for the projects?
Is it possible to work on open source projects in a financially sustainable way?
Given the rapid pace of innovation in the developer ecosystem, how do they make sure a product stays relevant and useful for years?

Moreover, we also want to focus on some of the harder questions like:

What are some of the toughest challenges that developers face in running their business?
Did they fear they would fail? How do they overcome that?

With these questions in mind, we started a series of interviews with makers. Our goal with these interviews is to share experiences that are often hidden behind a product or Github repo so that everyone, including aspiring makers, can learn from it.

We will be releasing the first set of our project starting with the story of Guillermo Rauch, CEO of zeit.co.

We hope this project inspires developers who want to build something. We hope to offer a transparent look into the various challenges and hardships these makers have faced for the sake of their dream. And we hope that it gives others the courage and motivation to do the same.

We would love to hear your feedback. If you have a suggestion for a maker you’d like to hear from, please fill out this form.

A big thank you to our writer Katie Crowley who helped us polish the articles, and to Marc Hemeon who quickly doodled the logo concept for us.

Stay hungry, stay foolish. Keep on building.

Vivian & Preethi

This project is made possible with sponsorships from frontendmasters.com, egghead.io and Microsoft Edge.

Our sponsors.

This post was originally published on betweenthewires.org

DEV Community: Between the Wires

Between the Wires: An interview with open source developer Sindre Sorhus

Tell us a little bit about your childhood and where you grew up.

How did you get into programming?

You spent five years in military as a front end developer and photographer. What was the web development like at that time?

How did you get involved with TodoMVC and Yeoman?

Why are you passionate about open source?

How about open source sustainability?

You have over 1000 npm packages. How do you stay so productive?

What is one advice you can give to new OSS contributors when dealing with demanding and toxic people?

You designed some logos for your own modules, they are awesome. How did you learn design?

What motivated you to start AVA project?

Why did you decide to get into macOS development?

What is your plan for next year? Are you planning to go full time or consider other ways to become financial sustainable?

What are some of the things you wish to improve in JavaScript ecosystem?

Why are JavaScript developers obsessed with unicorns?

Between the Wires: An interview with Dat Project Dir. of Engineering Karissa McKelvey

How did you get into programming?

How did you get involved with Dat Project?

What is Dat project?

How does the grant funding work for Dat?

If a foundation gives you a set of grants, how is the expectation being ** set?**

How do grant officers and engineers find each other to collaborate?

How do grant foundations perceive open source?

Dat runs a very distributed team. Tell us your best practices when it comes to team productivity and communication. What tools do you use?

What is Code for Science and Society?

Walk us through a day in the life of building Dat and Code for Science and Society?

Can you talk about a couple really difficult periods you’ve had to go through or are currently facing in building Dat and CSS? How do you overcome the struggle?

What’s next for Dat Project ?

What other hobbies or interests do you have outside of programming?

Between the Wires: An interview with entrepreneur and founder Charlie Cheever

Tell us a little bit about your childhood, and where you grew up.

What’s Expo?

What motivated you to create Expo?

Often one of the most rewarding moments for a startup founder is when your product is used in an unexpected or innovative way. Does that happen with Expo?

Walk us through a day in the life of building expo.io as the founder.

Why is it difficult to make money with developer products? How does Expo approach this?

Can you talk about one or two really difficult periods you had to go through as you were building Expo?

What’s next for Expo?

What are some of your hobbies or interests outside of your startup?

What’s New With Between the Wires

Between the Wires: An interview with Microsoft Edge PM Nolan Lawson

Between the Wires: An interview with data visualization scientist Irene Ros

Tell us a little bit about your childhood and where you grew up.

Tell us a little bit about your first programming experience.

How did you start data visualization work?

What was data visualization like five years ago?

What is one of the most exciting data visualization projects you worked at Bocoup?

You started OpenVis Conf 5 years ago, can you tell us about it?

Can you talk about a difficult period you’ve had to go through, and how you overcame it?

How do you help junior developers overcome this?

How do you balance between open-source and monetization for your data visualization projects at Bocoup?

What are the challenges today in data visualization field, both from the technology point of view as well as the community?

what other hobbies or interests do you have after programming?

MooTools

Introduction

Can you tell us a bit about yourselves and how you each got into programming?

Going back to the origin, do you know why Valerio started MooTools, and how it got started?

How did each of you start contributing to MooTools?

MooTools has such a distinct and memorable brand around it. What were some of its core values that made it stand out initially, and why do you think people remember it so positively today?

What do you think was the most impactful or important thing that you learned while working on MooTools?

MooTools was probably one of your first large open source contributions and projects as well. How would you say it impacted your career?

Can you talk about MooTools 2?

Do you think that your learnings from MooTools is one of the reasons why open source has been so successful at Facebook?

Compared to MooTools, or just your experience with open source initially compared to today, what’s changed?

What about from the contributor point of view? Do you feel it’s any easier or more difficult?

For someone who is maybe a year into programming, or two years into programming, and they’re just getting into open source today, what is one piece of advice you’d give to them?

All of us are here today because we’re very passionate about the web, so we’re curious to hear what keeps you on your toes and excited to keep contributing to making the web better?

Our OpenCollective Campaign

Four Weeks In

Launching Our OpenCollective Campaign

How Can You Help

Our Corporate Sponsorships

Frontend Master

Egghead.io

Microsoft Edge

Chris Coyier

Tell us a little bit about yourselfâ€Š–â€Šwhere did you grow up and what was your childhood like?

Tell us about your first programming experience.

In your podcast you mention later pursuing a computer science degree in college, but ultimately switching to some kind of art major. Can you tell us about that transition, and how your skills, interests, and career evolved?

If a foundation gives you a set of grants, how is the expectation being set?