
<div style="padding-bottom: 40px; padding-right: 250px; padding-left: 250px;">
    <img src="/assets/blog/2020-10-19-survival-guide-for-your-teams-newest-developer/eagle-wing.png" style="display: block; max-width: 100%;" alt="eagle wing">
</div>

After a long-winded search for employment, including copious rejections, maybe you’ve finally landed a sustainable position at a well-grounded company, or maybe you’re still on the hunt. The job market ebbs and flows, but as long as you stay dedicated with your spirits up, you’ll likely be making this transition as well. I started my journey into tech a year ago, and I’ve now been working as a developer at my newest company, Olio Apps, for about 3 months. After a pretty great interview, I felt confident that I would be offered the position. Soon after, I had a start date to look forward to! As anyone would be, I was excited, but I couldn’t help but be nervous as well. I felt like this was a bigger opportunity than my previous positions at small start-ups.

Throughout these last few months, I’ve learned some things I wish I'd known beforehand, but there have also been things I wish I hadn’t focused on as much. Pulling from my quick onboarding process and other experiences I've had joining teams, I’ve written this guide as a roadmap for new developers, aimed at showing them what to focus on in order to be a successful hire. This "survival guide" should help new developers onboard more effectively, connect with their team in a meaningful way, and focus on the things that matter while joining a new company or team.

<div style="padding-bottom: 10px; padding-top: 10px; padding-right: 50px; padding-left: 50px;">
    <img src="/assets/blog/2020-10-19-survival-guide-for-your-teams-newest-developer/chicks.jpg" style="display: block; max-width: 100%;" alt="chickling stage">
</div>

## First Day

So it’s your first day of work!

You’ll likely be getting access to the company’s software and email (if not later, depending on the company). You’ll probably be introduced to team members or managers that you’ll be working closely with, then go over your first tasks. Make sure you know what to work on, who to report to, and which tools you’ll need to be an active part of the team. JIRA, Confluence, Slack, and the company Gmail were some of what I was granted access to on my first day.

I expected there to be delay on some of these things, since there always seems to be… But I was lucky to have a small and lightweight team that got things done quickly, compared to a larger company that might move more slowly on getting approval for a new hire. The first day probably won’t be full of excitement, but you’ll likely learn some basic details about the company and your place in it.

First day checklist:

- I know my direct supervisor and who else to turn to for help.
- I have access to whatever I need to perform my job (at least for the next day).
- I understand my process for starting, working on, and completing a task (often, this could simply be moving a JIRA ticket from the to-do section to done).
- I am as prepared as I can be to start the next day of work.

<div style="padding-bottom: 10px; padding-top: 10px; padding-right: 50px; padding-left: 50px;">
    <img src="/assets/blog/2020-10-19-survival-guide-for-your-teams-newest-developer/ducklings.jpg" style="display: block; max-width: 100%;" alt="duckling stage">
</div>

## First Week

Your first week will be a great opportunity to reach out and connect with a few of your teammates. If there are any extracurricular activities, like happy hours or company meetups, make sure to go! If there’s a teammate around your level who’s been there a little longer than you, reach out and ask what they would recommend you focus on to succeed (after all, they’ve most recently been in your position with this team). Your first week is also a great time to get a feel for what level of communication your manager is expecting. Make sure to give updates on the tasks you’re completing, and if they’re still reaching out about your tasks, it may be a sign that you should be communicating a bit more frequently.

Whatever progress is made at this point, typically you’re still catching on to company-specific conventions and processes. Try to forgive yourself for any little mistakes that are bound to happen. During your first week, it’s okay to make mistakes, as long as you’re learning from them. Also remember that, as a new part of the team, your work speed is important but not the most important variable of your job performance. I had conversations with my supervisor about how accuracy, independence, and then speed were important, and typically in that order. So don’t sacrifice one higher priority item for another, and always be aware of where you are putting your energy.

First week checklist:

- I’ve tuned or optimized my dev environment for my position. Reach out to coworkers for tips on this one!
- I’ve gathered company resources (such as handbooks, PR guides, etc.) in case I have questions.
- I know who I can pair with on any problems I’m facing (you’d be surprised what experienced developers can teach you within the span of 15 minutes).
- I’ve reached out to coworkers for advice they wish they had when they first started here (and why not add some of them on LinkedIn?).
- I am periodically checking other employee’s work (i.e. pull requests) to see what coding patterns they use and what could be considered good or bad code.

<div style="padding-bottom: 10px; padding-top: 10px; padding-right: 50px; padding-left: 50px;">
    <img src="/assets/blog/2020-10-19-survival-guide-for-your-teams-newest-developer/geese.jpg" style="display: block; max-width: 100%;" alt="geese stage">
</div>

## First Month

Around the close of my first month, I started to feel like a strong part of the team, but don’t be discouraged if it takes a little longer. At this point, you’ll probably be fully onboarded and set up for success. And really, the best thing about the first month is that it’s when you start to see growth. You’ve learned company processes, and now dividends are paying off for having a growth mindset and learning from setbacks.

Even though you seem to be establishing yourself within the team, don’t forget to focus on basics such as testing the functionality of your work and communicating effectively with your teammates. During my first month, I started to focus more on speed of development rather than accuracy and ultimately paid for it with pull request rejections. I then had to dig through non-working code to fix the issues, which can be a difficult process, especially compared to creating something correctly the first time.

First month checklist:

- I’m starting to feel confident that I’m a valuable part of the team.
- I’m asking for feedback on work when I’m not getting a clear understanding of what’s going on with my code.
- I’ve started picking up smaller tickets of my own accord (as long as they’re within your scope of work).
- I’m starting to feel comfortable in areas of the codebase where I previously may have felt confused or lost on what was going on.
- I’m still welcoming code reviews and working on not repeating mistakes that have been commented on previously. (Your managers will notice this!)

<div style="padding-bottom: 10px; padding-top: 10px; padding-right: 50px; padding-left: 50px;">
   <img src="/assets/blog/2020-10-19-survival-guide-for-your-teams-newest-developer/eagle.jpg" style="display: block; max-width: 100%;" alt="eagle stage">
</div>

## Onward and Upward

By now, you will certainly know if you’re excelling or still need to make minor adjustments. Take the time to revel in the fact that you’re doing exactly what you want to do and getting compensated to do it! It’s a long road to get where you are, and it shouldn’t be taken lightly. Continuing to grow and develop your skill set will be important moving forward, but if you’re providing value by this point, you’re on a good path.

Remember to focus on the things you can control and that no hire is perfect. If you follow some of the core principles of this guide, you’ll have plenty of resources to work with on your journey, and your journey certainly doesn’t end here. Everyone on a team was the new hire at some point, and as time goes on, you’ll probably laugh at the nervous thoughts you had leading up to your first few days. Just know that no one here wants you to fail, and your coworkers want to enjoy working with you. Keep improving, don’t listen to thoughts that make you feel like you don’t belong, and you will certainly be just fine.


A Survival Guide for Your Team's Newest Developer


<img src="/assets/blog/2020-08-12-save-money-building-mobile-apps/calculator.jpeg" alt="A mobile phone calculator app" style="display: block; max-width: 100%;">

In this article, I discuss seven principles for minimizing the time and money spent building a mobile app. If you're looking to build an app, are pressed for time, and don't have an unlimited budget, keep reading!

## Planning

No plan is perfect, though a healthy amount of planning will help a great deal when it comes to saving money and time.

### Fully Explain

At my software consulting company, [Olio Apps](https://www.olioapps.com/), we are often approached with projects and asked to estimate without much information. Sometimes we're given little more than a sentence or two of a business idea ("Uber for cats! How much?"), or a slide deck with mostly pictures and a few words, and we are left to surmise what that actually means, or how grand the vision is. If you ask someone for a quote but provide little to go on, and you do get an estimate back, be aware it's a wild guess and could be off by orders of magnitude.

To help customers flesh out their product visions, we provide [Discovery and Roadmapping](/services/discovery-roadmapping/) engagements, where we spend a week doing working sessions with them, building up the use cases, user stories, and wireframes, and whatever else is needed to build an informed development plan and cost estimate.

<img src="/assets/blog/2020-08-12-save-money-building-mobile-apps/wireframes.jpeg" alt="Drawing wireframes on paper" style="display: block; max-width: 100%;">

### Mock Up the App

The clearer you make the picture of what you want up front, the less guesswork your engineers will have to do. You want to eliminate guessing. If you leave right vs. wrong up to chance, there is a very good chance it will be partially wrong, which will cost more time and money.

The more you can fully tell the story of how your software should work, and ideally how it should look, the more likely you'll get it right the first time. Mocking things up with pictures and written descriptions has a way of revealing the holes and corner cases not yet considered. It's cheaper and faster to find and flesh out the murky areas before you build.

Conversely, the most beautiful mockup images are just images, and though they may look great, software needs to be touched and used before you truly know if it is a joy to use, or super annoying and difficult. So make mockups of the most critical pieces. Whether you’re sketching the app in [Balsamiq](https://balsamiq.com/wireframes/) or prototyping in [Figma](https://www.figma.com/), emphasize functionality over beauty. Then get to a working prototype that users can try as quickly as possible, so you can learn and refine from working software.

<img src="/assets/blog/2020-08-12-save-money-building-mobile-apps/user-testing.jpeg" alt="Drawing wireframes on paper" style="display: block; max-width: 100%;">

### Get User Feedback Before You Build

Are you part of the target audience of your app? If so, that's a great start. Have you talked to others in the target audience and asked for feedback on your app? You don't have to wait until after you've spent a lot of time and money building the app to start. Before your app is built, you can and should ask for feedback to validate and refine your ideas.

Turns out, there is right way and a wrong way to ask for feedback. Wrong way: saying to family and friends, “I’m going to build an app for X! Will you use it?” The answer will be yes, but that’s not useful. It does not tell you whether real users will use it. Your friends and family are biased towards you. Better: “Do you have any problems with X? How do you deal with X today?” We recommend reading [The Mom Test](http://momtestbook.com/) to guide your approach to getting useful feedback.

If you've done the work to mock up your app, you can even build a clickable prototype using a tool such as [Figma](https://www.figma.com/) or [Invision](https://www.invisionapp.com/) to let users walk through the user interface and see how the app would work, before you spend the time building it. This will obviously save you more time and money.

## Technical Choices

We are a technical consultancy, so here's where I'll make some technology recommendations. There are many ways to build a mobile app. Depending on your choices, you could spend wildly different amounts of time and money to arrive at the same outcome. The common thread here is leveraging existing expertise and re-use.

<img src="/assets/blog/2020-08-12-save-money-building-mobile-apps/tools.jpeg" alt="Lots of tools neatly arranged" style="display: block; max-width: 100%;">

### Use Tools Lots of Developers Know and Like

If you choose technology and tools that lots of people know and like, you can find people happy to build it now, and others willing to maintain it going forward. If you pick something obscure, overly clever, or proprietary, there will be a smaller pool of people who can work on it, which will make it more expensive. If you are non-technical or getting advised on technology choices by others, do a little research, ask around, and see if the terminology being thrown around is familiar and well-received by others.

### Use a Cross-Platform Framework

A cross-platform framework cuts development time and gets your app running on multiple platforms with a single code base. One team can build for both platforms at once. The 80/20 rule applies: 80% of the code is shared, 10-20% is platform specific conditional code, but it all lives together in a single version-controlled code base.

There are many options, such as those listed in this [roundup article from March 2020](https://hackernoon.com/9-popular-cross-platform-tools-for-app-development-in-2019-53765004761b). The top four listed are React Native, Xamarin, Flutter, and Ionic. All of these are decent choices, and the best choice for you should be influenced by the current expertise of your developers (C# developers? Xamarin. React web developers? React Native. Angular web developers? Ionic.) But ongoing maintenance and the hiring of future developers to maintain the project should also be a consideration.

I recommend [React Native](/services/react-native-applications/) because it is well known and supported, and used successfully in many popular apps. It allows front-end developers who already know [React](/services/react-web-applications/) (the most popular frontend web framework as of August 2020) to leverage their existing expertise to build native mobile apps, as well as web apps. If you need something specialized and platform specific, you can drop down to native code and write an extension. These days, existing open source extensions exist to cover most common use cases. It is now possible to build a React Native App that runs on iOS, Android, Windows, Mac, and the Web.

### Use Libraries for Common Features Found in Every App

There are now libraries and components that implement the common things that most apps do. For example, almost all apps require you to sign up and log in. There's nothing new or ground breaking about this part of an app, just potentially time-consuming work, implementing the same thing many people have done before. Instead, make use of the libraries and services that allow you to skip the heavy lifting and get sign up and login functionality working right away. Some examples are [Amplify](https://aws.amazon.com/amplify/), [Cognito](https://aws.amazon.com/cognito/), [Firebase](https://firebase.google.com/), and [Auth0](https://auth0.com/). Unless you have a good reason to roll your own, it makes financial sense to use one of these, so you can spend more time on the actual unique value your app will provide.

## Lean on Experts

If you are not an app developer, or if you have a team of technical people who focus on other things besides mobile app development, consider working with experts who have successfully built multiple apps already. Not only will this help you get your app off the ground faster, it will also help you avoid mistakes and keep you from incurring technical debt that may slow down your project. Plus, an experienced team can work with you to bootstrap a good software development process that you can carry forward within your organization.

Looking for an experienced team to build your mobile app? [Contact us](/contact-us) today to start a conversation about your project.


7 Great Ways to Save Time and Money Building a Mobile App


<img src="/assets/blog/2020-04-24-internship-2020/team.jpg" alt="A team of people around a laptop" style="display: block; max-width: 100%;">

There are many paths into software. Some start a career right out of college, some self-teach in the evenings for years, others smash away at intensive summer boot camps, and some seem to roll into this world with a penchant for technology. For a lot of us, it’s a combination of these. Eventually, we transition into the professional side of software (though it sometimes doesn’t feel like it at the time). Maybe that means getting hired to build a website for your uncle's small business, starting an internship or apprenticeship, landing a full-time gig in a fancy office, or somewhere in between.

For me, it was an internship fresh out of a boot camp with a small but mature company in Portland, Oregon. It was an experience, though imperfect, I’m immensely thankful for. Shortly after completing my brief internship, I was hired by Olio Apps, a Portland-based software consultancy. As a company, Olio Apps focuses on building web and mobile apps, but as a team, we’re encouraged to focus on personal development through skill-building and sharing. One way we do this, while also giving back to the development community, is by occasionally offering internships to junior developers. We’ve seen several rounds of interns, and each time, we learn something new and refine the process. This year, I was given the opportunity to lead the internship. Thanks to careful planning, the support of the whole team, and two excellent interns, I’ll be the first to report it was a smashing success.

Internships can come in many shapes and sizes, and can have mixed results for the interns as well as the company. There are a lot of factors to consider when planning to host interns, such as company size, senior developer availability, project complexity, intern skill level, etc. Some factors can be controlled, and others can’t. But there are a few things that can help maximize the value of the internship both for the interns and the company. If you or your company is considering offering an internship in the future, or already has an internship program, here are some of my top tips.

### Choosing Interns

To find interns, we typically work with a local code school, Epicodus, and are given 10 or so junior developers to interview. We have quick, speed-dating-like interviews that are 30 minutes long. For us, it feels like seconds. But for them, most of whom are experiencing their first ever technical interviews, I’m sure it feels like hours. The code school then does the final match-making based on both the interviewers' and interviewees' responses. Because of this process, we don’t get the final say in who our interns are, but for the most part, we’ve had good luck with getting our top choices.

<img src="/assets/blog/2020-04-24-internship-2020/interview.jpg" alt="Two people in an interview" style="display: block; max-width: 100%;">

At Olio Apps, we kind of make a holiday of the intern interviewing and selection process, pausing our work to meet the interns and talk about how the interviews went. We involve the whole team in meeting and selecting the interns because team cohesion is an important part of our company culture. Based on our collective experience working with different types of people, we coined our ideal candidate “the humble ass-kicker.” We look for someone who is the right combination of cultural fit and skills (or perceived ability to obtain skills). That may seem obvious to some, but it can sometimes be tempting to lean toward someone who has impressive hard skills but lacks in personality, or vice versa. From experience, we’ve learned that a blend of hard and soft skills is essential, especially because there’s a lot of collaboration and pair-programming encouraged during the internships we offer. If someone isn’t easy to work with, it’s difficult for everyone.

It can be challenging to get a sense of a junior developer’s skills and personality during a brief 30-minute interview. We do about 5 minutes of “meet the whole team,” followed by 10 minutes of non-technical, cultural fit questions, and then dedicate the final 15 minutes to a collaborative whiteboarding exercise. Whiteboarding can be intimidating for junior developers, but it gives us an opportunity to see how they operate under stress, how they solve problems verbally and visually in real time, and how they ask questions and engage with team members. It also gives them a taste of a real-world technical interview, which is good for their professional development. After the 30 minutes are up, one of our team members usually offers to take them for coffee to answer any of their questions and decompress after the interview. Interviewing is always a two-way street (though sometimes it doesn’t feel like it as a junior developer), and it’s important to us to make a good impression with the internship candidates.

### Pre-Internship Planning

Having a plan for the internship is vital. Through our years of offering internships, there has always been a rough plan that includes a few lectures, practice problems, toy apps, and eventually test writing and basic tickets in various real-world projects. This time was different. As the internship facilitator, I created a structured (yet flexible) five-week plan that would provide a guide for the interns, as well as me, while I navigated taking on this new role and continued to fulfill my other roles as technical lead for [Shoutbase](https://www.shoutbase.com) and architect on other projects.

<img src="/assets/blog/2020-04-24-internship-2020/planning.jpg" alt="planner with sticky notes" style="display: block; max-width: 100%;">

The plan included a one-week ramp-up of JavaScript skills, which included reading materials, coding exercises, code review, and topic lectures. After the ramp-up, they were introduced to the Shoutbase code and the detailed tech design I had created for the feature we would implement together. I took the challenging parts while they started taking from an organized set of tickets. Starting small, they worked on writing unit tests for stateless utility functions, similar to what they had seen in coding exercises the week before, followed by writing different stateless utility functions themselves. After that, they moved to writing simple React components. By week three, they were writing progressively more challenging React components and integrating reusable existing components. After that, they added functionality to their components using our in-house rendition of Redux called [Sitka](https://github.com/olioapps/sitka). By the end, they got to experience the end-of-sprint testing, debugging, and bug-fixing cycle.

Having a detailed tech design and a structured plan of attack was critical to the success of the internship. It helped me communicate what I needed from them and eliminated any confusion around basic things (like what to name a certain function) as well as more major things (like state management and expected behavior). It also allowed me to step away and work on other duties while remaining confident that they could work independently and deliver what was expected, even as juniors.

Maintaining flexibility was also key. Each week had its own set of goals that could be fine-tuned based on the week before. Throughout the internship, we focused on learning and writing quality code, rather than stressing over hard deadlines. This gave everyone room to make mistakes, enjoy the experience, and learn.

### Involving the Whole Team

Beyond an introduction to writing code in a professional environment, a primary feature of an internship is exposure to senior developers. That way, interns get to hear different perspectives around programming, working in the industry, and tips and tricks. While I was the primary facilitator for the internship, each Olio Apps team member had their moment to shine by delivering a talk in their area of interest or expertise. The talks gave a primer on new subjects or expanded on what the interns had learned in code school. In all, there were over a dozen talks that included our company's philosophy for writing code, tooling to enhance productivity, pull request etiquette, ES6 syntax and conventions for clean JavaScript code, writing unit tests, advanced CSS and styling techniques, React, Redux-Saga, Sitka, frontend and backend architecture, sprint planning, QA, and manual testing.

The talks served many functions. Of course, they helped teach the interns skills they could then apply to their work, but it also gave the team members an opportunity to stretch themselves. While preparing for their talks, many of them refined their own understanding of certain topics and had to take on the beginner’s mindset, in order to simplify complex ideas into their simplest forms. It’s a challenging but rewarding task. In addition to that, junior developers often ask great questions that can spur conversation and even challenge senior developers' understanding.

We also recorded these talks. By recording them, the information could be shared internally amongst current and future team members. Instead of siloing information into a few “topic experts,” we can now create a bank of tribal knowledge of which we all share. And having a set of videos geared toward junior developers is a great place to start. Additionally, we can share these videos with future interns and potentially externally as well, to spread our knowledge beyond the company.

### Scoping a Project for Beginners

At code school, the students become very familiar with creating short-lived projects from scratch. For us, it’s important to provide a more real-world experience for the interns where they can be introduced to a sophisticated, public-facing app. It’s also essential to create a safe playground environment, where the focus can be on learning without the potentially stressful pace or standards of client work.

<img src="/assets/blog/2020-04-24-internship-2020/scope.jpg" alt="eye glasses on a desk in front of a computer" style="display: block; max-width: 100%;">

The timeline for the internship lined up ideally with the introduction of a new feature to our internal project, [Shoutbase](https://www.shoutbase.com). I had already implemented the majority of the backend for the feature, and the interns ramped up just in time to help me start on the frontend. The UI was relatively complicated, including forms, state management, and communication with the backend—“not your average code school project,” to paraphrase one of the interns. One might say it was a relatively ambitious internship project. Despite this, the interns were able to complete a huge chunk of the feature, and they exceeded our original goals for the internship.

The key was dividing the work into incremental pieces that the interns could understand and then progressively introducing more difficult tasks as their skills developed. While the end result of the feature was similar to how I (or another senior developer) would have written it, the path we took to get there was much different.

Normally, when I’m planning to introduce a new UI feature, I will break up the feature into pieces and create tickets that consist of isolated chunks of end-to-end functionality. This includes any state management, utility functions, tests, styles, and behavior. I had the interns start in areas more familiar to them, like writing stateless utility functions and tests, which strengthened their skills in that area, and then we branched out from there. Breaking the work up in a way that allowed them to focus on the same type helped them gain mastery in an area before moving on. In the end, we could weave the pieces together into a working UI.

The proverbial saying, “Measure once, cut twice,” is valuable philosophy for developers, but sometimes, it’s good for a junior developer to have to “cut” the same piece of code two or three times to understand the difference between “functioning,” “better,” and “best” code. There were a couple occasions where I provided a ticket with little guidance, reviewed the resulting code with a little more guidance, and then challenged the interns to try once again to take their code to another level. Though being asked to write the same piece of code over for the third time might be frustrating for some, a beginner with the right attitude is going to gain a lot of value from the experience and learn how to challenge their own code to reach a higher standard beyond being “done” or “functioning.”

The first couple of weeks, I understood that I was spending more time reviewing and re-reviewing the interns’ code than it would have taken me to write it myself. But I also understood that the time I was taking to write out thoughtful critiques, provide links to further reading on the topics, and offer suggestions, rather than giving out all the answers, was an investment into developing their skills. And that benefitted me as well: in the final weeks of the internship, they were able to work relatively independently and deliver code that needed very little revision.

### Defining a Workflow

Creating a consistent workflow helped the internship run smoothly for everyone. From the interns’ perspective, the workflow was relatively simple. Each Monday, we would review the progress from the week before and plan the following week based on the master plan I created pre-internship, factoring in any necessary adjustments. For me, I needed to integrate the internship workflow into my other responsibilities. This was particularly challenging for the first couple of weeks, when the interns needed the most guidance. To help alleviate this, I created a schedule of black-out times when I was unavailable, and the interns would have to rely on each other or ask a different team member for help. This helped me get my own work done, and it also gave the interns the opportunity to interact directly with the other developers at Olio.

<img src="/assets/blog/2020-04-24-internship-2020/workflow.jpg" alt="man writing workflow on a whiteboard" style="display: block; max-width: 100%;">

Another important part of the workflow, beyond just slinging code, involved giving and receiving feedback. Feedback is essential for growth, and encouraging two-way feedback ensures that both parties are getting what they need and that the process improves over time. Each Friday, the interns were involved in our team’s weekly retrospective, which is an informal meeting where we reflect on the week, celebrating the highs and discussing solutions for any low points. By involving the interns in the retro, we gained insight into their experiences that helped us create a better internship for them and hopefully others in the future, leaning into the positive aspects and attempting to eliminate or mitigate any negative aspects. They also got to participate in one of my favorite rituals of the company, and hear the thoughts and emotions of more senior developers as we experienced and navigated through the highs and lows of creating software.

### Words of Caution

After recently concluding a very successful internship, it’s easy to focus on the positive aspects, but I think it’s also important for me to address a possible downside that could impact both the company and the intern. Offering an internship can take a lot of resources. If you’re unable to front these resources, or if you think a low or unpaid internship is a good way of getting cheap code, think again. As I stated before, for quality results by the end of a several-week internship, significant investment by one or more senior developers is vital.

<img src="/assets/blog/2020-04-24-internship-2020/handshake.jpg" alt="Two people shaking hands" style="display: block; max-width: 100%;">

Personally, I think offering an internship is a combination of two things:

- an opportunity to give back to the developer community by giving the interns real world experience
- an opportunity to meet new developers as a trial period for possible hiring into your company

Both of these opportunities involve having respect for the intern's time and effort, instead of seeing them as a resource for cheap code.

### Conclusion

By now, I hope it’s clear that offering an internship can be a valuable experience for everyone at a software company. Whether you’re considering taking interns for the first time or you’re a seasoned pro at hosting interns, hopefully, you feel inspired to provide an internship that strengthens your team, empowers junior developers, and gives value to everyone involved. If you’re interested in hearing more about internships at Olio Apps, check out this post by former interns and current full-time employees, Ami and Cory: [Internship Experience](https://www.olioapps.com/blog/internship-experience/).


Providing a Rewarding Software Internship


<img src="/assets/blog/2019-11-25-hard-mode-development/alien.jpg" alt="A photograph of a mural of a space invaders sprite by Francesco Ungaro via Pexels" style="display: block; max-width: 100%;">

A day in the life of a software developer is mostly a system of routines: you do your stand-up meetings, you portion out your work, you set your goals, and (hopefully) you accomplish them with a little extra time to spare. Some days, you demonstrate your work to the client, some days you set up a planning meeting to codify your sprint objectives, and some days you create a technical design for a more complicated feature.

Whatever your day ends up looking like, it likely falls into a pattern of an established cadence set by your employer’s standards, or through trial and error experience with the project—except when it doesn’t.

In my case, my place of employment, [Olio Apps](https://www.olioapps.com/), mostly functions as a consultancy, taking on a variety of projects from different fields and disciplines—some greenfield projects and some that are already in production. For additional context, in my 14 months at Olio, I’ve personally worked on about six or seven different code bases for various clients.

Most recently, my boss, Aron, assigned me and my co-worker, Frank, to a prototype project where the client already had a deadline established. The delivery date they requested was about three weeks out from when we accepted the contract and the goal was to finish a prototype scheduling wizard that would be in a high-fidelity, demo-ready state.

As I mentioned before, software developers generally adapt to a “normal” cadence for their work flows; I have one as well, but this project required me to rearrange my “normal.” Aron coined the term “hard mode” to describe this paradigm for dealing with crunch, but what really makes “hard mode” different from what we deem normal and how did we successfully end up with a functional prototype that met all of the client’s requirements?

## “Normal Mode” Versus “Hard Mode”

Let’s start with operational definitions of what “normal mode” and “hard mode” are. For me, “normal mode” looks like this: my team and I set sprint goals about once a week, tackling a few small features or one large feature, with the goal of a small but stable release. The project I’ve worked on that is most representative of “normal” for me is the project that has comprised the majority of my time at Olio Apps thus far. The codebase was already in production when the project started, and it used our standard [React](https://reactjs.org/)/[TypeScript](https://www.typescriptlang.org/)/[Redux](https://redux.js.org/)/[Redux Saga](https://redux-saga.js.org/) stack.

The work was done on a per-feature basis, where the client would send a list of changes and bugs. This list was then broken up into individual Jira tickets and assigned to myself or my project partner. Though there was a deadline, we were rarely aware of it because there was no real crunch. Everything got done, we performed routine regression testing, and we would ship a build to the client every week.

This particular cadence had its moments of stress, especially when untangling unforeseen regressions, but overall, it had a lax and sustainable pace. Similarly, the majority of other projects I’ve worked on also had weekly checkpoints, where we had work scoped out at the beginning of the week, and we would release, demo, or at least check in on Friday.

In contrast, “hard mode” had a totally different rhythm. I’d experienced crunch before through hackathons and agile swarms, but usually only for an eight-hour block, as opposed to a two week project. Our pace was defined like this: Frank and I would set our goals in the morning, and we would do internal demos to our manager every afternoon.

On top of the time crunch, there were technologies in our stack that needed to be reconciled with the stack of the client, such as learning how to adapt our [Sitka framework](https://medium.com/olioapps/reduce-redux-boilerplate-with-sitka-493369691d38) to work with [ImmutableJS](https://immutable-js.github.io/immutable-js/) and using [BEM](http://getbem.com/introduction/) SCSS instead of [styled-components](https://www.styled-components.com/). There was also a sizable amount of legacy code whose patterns we wanted to emulate, to keep the app consistent and easy to continue building upon in the future. You can check out my blog post about how to handle legacy code [here](https://www.olioapps.com/blog/legacy-code/).

So that begs the question: how did we do it? How did we go from a set of mockups and a set of user stories to a full scheduling wizard in roughly 14 days with only two people working full-time on it? Let me count the ways.

### Scope

<img src="/assets/blog/2019-11-25-hard-mode-development/binoculars.jpg" alt="A photograph of binoculars by Skitterphoto via Pexels" style="display: block; max-width: 100%;">

One of the strategies we adopted for tackling “hard mode” was making certain we scoped blocks of work appropriately. In the case of creating the scheduling wizard, it felt natural to make each step of the wizard a discrete day’s work. Some days bled into each other when it came to fixing bugs from a previous step of the wizard, but overall, this scope and pace kept things organized and made daily goals clear.

### Specialization

Another thing that helped the workflow was having Frank and me stay highly specialized in terms of what we worked on. While I have confidence in my ability to handle Redux and business logic, my strength is in handling CSS/SCSS and translating the mockups into a high-fidelity user interface at a rapid pace. In contrast, Frank has more experience doing Redux and business logic and less experience doing design and CSS-oriented work. Dividing the work to match our strong suits made development faster and more efficient, and it prevented us from stepping on each other’s toes and creating merge conflicts while working on the same branch.

### High Level of Communication

<img src="/assets/blog/2019-11-25-hard-mode-development/phone.jpg" alt="A photograph of a red telephone on a white background by Negative Space via Pexels" style="display: block; max-width: 100%;">

For this project, Frank and I forewent the standard practice of using feature branches, making pull requests and merging work after review in order to reduce time spent not building the wizard. As stated before, we worked almost entirely on the same branch. When done improperly, working this closely git-wise can cause merge conflicts, and work can be lost while resolving those conflicts. In order to prevent this from happening, my partner and I were in close communication. We both had a rough understanding of what the other person was working on, and we would ping the other person via Slack to commit their work and pull from our remote branch when substantial changes were made. An unforeseen advantage of working this way was that we were able to test each other’s work regularly on our two different machines to verify that everything functioned and compiled as expected.

### Rigorous End-of-Day Demo

Another factor that made this project so successful was our project manager’s acute attention to detail. During every demo, which happened around 3:00 p.m., we would test obscure use cases in the flow of the wizard and put the user interface under intense scrutiny, directly beside the mockups. This allowed us to have a very concrete and approachable list of functionality and UI fixes, and having the demo a few hours before the true ending of the day gave us time to fix them. On a good day, this allowed us to tie off the step of the wizard we were working on and start fresh on the next step the day after.

### Time Management

<img src="/assets/blog/2019-11-25-hard-mode-development/clock.jpg" alt="A photograph an old fashioned alarm clock on a pink and blue background by Moose Photos via Pexels" style="display: block; max-width: 100%;">

The most crucial part of powering through “hard mode” was tracking and managing time. I did this by using [Shoutbase](https://www.shoutbase.com/), Olio’s time tracking application. Seeing where time sinks occurred while working on the scheduling wizard allowed me to get better at creating an appropriate timebox for when I should get a second opinion on how I was approaching a problem. This was arguably the most important part in terms of setting a cadence for the project as a whole, and it’s an important skill to have, whether you’re developing in “hard mode” or not.

## When to Develop in “Hard Mode”

So when is “hard mode” the best way to get the job done over a normal, relaxed cadence?

For us, there were a number of factors that led us to adopt this workflow and cadence. The first factor was the tight deadline, which is pretty self-explanatory: a closer deadline means less time to get work done. The second factor was that the app was still a prototype. The combination of these two factors meant that features like unit testing weren’t necessary at this phase of the web app’s development. The third factor was that the features that were a part of our client’s requirements had few technical unknowns. Once we had BEM and ImmutableJS sorted out, and we had acquainted ourselves with the codebase, we were able to continue in a “business as usual” way, just faster and with a narrower technical focus. There was no need for any new algorithms or patterns or libraries in order to accomplish our goals, which was good, since researching new technologies to implement them into legacy code can make a hefty dent in your time budget.

## Why It’s Not Sustainable

<img src="/assets/blog/2019-11-25-hard-mode-development/sprout.jpg" alt="A photograph a plant sprouting in gravel by freestocks.org via Pexels" style="display: block; max-width: 100%;">

As I mentioned in the previous section, there are advantages to changing the paradigm to “hard mode,” but with the advantages come disadvantages that make this style of development unsustainable for any developer, regardless of experience.

For one thing, the fast pace of development left limited time to add in unit tests. Unit tests are an important part of production code for ensuring the maintainability of a codebase and the scalability of a codebase: you know what the input of a function is, and what the output should be, and [Jest](https://jestjs.io/) (or your testing framework of choice) will catch any bugs before you release a build as you grow the app. For more tips on transitioning from prototype to production code, check out my co-worker Stormi’s [blog post about production versus prototype code](https://www.olioapps.com/blog/prototype-vs-production/).

Crunch is normal and expected in most development cycles—that’s just the nature of any work that has a deadline. I personally really enjoyed having daily milestones and the ability to finish work and receive feedback quickly, but despite the preparation we did and the adjustments we made to our workflow to speed up our development, it was still hard. It’s simply not sustainable to be working at that pace for a prolonged amount of time.

Not only can it be stressful when you start to run up against the clock, but that stress can also cause creative blockage when it comes to problem solving. We managed to mitigate a lot of the stress and mental fatigue by getting out of the office at 5:00 p.m., no excuses.

## Conclusion

What I gained from this experience is learning how important it is to have a strong division between work hours and personal time. I haven’t had the experience of working longer than a regular eight-hour day to compensate for a crunch like this, but I can say that timeboxing the daily sprints and going home at the same time was paramount to keeping myself energized and focused throughout the busy workdays.

To sum it all up, there’s no right or wrong cadence or way to get your work done, as long as it gets done, but it was an enlightening experience to switch things up and try working at a “crunchier” pace. That said, even “hard mode” development doesn’t have to be a bad experience, provided that you scope well, communicate well, and work efficiently. These may seem like obvious tools for completing a successful project, but if you aren't already doing foundationally important work beyond your actual coding, putting additional constraints on a project will make that really apparent.

I’ve laid out a few of the tips that my team has tried while handling crunch, but I’m curious if there’s anything I missed. [Feel free to @ me on Twitter (@ARC_Tangents)](https://ctt.ac/fFzIc).

---

## What did we miss?

Please let us know by tweeting to [@olioapps](https://twitter.com/olioapps)

## Ami Cooper

Developer at [Olio Apps](https://www.olioapps.com)

Thanks for reading!


Development on Hard Mode: How to Deal With Crunch


<img  style="width: 100%;" src="/assets/blog/2019-11-01-rest-hooks/phones.jpg" alt="Stock image of phones">

Imagine this: You just moved away from home for the first time to go to college. Your mom calls. "How are you? Is anything going on?" she asks.

"I'm good. Nothing exciting is going on yet," you reply. It's good to hear from her.

Twenty minutes later, you get the same call: "How are you? Is anything going on?" There's nothing going on. You get the same call every twenty minutes for the rest of your life. What a nightmare!

Thankfully, this isn't your reality, but this is the reality for many REST APIs out there, constantly getting polled with the same request over and over again. It is a communication nightmare.

As web services become more integrated and dependent on sharing data between systems, this wasteful use of REST APIs becomes increasingly problematic. Thankfully, there are modern solutions for the polling problem.

## Integrations

Integration has been a major theme for the [Shoutbase](https://www.shoutbase.com/) team lately. We’re asking questions like “how can we make the tools that we already use work even better?” and “how can we automate tasks and streamline our workflow?” Integrating systems makes work on the frontend easier, but implementing integrations on the backend can get complicated real fast. So we’re also asking questions like “how can we make meaningful integrations without having to overhaul our system, make extensive changes, and add increasingly complicated code to maintain?” In other words, “how can we make integrations simple?”

I love simple. It’s important that the end-user has a straightforward experience. And as an engineer, I want my specs and code to be simple, too. Simplicity isn’t always possible; I was reminded of that while implementing [OAuth2](https://oauth.net/2/) in our last [Shoutbase release](https://www.shoutbase.com/blog/fall-release/). But simple is an ideal nonetheless.

While seeking a simple integration solution, we came across Zapier. [Zapier](https://zapier.com/) is a platform for creating custom integrations called “Zaps.” I took a deep dive into Zapier (you can read more about that [here](https://www.shoutbase.com/blog/zapier-dynamic-duos/)), but one thing that really resonated with me was how they handled real-time communication between web services: [REST Hooks](https://resthooks.org/). It was simple. I liked it. We added it to Shoutbase.

In the rest of this article I want to clarify what webhooks are, what REST Hooks is, why you might want to use Rest Hooks, how the pattern works, how we implemented it in Shoutbase, and how to address potential security concerns related to the software pattern of REST Hooks.

## Webhooks

Key to understanding REST Hooks is understanding webhooks. Webhooks allow web apps to communicate with each other, sending automated messages to notify others that something new has occurred. In a typical API, the client-side application calls the server-side application and consumes data. Webhooks are often referred to as “reverse APIs” because they flip this relationship. Instead of the server waiting to hear back from the client, the server-side application will call the client-side application through an end-point URL provided by the client application. That end-point URL (supplied by the client and consumed by the server-side application) is a webhook. It’s that simple.

The beauty of a webhook flow is that it occurs in real time. As soon as the server has something it wants to report, it relays the information to the client via the webhook. The client doesn’t have to routinely poll the server, checking to see if there is new data. There are other ways to achieve this communication between services. For more on that, I think O'Reilly does a great job of clarifying the difference between webhooks, websockets, and server-sent events in this [article](https://learning.oreilly.com/library/view/restful-java-patterns/9781783287963/ch06s05.html). But I’m focusing on webhooks because that’s what REST Hooks uses.

## What REST Hooks Is and How It Works

According to the [website](https://resthooks.org), “REST Hooks itself is not a specification, it is a collection of patterns that treat webhooks like subscriptions.” The REST Hook subscriptions are created, updated, and deleted using a REST API. The pattern is easy to understand and implement and advances the power of the traditional REST API. With REST Hooks, the REST API is able to communicate with other apps in real time, via webhooks, without a complicated setup. The REST Hooks pattern has four basic requirements.

1. Mechanism to store subscriptions
2. Mechanism to modify subscriptions via API
3. List of event types & implementation of events
4. Mechanism to send hooks

The data needed to store and manage the REST Hooks is simple. Each REST Hook record needs only three pieces of information: An event name or names you want to subscribe to, a subscription owner or account relationship, and a target url (webhook) to send payloads too. The record may also include a state, active or inactive. You could also add additional information to the record in your own custom implementation, but that’s all you need for the basic REST Hooks implementation.

Next you need basic CRUD capabilities to modify the subscriptions. There’s nothing novel here. All you need are REST endpoints to create, update, delete, and read subscriptions. As new subscriptions are needed, REST Hook subscriptions can be created. As end points change, we can update them. And when subscriptions are no longer relevant, the client can choose to delete them.

The most challenging part is perhaps defining and handling events. Thankfully, most modern APIs, Shoutbase included, already have an event handling system to tap into. If you’re new to the idea of event-driven architecture, you can read more about it [here](https://docs.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven). Basically, you need to define a system that contains a list of events and event listeners, and then using those two pieces, you can transmit information about events as they occur.

In the case of REST Hooks, when the event listener picks up a new event, you need logic to find any matching REST Hook subscriptions in your database. When a matching REST Hook subscription, based on event and originating user, is found, you can send your notification or payload to the webhook defined in the matching REST Hook subscription.

The Diagram below depicts the process of creating webhook subscriptions and handling events using the REST Hooks pattern. Your implementation may appear slightly different depending on the setup of your API.

<img style="width: 100%; border: solid white 20px;" src="/assets/blog/2019-11-01-rest-hooks/chart.png" alt="Diagram depicting the concepts discussed above">

## Why Use REST Hooks?

Now that we understand what REST Hooks is and how it works, let’s dive in to why it's so useful. The major argument for REST Hooks is really an argument against the alternatives. First, let’s talk about REST APIs. This popular paradigm powers the web, but has some serious limitations. One of the most common ways to get “updates” on data from REST APIs is through polling, or routinely making the same request in hopes that new data might be found (just like your mom calling every 20 minutes). There are two problems with polling. First, there are a lot of wasted calls to the server. According to a [case study](https://resthooks.org/#why) by Zapier, using traditional REST API polling, “Over a representative time period, Zapier polled for changes 30 million times but only took action on 460,000 of those polls.” For those doing the math, that is 1.5% efficient. Over 98% of the calls were a complete waste.

Beyond the inefficiency of making fruitless calls, polling is also far from real time. Realistically, polling only occurs every 10-15 minutes. Any more than that, and the margin of wasted API calls would be even greater. Polling is more or less a hack for receiving real-ish time data. On top of that, polling can be complicated. It requires a mechanism for managing and storing previous state, and comparing new state against previous state to find changes.

REST Hooks solves those problems, while also working within the popular REST paradigm. There’s no need for polling because webhooks simply wait for new notifications and receive updates on data as it originates. The communication is basically real-time. And there is no need to maintain previous state and make comparisons. The event encapsulates the data changes, and the changes are communicated directly to the webhook.

## REST Hooks in Shoutbase

As I mentioned before, I recently implemented REST Hooks to Shoutbase. The current case is limited and it hasn’t been documented for wide developer usage yet, but I’m excited to open it up in the future.

Right now, we’re using REST Hooks within our Shoutbase Zapier integration. We created a REST Hook trigger called “Prepare Report.” When a user creates a Zap using the “Prepare Report” trigger, Zapier posts a REST Hook subscription to the Shoutbase API to create the new webhook subscription, containing a webhook “target URL” from Zapier. When the Zap is turned off or deleted, Zapier makes a request to the Shoutbase API to delete the subscription. The Shoutbase API can send data to Zapier using the webhook when certain events occur.

Thanks to the existing infrastructure of Shoutbase, implementing REST Hooks was fairly straightforward. I added new REST endpoints for creating, deleting, and modifying the REST Hook subscriptions. I added a new table in our PostgreSQL database for storing the subscriptions. The Shoutbase API is written in Golang, so I added a type for the REST Hook subscriptions, which I dubbed “WebhookSubscription.”

WebhookSubscriptions in Shoutbase look like this:

```go
type WebhookSubscription struct {
    ID        string
    OwnerID   string
    EventName string
    TargetUrl string
    CreatedAt time.Time
    UpdatedAt time.Time
}

```

Shoutbase has a [multilayer architecture](https://hub.packtpub.com/what-is-multi-layered-software-architecture/), with distinct separation between the presentation layer (or resource layer, containing the endpoints), application layer (or API layer, containing the business logic), and the data layer (connecting to the database). So I added a new API for WebhookSubscriptions that contains all the logic required to fulfill the REST endpoint requests and communicate with the database. This API contains all the security gatekeeping for subscriptions.

The final piece of the puzzle is handling the events. Shoutbase already has a powerful event system that we use for communicating with our client app via WebSockets, managing events relevant to other integrations (like Stripe), and passing asynchronous notifications and events between different parts of the Shoutbase API. I was able to create a new WebhookSubscriptionsEvents API that taps into the existing event stream and handles specific events for REST Hook subscriptions. When an event occurs that matches a REST Hook subscription in our database, we simply post the event payload to the target URL in the subscription.

REST Hooks was right for Shoutbase because we had a lot of the right ingredients already. We had a database to store REST Hook subscriptions. We had an existing REST API. And we already had a way of submitting, listening to, and handling events. It also filled the need to communicate in real time with Zapier to make more meaningful integrations. In the future, we hope to open up our REST Hooks API in Shoutbase for developers to create custom integrations with webhooks.

## Security

When data is passed from one system to another, security is always a concern. Before I conclude this discussion on REST Hooks, I want to clarify issues related to security because it is important to us at Shoutbase and [Olio Apps](https://www.olioapps.com/). The REST Hooks [documentation](https://resthooks.org/docs/security/) describes ways to implement the pattern with security in mind. I will list them here, as well as include my own suggestions.

1. Only accept new subscriptions and update requests from authorized sources. This may go without saying, but anonymous users should not be able to access or make changes to your API’s REST Hook subscriptions. You can use your existing API authentication to verify sources. Since the REST Hook subscriptions contain a user or account relationship, only the user who owns the subscription should be able to view or make changes to it.

2. Limit the events that are subscribable. If you have a system of events already in place, you may need to decide which ones are appropriate for subscriptions. Define which events can be subscribed to via REST Hook subscriptions and prevent subscriptions to unsubscribable, private events.

3. Never send sensitive information. This also goes without saying, but payloads containing private information should never be sent via REST Hooks. The docs recommend sending “skinny payloads,” or payloads containing little to no real data, but rather, a notification that an event has occurred. The client that receives the payload can then make a request back to the API for the new data. This ensures the client still has the proper authorization to access the data.

4. Be transparent about existing subscriptions to user accounts. The documentation for REST Hooks doesn’t mention this, but I think it’s important to note. Giving the power to the users to review and understand what subscriptions exist and where their data might be flowing will help ensure account security. If a user sees a subscription they don’t recognize or no longer desire, they can delete it. This is something I hope to implement in the Shoutbase App before we widen the scope of REST Hooks. We currently have something similar for managing OAuth authorizations in the Shoutbase UI.

By carefully considering and implementing the suggestions described above, REST Hooks can enhance your API without posing a risk to your users or your service.

## Conclusion

Integrating with other systems is not without its fair share share of complications. In efforts to make things appear seamless to end-users, a lot of heavy lifting has to occur behind the scenes. I prefer solutions that have three qualities: efficiency, effectiveness, and ease of implementation. In this case, REST Hooks fit the bill. We can now use REST Hooks to pass real-time data from events to webhooks and maintain those subscriptions via our REST API.


Implementing REST Hooks


<figure style="display: block; margin: 20px auto; max-width: 500px;">
    <img  style="width: 100%;" src="/assets/blog/2019-09-30-stand-up/monster-money.png" alt="frankenstein's bride as the face of a dollar bill">
    <figcaption>Source: <a href="https://www.marketwatch.com/story/i-got-engaged-to-a-money-monster-2019-03-28">marketwatch.com</a></figcaption>
</figure>

Once loved by agile teams, the daily stand-up meeting has really been taking heat the last couple of years. Given the commotion from outside teams, we decided to examine our own daily stand-up ritual. Was it still serving us? Or had we become trapped in a monotonous SCRUM cycle, unable to see time-wasting, zombifying “Blah Blah Blah. No blockers. Done” before our very eyes? Spooky. Before I get into my team’s experience, I’ll dive into what stand-up is and identify some of the common complaints. Then I’ll give some tips on resurrecting a stand-up that has lost its luster.

## What Is Stand-Up?

The daily stand-up, a.k.a. scrum meeting, is a brief meeting performed by agile teams. It typically involves physically standing up and having each team member answer three questions: What did you do yesterday? What do you plan to do today? What are any “blockers” you are experiencing or you foresee that could impede your ability to meet your goals? The focus of these meetings is productivity and efficiency, and they typically last 15 minutes or less.

## Why So Much Hate?

Stand-up sounds simple, clean, and brief, so why has it received so much bad press lately? Many argue that the daily stand-up is outdated, and some agile teams have abandoned the practice altogether. This is my summation of common complaints:

1. **Meetings drag on too long.** Though stand-up meetings are intended to be brief, in practice, they can last long past 15 minutes, as sub-teams discuss in-depth details, some over-sharing team members wax on about irrelevant information, and teams’ sizes grow beyond 10 or so members. Time spent in these lengthy meetings disrupts the workflow and keeps you from doing your important tasks.

<figure style="display: block; margin: 20px auto; max-width: 400px;">
    <img  style="width: 100%;" src="/assets/blog/2019-09-30-stand-up/scrum.png" alt="meme of Doctor Evil-I booked a meeting room for our two hour SCRUM">
    <figcaption>Source: <a href="https://devrant.com/search?term=standups">devrant.com</a></figcaption>
</figure>

2. **It feels like a pointless waste of time.** On the flipside of the over-sharers are the under-sharers. Some team members are so brief during stand-up to the point of irrelevance—”Yesterday, I did stuff. Today, I will also do stuff. Done!” The exchanges during stand-up no longer mean anything to the rest of the team, and while brief, the stand-up does nothing to improve productivity.
<figure style="display: block; margin: 20px auto; max-width: 400px;">
    <img  style="width: 100%;" src="/assets/blog/2019-09-30-stand-up/once-again.png" alt="meme of Robert Downey Jr. rolling eyes.-Daily standup once again">
</figure>

3. **It’s a challenge to get an entire team prepared and in one place at the same time to do an efficient stand-up.** Some teams waste additional time standing around waiting for everyone to get up and join the meeting. And among the over-sharers and under-sharers are the under-preparers, who forgot what they did yesterday and aren’t sure what they’ll do today, but darn it, we’ll wait for them to figure it out so they can answer their three questions because that’s what it says in the scrum manifesto.

<figure style="display: block; margin: 20px auto; max-width: 400px;">
    <img  style="width: 100%;" src="/assets/blog/2019-09-30-stand-up/waiting.png" alt="meme of Mr. Bean waiting.-waiting for dev team to join stand-up">
</figure>

## Our Thoughts on Stand-Up

Given the complaints addressed above, it’s not surprising to see popular headlines like “Stop the daily stand-up meeting” or “the daily stand-up is an anti-pattern.” During retrospective, we decided to float the idea of retiring our stand-up—not with the intention of actually dismantling the daily ritual, but more as a thought experiment. What would life be like without stand-up? What would we miss? What would we gain?

One by one, we gave our thoughts on stand-up. And from the majority, the sentiment was mostly positive. Here are the highlights of our favorite aspects of stand-up.

### Information Sharing

Beyond answering the “three golden questions of stand-up,” the brief meeting is also a time when tidbits of general knowledge are shared among team members. In our stand-up, it’s common to hear, “Yesterday, I learned this,” or “I started trying this new tool or practice.” These pieces of information might have otherwise trickled throughout the team in Slack chatter or over lunch, but stand-up is a nice time to share quick tips, when the whole team is present and listening. Some might argue that this is anti-pattern, but for us, this type of sharing helps stand-up be more human, keeps us more engaged, and adds more value beyond the basic function of stand-up.

### Onboarding New Members

Stand-up is especially helpful for onboarding new team members. As we all go around the room and discuss our accomplishments from yesterday and goals for today, it gives new members an inside look at other projects and provides some context for what others are working on. As we routinely share our day-to-day, new members quickly become integrated into the team. Right now, we’re hosting junior developer interns from a local code school, Epicodus. When they join our stand-up, they are able to see an abridged version of a day in the life of a software developer and how more senior software developers solve complex problems. This simple daily interaction adds an immense amount of value to their internship experience.

### Celebrating & Venting

We use stand-up as a time to sing the highs and lows of software development. It’s important to celebrate wins, and stand-up is a great time to celebrate as a team before the little wins from yesterday fade into memory. Similarly, stand-up is a valid space to vent about problems as they arise. Sharing sentiments daily, in a group setting, makes sure that issues get addressed quickly, rather than having to wait for the next retrospective (which is when we more formally celebrate wins and discuss problems). Though we try to avoid taking time during stand-up to discuss solutions to these problems, bringing them up can be cathartic, and individuals or sub-teams can organize to formulate solutions outside of the stand-up if necessary.

### Routine

Among the other benefits listed above, one of my favorite aspects of stand-up is its routine nature. You can always count on stand-up. It’s the ritual start of the day, though work and planning usually begin a little before stand-up. When preparing for stand-up, I have to be intentional and organized about how I plan my day and reflect on my goals and results from yesterday. Without this kind of organization and reflection, each day would seem like the same endless stream of completing tickets, nebulous and monotonous. But with stand-up, I focus on what made yesterday unique and how today will build on those results.

Though we mainly had positive remarks about stand-up, we also brought up some room for improvement. Some team members pointed out that it can be easy to space out when someone starts talking about granular details that aren’t helpful or interesting to others. Additionally, using project-specific jargon (such as specific Jira issue numbers) prevents other team members from understanding the full context of what is being discussed and therefore has less value.This feedback gave us an opportunity to hone our stand-up skills as a team, trim the parts that aren’t helpful, and focus on things that are.

## Tips for Making the Most out of Stand-Up

### Time Limits

A key part of a successful stand-up is maintaining its brevity. For our 8 person team, 10-15 minutes is the sweet spot. Depending on the size of your team and the nature of your work, yours might be longer or shorter. Find the right time limit that works for you, and practice hitting it. The scrum manager can help enforce the time in the beginning, but eventually, it will start feeling more natural. Physically standing up (if you’re physically able to) is one trick to keeping stand-up brief. Psychologically, standing up can encourage us to be more focused and to the point. When we sit around together, it’s more natural to start chit-chatting and extend the length of what should be a very brief meeting.

<figure style="display: block; margin: 20px auto; max-width: 400px;">
    <img  style="width: 100%;" src="/assets/blog/2019-09-30-stand-up/time-limit.png" alt="meme of Samuel L. Jackson holding a gun-Go over the time limit, I dare you">
</figure>

### Create a Routine

Maintaining a solid stand-up practice requires creating a routine that everyone can and will stick to. If time is wasted on a daily basis, waiting around for someone to join, it defeats the purpose of the efficiency and productivity focus of the stand-up. Some form of mutual understanding (or maybe even enforcement) will be necessary in the beginning to encourage team members to join the meeting in a timely manner.

It’s also important to select a time that works well for everyone. Without this, a routine will be difficult to adopt. For example, we have our stand-up at 10:15 a.m. every morning. For us, a 9:30 a.m. stand-up wouldn’t work because some of us have early morning meetings, kids to drop off at school, or unpredictable commutes. Other teams might find it better to do their stand-up at 8 a.m. or 12 p.m. Try out different times, calibrate a time that works well for your team, and encourage everyone to build a routine around it.

Having a back-up plan is also essential. In a perfect world, we would all be present at 10:15 a.m. on the dot every single morning. That’s the goal, but reality works differently. Thankfully, we have a contingency plan. If anyone is running late or not going to be present, they announce this as early as possible, so we can decide to either start without them, have them join virtually, or push stand-up back if necessary. Your back-up plan might look different than ours, but it’s important to have one to minimize any breakups to the routine.

### Use the Right Tools

Choosing the right tools can help streamline your stand-up routine. I use [Shoutbase](https://www.shoutbase.com/), a convenient time tracking app, which helps with stand-up in three key ways. First, (you guessed it) Shoutbase keeps track of how much time my team spends on stand-up. Each day, we're able to see how long stand-up takes and evaluate if we met our benchmark. We can also get a report to see how our stand-up has progressed over time. Second, I use the description field of Shoutbase time records to capture details about what I'm working on. The next morning, I have a catalog of what I did the day before, so I can easily give a report during stand-up. Third, Shoutbase allows teams to set goals for the day, week, month, or year. It's easy to see if our stand-up goals have been met or exceeded, and it gives us data to bring up during retrospective if necessary. I like using tools that can multitask, and Shoutbase is definitely one of them. Other tools, such as [Notion](https://www.notion.so) and [Trello](https://trello.com), are great for keeping track of progress on tasks, and you can always use a classic stopwatch to time your stand-up.

<figure style="display: block; margin: 20px auto; max-width: 400px;">
    <img  style="width: 100%;" src="/assets/blog/2019-09-30-stand-up/multitask.jpg" alt="meme multitasking like a pro">
</figure>

### Clearly Define Goals & Standards

The basic function of stand-up is clear: communicate your goals for today, progress from yesterday, and forthcoming blockers. But as discussed earlier, stand-up can be more than that. Our goals also include: sharing useful tips, celebrating wins, highlighting problems, expressing feelings, and facilitating cross-project cooperation. We have a running document defining the goals of stand-up and also the basic standards of procedure, so everyone is on the same page. If you don’t have a document like this, I encourage you to create one to keep your stand-up running smoothly.

### Iterate & Improve

Defining goals and procedural standards doesn’t mean your stand-up practices are set in stone. In fact, you should routinely interrogate your practice and make sure it’s still serving your team. Bringing up stand-up during a team retrospective like we did is an excellent way to get everyone's input. Work together to create a stand-up that optimizes the way your team discusses and meets goals.

## Conclusion

Some teams huddle around the campfire and whisper horror stories about a monstrous waste of time...stand-up! Not us. Over the years, we’ve fine-tuned our stand-up routine to serve us. Focusing on brevity as well as meaningfulness will help you make the most out of stand-up. Next time you do stand-up, think twice about responding with a zombie answer. Try to provide something of value to the rest of the team and most importantly, don’t ghost!

<figure style="display: block; margin: 20px auto; max-width: 400px;">
    <img  style="width: 100%;" src="/assets/blog/2019-09-30-stand-up/standup-zombie.png" alt="zombie meme">
</figure>


Daily Stand-Up: Productivity Asset or Monstrous Waste of Time?


<img src="/assets/blog/2019-08-30-graph-hacking/cover-image.jpg" alt="photo by William Iven on Unsplash" style="max-width: 100%;">

Recently, I was assigned to a project where we needed to build a graph with some pretty lofty specs.
[D3](https://d3js.org/) is often considered the best graphing library for frontend developers, but on a cursory glance, the documentation was a bit unclear and seemed denser than I had time to parse, given the scope and timeframe allotted. I shopped around for other graphing libraries and came across [Recharts](http://recharts.org/en-US/), a React-specific graphing library built on top of D3 that had been used more frequently and had a better rating than [Nivo](https://nivo.rocks/), [Victory](https://formidable.com/open-source/victory/), or [react-vis](https://uber.github.io/react-vis/).

While I know good documentation for D3 exists and there are widespread use cases of it in the wild, Recharts piqued my interest. The website for it was snappy and clean, the documentation seemed pretty robust, there were a good number of customizable props, and it followed the same pattern of importing components and giving them prop values, which would reduce the amount of time I’d have to spend bootstrapping. So Recharts was the winner.

## The Project

The client for this project gave us the following specs:

- The graph is a bar chart that can display both positive and negative values with the domain limited to -2000 to +2000.
- Bars with positive values should be blue, and bars with negative values should be red.
- Bars should be selectable.
- When a bar is selected, it is a slightly darker color, and a tooltip should appear over it, which displays the bar’s value.
- If a bar’s value exceeds -2000 or +2000, it remains capped at that height and has a perpetually visible label displaying its actual value.
- Bars with large values in either the positive or negative direction are a more vibrant blue or red than unselected or selected color.
- The graph will continually grow to the right, so its container will scroll once it reaches a certain length.

- The app that utilizes this graph is primarily for use on a tablet through a web browser.
- The Y-axis should remain static while you're scrolling through the X-axis.
- The label for the data point counts up incrementally by 1.
- When the userId changes, i.e. the result is recorded by User B rather than User A, the label for the series starts back at 1 and counts up from there.

And this is what the graph ended up looking like:

<img src="/assets/blog/2019-08-30-graph-hacking/static-graph.png" alt="Screenshot of a graph with red negative bars and blue positive bars">

## The Limitations of Recharts

While using this library to fulfill the requirements, I ran into a few roadblocks:

- The built in `<Tooltip />` component for Recharts only works on hover, which isn’t feasible for a tablet.
- While you can specify a domain for your graph, the graph does not truncate bar values to fall within the domain. That is to say, if the maximum of the domain was 2000, and the value of a given data point was 2500, the positive side of the axis would automatically scale to 2500.
- The conditional color of the bars could not be handled simply in the component. It required a pure function to calculate the color for the fill of the object.
- Many of the customizable props aren’t documented with examples in Recharts. The solutions I came up with to meet the specs were based on reading the Github Issues for the library’s repository, or looking at third-party examples on CodePen and jsFiddle.
- The Y-axis component has no "static" property. If you scroll along the X-axis, the Y-axis will eventually scroll out of view

## So How Did I Do It?

**Transforming the data**

In a perfect world, the data from the backend would come in exactly the correct shape to be easily consumed by Recharts graph, but alas, it did not. The data started like this:

```typescript
interface ResultShape {
  readonly resultId: string
  readonly userId: string
  readonly score: number
}

const results = [
  {
    resultId: "22f0-23as9-9adf-98sfd",
    userId: "user1",
    score: 1000,
  },
  {
    resultId: "18q0-23as3-9adq-98sq",
    userId: "user1",
    score: -200,
  },
  {
    resultId: "9748-2737-1747-7759",
    userId: "user2",
    score: 1500,
  },
]
```

And using this function:

```typescript
interface Coordinate {
  readonly label: string
  readonly value: number
}

export const convertTablesResultsToGraph = (
  results: ReadonlyArray<ResultShape>,
): ReadonlyArray<Coordinate> => {
  // create an ordered sort array of userIds
  const userIds = results.map((r) => r.userId)
  const sortOrderOfUserIds = [...new Set([...userIds])]
  // make a basemap of all results by userId
  const basemap = results.reduce(
    (acc, next): BaseMap<ReadonlyArray<Coordinate>> => {
      const id = next.userId
      const contents = !!acc[id] ? [...acc[id], next] : [next]

      const toReturn = {
        ...acc,
        [id]: contents,
      }

      return toReturn
    },
    {},
  )

  // convert this to an array of arrays.
  const basemaps: ReadonlyArray<ReadonlyArray<ResultShape>> =
    sortOrderOfUserIds.map((id) => basemap[id])
  const coordinates: ReadonlyArray<Coordinate> = basemaps
    .map((rounds) => {
      const cc: ReadonlyArray<Coordinate> = rounds.map((item, i) => {
        const { score } = item

        return {
          label: `${i + 1}`,
          value: score,
        }
      })
      return cc
    })
    .reduce((acc, next) => acc.concat(next), [])
  return coordinates
}
```

It became this:

```typescript
const coordinates = [
  { label: "1", value: 2500 },
  { label: "2", value: 100 },
  { label: "3", value: -1200 },
  { label: "4", value: -4000 },
  { label: "5", value: 1500 },
]
```

**Selecting a bar**

Browsing the examples in the Recharts documentation, I came across [this jsFiddle](https://jsfiddle.net/alidingling/7has60ua/), which demonstrated to me that you can use the component’s local state to track the index of the selected bar. It ended up looking like this:

```typescript
interface ResultGraphState {
    readonly selectedIndex: number | null
}

...
constructor(props: ResultGraphProps) {
    super(props)

    this.state: ResultGraphState = {
        selectedIndex: null
    }
}

...
```

It also demonstrated a way to make the fill of the bar change color conditionally, using the `<Cell />` component. In the example, they use a ternary, but in my case, I needed a function which could output six different colors.

Note: we keep all of our colors in an `appColors` object as hexcode strings.

```typescript
export const colorSelector = (
  value: number,
  trueValue: number,
  index: number,
  selectedIndex: number | null,
): string => {
  if (trueValue >= 2000) {
    return appColors.modalPositiveLargeValue
  }
  if (trueValue <= -2000) {
    return appColors.modalNegativeLargeValue
  }
  if (index !== selectedIndex) {
    return value > 0
      ? appColors.modalPositiveGraphValue
      : appColors.modalNegativeGraphValue
  }

  return value > 0
    ? appColors.modalPositiveGraphValueSelected
    : appColors.modalNegativeGraphValueSelected
}
```

I spun up the click functionality for toggling the selection of the bar in a class method and passed it into the `<Bar />` component as shown in the jsFiddle.

**Creating and rendering a custom tooltip**

The first thing I needed for this part was a custom tooltip, which I built using styled-components and this [CSS generator](https://leaverou.github.io/bubbly/) as a resource for giving the tooltip its signature pointy bit.

```css
const CustomTooltip = styled.div`
    display: flex;
    justify-content: center;
    align-items: center;
    ${({ isPositive }: DisplayProps) => !isPositive && "margin-top: 10px;"}

    .tooltip-body {
        width: 100%;
        position: relative;
        background: ${appColors.tableDataOverviewBackground};
        border: 1px solid ${appColors.tableLabelText};
        text-align: center;
        padding: 1px 3px;
        border-radius: 2px;

        &:after {
            content: "";
            position: absolute;
            left: 50%;
            width: 0;
            height: 0;
            border: 10px solid transparent;
            margin-left: -10px;
            ${({ isPositive }: DisplayProps) =>
                isPositive
                    ? `bottom: 0;
            border-top-color: ${appColors.tableLabelText};
            border-bottom: 0;
            margin-bottom: -10px;`
                    : `top: 0;
            border-bottom-color: ${appColors.tableLabelText};
            border-top: 0;
            margin-top: -10px;`}
        }

        p {
            font-size: 0.75em;
            color: ${appColors.tableLabelText};
            margin: 0;
            align-self: center;
        }
    }
`
```

I probably could have used the [blueprintjs](https://blueprintjs.com/) library for the tooltip component, but I ended up making my own to ensure that it would be lightweight and not contain any additional animations or properties I didn't need. The app was already calculating a data transform on a large swath of data, and keeping the graph performant was a key part of the feature.

Originally, I tossed the tooltip inside of the `<Bar>` component tags and found out the hard way that you can’t just shoehorn a non-Recharts component as a child to a Recharts component, especially given that the whole Recharts graph is actually an SVG. I tried to find a premade tooltip SVG that was free to use, but didn't see anything that really matched the mockups or seemed easy to implement.

Upon digging through the documentation, I came across the `<LabelList />`component, which thankfully can take a React element as a content prop, and even came with [another handy jsFiddle](https://jsfiddle.net/alidingling/a5Leskck/).

This jsFiddle shows that the function that creates the customized label receives props from the parent `<LabelList />` component, which contains the x and y coordinates of where the bar sits relative to the SVG, the width and height of the bar, and the data’s value. From there, I could place the tooltip and feed it the correct data.

The only problem was trying to render the div. It wasn’t showing up, but I knew that _something_ was being rendered based on what was happening in the Chrome dev tools tab. So I started looking into an element called `<foreignObject>`, which through some magic allows HTML to be nested inside an SVG tag. I added conditional rendering for selected vs. non-selected index with my selectedIndex from state, fed the component, and ended up with this:

<img src="/assets/blog/2019-08-30-graph-hacking/tooltip.gif" alt="gif of the graph being clicked on which prompts a tooltip to appear">

**Rendering the true value of a truncated bar**

Initially, I was stumped by this problem, until I remembered that the graph coordinate objects didn't have to just be an "X" and "Y" value. The coordinate could any shape that I needed it to be, as long as I specified the `dataKey` prop in the library components.

I ended up updating the coordinate shape from this:

```typescript
interface Coordinate {
  readonly label: string
  readonly value: number
}
```

to this:

```typescript
interface Coordinate {
  readonly label: string
  readonly displayedValue: number
  readonly trueValue: number
}
```

and updated my data transform utility like so:

```typescript
export const convertTablesResultsToGraph = (
    results: ReadonlyArray<ResultShape>,
): ReadonlyArray<Coordinate> => {
    ...

    const coordinates: ReadonlyArray<Coordinate> = basemaps
        .map(rounds => {
            const cc: ReadonlyArray<Coordinate> = rounds.map(
                (item, i) => {
                    const { score } = item

                    const isLargeValue = isValueTooLarge(
                        score,
                        2000,
                    )
                    const displayedValue = calculateDisplayValue(
                        score,
                        isLargeValue,
                        2000,
                    )

                    return {
                        label: `${i + 1}`,
                        displayedValue,
                        trueValue: score,
                    }
                },
            )
            return cc
        })
        .reduce((acc, next) => acc.concat(next), [])
    return coordinates
}
...
```

Using the updated data transformation utility, I was able to write an additional `<LabelList>` component to track the "true" value of the coordinate while maintaining its height at the very maximum of the graph's domain, which ended up looking like this:

<img src="/assets/blog/2019-08-30-graph-hacking/final-graph.gif" alt="moving image of the graph scrolling to the right and opening up tooltips" style="max-width: 100%">

**Creating a static Y Axis**

I will be the first to admit that this is the hackiest part of the whole process. But it performs well, and it looks pretty good, if I do say so myself.

I opened the modal containing my graph, opened the dev tools, and straight up copy-pasted the whole `<g>` group of lines that made up the Y-axis, the Y-axis labels, and all of the ticks into a new functional component, which looked something like this (with the bulk of it omitted because visual clutter):

```typescript
export const CustomYAxis = (): JSX.Element => {
  return (
    <div className="y-axis-wrapper">
      <SVG width="56" height="360" viewBox="5 0 56 420">
        <g className="recharts-layer recharts-cartesian-axis recharts-yAxis yAxis">
          ...
        </g>
      </SVG>
    </div>
  )
}
```

The SVG props for width, height, and viewBox were copied from the whole Recharts graph, and then modified to trim as much whitespace as possible. In order to maintain the same sizing and scale, I didn't delete the original `<YAxis>` from the graph. I just gave it the property `hide={true}`.

The whole render method for the graph ended up looking like this:

```typescript
return (
  <div className="graph-wrapper">
    <CustomYAxis />
    <BarChart {...props}>...</BarChart>
  </div>
)
```

and the CSS (styled from the parent component) looked like this:

```css
> div > .graph-wrapper {
  display: flex;
  flex-direction: row;
  padding-top: 1em;
  max-height: 435px;
  overflow-x: scroll;
  overflow-y: hidden;

  > .y-axis-wrapper {
    background: white;
    position: sticky;
    left: 0;
    z-index: 1003;
  }
}
```

The result?

<iframe src="https://codesandbox.io/embed/headless-rgb-8xstw?fontsize=14" title="recharts-hacking" allow="geolocation; microphone; camera; midi; vr; accelerometer; gyroscope; payment; ambient-light-sensor; encrypted-media" style="width:100%; height:500px; border:0; border-radius: 4px; overflow:hidden;" sandbox="allow-modals allow-forms allow-popups allow-scripts allow-same-origin"></iframe>

## Conclusion

In general, I'd say that while Recharts lacked a lot of features I needed to fulfill the specs of my project, it's still a good entry-level graphing library. The animations are super smooth (though I turned them off to prevent any potential lag), and there are a lot of component props to customize the graph that I'd be interested in exploring in future projects.

The most important, and the most fun part, was getting the chance to flex my problem-solving skills. I enjoyed having the opportunity to come up with ways around the limitations I encountered, and I hope that the documentation of my process helps other people running into problems with Recharts or helps the devs improve the library in the next version.

Anything I missed in my analysis or could've done better? Feel free to reach out in the comments!


A Practical Guide to Hacking the Recharts Library 


Over the past year, [Olio Apps](https://www.olioapps.com/) has made a commitment to changing our company culture around working remotely. We’d seen other teams enjoy success by going fully or partially remote, but for us, working outside the office felt like an inconvenience. We wanted to change that, and we knew that we had the technology to make it a reality.

Because of the nature of our industry, most of the issues with remote working are easily solved through proper planning, team management, and tools. And for a team like ours, the benefits greatly outweigh any drawbacks.

<img src="/assets/blog/2019-07-30-remote-working/group.png" style="display: block; max-width: 100%;" alt="a collection of photos of people working remotely">

## Benefits of Remote Working

Providing the option to work remotely has a number of benefits. Here are a few that have stood out to us over the past year.

### Fewer Sick Days

For most of us, it’s hard to justify taking off an entire day of work because we woke up with a scratchy throat or stuffy nose, but for the health of the team, staying home on days like this should be a no-brainer. Allowing employees to work from home while they are well enough to work but potentially contagious means fewer sick days taken and less germ spreading to your team members and their families. It goes without saying that a healthy team is a productive one.

### Improved Communication and Organization

When remote working becomes a regular part of company culture, communication hiccups start to diminish. It may seem inconvenient at first, but once you adjust and refine your process, remote working can be just as natural as in-office working and can even improve communication and organization across the board. Because you don’t have a coworker sitting next to you who you can turn to and ask, “Hey, where’s that file? What time is the meeting?” centralizing information and keeping projects more organized becomes a higher priority.

After ramping up our remote working routine, we created “face pages” for all of our projects that included project overviews, contact information, links to tech designs, meeting times, etc. to centralize project information. We made a greater effort to create calendar events with Zoom chat links to all of our meetings. We also set up routine, cross-team check-in times to report our statuses, which alleviated some stress for our project managers and kept projects moving in the right direction. These tweaks improved our remote working as well as our overall workflow.

### Attracting and Maintaining Diverse Talent

A major argument for any company to make remote work available is that it allows teams to hire diverse talent who might not be able to relocate or regularly commute. It also allows teams like ours to accommodate the changing lives of our current employees as their families grow, they buy homes outside of the city center, or their spouses accept jobs elsewhere. This year, we were able to add a fully remote project manager to our team, which previously wouldn’t have been possible.

### Overall Developer Happiness

Being able to work from home means different things to different employees, but the bottom line is: having the option makes us happier. Knowing I have the option to work from my couch or my favorite coffee shop gives me peace of mind, even if I don’t take the opportunity. Having the flexibility to work remotely makes midday doctors’ appointments easier, alleviates the number of long commutes each week, and allows us to spend more time with our pets or families.

<img src="/assets/blog/2019-07-30-remote-working/home.jpg" style="display: block; max-width: 100%;" alt="woman working from home">

## How We Became a Remote-Friendly Company

We took an “easing-in” approach to integrating remote working into our company culture. We started by working remotely one day a week. This required us to set up an online meeting space using [Zoom](https://zoom.us/) or our daily scrum standup, become more familiar with VS Code [Live Share](https://marketplace.visualstudio.com/items?itemName=MS-vsliveshare.vsliveshare), and set up a Slackbot reminder for regular check-ins to keep the whole team up to date on our individual progress.

For the first few weeks, preparing for remote day required ample planning, but it wasn’t long before it became a natural part of the routine.

After we became comfortable with working remotely once a week, we added another remote day, working remotely every Tuesday and Thursday. During our team’s weekly retrospective, we discussed pain points and ways to improve our remote days and made the appropriate adjustments the following week.

Right now, we’ve decided to keep Mondays and Fridays as in-real-life as possible to efficiently facilitate our weekly planning meeting, retrospective, and one-on-ones. It’s also nice to maintain the face-to-face social relationships in our workplace. Some of us choose to come in on work-from-home days anyway to get a change of scenery from our home offices or have in-person pair programming or working sessions.

A goal to strive for when transitioning into a semi-remote team is to try to make sure anyone working remotely has the same quality of experience as the in-office team members. Nobody should feel like they are less able to participate because of their remote working status. Pain points like poor audio quality during remote meetings or people being unresponsive in chat channels will reveal themselves early on. Thankfully, as problem-solvers by nature, a team of software engineers (or other technically minded or creative people) can usually find a solution.

One of the most impactful changes that we made to accommodate regular remote working included always having a Zoom number set up for every standup or meeting, so it’s ready and available for anyone who isn’t physically present. We also purchased a quality table microphone, so remote meeting attendees can easily hear all of the conversations in the room.

With the help of this technology and some tweaks to our organization, remote working has become second nature, and special circumstances that were previously burdensome—such as inclement weather, emergencies, or extended vacations—are simply taken in stride.

## Coding on Different Continents

While writing this blog post, I’m on a two week vacation in Europe. Thanks to the efforts of my team to be more remote-friendly, I’m able to stay in touch, keep my project moving forward, and conserve some of my PTO while abroad. Working while thousands of miles and nine time zones away from the office has had its own set of challenges, so I wanted to share my experience and some tips that might help you in a similar situation.

<img src="/assets/blog/2019-07-30-remote-working/plane.jpg" style="display: block; max-width: 100%;" alt="view out an airplane window">

### Preparation and Planning

Weeks before the trip began, we started planning what the team and I would be working on while I was traveling. Some compromises had to be made to make sure my workload was appropriate for working remotely in a situation where I wouldn’t necessarily be able to communicate with the team in real time or have reliable access to the internet. For the feature I was working on, a thorough tech design was completed and agreed upon before I left, so there would be no need for high-level questions while I worked from various planes, trains, and automobiles.

### Communication

Communication is key in situations like this. Even though I wasn’t able to join the team’s daily scrum standup, I did my own standup in Slack every time I checked in to do work. I reported what I had completed during the last working session, what I planned to do next, and any blockers I had (thankfully, none so far, due to good planning). My team was good about providing clear feedback via Slack and Github as prompt as they could, considering the time difference.

### Time Tracking with Shoutbase

[Shoutbase](https://www.shoutbase.com/) is a time tracking tool that I use to record and report my work time to my team. It definitely came in handy for this trip. During my two weeks abroad, I planned to work a total of three business days. But these “three days” looked nothing like my usual 9-5. My work time was chopped up between several stints during train, bus, and plane rides, and some relaxed morning and evenings at cafes and Airbnbs. The short stints allowed me to get work done while still maintaining happy vacation vibes.

Shoutbase made it easy for me to communicate how much time I had worked during my remote sessions, so there was no confusion about how much time I had left to complete my tasks or where I was at in terms of meeting my goals. It also made it easy for me to see my team’s progress while I was away, and I could conveniently track my own progress to make sure I hit my benchmark (without going too far over).

### Expecting the Unexpected

Especially when traveling abroad, something unexpected is bound to happen. One major factor is your access to the internet. I experienced a traveling developer’s worst nightmare: the wifi was down on both of my nine hour international flights. Thanks to some mindful planning (and some Netflix downloads), I was still able to stay productive. As stated earlier, technical designing beforehand will keep you from relying on Google and Stack Overflow or your distant team members. If you anticipate this issue and your project requires data from a remote source, creating a mock API to supply fake data ahead of time can be really helpful. And if regular connection to the internet is a necessity, consider getting a mobile data plan for your laptop, rather than relying on wifi.

### Create a Time Buffer

Don’t plan for every available “downtime” moment to be a remote working hour. I was previously considering doing a lot more remote work during my trip to be conservative with my vacation time, and I’m glad I didn’t. There will be unexpected times when you won’t be able to work effectively because the bus will be too cramped to pull out your laptop, your external battery will die, you might hit an unexpected blocker, or you’ll simply need a break. The buffer will alleviate the stress of working remotely and keep you from worrying about work while you’re vacationing.

<figure>
<img src="/assets/blog/2019-07-30-remote-working/prague.jpg" style="display: block; max-width: 100%;" alt="Stormi in Prague">
<figcaption>Gratuitous photo of me in Prague</figcaption>
<figure/>

## Conclusion

Remote working isn’t for everyone, but having the option to work remotely can open you or your company up to new possibilities. It might seem like a burden at first, but once you employ the right technology and practices, the benefits will become abundantly obvious. If you have any questions about making remote working a reality in your workplace, please reach out to your friends at Olio Apps.


Reinforced Learning