{"generator":"Jekyll","link":[{"@attributes":{"href":"https:\/\/blog.harrison.dev\/feed.xml","rel":"self","type":"application\/atom+xml"}},{"@attributes":{"href":"https:\/\/blog.harrison.dev\/","rel":"alternate","type":"text\/html"}}],"updated":"2021-10-08T15:07:46+00:00","id":"https:\/\/blog.harrison.dev\/feed.xml","title":"hharnisc.github.io","subtitle":"Jekyll source for personal blog.","entry":[{"title":"Twilio Console: A Large Scale Migration to Jamstack","link":{"@attributes":{"href":"https:\/\/blog.harrison.dev\/2021\/10\/05\/twilio-console-jamstack-migration.html","rel":"alternate","type":"text\/html","title":"Twilio Console: A Large Scale Migration to Jamstack"}},"published":"2021-10-05T00:00:00+00:00","updated":"2021-10-05T00:00:00+00:00","id":"https:\/\/blog.harrison.dev\/2021\/10\/05\/twilio-console-jamstack-migration","content":"<p>Twilio\u2019s 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\u2019ll 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.<\/p>","author":{"name":{}},"summary":"Twilio\u2019s 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\u2019ll 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."},{"title":"Transparent Salaries","link":{"@attributes":{"href":"https:\/\/blog.harrison.dev\/2020\/02\/15\/transparent-salaries.html","rel":"alternate","type":"text\/html","title":"Transparent Salaries"}},"published":"2020-02-15T00:00:00+00:00","updated":"2020-02-15T00:00:00+00:00","id":"https:\/\/blog.harrison.dev\/2020\/02\/15\/transparent-salaries","content":"<p>Transparent salaries have come up again in Tech Twitter under the <a href=\"https:\/\/twitter.com\/search?q=%23KnowYourWorth\">#KnowYourWorth<\/a> hashtag. There is interesting discussion going on around why are there compensation differences between US and non-US salaries, <em>is sharing your salary a good idea?<\/em> and selection bias. I\u2019d also like to share some of my personal experiences as someone who\u2019s 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.<\/p>\n\n<h2 id=\"knowyourworth\">#KnowYourWorth<\/h2>\n\n<p>Let\u2019s start with this Tweet:<\/p>\n\n<blockquote class=\"twitter-tweet\"><p lang=\"en\" dir=\"ltr\">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\u2019ll go first.<br \/><br \/>\ud83c\udfeb: B.A. - C.S.<br \/>\u23f3: 5.5 years<br \/>\ud83c\udff7: Staff\/G06<br \/>\ud83c\udf0e: NYC<br \/>\ud83d\udcb8: $205k base, $500k equity over 4 yrs<a href=\"https:\/\/twitter.com\/hashtag\/KnowYourWorth?src=hash&amp;ref_src=twsrc%5Etfw\">#KnowYourWorth<\/a><\/p>&mdash; Zac Sweers (@ZacSweers) <a href=\"https:\/\/twitter.com\/ZacSweers\/status\/1228205724255154177?ref_src=twsrc%5Etfw\">February 14, 2020<\/a><\/blockquote>\n\n<p>Lots going on here so lets dig in. (Sorry in advance for being intrusive Zac)<\/p>\n\n<h3 id=\"location\">Location<\/h3>\n\n<p>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\u2019re curious, this post about <a href=\"https:\/\/www.businessinsider.com\/what-its-like-living-in-new-york-100000-salary-reality-2019-2\">what its like to make 6 figures in NYC<\/a> 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.<\/p>\n\n<p>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\u2019s 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\u2019s hard to get a decent comparison of benefits.<\/p>\n\n<h3 id=\"responsibilities\">Responsibilities<\/h3>\n\n<p>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\u2019s 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:<\/p>\n\n<div class=\"language-plaintext highlighter-rouge\"><div class=\"highlight\"><pre class=\"highlight\"><code>$140 million annual revenue \/ 1700 employees = $82,352.94 rev per employee per year\n<\/code><\/pre><\/div><\/div>\n\n<p>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\u2019s yearly compensation.<\/p>\n\n<div class=\"language-plaintext highlighter-rouge\"><div class=\"highlight\"><pre class=\"highlight\"><code>(($500k \/ 4 years) + $205k) \/ $82,352.94 = ~4.0071\n<\/code><\/pre><\/div><\/div>\n\n<p>So Zac\u2019s 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.<\/p>\n\n<p>Comparitively, Buffer which operates differently to Slack, has a revenue per employee closer to $250K:<\/p>\n\n<blockquote class=\"twitter-tweet\"><p lang=\"en\" dir=\"ltr\">Here are the <a href=\"https:\/\/twitter.com\/buffer?ref_src=twsrc%5Etfw\">@Buffer<\/a> financials \/ metrics for October 2019.<br \/><br \/>- We crossed a key milestone of $22m in ARR \ud83d\udc4c<br \/>- Our highest monthly growth rate in around 1.5 years \ud83d\ude80<br \/><br \/>Thread with more thoughts \u2b07\ufe0f <a href=\"https:\/\/t.co\/LdIWuISagr\">pic.twitter.com\/LdIWuISagr<\/a><\/p>&mdash; Joel Gascoigne (@joelgascoigne) <a href=\"https:\/\/twitter.com\/joelgascoigne\/status\/1194735213588312064?ref_src=twsrc%5Etfw\">November 13, 2019<\/a><\/blockquote>\n\n<p>There are a number of reasons to have a high revenue per employee \u2013 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\u2019re from). This is all important context when you\u2019re negotiating your salary if you have this information availible.<\/p>\n\n<h2 id=\"is-sharing-your-salary-a-good-idea\">Is Sharing Your Salary A Good Idea?<\/h2>\n\n<p>In my opinnion <strong>it is the right thing to do, but it should not be your responsibility as an employee<\/strong>. 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\u2019s time. Instead of individuals posting salaries it would be better to share detailed reports of salary information <a href=\"https:\/\/docs.google.com\/spreadsheets\/d\/11s9VSyf4yaYUsqBKLaVH78NL8wdl8gXoj5BGAzjIFuc\/edit#gid=671465451\">like Buffer does<\/a>. This takes the burden off of employees, especially those from underrepresented groups, and places it on the company.<\/p>\n\n<p>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\u2019t treat employees very well. I\u2019ve had the opposite experience in that I could reference my compensation at my previous role with clear signals early on \u201cwe can\u2019t pay you at that rate\u201d or \u201cwe\u2019re in the right ballpark and can be competetive\u201d. This was my experience and your milage will vary.<\/p>\n\n<h2 id=\"selection-bias\">Selection Bias<\/h2>\n\n<p>As you\u2019re reading the #KnowYourWorth posts remember that there is <a href=\"https:\/\/en.wikipedia.org\/wiki\/Selection_bias\">selection bias<\/a> going on. You\u2019re more likely to get people who are proud or upset with their salaries and people who live in SF or NY. So if you\u2019re reading these and getting upset, keep in mind that you\u2019re probably seeing people who are on some extreme, the outliers. Chances are you\u2019re doing well, especially when compared to other industries.<\/p>\n\n<script async=\"\" src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script>","author":{"name":{}},"category":{"@attributes":{"term":"Transparancy"}},"summary":"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\u2019d also like to share some of my personal experiences as someone who\u2019s 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."},{"title":"Effective Syncs With Distributed Teams","link":{"@attributes":{"href":"https:\/\/blog.harrison.dev\/2019\/06\/02\/effective-syncs-with-distributed-teams.html","rel":"alternate","type":"text\/html","title":"Effective Syncs With Distributed Teams"}},"published":"2019-06-02T00:00:00+00:00","updated":"2019-06-02T00:00:00+00:00","id":"https:\/\/blog.harrison.dev\/2019\/06\/02\/effective-syncs-with-distributed-teams","content":"<p>Over the past few years I\u2019ve participated or lead syncs in fully distributed, partially distributed and centrally located teams. I\u2019ve 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\u2019ll share a process that has been borrowed from many different sources and tweaked over time with new teammates and companies.<\/p>\n\n<h2 id=\"why-do-this\">Why Do This?<\/h2>\n\n<p>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 <a href=\"https:\/\/www.amazon.com\/dp\/B0058DRUV6\/\">Good to Great: Why Some Companies Make the Leap\u2026And Others Don\u2019t<\/a> by Jim Collins, which provides several case studies on companies that have exhibited these behaviors sustainably.<\/p>\n\n<h2 id=\"define-the-process\">Define The Process<\/h2>\n\n<p>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 <a href=\"https:\/\/docs.google.com\/\">Google Docs<\/a>, <a href=\"http:\/\/notion.so\">Notion<\/a> or <a href=\"https:\/\/www.dropbox.com\/paper\">Dropbox Paper<\/a>. 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.<\/p>\n\n<h3 id=\"before\">Before<\/h3>\n\n<p>If you don\u2019t 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 <code class=\"language-plaintext highlighter-rouge\">YYYY-MM-DD<\/code> 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\u2019s 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.<\/p>\n\n<h3 id=\"during\">During<\/h3>\n\n<p>The meeting leader should start the meeting on time, this is a signal that peoples time is respected \u2013 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.<\/p>\n\n<p>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.<\/p>\n\n<h3 id=\"after\">After<\/h3>\n\n<p>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.<\/p>\n\n<h2 id=\"template\">Template<\/h2>\n\n<p>Here\u2019s a template written in Markdown that can be used to drive distributed team syncs:<\/p>\n\n<div class=\"language-md highlighter-rouge\"><div class=\"highlight\"><pre class=\"highlight\"><code><span class=\"gh\"># YYYY-MM-DD<\/span>\n\n<span class=\"gu\">## Agenda<\/span>\n\nMeeting leader: @harrison\n<span class=\"p\">\n-<\/span> [ ] choose meeting roles (other than leader)\n<span class=\"p\">-<\/span> [ ] go over last weeks action items\n<span class=\"p\">-<\/span> [ ] <span class=\"gs\">**add action items here**<\/span>\n<span class=\"p\">-<\/span> [ ] make sure this weeks action items have an assignee and are prioritized\n<span class=\"p\">-<\/span> [ ] choose meeting leader for next week\n\n<span class=\"gu\">## Notes<\/span>\n<span class=\"p\">\n-<\/span> What did the team talk about?\n<span class=\"p\">  -<\/span> some more context\n\n<span class=\"gu\">## Action Items<\/span>\n<span class=\"p\">\n-<\/span> [ ] Action items from the meeting @harrison\n\n<\/code><\/pre><\/div><\/div>\n\n<h2 id=\"meeting-roles\">Meeting Roles<\/h2>\n\n<p>Shoutout to <a href=\"https:\/\/twitter.com\/vaurorapub\">@vaurorapub<\/a> for teaching us about meeting roles while at Buffer.<\/p>\n\n<p>There are a few variations of this but there are essentially four roles:<\/p>\n\n<h3 id=\"the-leader\">The Leader<\/h3>\n\n<p>Develops the agenda, guides the group through the meeting and ensures that the team has equal speaking opportunities.<\/p>\n\n<h3 id=\"the-recorder\">The Recorder<\/h3>\n\n<p>Ensures everyone has access to the agenda (before, during and after), takes notes during the meeting and records action items during the meeting.<\/p>\n\n<h3 id=\"the-timekeeper\">The Timekeeper<\/h3>\n\n<p>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.<\/p>\n\n<h3 id=\"the-participant\">The Participant<\/h3>\n\n<p>Understands the agenda before the meeting and clarifies agenda items that they added during the meeting. Contributes to the conversation around agenda items.<\/p>\n\n<p>For a more in depth description here <a href=\"https:\/\/www.conferencecalling.com\/blog\/meeting-roles\">an article that goes in detail on each meeting role<\/a>.<\/p>\n\n<h2 id=\"gotchas\">Gotchas<\/h2>\n\n<p>Here are some gotchas that I\u2019ve 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.<\/p>\n\n<h3 id=\"large-teams\">Large Teams<\/h3>\n\n<p>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\u2019s likely that there is already a natural point of division in work.<\/p>\n\n<h3 id=\"partially-distributed-teams\">Partially Distributed Teams<\/h3>\n\n<p>In a partially distributed team, some members work in a central location while others are working \u201cremote\u201d. The \u201cremote\u201d 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 \u201cremote\u201d experience. People will quickly point out things like <em>the audio quality is not good enough with a single laptop in the center of the room<\/em> and <em>every time I try to talk I get cut off<\/em>. Some things can be solved with better tech while others are solved with empathy from being \u201cremote\u201d.<\/p>\n\n<h3 id=\"timezones\">Timezones<\/h3>\n\n<p>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.<\/p>\n\n<hr \/>\n\n<p>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\u2019s 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\u2019re happy with the process.<\/p>","author":{"name":{}},"category":[{"@attributes":{"term":"Remote Work"}},{"@attributes":{"term":"Productivity"}}],"summary":"Over the past few years I\u2019ve participated or lead syncs in fully distributed, partially distributed and centrally located teams. I\u2019ve 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\u2019ll share a process that has been borrowed from many different sources and tweaked over time with new teammates and companies."},{"title":"Getting The Most Out Of Kubernetes","link":{"@attributes":{"href":"https:\/\/blog.harrison.dev\/2018\/12\/11\/getting-the-most-out-of-kubernetes.html","rel":"alternate","type":"text\/html","title":"Getting The Most Out Of Kubernetes"}},"published":"2018-12-11T00:00:00+00:00","updated":"2018-12-11T00:00:00+00:00","id":"https:\/\/blog.harrison.dev\/2018\/12\/11\/getting-the-most-out-of-kubernetes","content":"<p>So you\u2019ve carefully crafted your first Kubernetes service, and you\u2019re 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\u2019s still unclear how the new service behaves when it\u2019s being pushed, and it\u2019s 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.<\/p>","author":{"name":{}},"summary":"So you\u2019ve carefully crafted your first Kubernetes service, and you\u2019re 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\u2019s still unclear how the new service behaves when it\u2019s being pushed, and it\u2019s 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."},{"title":"20 Questions To Ask Before Joining A Startup","link":{"@attributes":{"href":"https:\/\/blog.harrison.dev\/2018\/11\/25\/twenty-questions-to-ask-before-joining-a-startup.html","rel":"alternate","type":"text\/html","title":"20 Questions To Ask Before Joining A Startup"}},"published":"2018-11-25T00:00:00+00:00","updated":"2018-11-25T00:00:00+00:00","id":"https:\/\/blog.harrison.dev\/2018\/11\/25\/twenty-questions-to-ask-before-joining-a-startup","content":"<p>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\u2019t 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.<\/p>\n\n<h2 id=\"foundation\">Foundation<\/h2>\n\n<p>Making sure you\u2019ve got what you need in your day to day is critical. Unless you are independently wealthy, <strong>don\u2019t take a job that can\u2019t cover cost of living or does not provide health insurance<\/strong>. This means you need to spend some time to create your monthly budget (good to do this even if you aren\u2019t 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.<\/p>\n\n<p>If the job requires relocation it is very common for startups to offer relocation packages. I\u2019ve moved across the country twice and it cost around $3000-$6000 for things like:<\/p>\n\n<ul>\n  <li>relocation cubes (<a href=\"https:\/\/www.upack.com\/\">https:\/\/www.upack.com\/<\/a>)<\/li>\n  <li>shipping a car (<a href=\"https:\/\/www.uship.com\/vehicles\/\">https:\/\/www.uship.com\/vehicles\/<\/a>)<\/li>\n  <li>if not shipping a car, hotel while traveling<\/li>\n  <li>food while traveling<\/li>\n  <li>hotel for a few nights while finding more permanent housing<\/li>\n  <li>registration fees (license plate, sticker, etc.)<\/li>\n<\/ul>\n\n<p>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.<\/p>\n\n<div class=\"language-plaintext highlighter-rouge\"><div class=\"highlight\"><pre class=\"highlight\"><code>1. What is the base yearly salary?\n2. What are details of the health, eye and dental insurance plans?\n3. Does the company offer relocation? (if you need it)\n<\/code><\/pre><\/div><\/div>\n\n<h2 id=\"equity\">Equity<\/h2>\n\n<p>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. <a href=\"https:\/\/a16z.com\/2016\/08\/24\/options-ownership\/\">Here\u2019s an article on how options work<\/a>.<\/p>\n\n<p>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\u2019t mean much if there are hundreds of millions of shares already issued.<\/p>\n\n<p>Here\u2019s a nice formula from Buffer that shows one way of determining startup equity amounts: <a href=\"https:\/\/open.buffer.com\/buffer-open-equity-formula\/\">https:\/\/open.buffer.com\/buffer-open-equity-formula\/<\/a>. 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.<\/p>\n\n<p>Lets say you\u2019re 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%.<\/p>\n\n<p>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\u2019ve 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\u2019t have much cash on hand. Companies that have shorter exercise windows end up benefiting the people who are present during an exit. Here\u2019s some more information if you\u2019re interested in learning more: <a href=\"https:\/\/blog.colony.io\/on-creating-a-better-employee-equity-plan-d89bcab4a4e2\/\">https:\/\/blog.colony.io\/on-creating-a-better-employee-equity-plan-d89bcab4a4e2\/<\/a><\/p>\n\n<p>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.<\/p>\n\n<p>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\u2019s 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\u2019t 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.<\/p>\n\n<p>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\u2019s a helpful startup equity calculator: <a href=\"https:\/\/comp.data.frontapp.com\/\">https:\/\/comp.data.frontapp.com\/<\/a><\/p>\n\n<p>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.<\/p>\n\n<div class=\"language-plaintext highlighter-rouge\"><div class=\"highlight\"><pre class=\"highlight\"><code>4. How many total options are offered?\n5. What is the total number of issued shares?\n6. What is the vesting schedule?\n7. What is the exercise window of vested options?\n8. What is the strike price? (You might not get an answer to this one)\n<\/code><\/pre><\/div><\/div>\n\n<h2 id=\"funding\">Funding<\/h2>\n\n<p>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.<\/p>\n\n<p>Let\u2019s 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\u2019re spending cash.<\/p>\n\n<p>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 <a href=\"https:\/\/angel.co\/\">AngelList<\/a> and <a href=\"https:\/\/www.crunchbase.com\/\">Crunchbase<\/a> provide information about previous investments. Individual investors can usually be found on LinkedIn.<\/p>\n\n<p>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.<\/p>\n\n<div class=\"language-plaintext highlighter-rouge\"><div class=\"highlight\"><pre class=\"highlight\"><code>9. What is the total amount of funding raised?\n10. How much cash is on hand?\n11. What is the [burn rate](https:\/\/baremetrics.com\/academy\/burn-rate)?\n12. What round of funding has the company raised?\n13. Who has invested in the company?\n14. In the last year has the company failed to make payroll?\n<\/code><\/pre><\/div><\/div>\n\n<h2 id=\"board\">Board<\/h2>\n\n<p>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 <em>it depends<\/em>.<\/p>\n\n<p>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.<\/p>\n\n<div class=\"language-plaintext highlighter-rouge\"><div class=\"highlight\"><pre class=\"highlight\"><code>15. Who is on the board of directors and how many seats does each member have?\n<\/code><\/pre><\/div><\/div>\n\n<h2 id=\"responsibilities\">Responsibilities<\/h2>\n\n<p>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\u2019s not much room to work on things that are unimportant to the business or for people who can\u2019t 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\u2019re 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\u2019re not sure what direction to take your career, chose a role that will expose you to lots of different ideas you <em>might<\/em> be interested in. It is not uncommon for someone to find something they love doing and become the person who <em>owns a set of problems or services<\/em> related to that thing.<\/p>\n\n<p>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 <a href=\"https:\/\/a16z.com\/2017\/02\/18\/12-things-about-product-market-fit\/\">product market fit<\/a>. 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 <a href=\"https:\/\/en.wikipedia.org\/wiki\/Lean_startup#Pivot\">pivot<\/a> and will likely change the engineering team\u2019s focus.<\/p>\n\n<p>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\u2019t 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\u2019t let you speak to a potential co-worker. Keep in mind that you\u2019ll be spending lots of time working with these people, so you\u2019ll want to pretty sure that these are people who you can get along with. That\u2019s 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!<\/p>\n\n<div class=\"language-plaintext highlighter-rouge\"><div class=\"highlight\"><pre class=\"highlight\"><code>16. What projects do you picture I'd work on?\n17. Has the company found product market fit?\n18. How does the company collect feedback from customers?\n19. Who would I be working with to complete the projects?\n20. Ask each new potential teammate:\n  1. What do you work on?\n  2. What about your role are you enjoying?\n  3. What could the company improve on?\n<\/code><\/pre><\/div><\/div>\n\n<hr \/>\n\n<p><em>Technically<\/em> 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\u2019t have as good a ring to it.<\/p>\n\n<p>I\u2019d 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.<\/p>\n\n<p>It is unlikely that the interviewers will be able to answer <em>every question<\/em> for a number of different reasons, ranging from <em>don\u2019t know<\/em> to <em>I can\u2019t answer that<\/em>. It might be helpful to mark the questions that are important to you. For instance you might care a lot about <code class=\"language-plaintext highlighter-rouge\">equity<\/code> but not care as much about the <code class=\"language-plaintext highlighter-rouge\">board<\/code> structure since you know the founders very well.<\/p>\n\n<p>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\u2019d be in a better position to pass or accept an offer than if you used only these questions.<\/p>\n\n<p>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\u2019t 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.<\/p>","author":{"name":{}},"category":{"@attributes":{"term":"Startups"}},"summary":"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\u2019t 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."},{"title":"Remote Work Matters For Communities","link":{"@attributes":{"href":"https:\/\/blog.harrison.dev\/2018\/10\/26\/remote-work-matters-for-communities.html","rel":"alternate","type":"text\/html","title":"Remote Work Matters For Communities"}},"published":"2018-10-26T00:00:00+00:00","updated":"2018-10-26T00:00:00+00:00","id":"https:\/\/blog.harrison.dev\/2018\/10\/26\/remote-work-matters-for-communities","content":"<p>A few weeks ago, <a href=\"https:\/\/twitter.com\/rrhoover\/\">@rrhoover<\/a> 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\u2019s true - but that\u2019s not it. That\u2019s not why remote work is changing our world for the better.<\/p>\n\n<blockquote class=\"twitter-tweet\" data-lang=\"en\"><p lang=\"en\" dir=\"ltr\">Let&#39;s say you&#39;re looking for a new job. What&#39;s most important to you? \ud83e\udd14<\/p>&mdash; Ryan Hoover (@rrhoover) <a href=\"https:\/\/twitter.com\/rrhoover\/status\/1040643457901985793?ref_src=twsrc%5Etfw\">September 14, 2018<\/a><\/blockquote>\n\n<p>Now this poll isn\u2019t 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\u2019m not a scientist, and the point is, people care a lot about being remote workers themselves. That\u2019s cool. But we\u2019re missing out on that bigger picture why as a society, we should be supporting companies that do remote work.<\/p>\n\n<p>Remote work is not without trade-offs, and it\u2019s 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.<\/p>\n\n<p>My first experience with remote work was at Respondly (since acquired by <a href=\"https:\/\/buffer.com\">Buffer<\/a>) 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.<\/p>\n\n<p>Fast forward a couple years and I\u2019m working remotely 100% of the time. I\u2019ve moved away from the Bay Area and still have a fulfilling job in tech. While it hasn\u2019t been easy 100% of the time, I\u2019ve managed to stay disciplined with my schedule. I haven\u2019t fallen into the <em>sweatpants every day<\/em> trap you sometimes hear people talk about with remote work (there are days though \ud83d\ude02). I spend time at the local coffee shops, the library and a few restaurants and bars with wifi.<\/p>\n\n<h2 id=\"investment-in-communities\">Investment In Communities<\/h2>\n\n<p>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 <a href=\"https:\/\/www.amiba.net\/resources\/multiplier-effect\/\">stays in the community longer<\/a> if you compare spending at Starbucks or having coffee delivered from Amazon.<\/p>\n\n<p>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, <a href=\"https:\/\/www.citylab.com\/life\/2018\/05\/remove-work-vermont-money\/561626\/\">even offering $10,000 to live there<\/a> so long as you work in another state. The added opportunities will give people more options, rather than <em>needing<\/em> to live in a city. This isn\u2019t to say that everyone should work in a distributed team or live in a small town, just that <em>if<\/em> you can do you job from anywhere it should be your choice where to work.<\/p>\n\n<h2 id=\"being-part-of-the-community\">Being Part Of The Community<\/h2>\n\n<p>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 \u2013 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\u2019re on different sides. In reality, it ends up being an imaginary line that separates people.<\/p>\n\n<p>Giving people the option to stay in their communities is important, and this tweet sums it up perfectly:<\/p>\n\n<blockquote class=\"twitter-tweet\" data-lang=\"en\"><p lang=\"en\" dir=\"ltr\">Hey tech companies, you want to have a positive influence on society and politics?<br \/><br \/>Let people work remotely from their home towns<br \/><br \/>Let people vote in the communities where it matters most<br \/><br \/>Let them contribute to those local economies<br \/><br \/>Let them support their extended families<\/p>&mdash; \u0265\u0254\u0250o\u0279 (@roach) <a href=\"https:\/\/twitter.com\/roach\/status\/1048716567435866112?ref_src=twsrc%5Etfw\">October 6, 2018<\/a><\/blockquote>\n\n<p>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.<\/p>\n\n<p><strong>Special shout out to <a href=\"https:\/\/twitter.com\/katie_womers\">@katie_womers<\/a> for suggestions and edits!<\/strong><\/p>\n\n<script async=\"\" src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script>","author":{"name":{}},"category":{"@attributes":{"term":"Remote Work"}},"summary":"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\u2019s true - but that\u2019s not it. That\u2019s not why remote work is changing our world for the better."},{"title":"We Wrote A Book: Atomic Migration Strategy For Web Teams","link":{"@attributes":{"href":"https:\/\/blog.harrison.dev\/2018\/07\/09\/atomic-migration-stategy-for-web-teams.html","rel":"alternate","type":"text\/html","title":"We Wrote A Book: Atomic Migration Strategy For Web Teams"}},"published":"2018-07-09T00:00:00+00:00","updated":"2018-07-09T00:00:00+00:00","id":"https:\/\/blog.harrison.dev\/2018\/07\/09\/atomic-migration-stategy-for-web-teams","content":"<p>It all started at <a href=\"https:\/\/conferences.oreilly.com\/fluent\/fl-ca-2017\">Fluent Conf 2017<\/a> with a talk I gave on <a href=\"https:\/\/bufferapp.github.io\/buffer-talks\/2017\/06\/09\/migrating-with-atomic-design.html#1\">Migrating With Atomic Design<\/a>. After the talk I was approached by O\u2019Reilly and asked if I wanted to turn the talk into a book. My initial reaction was <strong>hell yes<\/strong>, followed quickly by <em>what did I just agree to<\/em> \ud83d\ude31. I\u2019m 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\u2019d never done it before and it seemed like a challenge that would push me outside of my comfort zone. I\u2019d love to share how I went about writing and what went into writing a book with a publisher.<\/p>\n\n<h2 id=\"getting-help\">Getting Help<\/h2>\n\n<p>When thinking about what we had to do at <a href=\"https:\/\/buffer.com\">Buffer<\/a> 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 <a href=\"https:\/\/twitter.com\/katie_womers\">Katie Womersley\u2019s<\/a> tirelessly advocating that a migration was the <em>right thing to do right now<\/em>. 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 \ud83d\ude4c). So we set out and created the outline and submitted the proposal to O\u2019Reilly.<\/p>\n\n<h2 id=\"actually-writing\">Actually Writing<\/h2>\n\n<p>The writing process, not including editing, took about 5 months to complete between October 2017 and February 2018.<\/p>\n\n<p>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 <a href=\"http:\/\/gitstats.sourceforge.net\/\">gitstats<\/a> on the repository you can see that most of the commits were around 9-10 AM:<\/p>\n\n<p><img src=\"\/images\/posts\/atomic-migration-strategy-for-web-teams\/commits-hour-of-day.png\" width=\"100%\" \/><\/p>\n\n<p>Taking a look at the same hourly view across the week you can see that later in the week I\u2019d get started a little later, closer to 10-11 AM:<\/p>\n\n<p><img src=\"\/images\/posts\/atomic-migration-strategy-for-web-teams\/commits-hour-of-week.png\" width=\"100%\" \/><\/p>\n\n<p>Other than Sunday there are basically zero after hours commits, which I guess that makes Katie and I morning people \ud83e\udd37<\/p>\n\n<p>Katie\u2019s writing style was very different from mine, she would write an entire chapter in one sitting! You wouldn\u2019t 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.<\/p>\n\n<p>We wrote the book in an O\u2019Reilly tool called <a href=\"https:\/\/atlas.oreilly.com\/\">Atlas<\/a>. 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.<\/p>\n\n<p>Most of the book was written from the local coffee shop <a href=\"https:\/\/www.google.com\/maps\/place\/Blackberry+Market\/@41.874172,-88.0687457,17z\/data=!3m1!4b1!4m5!3m4!1s0x880e53120ff84309:0x8c1fdb8c0340506b!8m2!3d41.874172!4d-88.066557\">Blackberry Market<\/a>. I work remotely and enjoy working the first half of the day with this view:<\/p>\n\n<p><img src=\"\/images\/posts\/atomic-migration-strategy-for-web-teams\/coffee-shop.jpg\" width=\"100%\" \/><\/p>\n\n<h2 id=\"review-and-edit-process\">Review and Edit Process<\/h2>\n\n<p>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.<\/p>\n\n<p>This is where O\u2019Reilly goes through your <del>code<\/del> 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!<\/p>\n\n<h2 id=\"publishing\">Publishing<\/h2>\n\n<p>We made it to the publishing phase \ud83c\udf89\ud83c\udf89\ud83c\udf89 <em>itshappening.gif<\/em> (I won\u2019t actually leave the GIF here since its the most distracting thing ever created)! The book was <a href=\"https:\/\/www.safaribooksonline.com\/library\/view\/atomic-migration-strategy\/9781491999950\/\">published as an ebook<\/a> on <a href=\"https:\/\/safaribooksonline.com\">Safari<\/a> and was done with the same level of quality that you\u2019d 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 <em>might<\/em> get to expand on it and turn <em>Atomic Migration Strategy for Web Teams<\/em> 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\u2019d ever be interested in writing a book. Now I\u2019m already thinking about the next one \ud83d\ude43<\/p>\n\n<p>Synopsis for <a href=\"https:\/\/www.safaribooksonline.com\/library\/view\/atomic-migration-strategy\/9781491999950\/\"><em>Atomic Migration Strategy for Web Teams<\/em><\/a>:<\/p>\n\n<blockquote>\n  <p>Atomic Design, created by web designer and consultant Brad Frost, is a system for working with the fundamental building blocks\u2014the atoms\u2014of 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\u2019s examples focus on migrating a frontend application, you can also use these techniques for mobile and backend applications.<\/p>\n<\/blockquote>\n\n<p>Here\u2019s a link to the book on Safari: <a href=\"https:\/\/www.safaribooksonline.com\/library\/view\/atomic-migration-strategy\/9781491999950\/\"><em>Atomic Migration Strategy for Web Teams<\/em><\/a> we\u2019d 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!<\/p>","author":{"name":{}},"category":[{"@attributes":{"term":"Atomic Design"}},{"@attributes":{"term":"Writing"}}],"summary":"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\u2019Reilly 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 \ud83d\ude31. I\u2019m 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\u2019d never done it before and it seemed like a challenge that would push me outside of my comfort zone. I\u2019d love to share how I went about writing and what went into writing a book with a publisher."},{"title":"Making The Case For Frontend Monorepos","link":{"@attributes":{"href":"https:\/\/blog.harrison.dev\/2018\/06\/15\/making-the-case-for-frontend-monorepos.html","rel":"alternate","type":"text\/html","title":"Making The Case For Frontend Monorepos"}},"published":"2018-06-15T00:00:00+00:00","updated":"2018-06-15T00:00:00+00:00","id":"https:\/\/blog.harrison.dev\/2018\/06\/15\/making-the-case-for-frontend-monorepos","content":"<p>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 \u2013 monorepos allow you to use a standard set of tools and make related changes across components.<\/p>\n\n<p>Here are the slides for the talk \u201cMaking The Case For Frontend Monorepos\u201d I gave at <a href=\"https:\/\/2018.syntaxcon.com\/\">SyntaxCon 2018<\/a><\/p>\n\n<iframe src=\"\/\/slides.com\/hharnisc\/frontend-monorepos\/embed\" width=\"100%\" height=\"500\" scrolling=\"no\" frameborder=\"0\" webkitallowfullscreen=\"\" mozallowfullscreen=\"\" allowfullscreen=\"\"><\/iframe>","author":{"name":{}},"category":{"@attributes":{"term":"Monorepo"}},"summary":"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 \u2013 monorepos allow you to use a standard set of tools and make related changes across components."},{"title":"The Optimist\u2019s Guide To Coding","link":{"@attributes":{"href":"https:\/\/blog.harrison.dev\/2018\/01\/29\/the-optimists-guide-to-coding.html","rel":"alternate","type":"text\/html","title":"The Optimist\u2019s Guide To Coding"}},"published":"2018-01-29T00:00:00+00:00","updated":"2018-01-29T00:00:00+00:00","id":"https:\/\/blog.harrison.dev\/2018\/01\/29\/the-optimists-guide-to-coding","content":"<p>Scrolling through my twitter feed, I saw Tweet about how software engineers seem to become less happy over time with coding. Personally I\u2019ve 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.<\/p>\n\n<blockquote class=\"twitter-tweet\" data-lang=\"en\"><p lang=\"en\" dir=\"ltr\">Looking at my twitter feed, it feels like the longer you&#39;ve been coding professionally, the less you actually like coding.<br \/><br \/>For people who&#39;ve been coding for 10+ years, is this how you feel?<\/p>&mdash; Saron (@saronyitbarek) <a href=\"https:\/\/twitter.com\/saronyitbarek\/status\/946562500065083392?ref_src=twsrc%5Etfw\">December 29, 2017<\/a><\/blockquote>\n<script async=\"\" src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script>\n\n<h2 id=\"dedicate-work-time-for-learning-every-day\">Dedicate \u201cWork\u201d Time For Learning Every Day<\/h2>\n\n<p>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\u2019ve done in the past:<\/p>\n\n<ul>\n  <li>Build a hello world React app<\/li>\n  <li>Implement merge sort in an unfamiliar language<\/li>\n  <li>Take a storytelling class on Kahn Academy<\/li>\n<\/ul>\n\n<h2 id=\"surround-yourself-with-people-who-are-excited\">Surround Yourself With People Who Are Excited<\/h2>\n\n<p>Excitement tends to be infectious. When you\u2019re around a group of people who are enthusiastic about what they\u2019re 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.<\/p>\n\n<h2 id=\"be-a-mentor\">Be A Mentor<\/h2>\n\n<p>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\u2019ve never seen. Most importantly you\u2019re helping someone else level up their skills and grow as an engineer. Over time you\u2019ll end up being surrounded by people who want to learn and grow!<\/p>\n\n<h2 id=\"stop-doing-things-that-arent-working\">Stop Doing Things That Aren\u2019t Working<\/h2>\n\n<p>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 \u201cSoftware Craftsman\u201d 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.<\/p>\n\n<p>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 \u2013 I could justify what I was doing. Done is better than perfect but perfect is never done.<\/p>\n\n<p>\u2026<\/p>\n\n<p>Keep building things that interest you and keep learning! The world has enough consumers but never has enough builders and doers.<\/p>","author":{"name":{}},"category":{"@attributes":{"term":"Software"}},"summary":"Scrolling through my twitter feed, I saw Tweet about how software engineers seem to become less happy over time with coding. Personally I\u2019ve 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."},{"title":"How I Hacked My Schedule To Get 3 Days Of Deep Work A Week","link":{"@attributes":{"href":"https:\/\/blog.harrison.dev\/2018\/01\/08\/how-i-hacked-my-schedule.html","rel":"alternate","type":"text\/html","title":"How I Hacked My Schedule To Get 3 Days Of Deep Work A Week"}},"published":"2018-01-08T00:00:00+00:00","updated":"2018-01-08T00:00:00+00:00","id":"https:\/\/blog.harrison.dev\/2018\/01\/08\/how-i-hacked-my-schedule","content":"<p>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\u2019t 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\u2019ll jump in and provide technical context (when I can) and try to help in a why that will reduce the reliance on myself.<\/p>\n\n<blockquote>\n  <p>The goal is to teach and automate myself out of a job!<\/p>\n<\/blockquote>\n\n<p>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 <a href=\"https:\/\/open.buffer.com\/no-office\/\">no physical office<\/a>, 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\u2019d find the answer after a bit of searching \ud83d\ude4c). Another challenge was that some teammates thought they couldn\u2019t ask me questions because I wasn\u2019t 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, <a href=\"http:\/\/heeris.id.au\/2013\/this-is-why-you-shouldnt-interrupt-a-programmer\/\">only to be lost by a random interruption<\/a>.<\/p>\n\n<p>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\u2019re interested in learning more about Deep Work, check out Cal Newport\u2019s <a href=\"http:\/\/calnewport.com\/books\/deep-work\/\">Deep Work: Rules for Focused Success in a Distracted World<\/a>.<\/p>\n\n<p>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:<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>\u00a0<\/th>\n      <th style=\"text-align: center\">Monday<\/th>\n      <th style=\"text-align: center\">Tuesday<\/th>\n      <th style=\"text-align: center\">Wednesday<\/th>\n      <th style=\"text-align: center\">Thursday<\/th>\n      <th style=\"text-align: center\">Friday<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Pairing, syncs, etc.<\/td>\n      <td style=\"text-align: center\">X<\/td>\n      <td style=\"text-align: center\">\u00a0<\/td>\n      <td style=\"text-align: center\">\u00a0<\/td>\n      <td style=\"text-align: center\">\u00a0<\/td>\n      <td style=\"text-align: center\">X<\/td>\n    <\/tr>\n    <tr>\n      <td>Deep Focus Work<\/td>\n      <td style=\"text-align: center\">\u00a0<\/td>\n      <td style=\"text-align: center\">X<\/td>\n      <td style=\"text-align: center\">X<\/td>\n      <td style=\"text-align: center\">X<\/td>\n      <td style=\"text-align: center\">\u00a0<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>I\u2019ve been doing this since mid November and have already noticed some changes:<\/p>\n\n<ul>\n  <li>Teammates from multiple teams have requested pairing sessions<\/li>\n  <li>The number of non-urgent questions has gone down (almost to 0)<\/li>\n  <li>Urgent communication is much more visible through Slack<\/li>\n  <li>I\u2019ve been able to complete several long standing tasks<\/li>\n<\/ul>\n\n<p>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\u2019s more than setting aside time for work, its also deciding what you\u2019ll do with the time you set aside.<\/p>","author":{"name":{}},"category":[{"@attributes":{"term":"Remote Work"}},{"@attributes":{"term":"Schedule"}}],"summary":"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\u2019t 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\u2019ll jump in and provide technical context (when I can) and try to help in a why that will reduce the reliance on myself."}]}