Forem: Remote Java Dev

Engineers are Always the Smartest People in the Room

Remote Java Dev — Fri, 07 Jun 2019 15:04:49 +0000

I was on a conference call a few weeks ago when our Project Manager mentioned that "engineers are always the smartest people in the room." He said it touch-in-cheek about a know-it-all engineer from another team. I’m sure you know the type. He thinks the business people are clueless, other engineers are neophytes, and management is full of engineers who couldn’t hack it technically.

Thankfully, the developer world is not completely full of arrogant engineers like the guy I just described. Ultimately I think this kind of perspective comes from not appreciating the wide range of skills and tasks necessary to successfully deliver useful software.

There’s no question that our work as engineers and developers can be immensely complex. However, that alone is not going to deliver real business value. Our myopic engineer doesn’t get that.

In the enterprise, building technically perfect software, if there even were such a thing, is meaningless without the expertise of product development, sales, customer service, logistics, management, and many other concerns. Engineering the software is fundamentally useless without the other concerns irrespective of task complexity.

Does it Matter?

Engineers may even be the "smartest" people in the room by some arbitrary metric like IQ. Does it matter? No. Not in the business world where we need to collaborate to deliver real business value. If you think it does matter, you’re better off finding a hackathon or some other contrived environment where you can measure your smarts against others.

However, good engineering skills are incredibly useful and valuable. There’s just a big difference in business value between arrogant engineers and humble ones.

Nobody wants to work with a jerk. Arrogant engineers put themselves at an immediate disadvantage when their colleagues naturally avoid having to deal with them. They drag down team morale. Likewise, team focus inevitably strays from delivering business value and turns towards avoiding the egomaniac whenever possible.

Time Sink

Arrogant engineers can also be a tremendous time sink for the team. How often have you seen engineers like this fight tooth and nail over meaningless technical minutiae? Far too often if you’ve been in the tech world for any length of time.

Code reviews are one of their favorite battlefields. The Smartest Guy in the Room loves to show his value by picking nits out of other developers’ code. “You used a plain old foreach loop instead of a Stream in a legacy codebase? What a fool you are!”

And so we waste huge amounts of time placating or avoiding the imperious one. He derails meetings to pore over irrelevant technical details that add no value. Ultimately, we spend less time delivering valuable business software and more time appeasing the malcontent.

Real Business Value

In the Enterprise Java World, real business value creation requires far more than engineering alone. On any reasonably large project we developers and engineers benefit immensely from our colleagues.

We need the product owner to provide direction on what to build. A good project manager can remove obstacles in our way and insure dependencies are delivered. Management can make sure we can focus on the project at hand and not have to deal with a barrage of other competing priority requests. The sales team delivers paying customers to the business without which everything collapses. Customer Service bridges gaps between what the software does and what its end users think it should do.

The list could go on and on. It’s easy to see how a myopic engineer misses the forest for the trees when viewing things in the global context.

Summary

I look forward to the day where project managers can no longer correctly opine that “the engineers are always the smartest people in the room.” This kind of engineer attitude is without question a significant detriment to the business and his team.

Even if it were true, it doesn’t matter in any meaningful sense. Engineers like this are a big time sink for his colleagues as they’re forced to deal with his misdirected priorities. Real business value results from the collaboration of many different concerns only one of which is engineering.

Remote Work is at a Tipping Point

Remote Java Dev — Fri, 31 May 2019 13:19:57 +0000

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 planned launch was delayed initially, but ultimately was a complete success and the first bulk payload of Starlink satellites are now in orbit.

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.

Best Podcasts for Remote Java Developers

Remote Java Dev — Thu, 23 May 2019 11:47:41 +0000

Best Podcasts for Remote Java Developers

The Best Podcasts for Remote Java Developers are focused on a mix of Java, Knowledge, and Remote topics.

The parabolic growth of podcast content is both a blessing and a curse. It's wonderful that there is so much information available so easily. The curse is finding what we're looking for amidst all the noise.

Here are some of the best podcasts out there covering topics that might be of interest to fellow Remote Java Devs. Enjoy!

Java / Tech

A Bootiful Podcast

Josh Long is a Spring Developer Advocate at Pivotal. He covers a variety of topics around the Java Spring, Spring Boot, and Pivotal ecosystems. He’s also a Java Champion, prolific author, and all-around expert when it comes to Java, Spring, Spring Boot, and Cloud.

Josh puts out a ton of content across various platforms including Spring Tips on Youtube. If you want to keep up to speed on the latest in Java, Spring, and Cloud Josh is a great person to follow.

Java Off Heap

Another great resource for the latest happenings around the Java world. Freddie, Bob, Michael, and Josh all focus on different parts of the ecosystem so there’s rarely a dull moment. Which is no mean feat considering talking tech can be a little dry.

Java Pub House

Another Freddie Guime and Bob Paulin production who are both very engaging and knowledgeable. This podcast tends to focus on more granular subjects which is a great way to expand your world as a developer.

We tend to get locked into a tech stack wherever we’re working and so listening to Freddie and Bob go deep on a library or framework that we haven’t used yet provides some great information. Or even to further expand on the capabilities of tools that we do use, but may not have been aware of their full power.

Cloud Engineering - Software Engineering Daily

Jeff Meyerson does a great job in his Software Engineering Daily podcast. He’s very skilled at methodically explaining complicated ideas and is a natural teacher. I’ve been listening mostly to his Cloud Engineering podcasts lately and they’ve been very thorough and informative.

You’ll find expansive coverage of Cloud topics surrounding AWS, Kubernetes, and much more. Jeff interviews experts in the Cloud domain and with his own wide-ranging knowledge makes for a very interesting listen.

Knowledge

The Knowledge Project

Shane Parrish has created an invaluable resource with his Farnam Street blog and companion podcast, The Knowledge Project. Anyone and everyone can benefit from the pearls of wisdom found here.

Even if you were to only read the Mental Models section of Farnam Street you would be far more resilient to the endless complexity faced in our daily lives. A simple paragraph truly doesn’t do Shane’s resources justice. Check it out for yourselves if you haven’t already.

North Star Podcast

David Perell has built a great collection of writings and podcasts. He routinely interviews some of the smartest people in the world on the North Star Podcast.

You’d be hard pressed to not take away some valuable insights from David and his guests. I’d also highly recommend following David on Twitter where his Tweetstorms are always a wealth of thoughtful information.

Naval Podcast

If you've never heard of Naval Ravikant, you’re missing out. If I had to list a top ten best podcast episode list, Naval would be the only multiple entrant. He is more of a philosopher than he is an entrepreneur or venture capitalist both of which he’s excelled at.

Follow his Tweetstorms or his recently launched podcast with bite-sized excerpts from some of his interviews. If you like money, Naval has great insights on how to get it in the new economy.

Remote

Tropical MBA

The Tropical MBA podcast is centered around the location independent lifestyle. If you’re a Remote Java Dev or aspire to be full time Remote some day, then this will be of interest to you. Dan and Ian share a wealth of location independent information.

You’ll also find much of the content focused on entrepreneurship and how to build a location independent business. You can follow Dan and Ian all the way through their business journey including the challenges they faced when selling.

Location Indie

The Location Indie podcast focuses heavily on location independence and the digital nomad lifestyle. Definitely check this one out if you’re interested in building an online business you can run from anywhere. Jason Moore and Travis Sherry have regular 30 minute podcasts as well as some longer interviews with their community members detailing their journeys towards location independence.

It’s a great podcast to hear the diverse ways in which people are living and working remotely. It’s easy to get tunnel-vision in our lives and fail to appreciate the countless permutations that are available to us in the world. The Location Indie podcast will help take those blinders off.

**Cross post from my blog: Best Podcasts for Remote Java Developers

Technical Email Design

Remote Java Dev — Thu, 18 Apr 2019 13:21:09 +0000

Technical Email Design

A good technical email design can save hours or even days of wasted time. This translates into dramatic savings for your business and highlights the unique value you can provide.

So what makes a good technical email design? Abundant clarity, liberal formatting, and thoughtful graphics are a good start.

Clarity

Clarity is king when designing technical emails. Therefore, like any good UX/UI designer we should be mindful of presenting information in an easily digestible form.

In contrast, how many emails have you received that were nothing but painful walls of text? The secrets of the universe might be contained in that wall of text, but you’d be hard-pressed to extract it in such a malevolent form.

Compare the following:

“A good object oriented design should adhere to the five SOLID principles which are Single-Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion.”

Good Object-Oriented design should follow SOLID principles:
- Single-Responsibility
- Open/Closed
- Liskov Substitution
- Interface Segregation
- Dependency Inversion

It’s clear which of these two approaches presents the information with more clarity.

Formatting

The previous example leads nicely into the topic of formatting. Above all, a little formatting goes a long way to making content more digestible. We’re not writing English Lit essays here. Formatting and clarity should take precedence over literary flare.

There are a number of tactics we can use to clarify our writing. I’ve listed some of my favorites below. While this is not an exhaustive list, it should be a good starting point. We certainly don’t need to deploy them all in every email, just pick and choose where it makes it sense.

Do Use:

Lists (Bullet and Numbered)
Headings and Subheadings
White Space
Indentation
Bold, Italic, Colored, and Highlighted text

Don’t Use:

Walls of text
Long sentences and paragraphs
Uncommon fonts

Graphics

Graphics can be an incredible time saver. Whether it’s a screenshot, a technical diagram, or a hacky MS Paint drawing, we can often replace volumes of text with a simple graphic. It’s just more natural to understand a graphic than it is to derive the same information from text.

Similarly to formatting, we have a number of tools available for graphics. Depending on the email’s audience we’ll of course prefer a different subset of graphics. Screenshots are almost universally useful regardless of the audience, especially a sequence of screenshots for any application flow for example.

“I would recommend embedding content within an email whenever possible.”

Also I would recommend embedding content within an email whenever possible. Attachments are fine for large files as a reference, but it ruins the flow of a good email if your graphic content is attached and not embedded.

Moreover, common sense should be used when deciding whether to embed or attach. For example, embedding a 1000 line Excel table within an email will make you very unpopular. Knowing not to do this is unlikely to be a problem for anyone reading this site.

Finally, resizing or scaling graphics should also be done liberally. We rarely need a 1MB+ image when a 100KB will work just as well. As remote Java devs, we should be conscious that not everyone is on a 1GB internet connection. Efficiently sizing our emails takes a minimal amount of effort and can make a big difference to our lower bandwidth counterparts.

Do Use:

Screenshots
Diagrams
Code Snippets
Embedded tables

Don’t Use:

Attachments when you could embed
Huge, un-resized graphics

Summary

A well-designed technical email should have clarity, formatting, and graphics. By minding these three concerns you can save yourself time and your employer money. As remote java devs, we should excel in our communications and writing clear, aesthetically pleasing emails are a great way to do so.

The payoff for writing good emails is avoiding unnecessary meetings and endless email volleys. These are time sinks and prevent us from providing the level of value of which we’re capable. Everybody wins if we can avoid these for ourselves and ultimately for everyone who would have been sucked up in these gyres of futility.

**Cross post from my blog: Technical Email Design

Simplicity in Writing

Remote Java Dev — Sat, 06 Apr 2019 15:01:58 +0000

The value of simplicity when writing business emails is of great importance. In addition, our effectiveness depends on making our writings easy to digest. A remote Java dev can exponentially increase his or her value to clients and employers by writing well.

“Business writing is about clarity and persuasion. The main technique is keeping things simple. Simple writing is persuasive. A good argument in five sentences will sway more people than a brilliant argument in a hundred sentences. Don’t fight it.” Scott Adams, Creator of Dilbert

The Day You Became a Better Writer (2nd Look)

Common Scenario

It’s helpful to think of every email we send in terms of cost. For instance, a poorly written email can set off a chain reaction of delays and loss of productive time.

Imagine the common scenario where you’ve been tasked with a new feature request. Initially you have only the most basic requirements and need more information from the Product Owner. It’s then up to you to analyze the request and its implementation details. What you do next is the difference between a high-value developer and an average one.

An average developer will wait for a meeting with the Product Owner to talk about the requirements with no pre-meeting email sent. After that, something like this usually occurs:

The meeting time comes and Average Dev becomes frustrated as the conversation devolves into ancillary minutiae. This is only broken up by a talkative non-critical participant’s habit of launching into unrelated stream-of-consciousness babbling. This eats up most of the meeting and finally the Project Manager announces you’ll all need to meet again next week to continue hashing out the requirements. (Average Dev's brain explodes)

High-Value Dev

In contrast, a high-value dev will analyze the feature request and write an email with the likely use cases and implications. This gives the Product Owner and the developer a common context. They can subsequently iterate over any disparities much more directly, clearly, and quickly.

A huge part of our value as developers is translating nebulous business requests into formal constructs. Often we’ll discover edge cases that the Product Owner hadn’t initially considered or vice versa. Identifying edge cases up front saves time by allowing us to account for them in the design. As a result this leads to more robust software and reduces maintenance costs. Both of which are hurt by the inevitable bolted on code handling edge cases that were not identified in a timely manner.

In short, a High-Value Dev

Takes the initiative of fleshing out requirements
Gets everyone on the same page with a well-crafted email
Values everyone’s time by avoiding the brain-exploding type meeting described above
Does much more than just code up a spec

Summary

Simplicity should be at the forefront of our minds when communicating in a business context. The nature of our work makes writing effective emails extremely important. Especially when it comes to mitigating ambiguity and simplifying complex systems. Additionally, you can save your company thousands of dollars in lost time by doing this well. In conclusion, as remote Java devs writing is even more important as our asynchronous communication skills should set us apart from our in-office counterparts.

**Cross post from my blog: The Value of Simplicity

Email is Still Important

Remote Java Dev — Thu, 28 Mar 2019 13:17:15 +0000

Email is still important in spite of the influx of numerous other communication tools. I’d contend that written communication, email specifically, has become even more important with the increasingly remote and distributed nature of our work as Java Developers. Email helps us clarify our thoughts, provides crucial context, allow for more productive meetings, and leaves a paper trail. All things that benefit us, our work, and protects our precious time.

Clarify Our Thoughts

There is some bit of magic that happens when we write things down. I don’t know the psychological reasons for it, but the act of translating concepts from our minds to a physical medium enhances understanding markedly. This is especially true with the complicated nature of issues that we deal with in the development world.

How often has this happened to you? You start writing a work email and halfway through you realize you’ve missed a crucial use case. Sometimes a vexing problem’s solution becomes crystal clear just by writing about it. If you’re like me, it happens way more than we’d like to admit. A Drafts folder full of half-written emails is a good sign. It means you’ve solved a number of problems by the mere act of writing an email and never had to hit send.

It Provides Crucial Context

Having a common context in which to examine a problem is tremendously useful. It’s also one of the biggest potential benefits of email. It’s a shame that email is too often neglected for this purpose and so often used for other trivialities.

Many complex topics we deal with daily require time to digest and fully mentally explore. You surely can come up with more thoughtful insights and questions on a topic you’ve had time to think about. Instead, we too often have to consider complex matters in real time in a meeting setting. This is of course far from optimal and easily remedied.

It Makes for Better Meetings

How many meetings have you sat through whose supposed purpose was some nebulous topic like “Business Requirements?” Those are usually the most useless because nobody took the time to write a good email to lay out exactly what that means. Even if requirements in the email were wrong or incomplete, it would barely be less beneficial. At least everyone would be starting with a common context in that scenario.

A good precursor email to a meeting can vastly improve the outcome, reduce the duration, or even negate the need for the meeting altogether. Every one of those situations is a big win, not only for us Devs who avoid having our souls destroyed, but also for management and the company’s bottom line. Multiply each meeting participant’s calculated hourly rate by the duration of the meeting in minutes/60 and there you go.

It Leaves a Paper Trail

I remember when I started my first programming job over 15 years ago there was a Team Lead who’d been with the company 30 years. One day she was annoyed because the Email Support team had told her she was running out of space on her Lotus Notes email account. She had saved every email she ever sent. Naively, I asked her “why,” and she proceeded to give me a much-needed lesson in the art of CYA in the corporate world.

Any of us who’ve worked in the corporate world for any length of time will have experienced some less-than-ethical characters at work. Keeping email chains of correspondence is just common sense in any significantly large organization. Sending emails and saving them are also great ways to prevent unsavory characters from attempting any chicanery in the first place. It’s much better to prevent these problems than try to deal with the aftermath.

Summary

As Developers we must protect our time. Emails are a great way to do this.

They let us:

Take the time to perform our knowledge work on our own schedule.
Share our insights with others so we’re all operating from a common context.
Help keep a meeting focused and on-task to prevent a huge time sink.
Protect ourselves from unscrupulous corporate goblins.

**Cross post from my blog here: Email is Still Important

Forem: Remote Java Dev

Engineers are Always the Smartest People in the Room

Does it Matter?

Time Sink

Real Business Value

Summary

Further Reading

Remote Work is at a Tipping Point

Freedom.

LEO Satellite Internet

SpaceX Starlink

OneWeb

The Others

Remote Options Explode

Internet Connectivity for Remote Workers

Summary

Further Reading

Best Podcasts for Remote Java Developers

Best Podcasts for Remote Java Developers

Java / Tech

A Bootiful Podcast

Java Off Heap

Java Pub House

Cloud Engineering - Software Engineering Daily

Knowledge

The Knowledge Project

North Star Podcast

Naval Podcast

Remote

Tropical MBA

Location Indie

Technical Email Design

Technical Email Design

Clarity

Formatting

Do Use:

Don’t Use:

Graphics

Do Use:

Don’t Use:

Summary

Simplicity in Writing

Common Scenario

High-Value Dev

Summary

Email is Still Important

Clarify Our Thoughts

It Provides Crucial Context

It Makes for Better Meetings

It Leaves a Paper Trail

Summary