Remote Java Dev

Remote Java Dev

Managing Career Risk as a Remote Developer

by

Managing Career Risk as a Remote Developer

When it comes to developers, there’s the regular kind and then there’s us. Managing career risk as a remote developer is an important concern. I’d contend it’s a far greater one than for our in-office counterparts living in a major metropolitan area.

Until that day when remote work becomes the regular kind, we’re going to have to do some extra legwork to mitigate our career risk. Fortunately we have a number of tactics to accomplish this goal. And on the current remote work transformation trajectory, the inherent career risk of being fully remote should only decrease as time goes on.

Assumptions

This post will apply best to remote developers who want to:

  • Remain remote, without going back in-office 
  • Be compensated based on US major metro area rates
  • Continue to develop or do technical work
  • Have consistent work without long gaps of unemployment

Career Risk

There are three main career tracks for remote developers: FTE(Full-Time Employee), Freelance, and Entrepreneur. While FTE and Freelance will mostly be developing for someone else’s business, Entrepreneurship will involve leveraging your coding ability to create your own product or service. 

Each of the three have their own risk and difficulty profiles. We’ll focus on FTE and Freelancing here as it’s likely to be most relevant to the most people. 

FTE

The easiest and most common remote arrangement is almost certainly the FTE route. You either start in-office and convert this job to full time remote or get hired as full time remote from the jump. 

The risk of working FTE though can be a problem, however. I think it’s helpful to think of yourself as a business. You offer Java development and consulting services for various forms of compensation including money, paid vacation, and other benefits.

As an FTE the business of you has a single client. This client likely pays you a salary for roughly 40 hours of work in a week. If you work more than 40 hours you likely won’t be compensated for it. 

The upside of working FTE is you will get paid reliably every two weeks or thereabouts. While your upside is hard-capped at your salary, ignoring bonuses, so too is your compensation downside. You’re not going to get paid less one year because you mostly did support compared to another year where you mostly worked on valuable new features.

The downside of working FTE is you only have a single client. You are entirely reliant on this single client for your livelihood. If your employer has financial troubles, you risk losing your entire client base. So what might be better than relying solely on a single client?

Freelance/Independent

The freelance or independent model can help mitigate the risk of the FTE single client problem. In the ideal world as a freelancer you cultivate a number of relationships with different clients. In doing so you decrease your vulnerability to losing any one of them.

Unfortunately, this is difficult as a Java developer and even more so as a remote Java developer. Particularly as such a large percentage of Java development is done in the enterprise, it’s not easy to find clients in this space. At least not ones who are interested in short term engagements unless you have a very specific niche within the enterprise Java space.

Rather than working for multiple clients at the same time, you’re more likely to find success working serially. For example, working 6 month contracts at different companies will help build up your client list over time. 

So while you may only work for one company at a time, if you lose your client, you’ll have a number of others at the ready. This requires much more work on your part to cultivate relationships and keep your sales funnel full. It’s simply not enough to settle in at one client and be lulled into a false sense of security.

The risk certainly feels greater as an independent. However, you’re likely just more attuned to it in this model compared to an FTE, though your risk profiles are not that different. An FTE is likely to feel much more secure than she should compared to you as an independent. Put simply, an independent more accurately estimates her risk compared to an FTE.

Mitigation Strategies

Effectively managing career risk as a remote developer requires mitigation strategies. This is far more important for remote developers than in-office ones. As our job choices are fewer that satisfy our one big non-negotiable, remote only.

Network

Building a strong network is an ideal way to mitigate risk. So what does a strong network mean? It means having connections with people who would actually hire or recommend hiring you.

LinkedIn

This is in contrast to the shallow connections we find so common on LinkedIn or that result from one-off networking events. You may have 500+ connections on LinkedIn, but how many of them would actually stake their reputation on recommending you to an employer? If you’re like most people, not too many.

It’s both a blessing and a curse that LinkedIn makes it so easy to connect. The curse is we end up with hundreds of shallow connections that would do us little good if we’re actually in need of a client. If we want LinkedIn to be a good source of leads, then it’s important to cultivate relationships beyond the shallowness of a simple connection. 

In short, a LinkedIn connection is merely an introduction. If it’s left that way, then it’s of little value. Given time is our most scarce and valuable resource, it’s likely to be more fruitful to develop a dozen strong relationships than it is to aim for hundreds of shallow ones.

Resume Adjunct

There are numerous ways we can provide potential clients proof of competence. These serve as a resume adjunct that is publicly available which also supports our credibility. Having an easily accessible portfolio of our work is a great selling point during client acquisition.

Github

One of the easiest ways to do this is to maintain our own public Github account. It’s the perfect place to build projects that demonstrate your expertise in a given tech stack. It’s also great for trying out new technologies rather than waiting for a current employer to start using them. 

Additionally, by working on side projects on your public Github account, you are separating yourself from the pack. The pack of average in-office developers who don’t worry much about their craft outside of work hours. However, as remote developers, we need to be better than average. Moreover, showing our work is an important step in this process and Github lets us do this for free.

Open Source

The next step up the ladder is contributing to open source projects, both in difficulty and in impact I would argue. It’s one thing to put your own project on Github, but it’s a higher degree of difficulty to collaborate with a distributed team on an open source project. 

To be perfectly up front, I’m not speaking from experience here as I’ve not yet contributed to open source. It’s definitely something I’d love to do and hope to do at some point. However, it can be a challenge to find the time between family, working a full-time job, side projects, blogging, and so on.

Attraction Marketing

There are a number of other ways to raise your profile and help with lead generation. Building a strong Stack Overflow ranking is one. Writing your own blog is my another one that I personally enjoy. The rise of podcasting is fully underway and it’s never been easier to start your own. LinkedIn is another good platform to distribute your content. 

Ultimately these platforms can help us build credibility in our industry. Additionally, they can help us with lead generation and client acquisition. As the more people we can reach who can benefit from our services, the better insulated we will be against career risk.

Continuous Learning

Finally, any mitigation strategy should include a healthy dose of continuous learning. If we want to be a top performer, we must stay on the cutting edge of Java tech. It can be overwhelming, but it’s something we must do to stay at the top of our field.

I like to use several different platforms and media for continuous learning. The three main categories are video, audio, and written word. 

Pluralsight and O’Reilly Safari are my favorites for video content. There are also plenty of other options such as YouTube. Josh Long’s Spring Tips and other videos are always good.

Podcasts are my preferred means of consuming audio content. Some of my favorites can be found here: Best Podcasts for Remote Java Developers. I’d also highly recommend the Pivotal Podcasts.

We have an endless amount of written content on the web. However, some of my mainstays are DZone and InfoQ. I also like the Pivotal Blogs for the vast array of Pivotal products, which are always relevant to our industry. TechCrunch is great for broader industry news too.

Summary

Managing career risk as a remote developer is crucial to our long term survival as non-standard employees or freelancers. Until the broader employment model embraces location independence, it’s vital that we actively work to mitigate our risk.

While both FTE and freelance arrangements can succeed when done remotely, they have different risk and difficulty profiles. FTE is generally easier to find remote only work. However, you are then entirely dependent on a single client. Freelance allows you to defray risk with multiple clients, yet it’s less stable and requires more work with lead generation.

The key to robust career management as a remote developer is having strong risk mitigation strategies in place. Building a strong network is very important. Focus primarily on developing strong relationships with your connections. These are more likely to be fruitful than having many shallow connections.

A strong resume adjunct is another beneficial strategy to employ. Whether via Github, open source, or an attraction marketing medium, it’s valuable to have public work available. This builds your credibility and ultimately makes you easier to hire.

The final piece of the puzzle is continuous learning. We have no choice but to drink from the fire hose so we might as well figure out a way to do it effectively. Pick your favorite media formats whether video, audio, or written content and find ways to work it into your weekly routine.

What’s Holding Back Remote Hiring?

by

What’s Holding Back Remote Hiring?

It’s easy to wonder what’s holding back remote hiring still in 2019. We have the technology to work remotely from just about anywhere on the planet. Yet, most jobs still require physical proximity as a condition of hiring. Why?

Inertia

When it comes to what’s holding back remote hiring, inertia is the first thing that comes to mind. Most of the biggest employers in the enterprise world have been in business for many years. 

This long history has certainly led to some calcification in their hiring processes. It’s a lot harder to modify hiring practices when your company size is 10,000 compared to 10. Big companies are slow moving and understandably so. 

If a company has grown large, they most likely have been profitable over many years. The larger the company grows, the more difficult it becomes to change. Moreover, change feels riskier as deviation from what’s worked in the past takes a lot of courage. 

Put simply, this is the natural human tendency towards loss aversion manifested at an organizational scale. We humans tend to value not losing over gaining something new.

Therefore it seems more prudent to continue hiring people into an office, because that’s the way it’s always been done. But eventually things always change. And we are rapidly approaching an inflection point. One where the inertia of hiring practices will morph into a significant disadvantage.

Hiring is Hard

Hiring has been a notoriously tough nut to crack. From the largest corporation to the small mom and pop shop, finding good employees is one of the most difficult challenges. 

It’s a time consuming and expensive process for both companies and candidates. The cost of a bad hire can quickly cause exponential deleterious effects on both the hiring and hired. It’s a process filled with risk for everyone involved.

Part of the problem is the tight coupling of benefits to employment here in the States. This tends to force people into seeking jobs regardless of fit. The alternative is to lose access to affordable health insurance. 

Ultimately everyone would be better off if employees needn’t rely on companies for benefits. Then both company and candidate could focus more on role fit. Instead, one side is compelled to get the job at any cost or risk losing health insurance. Unfortunately, we’re still a long way away from realizing this here in the US.

Hiring Managers

We can certainly empathize with the plight of hiring managers. They are tasked with taking on the big problem of hiring. They will also take responsibility for it in spite of its historically intractable nature.

Making a bad hire is something that will reflect poorly on your performance. There is an additional concern though. Did the bad hire look good on paper? In other words, when the bad hire was selected, did the hiring manager have a strong case to present to her director or VP?

Herein lies another key as to what’s holding back remote hiring. Hiring managers take on extra risk when making a hire outside of the traditional path. If a company has traditionally hired in-office, then a hiring manager may perceive hiring a fully remote employee as harder to sell to her boss. 

And if the remote employee doesn’t work out, then the hiring manager could be demeritted more greatly than had she hired a vanilla in-office employee. 

This is ultimately another big reason why we remote workers need to be top performers. It not only protects ourselves, but ultimately protects our managers who step up and hire us.

To be clear though, we’re talking about traditional companies here. Not the new breed of fully remote companies who have already embraced the new reality. Top level organizational support for remote hiring can solve this dilemma, but most companies are not there yet.

Summary

The lion’s share of companies are not remote-only. This means the bulk of hiring is still being done by in-office centric organizations. This creates a number of friction points when it comes to hiring remote workers.

Inertia plays a big role. It’s just easier for organizations to continue doing what they’ve been doing than it is to change course. The bigger the ship, the harder it is to turn.

Additionally, hiring is fundamentally difficult. Hiring a remote worker may be perceived to be more risky in a traditional company than hiring an in-office individual. 

Finally, hiring managers bear responsibility for their hires. In a traditional company, a hiring manager may invite more scrutiny by hiring a remote worker without high-level organizational support. 

I believe all of these friction points will eventually fade away. As more and more of these slow-moving companies are surpassed by remote-friendly companies, they will be forced to change or become extinct.

My Tech Journey from the Mainframe to the Cloud

by

My Tech Journey from the Mainframe to the Cloud

My tech journey from the mainframe to the cloud has been an interesting one. I certainly expected I’d be working in Java fresh out of college, though it was surprising how I got there. Specifically, by taking a brief detour to the land of the mainframe. 

While unexpected, it was a great introduction to the enterprise and the sheer enormity business domain could be. Ultimately it proved beneficial as a much needed reality check for the career I was embarking upon.

The Mainframe

My tech journey from the mainframe to the cloud began with wrangling COBOL for a large insurance company. There’s nothing quite like your first S0C7 and receiving a 500 page print out of the abend the next day. 

The tech was your standard mainframe fare of COBOL, JCL, DB2, IMS, and Casegen. The sheer size of some of the COBOL programs was incredible! It was common to see hundreds of thousands of lines of code in a single program. 

It was a far cry from implementing a bubble sort in Java 1 in college. The ISPF editor is still probably my favorite I’ve ever worked with, sorry vi.

Enterprise Java, Pre-Frameworks

After a quick couple years on the mainframe I started my enterprise Java career. They were simpler times. So simple in fact that we used little more than the raw JDK!

Struts had just come out, but that was a little too unproven for a cautious insurance company. And so we wrote all our Servlets, JSPs, and JDBC calls the hard way. 

The real fun began with the IBM tool suite as things were a bit less ergonomic in those days. The main culprits were WebSphere, VisualAge for Java, and Rational ClearCase. 

I still have no idea how ClearCase works(or didn’t work) and moreover how it passed itself off as a VCS for as long as it did. It was a valiant effort in the early days at least.

EJB World

I feel like I should have to write a pointless interface before beginning this section. The transition to the EJB paradigm was the beginning of the modern era of Java development in my mind. The era in which framework choices are one of the biggest decisions in an application’s life cycle.

Mercifully I had little exposure to pre-EJB 3.0 code bases. That is aside from cruft left over from EJB 2 to 3 porting efforts. If you can get past the boilerplate with EJBs, it wasn’t a terrible approach for the monolith world.

Humans cannot live by EJB alone though. JSF to the rescue! Err…in hindsight I should have waited for a different rescuer. JavaServer Faces was interesting to work with, I’ll say that much. It made some things work pretty easily and obfuscated many many other things. 

JBoss Seam was another common framework to be found in the EJB/JSF ecosystem. Seam wove together the two unruly beasts into a monster beast! Though a more manageable beast than EJB and JSF would have been without it to be fair.

Spring World

The transition from the EJB world to Spring was pretty easy. I guess when you’re used to rubbing two sticks together to make fire, switching to matches is trivial.

The Spring MVC and Spring Data projects in particular were revelations. The simplicity in which we can accomplish things in the Spring ecosystem still amazes me. It’s easy to see why Spring has taken over enterprise Java and is leading the way towards the next revolution.

Cloud Native Java

Finally, my tech journey from the mainframe to the cloud brings us here. I’m still very much on the learning path when it comes to cloud native Java development. However, it’s been by far the most interesting and fun path on my long and winding road.

The enterprise market’s move to cloud native development is still a work in progress. At its core is the shift away from the monolith and towards a microservices architecture. A primary reason for this being to take advantage of the elastic scaling offered by the major cloud providers.

Working with Spring Boot and Spring Cloud have been the latest epiphanies spearheaded by Pivotal and the numerous Spring teams. The ease in which we can create new Spring Boot apps with sensible defaults via Spring Initializer is extraordinary! 

It’s now entirely doable to stand up a functional API in a matter of minutes or hours. Compare that with trying to accomplish the same via JavaEE or an EJB/JSF app and it’s really no contest. Even if you’re not creating microservices, the Spring Boot project offers an immense improvement in developer experience.

Add in the docker containerization piece and it’s very easy to create applications ready for a cloud native deployment. As a developer it’s become extremely accessible to build microservices with Spring Boot, throw them in docker containers, and have them ready for a PaaS.

It will be interesting to see how broadly the enterprise shifts to cloud native development in the coming years. Will the majority of applications be moved away from monoliths? Will the microservices approach be reeled back in to a certain set of use cases? We’ll all have to stay tuned to find out.

Listening is a Superpower

by

Listening is a Superpower

They say listening is a superpower. 

Whoever they are, I think they’re right. 

It’s amazing that something so simple can be so rare to find in our everyday lives.

It’s hardly our fault though. 

We’re all just operating with minds hewn from evolutionary processes. 

Most of which are better suited to the African savanna than post-industrial civilization.

The Default

Do you ever get done with a conversation and realize you don’t remember hardly anything the other person said? 

You can remember in detail all the things you said, but little else. 

If this sounds familiar, you are most certainly not alone.

If you really pay attention to what’s going on when two people are talking, you’re likely to notice the following. 

Most conversations basically consist of two people taking turns talking past each other. 

And spending the time not talking, thinking about what to say next, and then waiting to interject.

When we’re in the midst of a conversation and we’re supposedly listening to someone else, we’re really just on the lookout for things that are personally relevant to our experiences. 

“You took a trip to Kentucky? Wow, my Aunt and Uncle found a big rock in Mammoth Cave, Kentucky!” 

To the surprise of no one, your mind is primarily concerned with you and how things relate to you. 

We are all the stars of the show in our own minds so we should be forgiven for our default setting of self-centeredness when it comes to conversation.

The Superpower

Listening is a superpower that can be developed.

As mentioned above, our default is to barely listen while waiting to talk again. 

The real superpower arises when we consciously focus attention on listening and not on thinking about what we’ll say next.

If you’re anything like me, this will not be easy. 

It will also take a lot of practice as our minds constantly want to shift the focus back on ourselves and back to the default. 

The benefits of doing so though will far outweigh the cost.

It’s really about being present in the moment when conversing with someone. 

Succinctly, it’s the removal of distraction by focusing on not dividing your attention towards what you want to say next.

The Benefits

Isn’t it just nicer to work with someone who listens to you? 

We all work better with people we like. 

Conversely, we don’t work as well with people we don’t like. 

And we don’t tend to like those who don’t listen to us. 

The seemingly trivial act of attentive listening can make us easy and desirable to work with. 

We bring more value to a project when we work well with many other personality types. 

We generate less friction amidst the team and enable easy collaboration. 

Another massive benefit to listening is how much we learn. 

It’s so much easier to retain information when we’re actively listening instead of splitting mental energy thinking about what we’ll say next.

This is especially important for us remote workers. 

We don’t have the in-person non-verbal cues to rely upon so we must overdevelop our other communication skills. 

Listening is an absolutely critical one to develop.

Summary

Listening is a superpower.

It requires conscious effort.

Our default mental state is to relate everything we hear back to ourselves.

This often means we spend much of our mental energy thinking about what to say next rather than actively listening to what we are hearing.

The more we overcome this natural tendency, the more we will benefit.

People will like working with us more.

Others will find it much easier to work with us and we will become more valuable as a result.

Remote workers especially should develop our listening skills.

It’s important for us to excel in certain communication methods to compensate for the nonverbal cues that are unavailable to us.

Pluralsight vs O’Reilly Safari

by

Pluralsight vs O’Reilly Safari

There’s Eclipse vs Intellij, tabs vs spaces, and then there’s Pluralsight vs O’Reilly Safari. While learning platforms may not be as contentious as coding styles or IDEs, we do have our preferences as Java Developers.

Pluralsight and O’Reilly are far from the only paid options, but are two of the best and worth comparing. You can also find plenty of good content elsewhere at sites such as Udemy or Lynda, now known as LinkedIn Learning.

A Few Caveats

It’s worth noting up front that I’m comparing Pluralsight vs O’Reilly Safari on some specific content areas that I’ve personally frequented. These content areas are Java, Spring, Cloud, Microservices, Docker, and Angular.

Pluralsight

As a video dominant platform, Pluralsight really shines with its user experience. Both the desktop and mobile usability are outstanding. The quality of Pluralsight content is also very good.

Pluralsight also offers the ability to download content to your mobile device. This is definitely useful for offline scenarios or to prevent choppy streaming from a mobile data connection.

The content library overall is well sized though not extremely large. This can actually be a benefit as it’s easier to find what you want without having to choose between 10 similar options.

Another item in the plus column is cost. While a monthly plan costs roughly the same as O’Reilly Safari, the yearly subscription option is much more affordable. I’ve seen regular discounts on a yearly plan for Pluralsight for $199 down from its regular price of $299.

There are also some additional features such as Learning Paths and Certification Practice Exams.  I haven’t personally utilized these, but they may appeal to some learners.

O’Reilly Safari

The content library is massive! The best feature of this platform is having access to both video and written content. 

The written content library alone is huge and has books from O’Reilly, Packt Publishing, Manning Publications, and Apress to name just a few. If you’re fine with digital copies of tech books, this alone makes the O’Reilly Safari service a good value.

The video content on Safari can feel a little sparse, though it is not.  I think it’s just that the written content library is so big that it feels this way. You can easily search for just video or just written content to remedy this.

The large amount of content also means that you can reliably find the most up to date books or videos. You’d be hard pressed to find a popular technology that doesn’t have a number of content options available.

Understandably, this all comes with an additional cost. Though the monthly subscription price at $39 is comparable to Pluralsight’s at $29, the real difference shows up in the yearly price. 

O’Reilly Safari checks in at $399 for a yearly subscription.

***UPDATE***

An intrepid reader gave me a great tip to check out ACM membership. This membership looks to include O’Reilly Safari access for a much reduced price. As of this writing a yearly ACM membership is $149, regularly priced at $198.

While I have not personally gone this route, you should check it out if you’re interested in O’Reilly Safari.

************

Likewise, another area of improvement for Safari is the user experience, especially when watching video content. The Pluralsight experience just feels better both on mobile and desktop. O’Reilly Safari’s video experience isn’t bad, but it could use some improvement to be on par with its top competitor.

Summary

The Pluralsight vs O’Reilly Safari comparison really boils down to what’s most important to you. 

Are you primarily interested in video content? Are you cost sensitive? Is user experience a big concern for you?  Pluralsight will deliver the goods if these are your determinant factors.

Do you want a massive content library? Is written content important to you? Does a moderate price difference mean little to you? Then O’Reilly Safari will be a better choice for you.

Honestly, you can’t go wrong with either platform. I’ve subscribed to both and found them to be excellent resources for ongoing learning.

Remote Work and Backup Plans

by

Remote Work and Backup Plans

It’s every remote worker’s worst nightmare. Your internet connection goes down, what do you do? If you’ve been in the remote work game for any length of time, you’ll already have backup plans at the ready. 

Now imagine you’re in the corporate office and the internet goes down. It’s time for a coffee break! As a developer you’re unlikely to be responsible for troubleshooting the network problems so there’s little stress. 

As a remote developer however, it’s a different story. We’re under far more pressure to make sure equipment-related issues do not prevent us from being online. It’s just the reality of a remote worker’s life.

Be Prepared

The Girl Scouts and Boy Scouts of America have a simple motto, be prepared. Good advice for us as remote workers. Our level of preparedness though will depend largely on how remote we are.

If you’re living near a major metropolitan area in a developed country, you don’t need to sweat too much. There will always be a coffee shop nearby with internet access or a computer supply store for any equipment you may need. Cell service is also likely to be excellent. Tethering to your cell phone’s hotspot is often all you need to weather a home internet outage. 

Things become much more critical when it comes to remote work and backup plans when you live farther away from civilization. What do you do when the nearest Fry’s is thousands of miles away? Or what do you do when your home internet connection goes down and there’s no coffee shop around the corner with WiFi?

Like any smart person would, you have your backup plans ready to go ahead of time.  Your home internet connection may be Plan A. Plan B might be a cell phone with hotspot service just in case. Plan C might be hopping in the car and driving an hour to an internet cafe.

The Essentials

The non-negotiables for us as remote developers are an internet connection, a computer, and phone service. We could even get away without a cell phone by using Skype or Zoom through our computer. Everything else could be pruned away if necessary.

Given our two absolute essentials, an internet connection and a computer, it makes sense to focus here first with our backup plans. Here’s an example of how a friend of mine, who works remotely from the South Pacific for a US employer, manages his internet situation.

A Remote Internet Backup Plan

My friend has two ISPs available at his location, so he maintains service with both. He also has cell service with hotspot capability with two cell phone providers. If those options were to fail, he has the option to drive less than 30 minutes to a coffee shop or internet cafe for WiFi access.

Plans

  • A:  Main ISP Home Connection
  • B:  Secondary ISP Home Connection
  • C:  Cell Phone Hotspot with Cell Provider X
  • D:  Cell Phone Hotspot with Cell Provider Y
  • E:  <30-Minute Drive to Coffee Shop or Internet Cafe for WiFi Access

To be fair, this backup plan may seem a little extreme. However, given my friend’s location in the South Pacific I think it’s an outstanding one. In fact, I plan to duplicate this backup plan when I move back to the South Pacific next year. It adequately protects against all but the most extreme situations, such as a catastrophic internet backbone failure which is incredibly rare.

A Remote Hardware and Software Backup Plan

If we’re living far away from a good computer retailer such as Fry’s or Microcenter as found here in the States, we’ll definitely want to plan accordingly. Having a backup laptop is a necessity for the more remote of us. 

It’s also good to have spares of a Bluetooth headset, wireless mouse, and power cable to name a few other useful items. While we could do without the spares, it’s worth the peace of mind to have them on hand.

Automating the setup of our development environment is another worthy endeavor. Using Docker Compose for dependencies is worth looking into to prevent having to start from scratch in case your main development computer goes down. We’ll of course need to backup our critical development environment files and configuration to an external source as well.

Finally, it’s always good to know what our resupply options are. For example, if you’re living in the South Pacific it might take 3 weeks for a new laptop to be delivered to you. You’ll also need to know which companies will actually ship to your location. These companies can be hard to find for the more remote of us.

Summary

Remote work and backup plans go hand in hand. The farther afield we live, the more thoroughly we need to plan for internet and equipment failures. It’s an added responsibility we accept when embracing a remote work arrangement, but ultimately I think most would say it’s worth it.

The two essentials we need backup plans for are internet connections and computers. A good internet backup plan has several non-linked options in case of failure. Likewise, we’ll definitely want at least one backup laptop, ideally with an automated means of reconstituting our development environment.

A little planning can ease a lot of stress. Especially for us remote workers of whom more is expected. Once you have backup plans in place for your essentials, you can free your mind of worry to focus on more important things, like delivering value to your company.

Further Reading