Remote Java Dev

Remote Java Dev

Tools of the Trade – Hardware

by

Tools of the Trade - Hardware

The hardware tools of the trade for a Remote Java Dev can be quite simple or involved if you like.  Beyond a computer and an internet connection there’s not much else you really need.  However, some tools can make our work a whole lot more pleasant.

***There are NO affiliate links on this page.  If you’d like to buy any of these items, I’d recommend shopping around for the best prices.***

Monitor

People will likely differ greatly on this topic.  For instance, some are just fine with a small laptop screen and some want a NASA Mission Control setup with a wall full of monitors.

Personally I’ve really taken a shine to the Dell 43 Ultra HD 4K Multi Client Monitor: P4317Q.  In addition a tiling window manager is also very useful for such a large screen.  The Dell Display Manager(DDM) is fine if you’re on a Windows machine. Although, I had to abandon DDM after it stopped working while  connecting the monitor through a KVM Switch.

I really like the one large monitor approach compared to multiple 24” monitors for example due to the lack of annoying bezels.  Consequently, it allows much more flexibility for window sizings without ending up with half a screen on one monitor and half on the other.  

Developing web applications is great on the 43” Dell.  You can fully view your IDE, a web browser, and your Console all without having to wear out the Alt+Tab buttons.  Less interruptions of concentration equal more efficient development in my experience.

Mouse and Keyboard

I’ve enjoyed the Logitech items in this category.  Especially the Logitech MX Master 2S wireless mouse series.  It has more than enough functionality and is ergonomically very comfortable for me.

As for keyboards, I’m currently using the Logitech wireless K800.  It’s decent enough although I’d probably prefer a mechanical keyboard, which the K800 is not.  I chose a non-mechanical model for other reasons, mostly being the noise level that comes with a mechanical model.  Keyboard noise is seldom a problem for remote workers, but it can certainly be a distraction while on conference calls.

Headphones

I’ve become a huge fan of the Bose QC35 II Noise-Cancelling Headphones.  These may be even more valuable for in-office workers, but are still a great item for remote devs.  We can’t always control outside noise whether it’s the neighbors mowing the lawn or a family member vacuuming the lounge.  

When it’s time to launch into Deep Work(Cal Newport), putting on the Bose QC35’s and listening to some non-vocal music is a great way to focus.

If you happen to like Electronic music as I do, I’d also highly recommend Mixcloud!  They have an almost endless catalog of the many genres within Electronic including my favorites, the Global Underground series.

Bluetooth Headset

A good Bluetooth headset can be had quite inexpensively.  I’ve found it to be very useful not just for conference calls, but also in everyday life.  I’ve had the Plantronics Explorer 50 for several years now and it’s done remarkably well given its sub-$30 price point.

KVM Switch

If you’re like me and have multiple laptops and computers then a nice KVM Switch is very useful.  I’ve had good luck so far with the 4K TESmart 4×1 HDMI KVM Switch. I’ve connected the single bluetooth dongle from my wireless keyboard and mouse to the KVM Switch and it’s worked quite well.  

Summary

To recap some of my favorite hardware tools of the trade:

Technical Email Design

by

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 compared to getting 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.

Further Reading on Emails

The Value of Simplicity

by

The Value of Simplicity

The value of simplicity when writing business emails is highly underrated.  In addition, our effectiveness depends on making our writings easy to digest.  We can all increase the value we deliver 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.

Average Dev

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.

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 brain-exploding meetings
  • 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.

Email is Still Important

by

Email is Still Important

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 a 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 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 you’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 benefits of email. It’s a shame that email is too often neglected for this purpose. And is instead 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 silly and could be 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.

Hello World

by

Hello World

Obligatory

It wouldn’t be a proper Remote Java Dev site without kicking it off with a “Hello World” post.  

Stay tuned for content in no particular order on topics such as:

  • Remote work
  • Consulting
  • Java rants and raves
  • Effective communication
  • Adapting to different work environments
  • Tools of the trade, both hardware and software
  • Legacy tech
  • Learning new tech
  • And much more

We're Already Working Remotely

Working as a Java Developer these days means you’re already working remotely at least part of the time.  It’d be far more uncommon to work entirely with people who are in the same room as you.

Any significantly sized project will see you working with people spread out over at least the same country and frequently across the globe.  This is our new reality and the more we can embrace it the more we’ll be able to shape it into something that works better than the old paradigm.

This site is dedicated to exploring a range of topics relevant to Java Developers and more specifically to working remotely in this capacity.