hharnisc.github.io

Twilio Console: A Large Scale Migration to Jamstack

2021-10-05T00:00:00+00:00

Twilio’s sustained growth over the last decade has led to several architectural iterations of the Twilio Console. With each iteration, comes changes to handle the biggest problems of the time. The next generation of the Twilio Console is no exception! In this talk, we’ll walk through why and how we went about migrating from the legacy Console to the new Console experience safely (spoiler, iframes were involved) and the impact this has had on our customers and the organization.

Transparent Salaries

2020-02-15T00:00:00+00:00

Transparent salaries have come up again in Tech Twitter under the #KnowYourWorth hashtag. There is interesting discussion going on around why are there compensation differences between US and non-US salaries, is sharing your salary a good idea? and selection bias. I’d also like to share some of my personal experiences as someone who’s had their salary posted publicly (while at Buffer) and worked at companies who are less transparent about salaries. Please note that these are my own opinnions and I belong to a group that is both privledged and overrepresented in tech.

#KnowYourWorth

Let’s start with this Tweet:

Pay inequality is a big problem in tech, especially for underrepresented groups like women and minorities. The best way you can help is by sharing yours. I’ll go first.

🏫: B.A. - C.S.
⏳: 5.5 years
🏷: Staff/G06
🌎: NYC
💸: $205k base, $500k equity over 4 yrs#KnowYourWorth
— Zac Sweers (@ZacSweers) February 14, 2020

Lots going on here so lets dig in. (Sorry in advance for being intrusive Zac)

Location

Location is probably the single biggest factor in compensation. Zac lives in New York, which has one of the highest (if not the highest) cost of living in the US at 129% higher than the national average. If you’re curious, this post about what its like to make 6 figures in NYC is enlightening. NYC has a very healthy tech scene (second only to the Bay Area), so there are usually multiple companies with competing offers for in demand software engineers.

When you compare compensation between EU and US it is not an apples to apples comparison. In the US, healthcare is privitized and there are much less social programs that act as a safety net. Public transit is either non-existent or needs major improvements in every US city. There’s too much to say for a single blog post here, so the TL;DR is that EU salaries are going to look low since it’s hard to get a decent comparison of benefits.

Responsibilities

Someone with the title of Staff Engineer (usually) has to work accross teams, is solving problems on the scale of years and is a mentor/guide to multiple engineers. Every role is different, but a good Staff Engineer brings a huge amount of value to a company, they are a force multiplier in some sense. One very rough way to get a sense of an employee’s value is to look at the average amount of revenue per employee and compare. Zac works at Slack, so I grabbed the best numbers I could find:

$140 million annual revenue / 1700 employees = $82,352.94 rev per employee per year

This number can be impacted by a number of things including the percentage of engineers, public perception and numerous choices made by C level execs. What we can do with this number is to compare it to Zac’s yearly compensation.

(($500k / 4 years) + $205k) / $82,352.94 = ~4.0071

So Zac’s salary represents the yearly revenue generated from about 4 engineers. Which, so long as Zac is fulfillng the responsibilities of a Staff level engineer, makes sense. A good Staff Engineer is going to influence 100s of not 1000s of decisions at a company during their tunure.

Comparitively, Buffer which operates differently to Slack, has a revenue per employee closer to $250K:

Here are the @Buffer financials / metrics for October 2019.

- We crossed a key milestone of $22m in ARR 👌
- Our highest monthly growth rate in around 1.5 years 🚀

Thread with more thoughts ⬇️ pic.twitter.com/LdIWuISagr
— Joel Gascoigne (@joelgascoigne) November 13, 2019

There are a number of reasons to have a high revenue per employee – it is much easier to be cash positive (humans are expensive) and it affords you more choices. Too much revenue per employee and you leave opportunites on the table (or off depending on where you’re from). This is all important context when you’re negotiating your salary if you have this information availible.

In my opinnion it is the right thing to do, but it should not be your responsibility as an employee. Hiding salaries is an excuse to pay people differently for the same job and is an easy place for bias to impact compensation. With transparent salaries, candidates can see compensation up front and waste a lot less of everyone’s time. Instead of individuals posting salaries it would be better to share detailed reports of salary information like Buffer does. This takes the burden off of employees, especially those from underrepresented groups, and places it on the company.

There are arguments to be made that your current salary can be used against you, but would you want to work for a company that does that? It seems like a red flag that the company doesn’t treat employees very well. I’ve had the opposite experience in that I could reference my compensation at my previous role with clear signals early on “we can’t pay you at that rate” or “we’re in the right ballpark and can be competetive”. This was my experience and your milage will vary.

Selection Bias

As you’re reading the #KnowYourWorth posts remember that there is selection bias going on. You’re more likely to get people who are proud or upset with their salaries and people who live in SF or NY. So if you’re reading these and getting upset, keep in mind that you’re probably seeing people who are on some extreme, the outliers. Chances are you’re doing well, especially when compared to other industries.

Effective Syncs With Distributed Teams

2019-06-02T00:00:00+00:00

Over the past few years I’ve participated or lead syncs in fully distributed, partially distributed and centrally located teams. I’ve learned that doing effective syncs in a distributed team is similar to doing them in a centrally located team. However, there are a few differences that make distributed team syncs a little more difficult than a centrally located team sync. I’ll share a process that has been borrowed from many different sources and tweaked over time with new teammates and companies.

Why Do This?

Effective syncs lay the foundation for strong communication channels and opportunities to build trust between team members. When everyone understands the shared goals and knows what they need to do, the team can move in the same direction. Getting everyone aligned is arguably one of the most important goals of any team or organization since it reduces wasted effort and increases velocity. A great deep dive on this subject is Good to Great: Why Some Companies Make the Leap…And Others Don’t by Jim Collins, which provides several case studies on companies that have exhibited these behaviors sustainably.

Define The Process

The first step to laying the foundation for communication and trust is to define a process to run team syncs. The driver for the meeting should be a real time collaborative document like Google Docs, Notion or Dropbox Paper. This is important because it allows the entire team to follow along and participate before, during and after the meeting. Participants should join the call individually and preferably on a headset to keep the noise down.

Before

If you don’t already have a shared document, create one with the template below. If you do have a shared document create a new entry at the top of the document with the same template. Update the YYYY-MM-DD with the date the sync will take place. Share this with all the participants as early as possible and ask team members to add agenda items. It’s also best practice to create a recurring weekly meeting with a link to the agenda. Syncs should last between 30 minutes (for teams around 4) and no longer than an hour (for teams around 8). The longer agenda items are on the list will mean that agenda items get more exposure. Participants will have more time to think about each item. About an hour before the meeting prompt participants (a calendar or slack reminder is great for this) to add missing agenda items to the list. Five minutes before the meeting starts send out the link for the video call in a shared channel.

During

The meeting leader should start the meeting on time, this is a signal that peoples time is respected – also late participants can catch up with the meeting notes. Starting at the top of the agenda, clearly state the contents of the agenda item and ask the person who wrote it if they would like to provide more context. Some agenda items can be announcements while others may require more discussion or possibly be an action item for next week. The leader should help guide the conversation if it gets off topic or unproductive. The timekeeper should be providing signals for spending too much time on a given topic. The recorder should be writing down what was talked about and adding action items.

There are few recurring agenda items that serve as a reminder to ensure that the current and future meetings go smoothly. Before talking about this weeks agenda items the team should choose meeting roles (other than the leader) and go through the status of last weeks action items. If any of the action items from last week remain they should be moved to the next weeks action items or chosen not to be done by the team. After this weeks agenda has been talked through the team should go through next weeks action items. The goal is to make sure each action has someone assignee and the list is prioritized. This helps each team member understand their next tasks. The very last item should be to choose a leader for the next week.

After

If there are action items that are related to longer term goals, the leader should link the action item to the longer term goals. (This depends on how longer term goals are communicated and prioritized) The leader should also create the next weeks agenda with the date of the next sync and share it with the team. As each team member completes their respective action items, they mark the item complete with the checkbox. This allows everyone to track progress and quickly communicate status. During the week as team members think of things to talk about they can add items to the shared agenda for the next week.

Template

Here’s a template written in Markdown that can be used to drive distributed team syncs:

# YYYY-MM-DD

## Agenda

Meeting leader: @harrison

- [ ] choose meeting roles (other than leader)
- [ ] go over last weeks action items
- [ ] **add action items here**
- [ ] make sure this weeks action items have an assignee and are prioritized
- [ ] choose meeting leader for next week

## Notes

- What did the team talk about?
  - some more context

## Action Items

- [ ] Action items from the meeting @harrison

Meeting Roles

Shoutout to @vaurorapub for teaching us about meeting roles while at Buffer.

There are a few variations of this but there are essentially four roles:

The Leader

Develops the agenda, guides the group through the meeting and ensures that the team has equal speaking opportunities.

The Recorder

Ensures everyone has access to the agenda (before, during and after), takes notes during the meeting and records action items during the meeting.

The Timekeeper

Ensures that the team is spending the appropriate amount of time on each agenda item. When agenda items go long, this person can interject and request an action item for a followup meeting or move on if the conversation is unproductive. The timekeeper can also contribute to the conversation.

The Participant

Understands the agenda before the meeting and clarifies agenda items that they added during the meeting. Contributes to the conversation around agenda items.

For a more in depth description here an article that goes in detail on each meeting role.

Gotchas

Here are some gotchas that I’ve experienced with some ideas on how to address each one. You might find some of your own along the way depending on your team and company.

Large Teams

With team syncs larger than 8, the number of agenda items and amount of discussion around each item tend to grow. This makes it difficult to have meetings under an hour. Through personal experience, 1 hour is the maximum amount of time you can keep the attention of a small group. If possible, the best thing to do is to split the group into smaller teams. It’s likely that there is already a natural point of division in work.

Partially Distributed Teams

In a partially distributed team, some members work in a central location while others are working “remote”. The “remote” team members end up getting treated second class (likely not on purpose) and it is more difficult to contribute to the sync. Some of the difficulties can be fixed by enabling team members from the central location to work from home so they can get the “remote” experience. People will quickly point out things like the audio quality is not good enough with a single laptop in the center of the room and every time I try to talk I get cut off. Some things can be solved with better tech while others are solved with empathy from being “remote”.

Timezones

When a team is split in very difficult timezone splits (8 hours apart or more) it can be difficult to find a time that works for everyone. There are tools that can help you find the best time for example: https://www.timeanddate.com/worldclock/meeting.html When the best time ends up being a bad compromise for everyone it can be helpful to ask teammates if they are ok with an early or a late meeting. Someone being a morning person or a night owl can make all the difference! The best solution might be to alternate between ideal timezones for different teammates.

While this process has been tested in a few different companies and team setups, it should be viewed as a starting point for your own team syncs. Every team is going to be different and what works for one might not work for another. It’s important to listen to the team and use their feedback to improve the process. If you do make changes, it is best to change one thing at a time and observe. Using the scientific method you can keep doing things that are working and revert things that are not until you’re happy with the process.

Getting The Most Out Of Kubernetes

2018-12-11T00:00:00+00:00

So you’ve carefully crafted your first Kubernetes service, and you’re ready to deploy it to production. Well, not quite: there are still some important unknowns to understand before your service will be ready for production traffic. It’s still unclear how the new service behaves when it’s being pushed, and it’s possible that Kubernetes will kill the service before serving a single request. While at Buffer, we developed a technique to optimize Kubernetes deployment limits by using load testing to identify optimal values for resource limits. When the service is under heavy load there are a few key metrics to watch to identify bottlenecks. These key metrics can be used to adjust resource limits. This real world approach allowed us to safely and efficiently switch our production traffic to our Kubernetes cluster and can be applied to any application.

20 Questions To Ask Before Joining A Startup

2018-11-25T00:00:00+00:00

When I first joined a startup in 2012 I did my best to ask the right questions when interviewing. My engineering background prepared me for engineering tasks and helped me write a resume, but it didn’t prepare me well for how to evaluate a startup offer. While this might be obvious to some, this is what I wish I knew when trying to break into the startup scene.

Foundation

Making sure you’ve got what you need in your day to day is critical. Unless you are independently wealthy, don’t take a job that can’t cover cost of living or does not provide health insurance. This means you need to spend some time to create your monthly budget (good to do this even if you aren’t interviewing). A good rule of thumb is 25% of take home pay should go towards housing and up to 40% in the Bay Area. 40% can be done if you minimize costs like going out or have a second income.

If the job requires relocation it is very common for startups to offer relocation packages. I’ve moved across the country twice and it cost around $3000-$6000 for things like:

relocation cubes (https://www.upack.com/)
shipping a car (https://www.uship.com/vehicles/)
if not shipping a car, hotel while traveling
food while traveling
hotel for a few nights while finding more permanent housing
registration fees (license plate, sticker, etc.)

Both times we moved we packed ourselves, which we could do because we were both healthy 20 somethings. So adjust if you plan on hiring movers.

What is the base yearly salary?
What are details of the health, eye and dental insurance plans?
Does the company offer relocation? (if you need it)

Equity

The amount of equity in the offer depends on experience and the stage of the company. This part of the guide will focus on options, since at the time of writing options are the most common way for startups to offer equity. Here’s an article on how options work.

The first goal is to understand the percentage of shares the company is offering. It is pretty common to get a written offer with the raw number of shares. While helpful, this is only part of the equation, since the number of shares doesn’t mean much if there are hundreds of millions of shares already issued.

Here’s a nice formula from Buffer that shows one way of determining startup equity amounts: https://open.buffer.com/buffer-open-equity-formula/. This formula is helpful because it takes risk into account by considering the number of people in the company. The smaller the company the larger amount of risk, and a greater reward if things work out.

Lets say you’re a relatively new engineer (2-3 years experience) and joining a company with less than 10 employees. A fair amount of equity would be likely be around 0.3% - 0.7%.

In the recent years it has become more common for companies offer a 10 year exercise window on stock options. This means employees have 10 years to decide to buy or pass on stock options once they’ve vested, which is a great! However it is still pretty standard to see a 90 day exercise window. The effect is that after leaving the company, employees have to make the decision to buy or pass up on purchasing vested stock options. This could be a difficult choice for someone who doesn’t have much cash on hand. Companies that have shorter exercise windows end up benefiting the people who are present during an exit. Here’s some more information if you’re interested in learning more: https://blog.colony.io/on-creating-a-better-employee-equity-plan-d89bcab4a4e2/

It is also important to note that early employees experience more dilution events. An example of a dilution event would be raising another round of funding. This is another reason why joining a company early should offer more equity. If you joining a company around a Series A raise, you can usually expect to see around 20% - 30% dilution.

The next item to consider is the strike price, which is the purchase price for the options when they vest. The strike price is often determined by the board, so it might not be possible to get this before starting. What’s important about the strike price is that it is the starting point, so the company needs to grow for you to make money from selling options. If you can’t get the strike price, make sure you believe the company will grow. Early employees often get a better (lower) strike price, to compensate for the risk.

After understanding the percentage of shares the company is offering and the number of issued shares, it is possible to get an idea of the potential value of the options. Here’s a helpful startup equity calculator: https://comp.data.frontapp.com/

Most importantly, the majority of startups fail. The equity could be worth nothing, which is another reason why it is so important to have a strong foundation.

How many total options are offered?
What is the total number of issued shares?
What is the vesting schedule?
What is the exercise window of vested options?
What is the strike price? (You might not get an answer to this one)

Funding

There are many factors in startup funding to consider. While getting information about cash on hand and burn rate are important, it is beneficial to understand who is investing along with some history on their past investments.

Let’s start with the basics. Ask for total amount of funding, how much cash the company has on hand (preferably that day) and the burn rate. With this information you can get a picture of the scale the company is operating as well as how quickly they’re spending cash.

After learning about operating costs and spending, dig into who has invested into the company. The investors can have a profound impact on the company culture and the direction of the company. Tools like AngelList and Crunchbase provide information about previous investments. Individual investors can usually be found on LinkedIn.

While it may seem a bit forward, ask if the company has failed to make payroll in the last year. If they have struggled to make payroll in the past, this makes choosing the startup a riskier venture and might be a signal that the founders are having trouble raising money.

What is the total amount of funding raised?
How much cash is on hand?
What is the [burn rate](https://baremetrics.com/academy/burn-rate)?
What round of funding has the company raised?
Who has invested in the company?
In the last year has the company failed to make payroll?

Board

Just like the investors, the board can have a huge impact on the direction of the company. Determining if the board is healthy for the company is difficult because it is highly subjective. Basically it comes down the deeply unsatisfying it depends.

When evaluating the board, look for an imbalance in power (or control). If an individual or closely connected group on the board can lock or overturn a decision themselves there is a higher chance that the board is unhealthy. A board with concentrated power is almost the same as an individual making all the decisions. Concentrated power is not objectively bad, especially if you know the people with control well and trust that they will do the right thing.

15. Who is on the board of directors and how many seats does each member have?

Responsibilities

A big perk of working at a startup is that the projects are high impact and the people are often at a high bar. There’s not much room to work on things that are unimportant to the business or for people who can’t pull their own weight. People often describe working at a startup like packing ten years into a single years worth of learning. Even if you’re a deep expert in a niche field, daily learning will be critical to get things done. Make sure the prospective projects are interesting and will take your career in the desired direction. If you’re not sure what direction to take your career, chose a role that will expose you to lots of different ideas you might be interested in. It is not uncommon for someone to find something they love doing and become the person who owns a set of problems or services related to that thing.

Startups change at an accelerated pace and is typical for projects to get cancelled (sometimes before the first day!). To get a feel for how often things change, ask questions about product market fit. It is critical that the company is working closely with customers to understand they are solving the right problem. Working with the customer can look like doing customer research, support forums (yes engineers do support sometimes at startups) or some other direct line of contact with the customer. If the company has already identified a product that fits the market, the engineering team is going to be solving whatever problems it needs to in order to build the product. If the company has not found a good fit yet, the focus will be on finding the right problem to solve. The process is commonly referred to as a pivot and will likely change the engineering team’s focus.

After gaining insight on future projects the next step is to get to know potential teammates. Hopefully the company involves potential teammates in the the interview process so you can meet them and ask questions. If the company doesn’t do this you can usually ask to meet with them, especially if they extend you an offer. Consider it a red flag if they won’t let you speak to a potential co-worker. Keep in mind that you’ll be spending lots of time working with these people, so you’ll want to pretty sure that these are people who you can get along with. That’s not to say that everyone will be your new best friend, but there should be a mutual respect. This is one of those occasions where you get to choose who you surround yourself with, so make sure these are quality people. If you get a bad feeling about someone, trust your gut here, there are lots of other startups!

What projects do you picture I'd work on?
Has the company found product market fit?
How does the company collect feedback from customers?
Who would I be working with to complete the projects?
Ask each new potential teammate:
What do you work on?
What about your role are you enjoying?
What could the company improve on?

Technically there are 23 questions but I grouped the last one together as a question for new potential teammates. Also 23 questions to ask before joining a startup didn’t have as good a ring to it.

I’d like to add a couple of notes before you go off and send this list of questions to potential employers. Try to get as many questions answered conversationally during the interview and save the unanswered questions for the end. It is ok to send a list of unanswered questions if time ran out during the interview.

It is unlikely that the interviewers will be able to answer every question for a number of different reasons, ranging from don’t know to I can’t answer that. It might be helpful to mark the questions that are important to you. For instance you might care a lot about equity but not care as much about the board structure since you know the founders very well.

This is not the definitive list of questions for everyone but more of a generic starting point. If you took this list and added questions based off your personal experiences you’d be in a better position to pass or accept an offer than if you used only these questions.

Finally, and most importantly, trust your gut. If you get to the interview and something feels off, it probably is. Just because a startup is doing well doesn’t mean they have their shit together. There are 1000s of startups to choose from and spending a little extra time to find the right one is worth the effort.

Remote Work Matters For Communities

2018-10-26T00:00:00+00:00

A few weeks ago, @rrhoover sent out a poll asking what people find most important when looking for a job, and remote work came out on top by a wide margin. The results were hardly surprising to me. Watching the discussion about health, parenting and general freedom it sparked, I found myself thinking that’s true - but that’s not it. That’s not why remote work is changing our world for the better.

Let's say you're looking for a new job. What's most important to you? 🤔
— Ryan Hoover (@rrhoover) September 14, 2018

Now this poll isn’t exactly a scientific study - it excluded a few things most people value like fair pay, a strong and ethical team, worthy mission etc. But then I’m not a scientist, and the point is, people care a lot about being remote workers themselves. That’s cool. But we’re missing out on that bigger picture why as a society, we should be supporting companies that do remote work.

Remote work is not without trade-offs, and it’s not for everyone. That said, there are some non-obvious benefits that can make the world a better place - more than just getting rid of your morning commute.

My first experience with remote work was at Respondly (since acquired by Buffer) mostly working with other people who were working remote. I was living in the Bay Area with teammates in New Zealand, Germany and other cities in the US. Up to that point I had only worked with local teams in an office and had no expectations. The only real difference I felt was the adjustment to written communication, since I am primarily an audio learner. This was quickly overcome and often better since it is possible to search through all previous conversations.

Fast forward a couple years and I’m working remotely 100% of the time. I’ve moved away from the Bay Area and still have a fulfilling job in tech. While it hasn’t been easy 100% of the time, I’ve managed to stay disciplined with my schedule. I haven’t fallen into the sweatpants every day trap you sometimes hear people talk about with remote work (there are days though 😂). I spend time at the local coffee shops, the library and a few restaurants and bars with wifi.

Investment In Communities

If you think of spending money as a small vote every time you spend it, getting a coffee can be an investment. When you spend money at the local coffee shop more of it stays in the community longer if you compare spending at Starbucks or having coffee delivered from Amazon.

The effect is that tech companies are investing in the communities where the employees live. Over the long term this could open up other opportunities in small towns with a big remote working presence. Some towns have already started to catch on, even offering $10,000 to live there so long as you work in another state. The added opportunities will give people more options, rather than needing to live in a city. This isn’t to say that everyone should work in a distributed team or live in a small town, just that if you can do you job from anywhere it should be your choice where to work.

Being Part Of The Community

When you spend time in the community you have to interact with other humans (weird right?!) and conversations happen where ideas are exchanged. This works best when people have different ideas. Tech centers like the Bay Area (and cities in general) have created pockets of like minded people – in both cities and the people who stayed in small towns. You could go political and point out that a lot of problems happen when these groups feel like they’re on different sides. In reality, it ends up being an imaginary line that separates people.

Giving people the option to stay in their communities is important, and this tweet sums it up perfectly:

Hey tech companies, you want to have a positive influence on society and politics?

Let people work remotely from their home towns

Let people vote in the communities where it matters most

Let them contribute to those local economies

Let them support their extended families
— ɥɔɐoɹ (@roach) October 6, 2018

This all makes me hopeful that things are going to keep getting better, so long as we can keep working together to make this a thing.

Special shout out to @katie_womers for suggestions and edits!

We Wrote A Book: Atomic Migration Strategy For Web Teams

2018-07-09T00:00:00+00:00

It all started at Fluent Conf 2017 with a talk I gave on Migrating With Atomic Design. After the talk I was approached by O’Reilly and asked if I wanted to turn the talk into a book. My initial reaction was hell yes, followed quickly by what did I just agree to 😱. I’m an audio learner and a slow writer, so writing does not come natural to me. However, I really wanted to write a book since I’d never done it before and it seemed like a challenge that would push me outside of my comfort zone. I’d love to share how I went about writing and what went into writing a book with a publisher.

Getting Help

When thinking about what we had to do at Buffer to get the migration process going, the more I realized this book needed more than the engineering perspective. The migration would not have happened without Katie Womersley’s tirelessly advocating that a migration was the right thing to do right now. Atomic Migration Strategy for Web Teams needed her perspective, to tell the whole story and be useful. So I asked if she wanted to co-author the book (she said yes 🙌). So we set out and created the outline and submitted the proposal to O’Reilly.

Actually Writing

The writing process, not including editing, took about 5 months to complete between October 2017 and February 2018.

Writing is very draining for me, so my approach to writing is very much about energy management. I had to write every day in the morning, when my mind was most clear and energy was at the max. Looking at the commit data from gitstats on the repository you can see that most of the commits were around 9-10 AM:

Taking a look at the same hourly view across the week you can see that later in the week I’d get started a little later, closer to 10-11 AM:

Other than Sunday there are basically zero after hours commits, which I guess that makes Katie and I morning people 🤷

Katie’s writing style was very different from mine, she would write an entire chapter in one sitting! You wouldn’t see as many commits, but you would see larger diffs in her commits. At one point we talked about if our different approaches to writing stressed each other out, her writing large occasional chunks and me with small daily changes, and we realized we were both writing in the most effective way that worked for us.

We wrote the book in an O’Reilly tool called Atlas. Atlas is a web application that allows you to write rich text (and a few other formats) and is powered by GIT. It was pretty good working with Atlas, though it had a few minor quirks in the editor. We chose the HTML editor, however I wish we could have had markdown as an option. Since the book was stored in GIT you could clone the repository locally and work in whichever text editor you like and even keep a copy for yourself in Github. Overall the experience was positive and I would totally use Atlas again to write a book.

Most of the book was written from the local coffee shop Blackberry Market. I work remotely and enjoy working the first half of the day with this view:

Review and Edit Process

After writing the initial copy we moved to the review and edit process. This took a couple months to get to after the writing process since the person responsible for our book was transitioning out of the company, the person who took over did an awesome job and picked things up right away. Editing took about 1 month starting in May 2018 and ending in June 2018.

This is where O’Reilly goes through your ~~code~~ copy, finds your spelling mistakes and calls you out on your grammatical errors made during moments of weakness. Actually the editors were super friendly and made wonderful suggestions that made the book so other people could read it. I am not great at spelling, anyone who looks at my source code comments can attest to this. Some of the grammatical errors I made also made me question my literacy, but hey, we made it through the process!

Publishing

We made it to the publishing phase 🎉🎉🎉 itshappening.gif (I won’t actually leave the GIF here since its the most distracting thing ever created)! The book was published as an ebook on Safari and was done with the same level of quality that you’d get with a paper copy of the book. My only regret is that we did not get an animal on the cover (I would have picked wolf). If the ebook does well we might get to expand on it and turn Atomic Migration Strategy for Web Teams into a hard copy (and hopefully get that wolf cover). But I could not be more happy than how it all turned out, 5 years ago I could not have told you I’d ever be interested in writing a book. Now I’m already thinking about the next one 🙃

Synopsis for Atomic Migration Strategy for Web Teams:

Atomic Design, created by web designer and consultant Brad Frost, is a system for working with the fundamental building blocks—the atoms—of modern web interfaces. This guide provides hands-on instructions for stitching these simple components together to rewrite your application in a low-risk and nondisruptive way. While the ebook’s examples focus on migrating a frontend application, you can also use these techniques for mobile and backend applications.

Here’s a link to the book on Safari: Atomic Migration Strategy for Web Teams we’d love a review if you get a chance to read the book. Any feedback is super helpful, especially if we get a chance to expand or release future editions!

Making The Case For Frontend Monorepos

2018-06-15T00:00:00+00:00

The industry is shifting to smaller, simpler components with ideas like microservices and component driven development. Monorepos keep all of the related code in one place, which might seem incompatible with with the shift towards modularization. However, in practice, the opposite is true – monorepos allow you to use a standard set of tools and make related changes across components.

Here are the slides for the talk “Making The Case For Frontend Monorepos” I gave at SyntaxCon 2018

The Optimist’s Guide To Coding

2018-01-29T00:00:00+00:00

Scrolling through my twitter feed, I saw Tweet about how software engineers seem to become less happy over time with coding. Personally I’ve been coding stuff in some capacity for a little over 22 years and still enjoy it just as much as those early days. It made me think about why coding is still fun and seemed like a great opportunity to share some of the things I do to keep it that way.

Looking at my twitter feed, it feels like the longer you've been coding professionally, the less you actually like coding.

For people who've been coding for 10+ years, is this how you feel?
— Saron (@saronyitbarek) December 29, 2017

Dedicate “Work” Time For Learning Every Day

I spend 30-60 minutes at the start of each work day either learning something new or writing about something I recently learned. It is important that this be time set aside from working hours rather than your personal time. I keep finding over and over that a skill I learned last month or last year ends up being super useful today. It is more of an investment and takes a bit for it to pay off. Some examples of learning projects I’ve done in the past:

Build a hello world React app
Implement merge sort in an unfamiliar language
Take a storytelling class on Kahn Academy

Surround Yourself With People Who Are Excited

Excitement tends to be infectious. When you’re around a group of people who are enthusiastic about what they’re doing, it tends to rub off. Sometimes it is the little extra push that keeps you motivated to get through a challenging problem. Often times these end up being the people who inspire you to learn something new - providing ideas for the 30-60 minutes of daily learning time.

Be A Mentor

Few things in software are as rewarding as guiding others through their software engineering journey. Pairing with teammates helps your teammate learn while reinforcing your own skills. More often than not, your teammate will surprise you with the way they solved a problem or used a library you’ve never seen. Most importantly you’re helping someone else level up their skills and grow as an engineer. Over time you’ll end up being surrounded by people who want to learn and grow!

Stop Doing Things That Aren’t Working

Over the years, ideas around software come along that seem great at first glance but end up doing more harm than good. One example is the “Software Craftsman” concept. I found that always striving for producing high quality software was making me think more about how to structure the code than the problem. I was over thinking things and spending too much time on problems where a quick and hacky solution would have been enough.

As a general trend, ideas that always push farther into the perfectionist mindset seem to decrease my levels of happiness. When I started spending more time thinking about the level of quality a project needed, I felt a sense of purpose in why I was coding with high quality – I could justify what I was doing. Done is better than perfect but perfect is never done.

…

Keep building things that interest you and keep learning! The world has enough consumers but never has enough builders and doers.

How I Hacked My Schedule To Get 3 Days Of Deep Work A Week

2018-01-08T00:00:00+00:00

Over the last year my role at Buffer has changed from an individual contributer to a technical leadership role. While the amount of time I spend coding and doing architecture hasn’t changed much, the way I go about the tasks has changed significantly. Instead of being focused on a project from start to finish, I move around projects as needed. Sometimes a team will get blocked on a tricky problem or need to make a decision that could impact other teams or request technical mentor-ship to level up their skills. I’ll jump in and provide technical context (when I can) and try to help in a why that will reduce the reliance on myself.

The goal is to teach and automate myself out of a job!

A couple of challenges started to crop up as the scope of projects increased. The first was that the frequency of random questions increased. It is important to note that Buffer is a fully distributed team with no physical office, so the random questions come in the form of private Slack messages. 99% of the questions fell under the important but not urgent category (sometimes they’d find the answer after a bit of searching 🙌). Another challenge was that some teammates thought they couldn’t ask me questions because I wasn’t explicitly on their team. This led to questions being asked when things became urgent, and often required an expensive context switch. While working on cross-team projects, this was making very difficult to get things done. Especially when working on projects that span multiple teams, there is a huge amount of context that needs to be formed in your mind before you start solving the problem. Building context can take hours, only to be lost by a random interruption.

After some reflection I realized both of these problems were related. Cross team projects require a clear communication as well as long periods of Deep Work. Deep Work involves minimizing distraction to stay focused on a cognitively demanding task, which allows you to get the most of your time. If you’re interested in learning more about Deep Work, check out Cal Newport’s Deep Work: Rules for Focused Success in a Distracted World.

For me personally I can context switch within these two boundaries, but crossing the boundary between communication and coding is very difficult. With that realization, combined with the observation that most of the questions I was getting were non-urgent I reorganized my schedule:

	Monday	Tuesday	Wednesday	Thursday	Friday
Pairing, syncs, etc.	X				X
Deep Focus Work		X	X	X

I’ve been doing this since mid November and have already noticed some changes:

Teammates from multiple teams have requested pairing sessions
The number of non-urgent questions has gone down (almost to 0)
Urgent communication is much more visible through Slack
I’ve been able to complete several long standing tasks

It is important to note that deep work time can be interrupted by things that are both urgent and important. Ignoring pager alerts would be bad for everyone! However, treating every question as urgent is likely to do more harm than good. Depending on how you work, this may or may not work for you. I chose to organize my schedule this way to minimize the type of context switches that were holding me back and make time for important things like pairing/mentoring. Being able to organize your own schedule is a wonderful perk of remote work. Figuring out what works for you can be a challenge, and can even change over time. It’s more than setting aside time for work, its also deciding what you’ll do with the time you set aside.

hharnisc.github.io

Twilio Console: A Large Scale Migration to Jamstack

Transparent Salaries

#KnowYourWorth

Location

Responsibilities

Is Sharing Your Salary A Good Idea?

Selection Bias

Effective Syncs With Distributed Teams

Why Do This?

Define The Process

Before

During

After

Template

Meeting Roles

The Leader

The Recorder

The Timekeeper

The Participant

Gotchas

Large Teams

Partially Distributed Teams

Timezones

Getting The Most Out Of Kubernetes

20 Questions To Ask Before Joining A Startup

Foundation

Equity

Funding

Board

Responsibilities

Remote Work Matters For Communities

Investment In Communities

Being Part Of The Community

We Wrote A Book: Atomic Migration Strategy For Web Teams

Getting Help

Actually Writing

Review and Edit Process

Publishing

Making The Case For Frontend Monorepos

The Optimist’s Guide To Coding

Dedicate “Work” Time For Learning Every Day

Surround Yourself With People Who Are Excited

Be A Mentor

Stop Doing Things That Aren’t Working

How I Hacked My Schedule To Get 3 Days Of Deep Work A Week