Test Deployment


# Introduction

It's 12:05 am and slightly hard to sleep. I found out that my employer Solvvy is going to be acquired by Zoom. This is a moment that many startup employees dream about. I'm fortunate to be a part of this experience. It's worth reflecting in this moment about change. Change is something that comes naturally to children, but we often learn to shy away from change as we become older. We become focused on habits and routines. After all, they provide predictability and comfort. However, I stand on the precipice of a large change along with my fellow Solvvers. Change is a great thing - hard, but great. This is true in all circumstances. A gem cannot be polished without friction, nor a person perfected without trials.

## Overview

I'd like to talk about change in several ways.

- What does change look like when you get new leadership or a new employer
- How can we leverage this change for growth
- What are ways to make the change enjoyable

# What does change look like when you get new leadership or a new employer

When we face changes in life with leadership or employers, we have to recognize that there is unknown. I have experienced significant change in these areas over the previous years and I have learned that we tend to project our past experience into what the future will look like. We might minimize the size of the change that is coming. We may assume that it will happen slowly, or not at all. We may even carry out the existing patterns and routines as the environment around us rapidly transitions.

Through my experiences I have realized that intentional awareness of upcoming change is useful. Reflecting and observing as pillars get torn down and rebuilt is valuable! I'm reminded of math class. At the beginning of a new concept you are given a definition. Theorems and subsequent problems derive from the definition. You can debate the definition in your head. Often times you question it when it is presented. "Is this really true? Why is it true?". We bang against the definition when we apply the mechanics incorrectly when solving problems. Eventually through time and experience we come to realize all along that the definition was true. _I have found that taking these definitions "to the bank" and applying them increases my ability to use them_. In other words, it shortens my time of understanding!

The same is true when you undergo rapid change, such as changing your workplace. The definitions of what govern the workplace, process, people, and tools, all change! The quicker we pick up on them, the quicker we can utilize these mechanics to help our teams, customers, and personal happiness.

### What is likely to change

Last year I experienced a significant change in leadership. I expected initially for business to carry on as usual, but that turned out to be inaccurate. Teams were re-arranged. I experienced three new bosses in one year. The way performance was measured changed. The expectations on what my role produced became different. The people on my team were swapped out. I went from working with the same people I had worked with for three years to training five new people as the lead of an entirely new team. The projects and priorities shifted.

In short, everything about my position changed. I was not expecting this when the leadership change first occurred. It was stressful, but in retrospect I'm thankful. I picked up a huge amount of new skills. I learned from many people. It was one of the best things that ever happened, despite the sense of chaos that accompanied so many changes in such a short period of time.

# Leveraging change for growth

Large changes are massive opportunities for personal growth. Success is achieved by stretching oneself, learning to feel comfortable being uncomfortable. Being aware that big change is coming gives you a mental model to turn on "learning mode". You can begin with self dialog. What am I excited about? What am I worried about? What are some things that I want to learn, or areas I want to focus. Who can I work with along the way?

Asking yourself these questions gives you a _plan_. Plans are nothing, but planning is everything, right? Gearing yourself up with plans on how to embrace change means that when it inevitably comes you are not shocked! You are prepared to embrace it, to roll with the punches, and to give your best self. It means that you have time to lock in habits that will prepare for the future.

You don't know what you don't know, and switching employers, companies, or leadership exposes you to a firehose of new ideas and personalities. This is the point behind all of it. Examining the ideas, processes, and tools gives you a chance to learn from them.

# What are ways to make change enjoyable

With change comes uncertainty. You may question your capabilities or knowledge. However, there are some common sense details to help us in moments of transition. These are facts that are already known, but it helps to remind ourselves!

1. Healthy mind, healthy habits

Healthy mind and healthy habits means positive self talk. It means a challenge to focus on happiness! Examine our identity and check it against who we want to be. Do we need to make changes to our routines to bring the two in alignment? Are our daily habits helping to build us more into who we are in our hearts? Aspire to be your best self because change gives an opportunity to realign our identity and habits with the one that makes us happy.

2. Reading or listening to a book

Reading or listening a book is an encourager in low moments, and moments of transition. Some books reinforce a sense of purpose that can get lost in the day to day grind. If you know you have an upcoming change and you want to enjoy it, a book can be a fantastic way to prepare. Some helpful books for millions of people: Atomic Habits, How to Win Friends and Influence People, The First 90 Days. These books each help craft a plan on how to embrace change and new relationships. A plan means boosted confidence. These are some of the most popular books in the world because they are fantastic at preparing us for the future.

3. Try to have fun

90% of success in life is showing up and trying your best, the other 10% I'll go out on a limb and say is about having fun. Recognize that change is not easy and our brains actually need time to internalize new environments. There is usually periods of mourning for what has been lost. This is normal! Try not to be hard on yourself as you adjust. If you have the ability to take time to yourself before a large change, it's a wonderful idea. Invest in your most important relationships. Have fun and celebrate with people close to you, and don't be afraid to be yourself in your new environment. People appreciate when you bring your whole self to the workplace.

# Wrapping up

Big change is coming, but change brings growth. Preparing for change will help us maximize the value and minimize the disruption. Giving ourselves grace throughout the process is necessary. Mourning for what is lost is normal. Look for the definitions, embrace them as best you can. Roll with the punches. After 12 weeks, the change will be replaced with a new sense of normal. Enjoy the ride. I'm looking forward to becoming a Zoomie, how about the rest of my fellow Solvvers. Are you ready for an exciting ride filled with change?

P.S. It's now 12:57am. I'm going to sleep (or rather lay awake with a busy mind trying to imagine the future).


Do you embrace change or fear it?


# Introduction

Notion and Dropbox paper share a fundamental feature; creating documents. Since these tools at their core are for creating content, I expect them to excel in this area. Notion has left me with a bad taste in my mouth. In the words of Marie Kondo, Dropbox Paper "Sparks joy". Notion is the cluttered closet that I toss trash into before company arrives. I close the door and hope I never have to open it again. Why do I feel this way? Well, let's examine six simple features that make Dropbox Paper my go to tool for document creation.

First we have to acknowledge a few details. The first is that Notion and Dropbox Paper are apples and oranges. Dropbox paper has an intentionally restricted feature set. Notion gives you the kitchen sink, including all of the leaks. They are at face value not solving the exact same problems. However I do have to ask myself... do I really want my document storage tool to also manage my epic planning?

Google docs barely even earns a mention - however they did announce support for markdown this year, better late than never, right?

# Overview

- What is Dropbox Paper
- The six reasons Dropbox Paper is better than Notion

# What is Dropbox Paper

Paper is a free product offered by Dropbox. It offers a document editor with a small feature set that is beautifully executed. It never gets in the way, but lets you instead focus on creating the content.

Some features that I love: Dropbox Paper only offers header 1, header 2, and header 3 sizes. The only formatting allowed is bold, strikethrough, and underline. Images are easy to embed. Code has first class support. Markdown is supported. Tables, calendars, checkboxes, mentions, and comments. Autogenerated table of contents. That's pretty much the whole feature set. This is one of Dropbox Papers biggest strengths. The limited feature set lets creators focus on creating.

You are obligated to improve your writing when you are limited to these tools. Documents that communicate complex concepts should be boiled down to be simple and concise. Dropbox paper is your best friend for this. The interface is also incredibly clean. No clutter anywhere. Just your beautiful document.

# Six features Dropbox Paper does better than Notion

### Line level information on author (See initials to the left of line)

Every line with a new author has the authors initials next to it. If you have multiple lines in a row with the same author, the initials only appear on the first line. This makes seeing who edited a document as simple as a glance. It's fantastic.

![Authors](/assets/images/blog/authors.png 'Authors')

### Text folding under headers, also known as collapse and expand

The ability to collapse and expand headers gives you the ability to concentrate on information as it becomes relevant. This single features increases the readability significantly. If I want to get an idea of the high level ideas I can fold all the content under the headers. This allows me to get a high level view of what the key ideas in a document are. Cleverly authored articles in Dropbox Paper maximize the value this feature offers. It's legitimately brilliant, and also so simple. Losing this capability in other editors is crippling once you have experienced the value it provides.

In my picture below all headers are folded except Grep, because I only want to look at grep right now. It's like expandable file folders, in a document.

![Folded](/assets/images/blog/folded.png 'Folded')

### Assignments and reminders

Dropbox paper has first class support for checkboxes. If you @mention a user next to a checkbox, it becomes a todo for that user. You can even put a date. They have a section in dropbox with all of your todos, and it will also remind you via email to complete todos. Why is this important? For my role I have to review product specs and tech specs. Every product and tech spec gets a Stakeholders section where each key stakeholder is mentioned. This fixes two problems that I have seen companies struggle with:

1. Getting sign off on a document that people should review, but don't. No more chasing people down. It completely automates away sign off and approval of documents that require cross functional collaboration.
2. No more surprised stakeholders saying "But I never agreed to this!" or "I didn't know this was coming". My response? "Oh really? You put a check in the box", or even better "We asked you to put a check in this box by this date and you didn't do it".

### Email updates with file diffs

Another one of my favorite features is that when you are assigned as a stakeholder, you get an email feed of diffs as the document changes. The dropbox backend is magical about combining these in logical ways. I am always happy to see what is removed, and what is added in a doc. Push notifications are a proven way to ensure that people stay up to date when collaborating. Without this feature I'm stuck going to a doc history page to see what has changed. That's a lot more effort than opening a single email thread and reviewing the items that have changed.

![Updates](/assets/images/blog/updates.png 'Updates')

### Wider screen support for tables

The attention to detail in UX is what makes Notion a literal nightmare for me. For example, the tables don't center properly. Dropbox paper makes sure that tables always render beautifully. Considering tables show up in almost all of my documents this feature while minor, makes a huge difference on my quality of life. I shouldn't have to hunt and scroll to be able to see all of the details. I want to use my whole screen and I want it to look beautiful, thanks.

![Tables](/assets/images/blog/tables.png 'Tables')

### Present mode

Dropbox paper offers a legitimate presentation mode. It's actually a button, and it makes the document significantly larger for when you are presenting to stakeholders. This is another tiny quality of life UX feature that makes a huge difference. Light mode and dark mode supported, as well as full screen.

![Present](/assets/images/blog/present.png 'Present')

### Number seven, beautiful document editing

I said six, but now I'm fired up and I can't help but sneak in a seventh item. The document editing is absolutely perfect in Dropbox Paper, and ultimately this is what matters the most to me. I can write in markdown, but it's not required. Everything goes exactly where it should. My cursor is never lost. I don't have to dig through menus to find my elements.

When I contrast this to Notion my palms literally start to sweat. Notion jumps my items around. I have to remove them and re-add them all the time. It's actually _so bad_ that I craft my documents in dropbox paper, and I copy and paste them into Notion. Shouldn't the document editing be the strength of a document editing tool? The menu below is the only thing you see in Dropbox paper. It's intuitive, not invasive.

![Menu](/assets/images/blog/menu.png 'Menu')

### Number eight, amazing search

Dropbox already has directory structure with beautiful permissions. It works just as you expect. Simple. The bottom line though is that in 2022 I don't want to use directories. I want to search and have my result come up instantly. Dropbox Paper has me covered here. The search is easy to access, and it works perfectly every time. Sometimes I only remember a snippet of a document I wrote 3 years ago. I put that snippet in and POW, my result comes up. I have never lost a document in Dropbox Paper. The search box in Notion is tucked away in the corner with almost no screen real estate. It makes me want to scream.

# Conclusion

All of these seemingly tiny features add up to a tremendously better user experience in Dropbox Paper. Notion may offer additional features, but the clumsyness of the implementation and the constant NQS (Non quality signals) make it a tool that I avoid. Consider using Dropbox Paper. Use a tool that works for you, not against you, and experience the difference it makes. Do you agree or disagree? I would love to hear your thoughts in the comments about which tool I missed, and what I got wrong. Thanks for reading, and enjoy your content production in the tool of your choice. All that matters is that you can express your creativity in the way that works best for you.


Six reasons dropbox paper is better than notion


# Introduction

Delivering projects on time is challenging, but it's nearly impossible if your team estimates ambiguous items. Development tasks are broken down by a code deliverable, stories are broken down by feature deliverable. Which one is more likely to be accurate?

We have learned as an industry that shipping small batch sizes increases productivity, efficiency, and reduces inventory. We know that continuous integration and deployment are compatible with fewer bugs and higher quality. These lessons guide the principle of estimating development tasks versus stories. In order to do this, we must go through a tech spec process to break a set of requirements into technical tasks. These tasks can be mapped to user stories.

The tech spec will serve as a blueprint. The foundation of our task management principles. The basis for communication of project progress. A reference for the future. A way to parallelize and distribute work across a set of engineers. The empowerment for individual developers to autonomously solve problems.

When we are able to incrementally deliver value and estimate granular tasks, we are going to create more consistent velocities. This increases predictability for stakeholders, but more importantly allows us to _accurately measure progress_. That's what we are going after. We want to be able to accurately communicate where we are, where we are going, and adjust proactively.

# Overview

- What is a story and a development task
- How to create a tech spec
- Loading your development tasks and stories into task management software
- Estimations, execution, reviews, and QA

# What is a story versus a development task

In order to get into these principles, we need definitions. I want to be crystal clear with examples.

#### What is a story

A story in this article will refer to a unit of value to the customer or business. For example:

- `"As a user, I can log into our application"`
- `"As a user, I can log out of our application"`

#### What is a development task

A development task represents a code change that gets us closer to being able to deliver the story.

- `"Create users table in postgressql"`

#### The difference between a story and a development task is essential

The problem with estimating stories is that there is overlap between the development tasks to accomplish two similar stories. This creates communication overhead that wastes time. Even worse is that people may believe there is a shared definition, but it's actually different inside of each persons head. People may even disengage during the discussion because creating crystal clear definitions becomes more of a burden than they can cope with. Let's jump back to our example in the context of an estimation session.

**"Okay now we are going to estimate the following stories":**

- `"As a user, I can log into our application"`
- `"As a user, I can log out of our application"`

_Discussion ensues_. Is creating the users table part of the first story? The second story? Should we come to an agreement as a team that the "logging in" task comes first? This would make creating the users table is a blocker to the login story. We will need to increase our estimation for the log in task to accomodate for the users table work. The logging out story can become smaller since the users table is already created by the time we start that one.

Do you see the problem here? There is ambiguity about what units of development work each story entail. We haven't even talked about the task of creating backend routes and UI components. Those tasks also could fit into either story.

# Creating Tech Specs

A tech spec will bear the burden of breaking stories into development tasks. A tech spec should break down development tasks down in such a way that the following statements are true:

- Task estimation is ambiguity free
- A developer who did not write the spec is able to work on the task
- We have a blueprint for future reference outside of task management software or pull requests
- The tasks can be worked independently in parallel by multiple developers

Let's examine each of these independently. We need to break down some walls and assumptions that may be brewing.

### Task estimation is ambiguity free

Estimation should become trivial. A well broken down tech spec almost inevitably turns into 1s, 2s, 3s, with the occasional 5 for a task that is more unknown or complex. Rarely do you see anything else. It almost makes the estimation session a yawn fest. People tend to agree with estimates from the author of a quality tech spec. A well trained team with quality authors has the option to skip estimation. The author can provide initial estimates and the team can sign off on those estimates asynchronously. On a team with less shared understanding or experience, it is valuable to conduct a synchronous estimation session.

Lets break down our example stories into tasks. We must accomplish the following development tasks in order to enable users to log in and log out.

- Create users table with all the trimmings (columns)
- Add backend route that allows us to authenticate sign in requests
- Add backend route that allows us to log out
- Create frontend for the user to log in and log out

We might have a few others depending on our requirements, for example, maybe we are going to need a backing service such as redis. Perhaps our database hasn't yet been created. For our purposes we are going to skip these additional tasks, but they are included for illustration.

- Create database
- Set up redis server
- Set up lockout policies for brute force attacks

Fantastic. We have all of our development tasks.

### A developer who did not write the spec is able to work on the task

A tech spec contains enough detail that another developer can complete the tasks. There is not a fixed amount of detail for a tech spec. All teams have different dynamics. The detail depends on your team and their skill, experience, and tenure. I have been on teams where all engineers have been present for 3 years as well as teams where everyone except me is brand new. Detail on tech specs for these two teams looks vastly different. For new teams or junior teams you may include links to a file or function in your source control (likely GitHub). I might provide a pseudocode implementation. You can define types and interfaces that the team must be implemented. You can stub out a PR. The development task may be to check out an existing pull request and fill in the stubbed functions. The author of the tech spec should assess the state of their team and provide the detail necessary for the team to execute independently. That's what success looks like for a tech spec.

### We have a blueprint for future reference outside of task management software or pull requests

Is a tech spec is necessary at all? Can this detail just live in a task manager? Of course it _can_ but I also know from experience that keeping each blueprints (tech specs) in a document provides immense value and knowledge over time. Onboarding team members, product managers, and also existing team members can easily find implementation details, and view comment conversations about tradeoffs. Document history can be examined. Tech specs in a quality cloud document editor (such as Notion or Dropbox paper) function as source control for your ideas and blueprints.

I have onboarded many engineers, PMs, and designers. These new team members take over domain areas that were previously overseen by ex employees. One of the most valuable resources for an onboarding team member are your specs and tech specs. They explain past product and technical decisions. Details about each story, and how it was implemented. There are often even have a specs / tech specs for multiple iterations of a business critical feature.

Put all these resources at your onboarding team member's fingertips, they will thank you for it. They give new owners historical context on _why_ something was built the way it was. The knowledge at the time, the business goals, the technical tradeoffs. You will see the lights in their eyes and the heart emojis flowing out of their slack. Sigh with relief knowing that you don't have to try to communicate three years of knowledge over a single meeting or slack conversation. Check.

### Leveraging your tech spec to fill in Jira ticket descriptions

The best way is to link out to your tech spec within a Jira task. Most document editors allow you to create links that jump straight to a header in a section. The Jira task has a title, an estimation, and a link to the relevant details in the tech spec. This ensures that you can continue editing and updating the tech spec without modifying your task. The future readers of the spec will benefit from any changes. An alternative is to copy the details into the task body. My challenge with this approach is that the blueprint (tech spec) can become out of date if the description is modified in the task manager.

### The tasks can be worked independently in parallel by multiple developers

Can you build the login frontend before the table and backend are built? Absolutely. Working tasks in a waterfall slows development. It requires additional communication and coordination since team members may not be working on the same projects at the same times. Throw all of that out. Let one engineer build the login form as the other performs the backend task and database task. Your tech spec has the name of the route `/users/login`, right? It has the shape of the request and response, right? People should have what they need to build their respective component in parallel.

So what would stop us from implementing the login form in parallel? The ability to test it end to end and confirm it works? No problem! We can add one more development task.

- Confirm that login form works with backend endpoints (connect the wires)

Now we can do the backend and frontend simultaneously. Let your lead, tech spec author, architect, or excited frontend engineer take the final task. This is where the fireworks fly, and the highest complexity comes in. To connect the wires you must understand the system end to end.

Not every task must be worked in parallel. Some tasks are best worked as blockers to other tasks. That's expected. Just order the tasks from top to bottom in the tech spec in the order you anticipate them being worked. That's enough, particularly since each task is small enough that no single task should take a long time _anyways_.

# Loading your development tasks and stories into task management software

Now that the tech spec and stories are written, we want to put them into task management. The tech spec author ought to own this step. The author is typically more senior and also understands the links between tasks most effectively. If a dev task blocks another dev task, create that link. I actually have a .csv template that I use to import my tasks into JIRA. The beauty of this is that if I have a tech spec with 30 tasks I just drop them into the CSV, mark the links between tasks, and upload. Boom, done. Let me know if you want the template! It's certainly the fastest and most reliable way of creating a set of Jira tasks that are linked together.

### Marking links and executing on our tasks

Every development task gets marked as a blocker to its respective story. You can't test the story until each required development task is done. The development task approach allows us to examine the epics progress along the way. As each development task is complete we get a little closer to the epic being complete. Contrast that to when we execute and estimate on the story. Our progress was basically binary. Completing a table or backend route moved no tasks when we were representing our Jira work purely as stories.

# Estimations, execution, reviews, and QA

Let's examine how this methodology ensures that each of these steps is easy.

### Estimation

Estimation should be a trivial process now, with no ambiguity. Can people estimate how long to create a table, a route, and a frontend login component? Should be easy! Stories get estimated as a 0. Stories represent a unit of value to a customer, that can be tested. They are not related to the development effort required to enable the story for the QA team and customers.

### Execution

Each developer can pull a task from the sprint. The details of the tech spec cover details according to the knowledge the team requires. Each dev task is standalone and can be worked on without fuss.

### Code review is so much easier

One wonderful side effect of working development tasks versus stories is how much easier the units of work are to review. When you are adding a single route, a single component, a single whatever, the feature is broken up into logical units of delivery. My example did not include a feature with many components that constitute something larger, such as several new pages in the application. If you have ten components necessary to build 3 new pages, then each component can be a development task. The pages that stitch together the components can be development tasks. Everything can and should be feature flagged so that code can be merged to production. QA and Product teams switch on the flag to test the feature or incrementally roll out when they are ready.

### QA

When stories become unblocked by their development tasks, they move into QA. We can release stories incrementally for QA. For example, let's say are going to deliver 5 new features that together make up a single epic. As each feature's development tasks are completed, each story can move into QA.

# Wrapping up

We now have a framework to break work granularly into a set of tasks that are easy to estimate, easy to execute, can be worked independently, in parallel, and shipped without being held back in inventory. I will consider following up with an additional blog post of a meaty tech spec. I may also shares templates for product spec, tech spec, and stories. Through this process, estimations will become accurate, velocity more predictable, and delivery more stable. The lesson begins with working on development tasks not stories. I hope this has been useful for you.


Why you should estimate development tasks not stories


# Introduction

Growing your career as a software developer requires intent. Leaving it to chance means a higher chance of being left behind while others move ahead. I'd like to share some of the lessons I have learned as I move ahead in my career. This article focuses on growing your career in startups in a growing company. It can look different in other circumstances.

## Overview

These areas of growth are most commonly neglected; planning for the future, continually improving, and communication. It is expected that if you are here reading this that you are already a competent developer. Competence is a requirement to moving up in your career. One of your first focuses should be becoming an excellent developer who can deliver tasks. Once you have that down, let's move to the softer skills.

- Plotting a course for the future
- Continuous Learning
- Planning and estimation

## Why do this at all?

The times that I experience the least career satisfaction and the most burnout are the times when I'm not intentional. Personal mental health and job satisfaction are big motivators for caring. However, just as motivating is the concept of my company being successful. Many companies offer incentives to the employee based on the outcome of the company. These could be RSUs, ISOs, or some other concept like profit sharing. I want to give myself and the company the best odds of being successful. It's more rewarding, and it gives me the resources in life to do the things I want to do more, like take my family to Disneyland. Your reasons can look different, but I can't say strongly enough that being intentional is a big reward all on its own.

# Plotting a course for the future

Plotting a course for the future means playing strategically. What does your employers future look like? Is the company growing? What about the department? Where do you fit into these growth plans, and is your boss aware of your aspirations? Don't sit back and wait for opportunities to come to you. Carve out your place in the growing organization.

## Getting buy in on your growth

Bosses all behave differently, but one thing remains constant. You want your boss to be bought into your growth and success. That will not typically happen without working closely with them on your career. I find it best to establish rapport and let your boss know that you have aspirations to grow. Some questions that I like to think about:

1. What does the company need right now, what will the company need in the future?
2. How do my skills help solve the needs of the company now, and the company in the future?
3. What skills am I missing in order to fill these needs right now, and in the future?
4. Does my boss know that I want to work on what I'm missing, and utilize what I already can do most effectively?
5. How can I get my boss invested in my success, so that it is linked to their own personal satisfaction.

### Look at things from your bosses perspective

Your boss already probably has a lot on their plate. What are their levers to help them do their jobs more effectively? Look for wins that make your boss look good and make sure you are celebrating wins together. Listen to what the stressors are on them and push yourself and the people around you to make sure that you are on target. Remember that convincing people requires you to consider things from their perspective. This conversation can't focus on everything you want, especially not initially. You need to help them by using your competence to solve their problems as well.

### Starting the conversation

One magic phrase I use to get my boss invested in my success is:

**"Can you give me some advice?"**

This lets them know that you are willing to listen to their knowledge. It let's them know that you want to work with them. I will use this to lead into the answers to the questions I posted above. Pick three things at any given one on one to review with your boss.

Over the course of 4 - 8 weeks from starting you should ideally be in a place where you and the boss have come to an agreement about opportunities and where you fit into those. Try to be observant in the workforce.

### Celebrating Wins

It's critical that you celebrate your wins with your boss. Everyone will notice your misses. They will stick out in their mind. Are you celebrating your wins and letting your boss know when you see a deficiency and you go out of the way to fix the problem? If you are doing the fixing but never celebrating the wins then you are doing it in silence. You're a fantastic worker, but nobody will celebrate what they never heard about. This is one of the most overlooked areas of my early career. Advocate for yourself and your career by celebrating wins!

### Pointing out opportunities

When you do see an opportunity it's not necessary to always fix it right away. It's usually better to discuss these before you take action, so that you can bring your boss along for the ride and celebrate the win together later.

"I noticed <insert observation>. We are spending extra time because <insert cause>. I think there is an opportunity to fix this by <insert potential solution>. What do you think?"

**Example:**

"I noticed our backlog grooming sessions are not productive. We are spending extra time because the stories are not defined before we get into backlog grooming. I think that if we have these ready to go before we start it will be a lot more productive. I would like to have a conversation with our PM to make sure that they have what they need and that expectations are clear. What do you think?"

Notice how in this example we are providing an observation, a cause, a potential solution, and offering to implement the solution. We are also seeking wisdom and advice before acting. The plan is going to be improved based on your bosses feedback, and they will be eager to see if the outcome improves measurements that affect their own performance, such as team velocity. This toy example is slightly contrived and possibly even too small. I want to caution against bringing something minor to your boss, ideally we want to be making observations that are large enough to merit this conversation.

### Defining your gaps

Let's assume that your boss is in agreement that the company is growing and that you want to be a part of the growth. Maybe you want to move to an architect role, or senior SWE, or management, or some other role. Give your boss an assessment of the skills you believe that position requires. Then assess your own skills and ask them to review it with you. Can you tell me if you agree with my assessment? Do you think there are other gaps that I need to fill in? What will the plan be to fill the gaps so that when this position does open that you are ready to jump right into it.

Let's now talk about how to implement our plan to fill the gaps.

# Continuous Learning

When was the last time you took a class or learned something new in a structured way? I hope that you said sometime in the last quarter. If you didn't then I want to plead with you to take this seriously. This is one of the biggest opportunities you can take. Every employer should be willing to help you find the time and the money to take online courses. Three possible options are Udemy, Coursera, or Linkedin Learning. This is absolutely not optional from my perspective, because you don't know what you don't know. The only way to find out what you don't know is to expose yourself to new ideas and new technologies.

### Specific Skills

Picking a course is as simple as deciding if there is a specific technology or a general skill that you should pursue. For example, if my company is using GraphQL and I don't feel strong at GraphQL, then that's a course I should take. Courses around specific skills will focus on increasing your _competence_ in a subject area. This pays dividens because it will allow you to estimate and deliver more effectively. These courses can be targeted to your company and role. If you are a leader I would highly recommend requiring each of your team members to complete at least one course a quarter. These courses are typically in the 2 - 4 hour range, so it's not a stretch to challenge your employees to do this. They will thank you for it.

### General Skills

If you want to go with a general skill, consider what skills you think are valuable for your career to improve. Project management, agile methodologies, and estimation are all skills that will make you a more effective team player and leader. Everyone wins when you learn these skills as well. In this case you can look at courses offered by your provider with a high rating and lots of learners. This will help you to easily find high quality content that gives you new perspectives.

### Reading Books

Reading books is one of the best ways to get exposed to new ideas. People mention the best books they have read in passing all the time. It's also a great question to ask someone that you respect - "What are your top books?". Some of my top books include: [The Lean Startup](https://medium.com/r/?url=https%3A%2F%2Fwww.amazon.com%2FThe-Lean-Startup-Eric-Ries-audiobook%2Fdp%2FB005MM7HY8%2Fref%3Dsr_1_1%3Fcrid%3DRLVZLKDF2Y6W%26keywords%3DLean%2Bstartup%26qid%3D1651683235%26s%3Daudible%26sprefix%3Dlean%2Bstartup%252Caudible%252C141%26sr%3D1-1), [Principles: Life and Work](https://medium.com/r/?url=https%3A%2F%2Fwww.amazon.com%2FPrinciples-Ray-Dalio-audiobook%2Fdp%2FB074B2CZJG%2Fref%3Dsr_1_1%3Fcrid%3D1ORX2RB3Y5VNR%26keywords%3Dprinciples%26qid%3D1651683217%26s%3Daudible%26sprefix%3Dprinciples%252Caudible%252C138%26sr%3D1-1), [The Innovators](https://medium.com/r/?url=https%3A%2F%2Fwww.amazon.com%2FThe-Innovators-Walter-Isaacson-audiobook%2Fdp%2FB00M9KICAY%2Fref%3Dsr_1_1%3Fcrid%3D1ZT8IB9OZN7PH%26keywords%3Dthe%2Binnovators%26qid%3D1651683204%26s%3Daudible%26sprefix%3Dthe%2Binnovator%252Caudible%252C137%26sr%3D1-1), [Zero to One](https://medium.com/r/?url=https%3A%2F%2Fwww.amazon.com%2FZero-to-One-audiobook%2Fdp%2FB00M284NY2%2Fref%3Dsr_1_1%3Fcrid%3D12DK2SAEETV75%26keywords%3Dzero%2Bto%2Bone%26qid%3D1651683191%26s%3Daudible%26sprefix%3Dzero%2Bto%2Bone%252Caudible%252C132%26sr%3D1-1), [The Speed of Trust](https://medium.com/r/?url=https%3A%2F%2Fwww.amazon.com%2FThe-Speed-of-Trust-audiobook%2Fdp%2FB001U2MTAG%2Fref%3Dsr_1_1%3Fcrid%3D3S5MFYWYQIDV9%26keywords%3Dspeed%2Bof%2Btrust%26qid%3D1651683177%26s%3Daudible%26sprefix%3Dspeed%2Bof%2Btrus%252Caudible%252C131%26sr%3D1-1), [The First 90 Days](https://medium.com/r/?url=https%3A%2F%2Fwww.amazon.com%2Fdp%2FB00CH7FE1O%3Fplink%3D8a0u8Xfc2utp4fB5%26ref_%3Dadblp13npsbx_1_3_im), [The Art of Woo](https://medium.com/r/?url=https%3A%2F%2Fwww.amazon.com%2FThe-Art-of-Woo-audiobook%2Fdp%2FB000Z7FI3M%2Fref%3Dsr_1_1%3Fcrid%3D3FFLN68FUW1D1%26keywords%3Dthe%2Bart%2Bof%2Bwoo%26qid%3D1651683273%26s%3Daudible%26sprefix%3Dthe%2Bart%2Bof%2Bwoo%252Caudible%252C146%26sr%3D1-1), and [How to Win Friends and Influence People](https://medium.com/r/?url=https%3A%2F%2Fwww.amazon.com%2FHow-Win-Friends-Influence-People%2Fdp%2FB0006IU7JK%2Fref%3Dsr_1_1%3Fcrid%3D1AJ69W2FH7F1Q%26keywords%3Dhow%2Bto%2Bwin%2Bfriends%2Band%2Binfluence%2Bpeople%26qid%3D1651683310%26s%3Daudible%26sprefix%3Dhow%2Bto%2Bwin%2Bf%252Caudible%252C144%26sr%3D1-1). 
Some books on my list to read: [Radical Candor](https://medium.com/r/?url=https%3A%2F%2Fwww.amazon.com%2FRadical-Candor-Revised-Kick-Ass-Humanity%2Fdp%2FB07XVQB7XV%2Fref%3Dsr_1_1%3Fcrid%3D10IMZTCTSVRL3%26keywords%3Dradical%2Bcandor%26qid%3D1651683346%26s%3Daudible%26sprefix%3Dradical%2Bcandor%252Caudible%252C131%26sr%3D1-1) and [Measure What Matters](https://medium.com/r/?url=https%3A%2F%2Fwww.amazon.com%2FMeasure-What-Matters-audiobook%2Fdp%2FB07BMJ4L1S%2Fref%3Dsr_1_1%3Fcrid%3D17RVS7FBXKBOX%26keywords%3Dmeasure%2Bwhat%2Bmatters%26qid%3D1651683368%26s%3Daudible%26sprefix%3Dmeasure%2Bwhat%2Bmatter%252Caudible%252C131%26sr%3D1-1).

### Continuous Learning Wrap Up

You will never reach your potential without exposing yourself to new ideas on a regular basis. Never settle for only what you already know. Commit to slightly less every week to leave time for making yourself a more rounded employee. These are skills that will continue giving, even after you move on to a new employer someday.

# Planning and Estimation

The best reports for any boss are the ones who can deliver on what they promise. Companies depend on engineering teams to deliver features. These features drive sales, investments, and the company. Reliability should be the relentless focus of startup engineering teams. Reliability around delivery is incredibly hard at startups. Almost by definition a startup never has quite enough resources to fill all the gaps, and goals are constantly changing as new data comes in. That's not an excuse for being unreliable.

You need to become an excellent planner and estimator if you want to move up in your career. Planning and estimating effectively is the number one way to relieve stress and crunch. Burying your head in the sand and saying "we will just work as fast as we can and deliver when it's done" is just not acceptable if you are moving up in your career despite how true it may be.

### Setting dates

Our industry seems to shy away from the concept of setting dates and expectations on our software engineers. This isn't preschool though, this is a professional work environment. Dates are part of the job eventually. You can always provide a SWAG (Scientific Wild Ass Guess) that is based on your experience. At early stages your SWAG / T shirt size is going to be imprecise. That's why you define it in weeks. It might be plus a week or two, or minus a week or two. If you literally have no ability to estimate you can always....

### Set a date for a date

This is the point of a spike in agile. There are times when you can't provide accurate estimations. This could be for epics because the scope is ill defined. It could also be for stories because there are too many unknowns. You should always be willing to set a date to have a date. "I don't know when we can get this done by, we need to research x, y, and z. Once we research those I can give you a date. I'll have the research done by next Friday".

### Resource and quarterly planning

I have a blog post dedicated to resource and quarterly planning that I recommend you check out. You can view that blog post <https://blog.rune.tech/posts/software-engineering-quarterly-resource-planning> if you would like to become better at this process. It's a requirement to move up as a software engineer into a role with more responsibility.

# Summary

This all comes back to what your own personal goals are. What are you bringing to the table at your workplace and to those around you? I want to improve those around me and challenge myself to become a better person every day. We've examined how to plot a course for the future with your boss. Questions to ask yourself, starting conversations with your boss. We've included spotting opportunities and surfacing them. Making sure that our skills are growing and we are learning the unknown unknowns. Dates and planning. There is so much more than this but these are basic concepts that I have neglected to my own dismay at various points. I hope they are helpful to you in your career.


How to grow your career as a software developer


# Introduction

I have often seen engineering and product teams making commitments in the absence of resource planning. Most companies I work at have followed quarterly planning. It's important when doing planning at any interval to have an idea of _what is possible_. This is the point of resource planning. Without taking stock of your team, their capabilities, and their upcoming plans, you are going to head into the quarter blind.

### Importance of Goals

In an upcoming blog post I will talk about the importance of goal frameworks. OKRs are the framework I recommend, but there are other options. The important thing is to have a goal with measurable key results. Goals give you the ability to aggressively prioritize what must get done. They must be at least briefly mentioned.

## Overview

There are three key steps in my quarterly planning.

1. Resources
2. Projects, Tshirt sizes, and priorities
3. Connecting resources to projects

# Resources

Resource planning will take into account onboarding, ongoing maintenance, out of office time, and any other factors that your team can capably predict. The amount of time your team has can then plug into the projects the team wants to accomplish in a given quarter. Let's jump into a toy example.

I have four developers on my team. I know one of them is onboarding during this quarter and one of them is taking a vacation. Our team is growing so we have interviews. Oh and our product is bursting at the seams with maintenance. Every week we have to dedicate time to fixing bugs for our sales team.

![Resources](/assets/images/blog/resources.png 'Resources')

#### Onboarding Planning

I assume that an onboarding developer will not be able to contribute for at least 60 days. Realistically they should be contributing _something_ by day 30, but they typically also will require time from other developers. So they are going onto my planning as a 0 for the first 90 days. Then I will ramp them up to be producing at a .8 person week at the 90 day mark.

#### Out of Office time

Ask all your team members what their upcoming calendars for the quarter look like. If someone is out of office for a week. They are a 0 for that week. Simple, but effective. I also schedule 0.05 off every person because I know that people have appointments, get sick, eat lunch, use the bathroom, and tend to their families.

#### Maintenance Time

Maintenance must be accounted for during resource planning. If I'm new to a team I assume that 20% of their time is dedicated to maintenance. You can customize this using your gut instincts, or even better would be having data to back this up. Base camp actually defers maintenance during their 6 week product cycles. They spend 2 weeks at the end of every 6 week cycle doing bugs, so they might not even need to schedule maintenance time.

### Putting it together

Now that we have allocated time for maintenance, OoO, and training, we can get a total amount of time (in person weeks) that we have available for the quarter, week by week. This will become an input to our actual project planning.

# Projects and Tshirt sizes

It's important to know what projects have to get done, when they have to get done, what their priority is, and roughly how big we think they are. Estimations are guaranteed to be wrong by definition, and also because product development is overly optimistic by nature. You need to get your lead engineer, or the team to provide estimations at a weekly scale. I ask for a number of single person weeks between 1 and 12.

#### Project fidelity

Your team won't have all the details on projects at this stage most of the time. Estimation is an art form and the best lead engineers can get reasonably close. Make sure all stakeholders watching this process understand that estimations will be wrong and are subject to change.

#### Accounting for optimism

Teams in my experience always underestimate, no matter how good they are. I always multiply my teams estimations by a 1.2. The adage of underpromise and overdeliver is critical. You might have board members or sales depending on projects being done by the time you specify. You don't leave the house for a wedding 1 hour away, exactly 1 hour before it starts. You provide buffer because it's wise. It's different than sandbagging. Ultimately teams are expected to develop "as fast as they can" anyways, so if you happen to finish early, that's fantastic, move the schedule up. Don't finish late, but if you do, overcommunicate. The output from this exercise gives you the means to communicate EARLY when things are going wrong.

# Connecting resources to projects

Connecting resources to projects is what matters. This process forces stakeholders to consider what priorities are most critical. By saying yes to one project you can literally see another project bump down. If someone in the middle of the quarter asks you to pause work on something for another project, you can confront them with this gantt chart to make sure the impact is understood. We are here to make our companies, stock holders, customers, and ourselves successful. This is about protecting ourselves from unrealistic expectations, and making sure that we can deliver on our promises.

![Gantt](/assets/images/blog/gantt.png 'Gantt')

#### Prioritization

The most important projects go at the top. You now have the estimated amount of time the project will take, even accounting for optimism. You have the number of person weeks available for any given week. Lay out where the project falls week by week in this quarter.

#### Maintenance period and QA

Teams also need to account for QA and maintenance after release. I know from experience that the most important bugs to fix, and the most common bugs often relate to recent releases. You can't ship a feature and walk away. There will be rough edges that should be fixed immediately. There will be breaking bugs that can't be left alone. This is a special category of bug in my planning, and I allocate time for it. QA also must be accounted for.

## Time committment

This process should not take days. It should be possible to do in _hours_. The meetings might happen over a week or more, but the amount of time dedicated should not be large. I prefer in many cases to have the PM, Designer, and Lead go through these exercises independently, then conduct a review sign off meeting with the team at large. This saves wasted time on meetings and most engineers depend on their lead for the estimations _anyways_. It is critical that the team has buy in on the plan, so it's also acceptable to perform all steps together.

Resource Planning should only take the lead engineer an hour of their time. Typically your PM and lead engineer have a reoccuring 1-1, this is the right time to discuss the resource planning.

T shirt sizing can take less than an hour if projects are reasonably described and scoped by the PM.

Resources to projects can happen by the lead engineer / pm working together. This might be several sessions as the details evolve. By the beginning of the quarter the gantt chart should be locked down.

## Ongoing Maintenance, what comes next

I create a new sheet each week and updating the actual vs the predicted. This allows me to easily keep track of where projects are at. I stay on top of communicating any changes in the schedule to ensure people understand that projects are in good hands. This builds trust and confidence, and prevents miscommunication. Updating the sheet weekly takes less than 10 minutes for me. At a minimum you should create an end of the quarter sheet and compare the beginning of the quarter to the end of the quarter. Do a retro with your key stakeholders and look for opportunities to improve.

# Summary

This exercise provides accountability, growth, and protection. You will not need to spend a large amount of time to enter the quarter prepared. You can adapt without sacrificing communication. You have a realistic document to point to when you are saying no to something. You can explain why something is going to take the time you expect. Dial in your estimations as you gain more information. We can explore how to improve these week by week in a future article. If you like this process feel free to grab my [excel template](https://docs.google.com/spreadsheets/d/1kSxGp5gx8hvv5XEsUa9cmB0ZgUxg7vevi8wshaYrYdo/edit?usp=sharing). We also do talks and consulting, feel free to reach out at <https://www.rune.tech/contact>.


Resource based planning for product and engineering teams


## Monorepos in 2022

You may have already noticed but Monorepos are trending. They offer efficiency benefits can be hard to appreciate until you have experienced them. For example, was making a CI change at my company. I had to open 15 pull requests, one for each project. In every case I was adding a single line to a .yml file. Fifteen. Pull. Requests. In a monorepo this pipeline would have been a shared file. It would have been a single pull request with a single line.

Monorepos include many other benefits, but there are also some new challenges. Deployment and tooling become harder. Turborepo is a tool I have been using to manage my monorepo for Rune. I'm happy with the results. Now I can easily build, test, lint, pretty, or dev all of my projects simultaneously. I would like to share some of the tips and pitfalls. The described monorepo uses:

- Turborepo
- Yarn workspaces
- Vercel for deploys
- Next.js

### Overview

This post is for people who manage multiple projects. You may be using separate repos right now, working on a monorepo, or debugging a problem. In my case, I have Next.js projects for blog, marketing, app, store, chat server, and shared components.

## Basic setup

To set up Turbo just follow the guides below.

### Yarn Workspaces

I prefer yarn to npm for many reasons, but you can also use npm workspaces.

Yarn workspaces can be set up by following this guide: https://classic.yarnpkg.com/lang/en/docs/workspaces/

### Turborepo

Turborepo was straightforward to set up. I was just using a simple Makefile before switching to Turbo. I was pleased with the improvements, particularly I think the remote cache is fantastic.

Begin by following this guide: https://turborepo.org/docs/getting-started

### Vercel Monorepo

I highly recommend deploying your monorepo with Vercel. They make it extremely convenient. Don't skip the Ignored builds step. Keep in mind it's relative to the defined project root. There is a limit of 3 projects on the free plan for monorepo.

Set up your projects according to this guide: https://vercel.com/docs/concepts/git/monorepos

## Thoughts

### Packages vs symlinks

Before Turbo I was using a shared folder that I symlinked into various projects. This allowed me to share components. I switched shared folder to a package and used `paths` property in tsconfig.json to allow easier importing. However the downside I encountered was that intellisense no longer was able to auto import or click into packages. This was a downside that disappointed me. I am going to continue investigating the pakage path to see how to mitigate these downsides. I noticed they are present in the ecommerce example from nextjs as well.

## Gotchas

### Cryptic Type Errors due to yarn workspaces

When we switched to workspaces we began seeing errors related to types that weren't even dependencies in our project. Example:

```javascript
Type error: Cannot find type definition file for '__mocks__'.
  The file is in the program because:
    Entry point for implicit type library '__mocks__'

error Command failed with exit code 1.
```

This was easy enough to fix once you knew what to do. Add this to your `tsconfig.json`:

```javascript
"compilerOptions {
  ...
  "typeRoots": ["node_modules/@types"]
}
```

### Dangerous warnings due to yarn workspaces

When switching to yarn workspaces you need to keep an eye out for warnings, especially at the beginning. There is a chance for packages to collide with each other if you have not specified a specific version. This error cost me a day. Everything worked fine locally, but deploying on Vercel would fail with an error that I did not realize was due to this warning.

```javascript
warning Pattern ["next@latest"] is trying to unpack in the same destination "/vercel/.cache/yarn/v6/npm-next-12.1.5-7a07687579ddce61ee519493e1c178d83abac063-integrity/node_modules/next" as pattern ["next@^12.0.8","next@^12.0.8","next@^12.0.8","next@^12.0.8"]. This could result in non-deterministic behavior, skipping.
```

The error I saw in Vercel console:

```javascript
Error: `pages/404` can not have getInitialProps/getServerSideProps
```

The solution was to simply change a dependency in my other projects from:

`next@latest` to `^12.0.8`

### Errant warnings using JSX components

I received some errors relating to JSX components mounting. I suspect these were also caused by the warning above. However, these ones did have the ability to resolve by pinning a version.

`'Component' cannot be used as a JSX component`

Resolutions and overrides:

```javascript
"resolutions": {
	"@types/react": "^17.0.1",
	"@types/react-dom": "^17.0.2"
},
"overrides": {
	"@types/react": "^17.0.1",
	"@types/react-dom": "^17.0.2"
}
```

### Resources

If you want to peruse my sources they can be seen below:

- <https://stackoverflow.com/questions/71809703/component-cannot-be-used-as-a-jsx-component?noredirect=1#comment127187138_71809703>
- <https://stackoverflow.com/questions/71985341/error-pages-404-can-not-have-getinitialprops-getserversideprops>
- <https://github.com/yarnpkg/yarn/issues/4812>


Tips and pitfalls of setting up a monorepo with Turbo, Nextjs, and Vercel


# Introduction

Software engineers needs tools to make the right habits effortless. The right habits are going to make your code more maintainable and save your time and effort. It's easy to miss these steps when beginning a project, but I know from experience that putting them in place early will pay dividends forever. Think of it as compound interest.

There are a ton of best practices so my list is not exhaustive, but they are practices that I have seen missing in many of my workplaces. I always try to incorporate them as part of my onboarding. They build trust, momentum, and competence as part of my start. They can do the same for you!

## What is included in my list of best practices

I'm specifically focusing on easy wins. These are easy to add to any existing project.

- Pre commit hooks
- Prettier
- Eslint
- VScode editorconfig
- VScode recommended plugins

### Prettier

Prettier is a community staple at this point. We should all strive to stay in line with the community. It makes adding developers to teams easier, and you will be a better fit when you search for your next job.

`yarn add -D prettier`

Add .prettierrc

```javascript
{
  "semi": false,
  "singleQuote": true,
  "tabWidth": 2,
  "useTabs": false
}
```

Add .prettierignore

```javascript
node_modules
dist
```

Again simple, but we are now done.

### Eslint

For this we want to make it run nicely with prettier. Let's add eslint and some other helpful tools. You can pick `eslint-config-airbnb` or `eslint-config-next`, or <insert your favorite eslint config>.

`yarn add -D eslint eslint-config-prettier eslint-config-next`

Add .eslintrc

```javascript
{
  "extends": ["next", "prettier"],
  "rules": {
    "react/no-unescaped-entities": "off"
  }
}
```

### Pre commit hooks

I am using [husky](https://www.npmjs.com/package/husky) "modern git hooks made easy". Running a linter on pre-commit hook saves tons of time in the long run.

`npx mrm@2 lint-staged`

Update package.json

```javascript
"lint-staged": {
    "**/*.{js,jsx,ts,tsx}": [
      "eslint",
    ],
    "**/*.{md,mdx,json}": [
      "prettier --write",
    ]
  },
```

My example is within a monorepo, so husky runs the lint task in every applications package.json. Fantastic! That's it! We're done here.

## Halftime

We now have husky, prettier, and eslint. Let's finish the job and do the best part. Catching and dealing with these on file save so that life is literally as simple as saving a file.

### VScode .editorconfig

Adding vscode editor config is one of the easiest and best things you can do for your engineering team. It will save so many failed tests and errors.

New file at project root `.editorconfig`

```javascript
root = true

[*]
indent_style = space
indent_size = 2
tab_width = 4
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true

[*.md]
trim_trailing_whitespace = false

[*.js]
quote_type = single

[{*.c,*.cc,*.h,*.hh,*.cpp,*.hpp,*.m,*.mm,*.mpp,*.js,*.java,*.go,*.rs,*.php,*.ng,*.jsx,*.ts,*.d,*.cs,*.swift}]
curly_bracket_next_line = false
spaces_around_operators = true
spaces_around_brackets = outside
# close enough to 1TB
indent_brace_style = K&R
```

### VScode recommended plugins

Recommended plugins and settings can be shared by your team. This will prompt your team members to install recommended packages. This creates consistency on the team and saves time. You can customize the extensions, here is my sample:

`mkdir .vscode`
`touch .vscode/extensions.json .vscode/settings.json`

Update .vscode/extensions.json

```javascript
{
  "recommendations": [
    "esbenp.prettier-vscode",
    "csstools.postcss",
    "bradlc.vscode-tailwindcss",
    "ms-vscode.vscode-typescript-next",
    "rbbit.typescript-hero",
    "mikestead.dotenv",
    "eamodio.gitlens",
    "GitHub.copilot"
  ]
}
```

Update .vscode/settings.json

```javascript
{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.formatOnSave": true
}
```

## Wrapping up

We are now done with the basic set of best practices. We have implemented prettier on file save, eslinting, pre commit hooks, recommended plugins, basic settings. This is enough to prevent a lot of wasted time. You can customize each of these steps according to your own preferences and teams. Hopefully this will be a timesaver for you as much as it has been for me.


Best practices any team can use with their typescript projects


## Next.js Invisible Captcha in 2022

When I went to add Captcha to my site I was disappointed in the resources. I expected this to take about 10 minutes, and it ended taking me a few hours. I had to stitch together details from a variety of StackOverflows, Google documentation, Medium posts, and Github repo documentation. While this is fairly typical, I wanted to have a single place that contained all the useful information. This article focuses on invisible ReCaptcha. My examples are in Typescript. This article uses:

- Next.js
- React
- Dotenv
- Typescript

### Overview

It's important to have a high level view of what we are doing, and how ReCaptcha works.

1. We need a secret and key from ReCaptcha provider
2. We need to install ReCaptcha script, we will use an npm package for this
3. Add the installed package component into contact form
4. Before sending our form data we generate a Captcha token. Include this token in the payload.
5. Backend route will take this token and call a simple validation to tell us if the user is valid or not valid. If it's invalid we won't process the form submission.

### Creating a reCaptcha Key

My reCaptcha kept returning false due to "invalid input secret". I was able to locate a [StackOverflow](https://stackoverflow.com/questions/36939870/google-recaptcha-returns-false-due-to-invalid-input-secret) that pointed out something opaque. Your keys must come from [https://www.google.com/recaptcha/admin/create](https://www.google.com/recaptcha/admin/create) but not [https://console.cloud.google.com/security/recaptcha](https://console.cloud.google.com/security/recaptcha). Are you kidding? Go ahead and create a secret and a key at the correct one.

### Add key and secret to your .env file

If you don't have dotenv set up yet, go ahead and just hardcode these in for your testing. Once you get them working, find a nice article somewhere that teaches you how to use dotenv. Or just examine the source code in the [next.js example with dotenv](https://github.com/vercel/next.js/tree/canary/examples/with-dotenv).

```javascript
# CAPTCHA
RECAPTCHA_KEY="key"
RECAPTCHA_SECRET="secret"
```

### Install react-google-captcha

Go install [react-google-captcha](https://github.com/dozoisch/react-google-recaptcha). This package made installation of captcha more convenient than anything on the official documentation. Just use `import ReCAPTCHA from "react-google-recaptcha";`.

### Add invisible ReCaptcha to your ContactForm component

This is as simple as it gets. Invisible ReCaptcha uses your submit button to generate the Captcha token. This is obviously much more convenient for a user than a ReCaptcha checkbox.

```javascript
const recaptchaRef: any = React.createRef();

...

<ReCAPTCHA
  ref={recaptchaRef}
  size="invisible"
  sitekey={process.env.RECAPTCHA_KEY!}
/>
```

My submit button looks like this (but yours can look different). This is included as an example, but not strictly important for the tutorial.

```javascript
<Button
  type="submit"
  className='mt-2 w-full inline-flex items-center justify-center px-6 py-3 border border-transparent rounded-md shadow-sm text-base font-medium text-white bg-sky-700 hover:bg-sky-800 focus:outline-none focus:ring-2 focus:ring-offset-2 focus:ring-sky-600 sm:w-auto h-12'
  onClick={submit}
  text="Submit"
  state={state as any}
/>
```

### Generate captcha token on form submission

I define my payload in the `submit` onClick handler. I included the whole function although only the

`const captcha = await recaptchaRef.current.execute();`

is relevant. Also, the documentation for react-google-recaptcha claimed that you should use executeAsync here, but it broke everything when I did that. This worked fine.

```javascript
const submit = async (e: MouseEvent) => {
    e.preventDefault();
    setState('Loading')
    try {
      const captcha = await recaptchaRef.current.execute();
      await axios.post('/api/contact', { firstName, lastName, email, phone, subject, message, captcha, communicationMethod })
      setState('Success')
      setEmail('')
      setModalOptions(successOptions)
      // window.grecaptcha.reset();
    } catch (e: any) {
      setState('Error')
      setModalOptions({
        title: 'Unable to send message.',
        description: e.response.data.error,
        action: 'Okay',
        icon:
          <div className="mx-auto flex items-center justify-center h-12 w-12 rounded-full bg-red-100">
            <ExclamationIcon className="h-6 w-6 text-red-600" aria-hidden="true" />
          </div>,
        setOpen: setShowModal,
      });
    } finally {
      setShowModal(true);
    }
  }
```

### Add a helper function for validateCaptcha

This was one of the areas that I was most disappointed in the internet. I was thankful to have code examples to work off of, but as far as syntax goes they were basically trash (no offense internet). I also have two forms that I want to use Captcha on, so extracting captcha validation to a helper function is the right choice. Let's actually do this using modern es6 syntax:

```javascript
import axios from 'axios'

export default async function validateCaptcha(response_key: string) {
  const secret_key = process.env.RECAPTCHA_SECRET
  const url = `https://www.google.com/recaptcha/api/siteverify?secret=${secret_key}&response=${response_key}`

  try {
    const response = await axios.post(url)
    return response.data.success
  } catch (error) {
    console.error(`Error validating captcha: ${error}`)
    return false
  }
}
```

### Use our helper function in the backend to validate Captcha

Place this block right at the top of your submit handler in the api.

```javascript
import { NextApiRequest, NextApiResponse } from 'next'
import validateCaptcha from '../shared/components/validateCaptcha';

export default async function Contact(req: NextApiRequest, res: NextApiResponse) {
  const { captcha } = req.body;
  console.log('captcha', captcha);
  const validCaptcha = await validateCaptcha(captcha);

  if (!validCaptcha) {
    return res.status(422).json({
      error: "Unprocessable request, Invalid captcha code.",
    });
  }

  ...

};
```

### Wrapping up

Now you can test. If something goes wrong here is the list of resources that I used to create this article and troubleshoot when I had problems. Good luck hunting bots! Try using the chat widget if you want to talk about a more specific problem and who knows. Maybe a human will respond (no promises).

- <https://github.com/dozoisch/react-google-recaptcha>
- <https://stackoverflow.com/questions/1264703/google-recaptcha-keep-getting-incorrect-captcha-sol>
- <https://stackoverflow.com/questions/36939870/google-recaptcha-returns-false-due-to-invalid-input-secret>
- <https://stackoverflow.com/questions/54695089/invalid-input-response-and-secret-when-verifying-google-recaptcha>
- <https://stackoverflow.com/questions/46514194/how-to-reset-google-recaptcha-with-react-google-recaptcha?rq=1>
- <https://stackoverflow.com/questions/67935841/recaptcha-v3-error-incorrect-captcha-sol-randomly>
- <https://stackoverflow.com/questions/1264703/google-recaptcha-keep-getting-incorrect-captcha-sol>
- <https://stackoverflow.com/questions/27133172/recaptcha-documentation-unclear-and-cross-site-error-testing-it>
- <https://stackoverflow.com/questions/3232904/using-recaptcha-on-localhost*>


How to Implement Invisible Captcha with Next.js in 2022


### What is a computer virus?

Computers viruses are one of the dangerous side effects of our connected world. They can be used to steal your identity, steal your data, or even cause your computer to crash. There is a sense of violation that is reminiscient of the feeling you have when something is stolen from you. So who is behind these viruses?

### Who creates computer viruses?

Viruses can be created by any number of bad actors. It's not likely they are coming from our community. More likely these come from organized crime groups or even nation states. The days of college student "hackers" creating a virus are behind us. These are legitimately dangerous threats that will use your computer to wreak havok. Why would these bad actors be doing this?

### How can a computer virus harm me?

Viruses can be used to conduct espionage, ransom attacks, or even large scale attacks on infrastructure. The basic premise is that a virus can be installed on your computer without you knowing it. Viruses can even be hidden until the attacker has affected enough devices to begin crashing ecommerce websites, and extorting them for ransom. Lost revenue can be greater than the actual ransom amount. This is one example, but there are even bigger risks.

Some viruses can even be used to conduct large scale attacks. You may not know it, but if you are infected your computer can be used as part of a botnet to conduct attacks on even our own cities and country. But what about the individual impacts that can occur?

Viruses can also be used to sneakily capture personal data, or present false advertisements that entice users to enter sensitive information. These are the most common attacks that result in effects such as identify theft and financial loss. There are basic steps that can be taken to reduce these risks.

### How can I protect myself from computer viruses?

The key detail to remember is that an up to date computer with virus protection is much more difficult to infect. This is why we recommend always keeping your computer secure and up to date. We understand not everyone has the interest or expertise to do this. That's why we offer a monthly subscription to our customers.

### How can Rune help me with computer viruses?

I have been removing viruses and fixing computers in the community for over 15 years. I would like the chance to bring you into our technology wise family. It would be my pleasure to help keep you, your devices, our community, and country safe.

- Erik Mellum


Where Do Computer Viruses Come From?


# What is Rune

Rune is a technology company based in Chico, CA. Rune offers services including computer repairs, website / software development, and business IT services. We wouldn't be in business unless we believed in our solutions. We guarantee you will love our solutions and the Rune experience. We can work together to make your technology pleasure rather than pain.

## Who Founded Rune

Rune was founded by Erik & Krissy Mellum. Erik grew up in Chico having gone to school at Shasta, Bidwell, PVHS, and finally Chico State. After graduating with a degree in Computer Science Erik had the opportunity to work for VC funded startup software companies in the Silicon Valley. Krissy is also a local Chico native with her Masters in Education from CSU Chico. Erik and Krissy are the loving parents of four children. They are incredibly excited to bring their expertise to the wonderful community of Chico.

## The Reason Behind Rune

Erik began his working career at In n Out burger where he discovered the beauty of excellent process and customer service. He then began fixing computers at a local computer store and found a niche applying his love of service with his technical aptitude. Erik was able to work and learn at Build.com to see how a successful local tech company functions. He was inspired to get his Computer Science degree, and upon graduation went to work for startups funded by some of the most prolific venture capital companies in the Valley. This was an opportunity to learn from the best, and see the inner workings of some of the most successful companies in the world. He honed his craft of software development, but always yearned to create a company in the local Chico community. The day has come, and Krissy and Erik cannot wait to share their skills to benefit the community.


Rune Launches in Chico


## Computers are everywhere

Computers are becoming more and more important to us. They are the backbone of our daily lives. We carry phones in our pocket, tablets in our backpacks, and they sit on our desks at home. Since the pandemic we even are using them to do remote communication in a way never before seen. Manufacturers try to make them as easy to use, but it doesn't mask the fact that we live in a world that is filled with incredible technical complexity. Even the most professional computer programmers can't always explain why software breaks. My own mother has a knack for breaking computers in ways that I truly have never seen before.

### Why do computers always break for me?

Some people seem to have more trouble with computers than others. This is not a surprise given that we all see this in our daily lives. Our children seem to either have great luck, or great understanding. As we get older, we tend to have more challenges. Some of this can be due to our lack of knowledge, but it also does seem that disaster strikes at the least opportune times, on those of us who understand the least. Murphy's law is no joke. So what are some steps we can take?

### How can I prevent my computer from breaking?

1. Keep your computer up to date.
2. Install virus protection.
3. Find a friend or family member who can help.

### What if I don't know how, or I don't want to?

We understand that not everyone has the capability to update their computers, make sure that you have the latest patches, and virus protection running. How can you perform these steps if they are foreign to you? Or what if you are just not interested in doing it? That's not an unreasonable stance, but it is one that you should be aware and take steps to remedy. After all, hacks and identify theft are more common today than they were last year, and tomorrow wil have more risks than today.

### Why is Rune different, and how can they help me?

It's clear that doing nothing is not an option in our modern technology filled world. Rune is a business founded on customer service. When I worked at In-n-Out burger I got through the day smiling, knowing that every meal I served had the potential to turn someone from hangry to happy. The same is true for computer repair. We care deeply about making your experience with computers a positive one. This may literally seem impossible if you have struggled for years with technology, but please, we can shift your perspective.

### Why a subscription may be right for you

We offer a subscription based service specifically because we know from experience that this has the potential to turn computers from pain to pleasure. Take a second to imagine having a computer that is up to date, secure, and knowing that when you do get stuck, you can talk to someone that you enjoy talking to. Someone who also has a life, with children, part of your local community. We have the chance to work together to make our lives and community better. Take the step today and join our team as a TechPro!

The bottom line is that having no help is not an option. We are all guaranteed to get stuck sometimes. Save yourself the pain and frustration by having a plan for when it happens. Change our perspective to make calling for help more like visiting a friendly barber, or having coffee with a friend. This shift can make computers personal, and something we look forward to. That makes all the difference.

I hope I get to help you someday. It would be my pleasure.

- Erik Mellum


Rune Launches in Chico

What is Rune

Who Founded Rune

The Reason Behind Rune

From the blog

Business IT

Technical Support