How to Run a Remote Team

From Zapier: a great list of tools and approaches that make remote work environments successful

 

A lot of energy has been expended over the last few years debating the merits of remote work. Unfortunately, not much information is shared about how to setup remote work so that you and your team can be successful.

For over three years, Zapier has ran as a remote team. We’ve grown from three founders to over twenty people. We’ve gotten a lot of questions about how we make it work. This chapter will explain how we make it work.

Read more from the source: zapier.com

The Difference Between “Remote” and “Remote-First” – ThinkGrowth.org

From Litmus: the 10 things remote teams need to succeed

 

One misconception about remote work is that it hinders collaboration. In my experience, the inverse is more likely: offices hinder independent work. Collaboration tends to happen in short bursts, followed by longer periods of writing, designing, coding and thinking. It’s more important to give employees quiet time than it is to cram them into an open office.

Read more from the source: ThinkGrowth.org

Remote-First vs. Remote-Friendly

Remote-first work environments take some work but can be very appealing

 

I think there’s a split between being remote-friendly — hiring some workers in a different city — and remote-first, meaning you build your development team around a workflow that embraces the concepts of remote work, whether or not your employees are remote.

By forcing yourself to use chat instead of meetings, by forcing yourself to use chatops to mercilessly automate every single manual action, you end up creating things faster, with more built-in context, and greater ability to share your knowledge across the organization.

If you’re not working in a remote-first environment today, not only are you not going to have a remote-friendly environment tomorrow, but you’re going to eventually have a hard time retaining talent and keeping competitive pace in the future.

The world of work is changing. That’s just the way it is.

Read more from the source: zachholman.com

Webpack 3: Official Release

Just when we moved fully to Webpack 2, Webpack 3 comes out with scope hoisting and magic comments

 

After we released webpack v2, we made some promises to the community. We promised that we would deliver the features you voted for. Moreover, we promised to deliver them in a faster, more stable release cycle.

No more year-long betas, no breaking changes between release candidates. We promised to do you right by you, the community that makes webpack thrive.

Read more from the source: Medium

Why I Chose React Over Vue – Steven Poulton

A look at why immutability and functional workflow are better solutions than reactive state and domain-specific language

 

React and Vue are ostensibly very similar and I have shipped projects using both. They both use a virtual DOM and they are both narrowly-focused view libraries. They are both solutions to the same problem as reactive HTML rendering tools but I believe they have a single defining difference that cascades down through your entire workflow. React fully embraces Javascript, Vue does not.

A common mantra often heard amongst React users is “it’s just Javascript” and that’s very true. Vue just seems to have a lot of unnecessary magic which makes components more difficult to reason about.

Read more at Medium

Winning with CSS Variables

Some cool ideas of things to do with CSS variables; now supported by all modern browsers

 

CSS variables now enjoy wide cross-browser support. But what are they and why should we use them?

Any CSS property — color, size, position, etc. — can be stored in a CSS variable. Their names are all prefixed with –, and you declare them by adding them to an element right where you add its other styles.

Read more from the source: vgpena.github.io