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
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
What are developers up to today?
Each year since 2011, Stack Overflow has asked developers about their favorite technologies, coding habits, and work preferences, as well as how they learn, share, and level up. This year represents the largest group of respondents in our history: 64,000 developers took our annual survey in January.
As the world’s largest and most trusted community of software developers, we run this survey and share these results to improve developers’ lives: We want to empower developers by providing them with rich information about themselves, their industry, and their peers. And we want to use this information to educate employers about who developers are and what they need.
We learn something new every time we run our survey.
Read more from the source: Stack Overflow
Amazing analysis of what developers REALLY want to work on
For me, the weekends are mostly about spending time with my family, reading for leisure, and working on the open-source projects I am involved in. These weekend projects overlap with the work that I do in my day job here at Stack Overflow, but are not exactly the same. Many developers tinker with side projects for learning or career development (or just for fun!) and at Stack Overflow, we support all types of technologies, from professional to hobbyist. Whenever people are working, we’re available to answer their questions. But what languages tend to be asked about on weekends, as opposed to weekdays?
Read more from the source: Stack Overflow Blog
There are so many unseen downsides to estimation. Instead, prioritize and get to work.
Software Estimation is a Losing Game – Should we even bother?
Let’s call it, Budget-Driven Development, or BuDD for short. In BuDD, development teams are given a set of resources and develop what they can until the budget is gone. I’m sure I just gave someone a heart attack, but when you think about it, it’s not too unreasonable. Many contracts have fixed time and costs. You make a guarantee that the customer will get a specific number of man-hours of development. Given a prioritized backlog, developers work on the three most important items. I imagine it would work similar Pandora’s prioritization model, but not be constrained by time.
You guarantee quality to your customer by:
- Delivering capability often.
- Allowing the customer to prioritize development.
Read the full article at: rclayton.silvrback.com
User experience begins with strategy and requires layers of feature scope, site structure, site skeleton, and “surface” or the graphic interface
In a post adapted from a short talk Mike Atherton gave at the SODA Social meetup in London on May 14th, 2015 he writes:
In UX there’s no ‘one-size-fits-all’ design pattern for a given situation. Despite what clients ask, there’s no more a ‘best practice from a UX perspective’ than there is a ‘best recipe from a cookery perspective’.
“Give me six hours to chop down a tree and I’ll spend the first four sharpening the axe.” – Abraham Lincoln
It’s about research, understanding, and evaluation. Figuring out the right problem to solve, before dipping into our toolbag of methods and patterns to solve it.
Read the post at Medium