Remote Java Dev

Remote Java Dev

Pretending We’re Not Already Remote

by

Pretending We’re Not Already Remote

It’s a curious phenomenon in today’s corporate world. We collaborate constantly with people all over the globe while pretending we’re not already remote.

Yet glancing at job search websites we see explicit location requirements everywhere. “We need a ROCKSTAR Developer,” the job listing demands! But only if you live in Gary, Indiana.

Evolution of Technology

I suspect the main reason for pretending we’re not already remote is due to the evolution of technology. The incremental advances in technology over the past twenty years have been transformative.

Internet access and smartphones have dramatically changed the way we work and especially for those of us in the software world. One by one, the impediments that required us to be tethered to an office are being removed.

We used to require an office location’s fast network connection, because home-based internet was expensive, slow, and unreliable. This is a solved problem now for anyone near a significant population center worldwide. And with the LEO Satellite Internet wave quickly approaching, this barrier too will fall for even the most remote of us.

In addition, we now carry around supercomputers in our pockets posing as phones. It’s never been easier to stay connected with our co-workers whether via email, Slack, or Zoom.

Even a decade ago I carried on Skype video calls over a high latency Geo Satellite internet connection. Now I could have that same video call on my smartphone with drastically better quality.

The tools and internet connections are only improving as the ratchet of technological advancement continues to turn. Simply put, our tools used to require we work in a specific location. This is no longer the case.

Inertia

It’s the inertia, stupid! This play on the famous James Carville quote sums things up nicely. The corporate world moves slowly to the surprise of no one.

Where have all the major innovations occurred over the last twenty years? Certainly not at IBM and other old behemoths. It’s been the Silicon Valley VC-backed startups that have led the charge. The IBMs of the world are incentivized to move slowly because they have much more to protect.

And so it is with the vast majority of corporations when it comes to job location requirements. We don’t need to sit in the same office as our peers to do our jobs as developers. Yet that’s the way it’s been done for decades so by gum that’s what we’re going to do!

It’s the “nobody ever got fired for choosing IBM” effect. What CTO of an established corporation wants to stick her neck out and remove location requirements? It’s far easier for management to just stick with inertia and keep pretending we’re not already remote.

I believe eventually we’ll reach a tipping point where even the behemoth corporations will embrace remote work. Unless of course they get disrupted and supplanted by an innovator before that happens.

Remote First Companies

Thankfully, not all companies are stuck in the 20th Century. A rapidly growing number of companies are choosing to go fully remote from Day One. These Remote First companies are gaining an early mover advantage by adapting to the reality of today’s connected world.

It’s hard enough to find and maintain product/market fit. Doing so while also mimicking the mistakes of legacy companies can be catastrophic. I believe that’s why we’re seeing rapid growth in new companies where remote first is baked into their DNA.

These innovative companies don’t carry the burden of decades of inertia. They are able to operate in our current reality much more effectively and most importantly, attract a better talent pool unbounded by obsolete geographic restrictions.

Employee Retention

Employee retention for remote workers is also dramatically higher than their in-office counterparts. Moreover, personnel churn is a huge drag on any organization’s bottom line. Just think of the cost it takes to replace a software developer.

Between the time spent by Human Resources, the Hiring Manager, and Technical Interviewers, it can easily cost thousands or even tens of thousands of dollars for a single hire. And then there’s the cost of reduced productivity while the new hire ramps up. This will usually last many months and results in a hidden cost to the company.

Early Movers

The number of remote first companies are too many to list. However, there are some prominent ones who have been leading the charge. What these companies have in common is not only a commitment to remote work, but also a commitment to processes that best enable collaboration across distance and time zones.

Automattic, founded by the prolific Matt Mullenweg, has been a trailblazer in the remote revolution. Doist is another highly successful scion of the remote first companies and was founded by the equally impressive Amir Salihefendić.​

The remote first Java world also boasts several highly successful ventures. Toptal, X-Team, and Clevertech all welcome talent worldwide and embrace the core tenets of our new remote work reality. Though not limited to the Java space, they do boast a significant presence in this tech stack.

This is only a small sample of the remote first companies leading the charge. The ranks of the remote optimized companies will only grow in our rapidly shrinking and connected world.

Summary

Ultimately there are two kinds of companies. Those that know they are already remote and those that don’t.

Those that don’t are mostly yielding to inertia and understandable caution towards big changes. Unfortunately for them, ignoring reality often has dire consequences. Just ask Blockbuster.

Companies that know they are remote embrace it prominently. They recognize it’s a competitive advantage for talent acquisition and retention.

Better people with better processes without obsolete geographic restrictions.

Further Reading

Working Remotely from the South Pacific

by

Working Remotely from the South Pacific

There’s remote work and then there’s REMOTE work. The former is working from home in a major metropolitan area in the United States. REMOTE work on the other hand is working from a tiny island thousands of miles away from the US mainland. Over the years I’ve had a few stints working remotely from the South Pacific and it’s amazing how well it worked!

South Pacific

The Kingdom of Tonga in the South Pacific is a second home for me. The small archipelago lies 1800 km north of New Zealand and 8600 km from Los Angeles. The population is about 100,000. To put it succinctly, it’s REMOTE.

I served as a Peace Corps Volunteer in Tonga and met my wonderful wife there as well. Though we’ve been living in the States for the past decade, we’ve made several months-long trips back to Tonga. These happy occasions gave me the opportunity to really stress test working remotely from the South Pacific.

Internet

Internet connectivity is the one non-negotiable for just about every remote developer. In a place like Tonga, this can be a challenge.

Although Tonga has recently been connected to the Southern Cross Cable providing fibre optic connectivity to the main islands of the country. It’s quite amazing that a place as remote as Tonga is now fully on board the high speed internet.

It wasn’t long ago however that Tonga relied solely on geostationary satellite communication to connect to the outside world. This mode of communication meant a latency of around 600ms in the best of circumstances.

Surprisingly, while this may matter greatly if you’re trying to play Call of Duty, it actually didn’t matter that much for real world development.

On each trip back to Tonga I had WiMax internet set up at our home. A quick install by the ISP provider of a wireless antenna mounted on a pole had me up and running in an hour.

Home Office

I use the phrase home office a little loosely here as will soon become apparent. Some people’s office is a coffee shop where all that’s needed is a laptop and an internet connection.

My office was a small 8’ x 10’ corrugated tin shack. Inside I sat on an REI camp chair with my laptop and I might as well have been working at the local US Starbucks. Though incidentally Tonga does not have a Starbucks or even a McDonald’s for that matter. Being REMOTE has its virtues!

For extra comfort I’d keep a cheap fan blowing in the shack as Tonga is quite hot and humid most of the year. Mosquito coils were also a necessity to keep the blood thirsty mozzies at bay especially in the early morning hours.

Work

It’s natural to assume that working remotely from the South Pacific would be difficult. It’s also easy to assume that being several time zones away and having a long-distance internet connection could be problems. Ultimately, I found these assumptions easily refutable when faced with the reality of my own experience.

I attended numerous conference calls while in my little tin shack home office in Tonga. I signed up for a US Skype phone number and forwarded my US office phone to this number while I was abroad. This made it easy to communicate by phone or IM, which were the primary means of communicating at this former small employer.

It did take a little longer to connect over the network to resources back in the US. For instance, my local development environment app server would usually take about 2 minutes to start up.

Over a satellite internet connection it took about 4 minutes to start up. Fortunately, tools at the time like JRebel and File Sync allowed for hot swapping of changes to eliminate the need for frequent app server restarts. This was in the pre-cloud days where on-prem data centers were the norm.

One of the more interesting things I did was connect via NoMachine, which is a Remote Desktop app, to my office computer back in the United States. It worked though!

You’d think over a satellite internet connection that it’d be completely untenable, but while certainly a little slow it was doable. It’s not something I’d recommend for more than the occasional operation yet it’s still amazing that it was even functional.

On one occasion I had to reload hundreds of thousands of rows in Salesforce from an ETL job. In spite of the distance though, I was able to successfully run the ETL job from a tin shack in Tonga.

Of course these days with Tonga having a fibre optic cable backbone, these kinds of things would no longer even be surprising. The distance just doesn’t matter that much any more.

Summary

This is ultimately a case study of working remotely from the South Pacific as a java developer. It proves that whether you are in a coffee shop in the US or a tiny island in the middle of the Pacific, your location just doesn’t matter that much any more.

As long as you have a laptop and an internet connection, you can do your work and do it well. You might even work better from a tiny island as you no longer have to deal with the stresses of the modern US urban existence. A clear mind is a tremendous competitive advantage.

Further Reading

10 Years of Quarkus Required

by

10 Years of Quarkus Required

The average developer job description is absurd. “10 years of Quarkus required” and other such things are easy to find. Given Quarkus has only been around for a fraction of 10 years doesn’t matter. It is “required!”

While this example is a little extreme, it’s easy enough to believe isn’t it? I imagine you’ve seen all sorts of similarly comical tech requirements congealed together in one big hash of a job posting. It’s the first real test of candidate screening in my opinion.

Your First Test

Your first test is to wade through this morass of a job posting and deduce what they really want. Sure they’ve got everything from COBOL to SmallTalk to GoLang in there, but can you pick out the fact that they really someone to rewrite their SOA monstrosity?

This is one area where larger companies are especially egregious. It must be a law that the more hands a job description passes through the more likely it is to approach an Absurdity Maximum. This gives away that a Tech Lead, an Architect, a Manager, a Director, and HR all pitch in to make the job description goulash.

I’ve found smaller tech shops generally make a better attempt at reasonable descriptions. It makes sense too. A bad hire on a small team is much more impactful than a bad hire in a company of thousands. The blast radius of a Goofus at Gigantech is pretty small compared to at a small shop where Goofus might have Prod credentials.

Gatekeepers

And then there are the gatekeepers. The Human Resources professionals whose thankless job is to sift through dozens to hundreds of resumes. It’s an extremely difficult task and one I don’t envy them.

The sheer volume of applicants necessitate that HR has to resort to unfortunate tactics such as randomly picking a sampling to visibly skim over. Advances in HR software over the past decade have surely helped ease this burden somewhat, but it’s also easier than ever to apply for jobs so they’re still fighting a losing battle.

Then HR has to attempt to determine an applicant’s legitimacy without a huge amount of pertinent information. It’s not possible to check the veracity of resume claims, especially without the deep technical knowledge necessary to do so. At best HR can only disqualify the most egregious of pretenders and social misfits.

The HR phone screen is in place to do just this. I’ve found it’s virtually impossible to be culled during this process. As long as you can put together a few sentences and aren’t a complete jerk, you pass.

In the tech world, HR can’t be expected to do much more than this. Our domain is full of deeply contextual and specific knowledge. Even a seasoned HR IT recruiter will have a tough time making sense of the alphabet soup of technologies we deal with on a daily basis.

Acronyms

Which brings us to one of the most ridiculous yet important parts of a technology job description, the acronyms. The acronym game reminds me of dueling banjos.

The company starts the music by putting out a job description that lists every tech acronym used in the whole enterprise. The job applicant answers by including on her resume every technology she’s ever worked with for more than a minute.

It takes a showdown at the Ok Corral, aka the Technical Interview, to see who’s bluffing. Usually it’s both. The real trick is finding out whether the applicant and the company are bluffing about the less important acronyms.

This is the unfortunate state of tech hiring in many places. I’m positive both sides would much rather have a better system to save each other huge amounts of time and wasted efforts.

Summary

10 years of Quarkus required is the type of absurdity commonly found in developer job descriptions. Even discerning what a company actually wants from job descriptions like these is a puzzle.

Successfully navigating the job search requires a bit of luck and some skill in satisfying the HR gatekeepers. Ticking the acronym boxes of a job description is often an unfortunate requirement to pass the initial screening process.

I suspect the friction found in this process is at least a little deliberate. It serves to eliminate candidates who aren’t serious about the job and won’t dedicate the time to jump through a few hoops to get it.

Hopefully someday soon we’ll have a better system and will look back and laugh at the ridiculous 10 years of Quarkus nonsense we used to endure.

Why Meetings Fall Flat

by

Why Meetings Fall Flat

If you’ve worked in the corporate world, you’ve likely experienced exactly why meetings fall flat in many ways. In fact, if you’re a developer it’s probably one of your greatest causes of job dissatisfaction if you work for a company that loves its meetings.

The average corporate meeting suffers from a number of pitfalls. It’s hardly controversial to say that most meetings in the corporate world are ineffectual and wasteful.

We’re long overdue for an Agile-like transformation in the world of meetings to an approach that values people’s time and takes full advantage of diverse perspectives.

“The Medium is the Message”

Philosopher and author Marshall McLuhan said it best, “The Medium is the Message.”

“It means that the nature of a medium (the channel through which a message is transmitted) is more important than the meaning or content of the message.” – Wikipedia

And so it is with meetings. People gather in the same room at the same time to share information and solve problems quickly. That’s how it’s supposed to work at least.

Now, the meetings mostly take place over a phone bridge as most teams are distributed. How else are you going to communicate when the project manager is in New York and the IT support team is in the Philippines and the product owner is in Texas?

The fundamental problem of most meetings is inherent in its medium, synchronous verbal communication. While this modality is certainly useful in some contexts, it’s deployed far too often than is warranted.

We have much better technological tools these days that can help us collaboratively solve problems more effectively through other means.

The Biggest Problems

The biggest problems of meetings are centered around synchronous communication and the combination of personalities on the call. Add in the ease in which meetings can be completely derailed and you have a recipe for futility.

Synchronous Communication

Real time conversation can be tremendously efficient. Meetings however, rarely achieve this in practice. As I’m sure you’ve all experienced, when more than two people enter a conversation the effectiveness of synchronous communication craters quickly. As the number of people in the conversation grows, so does the propensity of non-speakers to become passive observers.

There’s also the social pressure element to meetings that encourage sub-optimal responses. For instance, when asked a question in a meeting you will naturally feel pressured to answer on the spot. Especially if the question is something in your realm of expertise. If the answer doesn’t come to you immediately, you’re much more likely to give an approximate answer which likely won’t be fully thought through. This is just the way the human mind works.

In order to avoid the embarrassment of saying “I don’t know” in front of a group of our peers our minds tend to give us a “good-enough” answer to move the conversation in a different direction. Usually away from us or towards a topic where we have more conviction in our answers. The amygdala is a powerful force and even the most resolute of us have to deal with irrational fear responses.

In short, synchronous communication is especially vulnerable to generating emotional responses. Add in the notoriously poor fidelity of the average human memory and it’s hardly surprising that it often takes many meetings to solve even the simplest of problems.

Personalities

Why then don’t we just build a team full of people who work well together to solve this problem? To be sure, hiring a cohesive team will absolutely be a goal of any leader. Unfortunately this alone will not solve the major problems.

Even if we manage to assemble a team with highly cohesive personalities, it’s inevitable that we’ll need to work with others outside of this core group. This is another way of saying it’s not realistic to solve this problem on the front end by simply optimizing hiring for interpersonal compatibility.

We’re going to have to work with people whose personalities don’t mesh well. And so it’s much more effective to build a fault tolerant communication system than it is to psychoanalyze prospective hires.

Introverts and Extroverts

Unsurprisingly the software development world is full of introverts. And a telltale characteristic of many introverts is the preference to avoid confrontation.

Give an introvert a little time and a different medium however and you’ll certainly get a better response that fully answers a question and avoids acrimony. Removing the emotional response triggered by meetings is far more likely to lead to better outcomes.

Combining extroverts and introverts in a distributed synchronous verbal exchange usually doesn’t go well. The extroverts are highly likely to take over the meeting and leave no breathing room for others to interject.

When forced to rudely interrupt to get a word in edgewise, it quickly becomes a toxic environment. This toxicity serves to totally defeat the purpose of collectively gathering to solve problems in the first place.

While most extroverts do not intentionally try to take over exchanges, it’s just natural for them. Especially when paired with introverts who are not as comfortable thinking out loud in a group setting. The best leaders will recognize this and set up a system to seek input from both the introverts and extroverts on the team.

Derailed

Stop me if you’ve heard this one before:

Today’s meeting is about adding a new feature to the app. It starts off well enough with discussion around the most important aspects of the feature.

Then the group “talker” chimes in and before you know it he’s left Feature World and starts giving a soliloquy on the original architect’s lack of foresight in designing some other unrelated part of the system.

He would have done it MUCH differently and as a result the app would be slightly easier to work on for the developers.

May I present Exhibit D in why meetings are vulnerable to futility. It only takes one such “talker” to completely derail any meeting.

In practice, you’re lucky if there’s only one of these in any meeting of more than 5 people. They may not all be quite so brazen, but having to perpetually nudge the conversation back on target is extremely tiresome and wasteful of everyone’s time.

It also takes an iron-willed leader of the meeting to do so and these can be hard to find. Few things cause meetings to fall flat quicker than dealing with a serial derailer.

Summary

There are many reasons why meetings fall flat in the corporate world. Meetings take place in a synchronous medium which has inherent drawbacks for yielding good decisions.

While not all contexts are inappropriate for the medium, meetings are too often utilized to decide things that would be better dealt with in a different format.

Meetings suffer from a myriad of deficiencies. The synchronous nature of meetings promotes emotional responses from participants.

Personality differences are also inevitable and can lead to poor decisions where an overconfident, yet incorrect, extrovert is more convincing than a docile, yet correct, introvert.

And finally, meetings are easily derailed as it only takes one person to dive into irrelevant minutiae and the usefulness of the meeting is hopelessly lost.

Is 100% Code Coverage a Worthy Goal?

by

Is 100% Code Coverage a Worthy Goal?

If 75% code coverage is good, then 100% coverage must be better right? Like so many things in the software development, it depends. It depends on what your application is doing and what are the greatest risks of failure. In the Enterprise space, the question “Is 100% code coverage a worthy goal?” should be asked far more often than it is.

Edge Cases

First off let’s dispense with some edge cases. If you’re writing code that has life or death implications then it’s of course imperative to test everything as thoroughly as possible.

Likewise if the cost of failure is exorbitant such as writing code for a Mars Rover, then by all means we should test everything. You can surely think of many other instances along these lines. This post is not targeted at these scenarios.

Identify What Matters Most

Rather we’re concerned here with more standard enterprise applications and how we should approach test coverage for them. Time pressure is a fact of life in our world. We need to prioritize our efforts towards things that matter most.

Testing is definitely important! We just need to focus on testing the most important things first. To accomplish this we need to identify our application’s most likely points of failure.

If you don’t ask yourself why are you testing code blocks periodically, you’re probably wasting time and money. If you’re anything like me, you’re convinced of the value of writing tests. Sometimes it’s easy to get carried away though.

In our quest towards an idyllic world of pure Test-Driven Development(TDD) we can lose sight of more important concerns. Based on my experience most projects in the Enterprise world are not good candidates for 100% code coverage.

We’re much better off stepping back and assessing where our code base is most vulnerable. Then we can focus our testing efforts where they really matter.

Targeted Testing

Does your app perform complex calculations? Do you rely on a number of external API calls and collate results? Will it heavily depend on UI interactions or need to process uncontrolled file inputs? Asking these sorts of questions can help us focus our testing on the most likely source of system bugs and errors.

For instance if we’re working on bank software where extreme precision is required in calculating financial transactions, we’re definitely going to want unit tests to validate. Do we rely on a number of external API calls? Then our integration test coverage will need to be significant.

Building a robust test suite covering the main risks of our given application is the real goal here. That’s where the value of testing will shine through. Not by hitting an arbitrary test coverage metric that’s good for little else than as a mottled feather in a manager’s cap.

Testing Antipatterns

There’s no shortage of information on the topic of testing antipatterns around the web. At a high level though I’d suggest you pause if you feel like you’re writing tests that offer no value beyond ticking a code coverage box.

Some of the more common testing antipatterns involve writing tests that do little but exercise a framework or system library. For example, constructing an elaborate mock in order to verify when you call a method it returns the mock is not particularly useful.

Unless you have very good reason to do so, just let the framework and system library teams test their own code. We have more important things to do and how soul-crushing is it to write such things anyway?

Monitoring

This may be a little controversial, but monitoring is a vital component in system accuracy and is often just as valuable as upfront testing. Years of experience has taught me that we simply can’t predict all the stressors acting upon our applications until they are live in Production. Aiming for 100% code coverage does nothing more than give us a false sense of security.

We inhabit a world of Fat Tails and Black Swans in the software domain. It’s important to have enough humility to accept that we can’t predict everything that could go wrong with our applications.

It’s much better to accept that there will be situations in Production that need to be fixed. And prepare for them so we can respond quickly when the inevitable occurs. Monitoring provides the means to this end.

Summary

Striving for 100% code coverage is simply not a worthy goal in and of itself. Unless of course you’re working on an extreme edge case project. We’re much better off identifying the most likely points of failure in our application and focusing our testing efforts in this area.

We save ourselves and our clients a lot of time and money by not writing useless tests. Tests that do little but verify a framework or system library does what it’s supposed to do. Instead, plan ahead and implement a good monitoring system to quickly respond to unanticipated Production issues.

Remote Work is at a Tipping Point

by

Remote Work is at a Tipping Point

The future of remote work is at a tipping point.  

Did you almost buy Bitcoin back in the early 2010s? Back when a mere few hundred dollar investment would make you a Crypto-Millionaire today? I missed that wave and I’m still not happy about all the Lambos gone a begging.

The good news is there’s another wave coming. And this wave won’t require a risky, speculative investment to capitalize on. It may not make you a millionaire, but what if it could give you something just as good?

Freedom.

The ultimate freedom to live and work wherever you want in the World.

How? LEO Sat or more descriptively, Lower-Earth Orbit Satellite Internet connectivity. Ubiquitous, cheap, and fast internet will not only cause our remote options to explode, but also help solve our ever-present internet connectivity conundrum.

There’s strong evidence that we are at the precipice of a transformation in Global Internet connectivity. It’s becoming more likely by the day that within 5-10 years, almost every corner of the planet will have access to affordable high bandwidth, low latency internet.

LEO Satellite Internet

What speed and latency can LEO Satellite Internet deliver? By most accounts they will be able to deliver up to 1 Gbps per user and latency in the neighborhood of 25-35ms.

This level of performance would beat most existing wired connections. Only Fibre connections would likely maintain an edge over a built out LEO Sat network.

While we may be several years away from realizing this level of performance in the wild, it’s exciting how close we are to its fruition.

There are a number of companies either in active development of LEO Satellite Internet constellations or working towards that goal. Elon Musk’s SpaceX and OneWeb are the current leaders in the direct-to-consumer target market with TeleSat focusing more on business, government, aviation, and maritime use cases.

A couple more recent entrants into the fray are Tech giants Amazon with Project Kuiper and Facebook with Project Athena. Boeing is another big name to keep an eye on though they don’t seem to be moving as aggressively as other players in the field.

SpaceX Starlink

Musk’s SpaceX Starlink is ubiquitous in the news these days. Starlink’s first planned big launch shocked most observers with a payload of 60 satellites aboard their Falcon 9 rocket. The launch was scheduled for this past week, but has been pushed to next week to reportedly perform software updates.

It’s hard to bet against SpaceX with their unique ability to not only manufacture their own satellites but also launch them aboard their own rockets.

OneWeb

OneWeb is another prime contender in the LEO space. They’ve raised over three billion dollars to date and have some first generation satellites in orbit already. OneWeb is planning to be fully operational by the end of 2021.

The Others

TeleSat, Amazon, Facebook, and Boeing are among the others in the race to lower Earth orbit. The upfront capital costs in this race are exorbitant, but luckily these companies have some of the deepest pockets around. Moreover, we’re far away from market saturation for cheap, reliable, and fast internet so there’s plenty of room for competition.

Remote Options Explode

One of the biggest limiting factors working remotely is our internet connection. Even here in the States, reliable, fast internet is mostly limited to areas surrounding an urban core. If you want to spend a few weeks at a rural lake cabin, the chances of being able to work remotely during that time are not good. Any rural internet connection you might have will almost certainly prevent it.

Now imagine you have a fast Satellite Internet service that will work just as well at your suburban home as it would at a cabin in Yosemite Park. In this world your possibilities have exploded! Maybe you want to take the family to New Zealand for a few months. In this new world you can still work and have the freedom to live a whole new life.

Traveling is only one new possibility of course. Where you choose to live as a remote developer also will now be your choice. Does living in remote Montana appeal to you? It now becomes possible with LEO Sat Internet.

Last-mile internet connectivity was always going to be limited with wired connections, whether DSL, Cable, or Fibre. Such capital intensive activities as laying physical wire to every point on the globe was never going to happen. It’s of course much easier to bring a portable antenna with you than tethering wires around the globe.

Internet Connectivity for Remote Workers

Finicky internet connectivity is a latent fear of every remote worker. We’ve all this happen at some point. Your internet goes kaput while on a meeting or screen-sharing session or a video call. Unless you’re working for a 100% Remote company already, you’re quickly worrying that management or colleagues may interpret a common tech hiccup as an indictment of the remote work arrangement.

As remote workers, we already feel pressure to over-deliver. This means that every equipment or internet failure we experience impacts us more than our in-office colleagues. We need to have backup plans. It’s even better when backup plans are provided for us, such as by our ISP.

While LEO Sat internet won’t solve all internet connectivity woes, it does give us another viable option. It could also provide terrestrial networks with robust fail over capabilities. Existing ISPs could contract with LEO Sat providers to expand their coverage beyond the bounds of their current wired infrastructure.

Summary

Remote work is at a tipping point and the dawn of LEO Satellite Internet connectivity is here. It’s virtually inevitable that within the next 10 years our global internet coverage and performance will improve dramatically. SpaceX Starlink is the current favorite to win the race to Lower Earth Orbit. Though several other companies are charting their own paths to blanketing the planet in internet connectivity.

The coming wave of reliable, cheap, and fast internet will cause remote workers’ location options to explode. We’ll no longer be tethered to an urban center solely for its high speed internet. Whether you want to live in rural Montana or a village in the lowland forests of Madagascar, internet connectivity will soon no longer stand in your way.

Further Reading