Remote Java Dev

Remote Java Dev

Best Podcasts for Remote Java Developers

by

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 there’s so much great content. 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(now VMWare) 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.

Summary

Choosing the best podcasts for remote java developers is a daunting endeavor. While there are no doubt many others providing great content, we only have so many hours in a day.

I hope you’ll enjoy these great resources as much as I have.

Engineers are Always the Smartest People in the Room

by

"Engineers are Always the Smartest People in the Room"

I was on a conference call a few weeks ago when our Project Manager said “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 this. Ultimately this thought process comes from a lack of perspective in my experience. That is, a failure to appreciate 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 misses this crucial point.

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.

Why Working Remote can 10x Productivity

by

Why Working Remote can 10x Productivity

Working remote as a developer can easily 10x your productivity. It might even be the only thing you’ll accept once you’ve had a good, long taste of it.

Having the freedom to optimize for your own personal work style can be a transformative experience. It’s not uncommon to find tasks that once took you days in-office can be knocked out in hours while working remotely.

My experience working remotely falls very much along these lines.

Morning Commute

My morning commute on a remote day is roughly 5 seconds. Although I do have to navigate through a minefield of Legos strategically left by my boys in the family room. You learn to wear shoes in our house or pay the price!

Early Morning

I’m an early riser. I like to do my most taxing work early in the morning when I feel most alert and refreshed. There’s something about early mornings that promote clarity of mind in my experience.  

Spending 30+ minutes commuting in the early morning in addition to 20 more minutes getting ready to commute is a massive detriment. It’s easily an hour of highest productivity time every in-office day that goes to waste to satisfy an unnecessary physical presence requirement.

And that’s before considering the added stress of commuting which further conspires to degrade mental focus in the subsequent hours.

Common Occurrence

It’s a common occurrence to get more done before 8am on a Remote Day than in an entire In-Office day. By taking advantage of my predilection for early morning work, it’s much easier to knock out Deep Work tasks which are the backbone of any Java Developer’s value proposition.  

Much of the in-office corporate day revolves around meetings. Even as a Developer for a corporation your weekly schedule is likely pockmarked with meetings you can’t decline without raising eyebrows. Given this context, it’s easy to understand how working remotely we can get more done in a couple uninterrupted morning hours than entire in-office days.

Better Equipment

Since I’ve started working predominantly remotely I’ve invested in some much better hardware than I’d be provided with in any in-office setting. If you’re interested in what I’m currently using, feel free to check out this post: Tools of the Trade – Hardware.  

It’s bizarre that some companies will pay Java Developers here in the US over six figures and then provide them with substandard hardware. For example, one decent sized corporation I knew of gave its in-office Java Developers two old 19” ViewSonic monitors. The manager by contrast was given two 27” Apple monitors.

Personally, I have no problem spending a bit of money on my own hardware. It’s a small price to pay for the massive benefits of Remote work on my productivity and quality of life.

I think most forward-thinking Remote-friendly employers these days will provide a budget for their developers to buy their own hardware. This is the best of both worlds and a trend that I hope continues. I don’t think it’s hyperbole to say that happier, well-provisioned developers will do better and more impactful work.

Via Negativa

Optimizing for our own personal work style is largely about removing impediments. Nassim Nicholas Taleb in his book Antifragile refers to this broader concept as Via Negativa. To me this means removing impediments to the critical subset of things that matter most.  

Take commuting for example. This adds virtually no value to my output as a Java Developer and therefore it should be eliminated.

Likewise, environmental factors such as working in a loud cube farm sitting underneath a vent blowing cold air on you all day will degrade performance. Things like these are prime candidates for culling in observing the Via Negativa principle.

Removing impediments to our productivity leaves us more time and attention to focus on things that provide the greatest value to the business. Most notably, solving business and technical problems.

Encourages Output Mentality

One of the most beneficial features of Remote Work for a Developer is keeping deliverables at the front of mind.

It’s too easy and common while in-office to fall victim to the butts-in-the-seats definition of work. The simple act of physically being at work signals to others that you are fulfilling your obligations.

If you’ve worked in the in-office corporate world I’ll bet you’ve seen more than a few people whose simple act of showing up every day and little more was enough to keep their jobs for years.

This is a safety net we don’t have as Remote Developers. In truth, it’s not a safety net at all.

It’s a pernicious trap to fall in where your skills and abilities erode with no immediate penalty. That is until the day your job ends and you’re forced to find a new job with your atrophied skill and obsolete tech.  

Being a Remote Developer means we have to deliver. It means we have to prioritize well.

It might be more fun to rewrite a clumsy, yet bulletproof method from 2010 than to flesh out edge cases in a new feature request. As a Remote Dev though, there is no choice. We do the most important things first.

Evening Commute

Also 5 seconds. Although the Legos have usually been rearranged by this point so there is a whole new minefield to navigate.

Summary

Working remote is an easy way to 10x productivity for me as a Java Developer. It allows me to Via Negativa eliminate numerous factors that degrade my output.

These include commuting, environmental liabilities, and poor equipment. When remote, we can better optimize for our own productivity which for me is overwhelmingly in the early morning hours.

Remote work also encourages us to adopt an output mentality. It’s imperative that we prioritize well as there’s no physical presence “safety net” to fall back on.

This is advantageous to both our employer and to ourselves as we continually improve by delivering value.

Further Reading

An In-Office Day, Sound Familiar?

by

An In-Office Day, Sound Familiar?

What does an in-office day feel like in 2019?

If you’ve been working mostly remotely for any length of time it feels like traveling back to a more primitive age. A time when your output as a developer was a secondary concern to acting the part in person.  

The amount of unpleasantness you endure to even arrive at the place where you must be in order “to work” is significant. Environmental factors that are easily controlled in your home office are now completely out of your hands.

If you’re like me and try very hard to optimize your individual work approach, those pretty much go out the window during an in-office day. You’re on someone else’s schedule while in-office.

Before Sunrise

To me an in-office day means waking before sunrise. Though truly my in-office work day begins the night before in picking out work clothes. Then ensuring they are clean and wrinkle-free which often means time spent ironing or steaming them as well.

After getting ready I then face a 30+ minute commute in a metro area. Waking before sunrise is also a big trade off.

If I were to depart later in the morning, my 30+ minute commute would double. Also, any sort of inclement weather or accident along my heavily traveled expressway commute will cause my 30 minute best-case commute time to inflate rapidly.

Every trip into the office likewise increases gas and vehicle maintenance costs. In short, there are many disagreeable things to deal with on an in-office day before I even step foot in the door.

The Meetings

If you’re lucky you have time to grab a cup of coffee and a snack before the favorite in-office pastime begins, The Meetings!

Since we’re all in-office we should have a meeting for this and a meeting for that and meeting for those things. It’s a post for another day, but corporate world meetings are usually a big waste of time.

The synchronous nature of in-person meetings can be hugely detrimental to their effectiveness. If humans had high fidelity memories this would not be a problem.

Unfortunately, we do not. This means that many of a meeting’s discussion points will be interpreted differently or incorrectly by its participants’ memories.

It’s not easy to take notes on your laptop while other people are talking. It would be even more distracting if a room full of people were all typing away furiously during the meeting.

Instead we must rely on our memories or incomplete handwritten notes to recall what was discussed. This usually leads to something like this:

How many times have you sat in a meeting where the exact same problem is being discussed that had been covered at length on a previous occasion?

Far too often if you’ve been around the corporate world for any length of time.

The Good Part of In-Office Days

I don’t mean to suggest that in-office days are only bad. Talking with your colleagues about things outside of work organically is a wonderful thing. These kinds of conversations are just easier in person when we can naturally process non-verbal cues.

It really helps to forge more personal bonds and in general builds trust in relationships. It’s very nice to have these personal connections, and also helps us be more empathetic with our colleagues. Moreover, we can prevent animus that arises from treating each other in a transactional manner.

Cube Work

Trying to perform deep work in a cube farm is suboptimal to say the least. Whether it’s conducting complex analysis or writing code there are just too many distractions in the common office setting to be done well and with efficiency.

It’s a pernicious arrangement for us developers whose fundamental value proposition is to automate. And to automate well we need to attain deep levels of concentration to generate accurate mental models of the problem domain and technological topologies.

Among the distractions in your average cube arrangement are noisy neighbors, drop-ins, and environmental factors.

Sales Guy

If you’ve never had the pleasure of sitting next to a sales team, I highly recommend it for about a day. It will make you appreciate your home office more than just about anything.

I’ve had that pleasure and let me just say it was…loud. My favorite part was the sales guy in the adjacent cube who would conduct all his affairs on speaker phone, including ordering lunch from Jimmy Johns on a regular basis. Even the best noise-cancelling headphones can only do so much.

Drop-Ins

Then there are the drop-ins. You want to focus on a tricky bit of functionality and a colleague drops in and wants to talk about picking morels this weekend. If he’s a talker and not particularly self-aware, you’re going to be listening to morel talk for awhile until you can escape to the restroom.

Environmental Factors

In an office you are at the mercy of many factors in the environment. Maybe it’s the guy in the next cube who bathes in Axe Body Spray every morning.

Or the gal who listens to Spotify pop music on speakers at her desk. Or the animal lover in your all-morning meeting who is covered in cat hair when you are very allergic and asthmatic to pet dander.

The HVAC system is another point of consideration. Some office HVAC systems are incredibly loud and then shut off to deafening silence with regularity. If you happen to be right underneath a strong vent you might be freezing all day if the person in control of the HVAC likes it cool.

These are just a few things I’ve personally experienced during my time in-office over the years.

Home Again

After you’ve put in your time at the office, it’s time to travel back home again. For me this means an even longer commute than in the morning as the afternoon rush hour begins too early to beat it and still work a full day. My best case 30 minute commute turns into a 45-60 minutes if I’m lucky and there are no accidents or bad weather.

On average this means I have a 75-90 minute longer work day for travel alone. I suspect this is pretty normal for those of you that commute on a regular basis.

That’s a lot of extra time away from your families and friends. This is a massive quality of life detriment that persists largely due to inertia.

Summary

The in-office day is full of negatives for a developer. Aimless meetings, distracting environments, and stress-inducing commutes all conspire to degrade our productivity and quality of life.

However, meeting colleagues in person definitely has some benefits. It enables empathy and strengthens trust which can pay dividends in both a work and personal context.

On balance though, developers need to concentrate deeply in order to fulfill our value proposition. The way we do this is going be largely dependent on the individual. An in-office environment is a lowest common denominator paradigm of a bygone era.

The best companies are quickly realizing this and empowering their people to 10x their productivity by allowing them to optimize for their own best work style and place.

Empathy as a Developer

by

Empathy as a Developer

Exhibiting empathy as a developer is a telltale sign of a true professional. If you’ve worked as a developer for any length of time you know all too well what it’s like to work with the oblivious.

There are many ways we can express empathy in our daily lives as developers. Some primary examples being in our code, towards other developers, and in our communications.

Your Code

Writing your code with an eye towards empathy is a sure sign of a good developer. How do we write empathetic code?

By not only writing code that a computer can understand, but also code that other developers can easily grok. This may even mean “dumbing down” your code if you’re an especially clever one.

A primary concern in writing code should be the people who will maintain your code in the future and the code’s overall understandability. Writing overly “clever” code that is not intuitive is a fertile breeding ground for future bugs or to just become an outright albatross.

Writing clear code may just save you a huge amount of time and trouble too. It may even be you having to alter that clever bit of code years later wondering what in the world you were thinking.

Towards Other Developers

Showing empathy towards other developers should be valued and demonstrated much more in the software world. Said differently, it should not be as acceptable as it has been in the software world to be a jerk.

People who write software are indeed very intelligent. Some developers however translate that into they are the smartest people in every room while very stupidly treating other people as inferior.

We’ve all painfully spent way too much time with people like this. They enjoy conflict and arguing over even the most menial detail as if it were life and death.  

Software jerks like this essentially lack perspective. They fail to understand that interpersonal relationships are more important than memorizing some obscure technical details. This manifests in a number of ways in the professional developer world.

Code reviews are a great opportunity to exercise empathy towards your fellow developers.

Picking nits in code reviews is a guaranteed way to make people cringe when having to work with you.

By all means share helpful suggestions and gracefully identify potential bugs, but keep violations of your own personal coding manifesto to yourself.

The same goes for busybody suggestions. We’re all full of a million ideas about how everything in the app could be better.

If you choose another person’s unrelated code review as an opportunity to start sharing them, you’re just being a busybody and wasting everyone’s time.  

Communication

Empathetic communication is a closely related concern to the previous topic. I especially appreciate the following axiomatic approach to communication. Praise in public, criticize in private.  

This is one sure way to engender trust among our peers and surely we all enjoy working much more with people who do this. This leads to better relationships, better code, a better work life, and it’s free to implement.

A project meeting is a great time to praise a colleague for her contributions. Conversely, it’s an awful time to call out a bug you found in her code. The Silver Rule provides a good framework in which to conduct yourself.

Do not do unto others as you would not have them do unto you.

The Silver Rule

Summary

Empathy as a developer is to simply be mindful of our actions. Whether it’s in our code, towards our peers, or how we communicate we should always keep in mind the downstream effects of what we do.  

We should write code that is robust and understandable to future developers. Likewise, we should treat our fellow developers with the same consideration we’d like to receive. And finally, we should communicate with the goal of lifting up our peers and creating an environment where trust can flourish. 

Doing these things well make us indispensable and put us among a small cohort in the development world.

The Code We Don’t Write

by

The Code We Don’t Write

The code we don’t write is just as important as the code we do write.  As long as humans are doing the coding it’s worthwhile to pursue simplicity.  Complexity grows when we add unnecessary abstractions in the pursuit of a mythical “pure Object-Oriented Design” ideal.

Attempting to code for potential future implementations is a prime source of code bloat.  More generally we should favor less code as simply there is less that can break and if it does, it’s likely to be easier to debug.  

Future Implementations

What will be the top news story one month from today?  Who knows, right? There are way too many variables to predict.  

Yet in software development, we are encouraged to write code to account for future implementations.  This is generally a smart principle I think most would agree. However, it can easily lead us astray.  

Be wary any time you find yourself writing code that is intended to account for potential future implementations.

It’s too easy to interpret this principle as giving us license to try and predict the future.  Be wary any time you find yourself writing code that is intended to account for potential future implementations.

Unless you have long experience in the business domain, it’s likely you’re trying to code for things you can’t possibly predict with any significant degree of accuracy.

By all means, we should write our code with the ability to be extended!  We should have the humility to not mistake this for assuming we can predict what that extended functionality will be.

Favor Just-In-Time Abstractions

Sometimes we forget, but almost every code base we work in will undergo significant change. In general, it’s much easier to add an abstraction when we need it than it is to remove one.  

It’s human nature that we’re far more likely to leave an abstraction in place than we are to remove one. Especially if we’re not intimately familiar with the code and the potential ramifications removing it.

We should only add layers of abstraction with great care.  Every layer of abstraction should be viewed as an inflection point of complexity within the system.  We need to carefully assess whether the layer of abstraction will increase or decrease complexity and act accordingly.

Code to an Interface!?

It may be heretical, but we don’t need an interface for everything.  This goes hand-in-hand with resisting the temptation to code for unknowable future implementations.  In contrast, we should add abstractions and interfaces when there is a clear and immediate reason to do so. 

Imagine we need to implement a simple BillingService for a new application.  It’s a small company and there is only one billing system. Do we create a Java interface for BillingService?  And then a BillingServiceImpl class implementing BillingService?

We find code like this everywhere.  But what has the interface really given us here?  Nothing, except some extra lines of code and a bunch of boilerplate that is essentially useless.   Another file in the repository and more surface area for typos and bugs to potentially hide. 

 Another file in the repository and more surface area for typos and bugs to potentially hide. 

In truth, when we write something like this we’re only doing it because we were told at some point to “code to an interface.”  This is a useless abstraction here. The interface has bought us nothing, increased system complexity, and most perniciously made us feel like we have done the right thing because we adhered to “Good OOD” principles.  

Just write BillingService as a class.  If in the future our example company acquires another and we need to have two billing services, then we can refactor and have a good reason to do so.  Then creating a Java interface will make more sense and the added layer of abstraction will buy us something worth having.

Counterpoint

To be fair though, a case can be made for writing BillingService as an interface and then a BillingServiceImpl as a class.  The primary reason being most developers use this approach and will be instantly familiar with it.

That familiarity alone might be worth enough to consider using it regardless of its detriments.  We’re all still using QWERTY keyboards after all, aren’t we?

Summary

In conclusion, the code we don’t write can add tremendous value by preventing cruft.  Pursuing simplicity in our code is a worthwhile ideal and should take precedence over theoretical prescriptions such as “pure OOD.”  In other words, good OOD is important, but not as important as simple, understandable code.

Be wary of trying to predict the future with your code.  Future implementations are often unknowable and should be treated as such.  

Adding abstractions to our code should be done with care.  Add abstractions when they are needed, not when they might be needed if X, Y, and Z could become true in the future.

Coding to an interface is a good heuristic.  However, this principle is often treated as a command and deployed mindlessly.  

If you find yourself writing boilerplate interfaces, just stop for a moment and ask yourself what benefit it’s providing?  Often enough, you’ll find you’re doing it out of habit rather than from conscious deliberation.