Remote Java Dev

Remote Java Dev

Communication

Documentation Rot

by

Documentation Rot

Enterprise development teams have a bad case of documentation rot. Maybe not all, but the places I’ve worked that had a strong in-office culture sure did. In contrast, working remotely organically yields better documentation practices in my experience.

It makes perfect sense when you think about it. Remote workers are generally better at asynchronous communication. They also know the value of good documentation as they can’t just yell over a cube wall to get answers. This alone has tremendous value in terms of productivity.

In-Office Documentation

I’m pretty sure everyone has had this experience. You start at a new client or employer and need to set up your dev environment. So you ask the nearest Dev about documentation to accomplish this and get that familiar apologetic look. She says to check the team Wiki and let her know WHEN you hit a roadblock.

The Wiki was last updated by “Deleted” in 2013. They also no longer use Apache Ant, Ivy, or Lucene. At least it correctly tells you to download a JDK, though not Java 6 anymore, thankfully.

And so you begin the painful first week in-office by stumbling through an obstacle course. The best of us will update the team Wiki with the latest information so the next poor soul doesn’t suffer the same fate.

However, in-office environments are not conducive to this. As most problem solving is done verbally in person, which makes it far more difficult to capture for posterity.

This of course is just to get your dev environment up and running. You’ll have to repeat this process in order to perform any number of useful tasks. That is, finding sparse to no documentation available and leaning on in-person collaboration to learn and accomplish the tasks. 

Therein lies the biggest problem with in-office dev team cultures. Too much tribal knowledge lives in the heads of the development team and not enough lives on a durable medium in the form of accurate documentation.

In-office work encourages this manner of work, especially in these days of Agile, which I’d contend is suboptimal in many instances. In person, synchronous communication certainly has its time and place, but it is far over-utilized due mostly to inertia.

Good Documentation is a Company Asset

Any good company has a collection of processes to deliver a valuable outcome to its customers. These processes are a valuable asset. Imagine if every time you went to your favorite Italian restaurant and the chef decided to make your lasagna with a completely new recipe. You’d be annoyed because it would taste differently every time.

Good documentation yields a predictable and repeatable result. This allows us to iteratively improve upon the process. Others can perform the process themselves and perhaps find improvements that we might have missed.

In the development world, good documentation means greater self-sufficiency. We work with a lot of incredibly smart people in this industry. And documenting well allows us a much greater ability to evaluate the efficacy of any given process.

This documentation then becomes a valuable company asset. It becomes easier to onboard new developers.

New developers become productive far more quickly when team practices are well codified. And perhaps most importantly, processes can be improved upon far more easily when they are clearly written.

Remote Developers Do It Better

I’ve found documentation rot is much easier to avoid when working in a remote team. We simply must document well given the context in which we work. 

I believe our reliance on good asynchronous communication practices tends to yield superior results. It’s imperative that we’re more thoughtful and deliberate in how we communicate in a remote environment. 

Therefore the quality of our communications tends to be higher and also gives us a huge head start when creating good documentation. Often it’s simply a matter of taking things we’ve already written in chat or an email and editing them to put on a team Wiki. 

Contrast this with an in-office environment where you’ll often create documentation from scratch as the process you’re covering has only been relayed to you verbally. This is added friction that often means developers just throw up their hands and leave things undocumented. The tribal knowledge remains tribal and the landmines remain for the next unlucky developer who joins the team.

Summary

Documentation rot is a scourge upon development teams. Especially within the in-office culture which is far too conducive to unhygienic documentation practices.

The in-office work environment tends to rely far too heavily on synchronous, in-person communication. As a result, too much tribal knowledge ends up in the heads of the development team and is rarely codified and well maintained in a Wiki.

Good documentation is a valuable company asset. It allows processes to be continually reviewed and improved upon. Developers can be far more self-sufficient and ultimately more productive when they maintain and have access to quality documentation.

Experienced remote developers are skilled in asynchronous communication. The remote context prioritizes aptitude in this area and gives us a leg up on our in-office counterparts. Thoughtful asynchronous communications tend to easily translate to durable documentation on a dev team Wiki.

Unplug to Get Things Done

by

Unplug to Get Things Done

We’ve all had it happen to us. You’re right in the middle of solving a really vexing problem and then your IM starts blowing up or emails start flooding in. If you don’t unplug to get things done sometimes, it’s too easy to get distracted by the chirping notifications.

This can be extra challenging for remote workers. Because we tend to be very sensitive about being responsive in short order. Though in-office workers still get the short end of this stick by far. You can’t unplug when all and sundry can stop by your desk and divert your attention at will.

Eliminate Distractions

Most would agree we should deliberately manage anything that can distract our attention as best we can. This is especially important for things like IMs and emails, whose arrival can make us feel like they need immediate responses though this is usually not the case.

Turning off email and IM clients temporarily is a good strategy. Particularly when you’re going to be doing cognitively demanding work that will suffer from interruption. 

Depending on the makeup of your team and work inflows this approach may be more or less necessary. I’ve worked on teams who were great with asynchronous communication and I never had to turn off my email or IM. 

And then there were other teams who relied heavily on synchronous communication which required having to unplug to get things done far more frequently. Perhaps ironically to some, the teams I’ve worked on who relied on async communications were far more effective than those who relied on real-time correspondence.

The Chatty Coworker Conundrum

The chatty coworker is a special case we encounter on occasion. This person tends to over communicate to the point of hindering our work. I’m sure we’ve all bumped into a version of this person throughout our careers.

This is one place where the chasm opens between in-office workers and remote workers. An in-office worker with a chatty coworker problem is basically stuck with only bad options to address it. Whereas a remote worker has a far more palatable way to fix this issue.

If you’re in-office your ability to concentrate on any one thing is already diminished due to the environment itself. When a chatty coworker can stop by your desk at any time, you’re lucky to get much of anything done without having to hide in a conference room.

Your other options are to confront the coworker or perhaps go to the manager. Both of which will likely lead to animosity. I think most would prefer not to go this route if at all possible. 

Contrast this with a remote worker who can easily close her email and IM clients in order to concentrate on her work. And then deal with incoming communications from the chatty coworker on her own schedule.

Confront the Distractors?

But isn’t a more direct approach better? Shouldn’t you just confront the chatty coworker directly? In most situations I would say, no. 

Perhaps if we were rational beings without emotions the answer would be different, but we’re not. We’re primarily emotional beings who are capable of rational thought rather than the converse.

Imagine a coworker comes to you and tells you straight that you talk too much. Or that you need to cool it with the 50 IMs per day because you’re a distraction. No matter how true it may be, you’re going to get pissed off about it.

Our minds are finely tuned machines when it comes to justifying our own behavior. Even if we were to see the same behavior in someone else and easily identify it as deleterious. It’s us, after all! And we “know” we only do things for good reasons. 

There’s another thing to consider as well. What if the “chatty coworker” is not that chatty at all and you are just overly sensitive to incoming communications? You then risk creating animus due to your own miscalculation by confronting someone over their communication frequency.

Remote work provides an easy solution to this whole morass. You don’t have to criticize coworkers and can still get your work done by being in control of distractions imposed upon you. It’s a win-win situation.

Summary

Sometimes we just have to unplug to get things done. Turning off email and IM clients are an easy way to eliminate distractions to allow us to focus on our work.

Occasionally we will work with a chatty coworker. One whose communication style and frequency is difficult for us to manage without utilizing a reducing valve.

Working in-office makes a chatty coworker extremely difficult to deal with. While working remotely affords us much better options to control our interactions with said coworker.

We should be wary of confronting those who we may view as distracting. This approach can often lead to irreparable harm in working relationships due to our natural human proclivity towards emotional responses.

A Problem with the Agile Manifesto

by

A Problem with the Agile Manifesto

I have a problem with the Agile Manifesto. And while Festivus is over, I’d like to air one more grievance. One of the principles, while well intentioned, has missed the mark quite badly.

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

–Agile Manifesto Principle

Agile is Still an Improvement

Most would agree that Agile has been a big improvement. Especially over the top down, command and control Waterfall methodology that was dominant prior to Agile.

To the credit of the Agile Manifesto’s authors, their approach has been nothing short of transformative in the software industry. The vast majority of software development is better executed under Agile than Waterfall. 

There are of course some use cases where Waterfall is still the better approach. But in the modern business world, where most Java development happens, Agile makes more sense.

To be fair, the Agile Manifesto was written in 2001. So any critique here has the benefit of almost two decades of hindsight.

“The Most Efficient and Effective Method”

I’d contend promoting synchronous communication as the most efficient and effective method is incorrect. Granted, it may be the most efficient way to convey information. However, it is not the most effective.

For example, you could listen to a podcast at 10x speed and it would be far more efficient than listening at 1x speed. Yet if you can’t digest the information at 10x speed, then it’s not effective is it?

The combination of efficient and effective is what I’m ultimately taking issue with. My experience has been that asynchronous communication just works better for development teams.

While a synchronous exchange can certainly be beneficial, it’s usually best when it occurs after an asynchronous one. And synchronous should certainly not be used in isolation regarding topics of any complexity. 

Real time conversations introduce a number of problems. Not least of which are personality differences and conversation derailment as further discussed here.

The reality is that software development is complex. Both the business and tech domains’ complexity take time for people to comprehend. Trying to do so in a synchronous conversation will not be as effective as would an asynchronous exchange.

“Face to Face Conversation”

Today’s software development teams are predominantly distributed in nature. Meaning face-to-face conversation is no longer feasible without video conferencing technology. 

If we optimize for face-to-face interactions, then we’re left with two options. One, force everyone into the same office which introduces a vast array of problems. Or two, opt for a glut of Hybrid Meetings which have their own set of headaches.

We need look no further than open source software for a supernova counterexample to this face-to-face ethos. Think for a second how many lines of code running in your Production environment right now are from open source libraries. Then compare that to how many lines of code you’ve written that are running in Production.

Much of these open source libraries we all rely upon are the result of collaboration by people who’ve never met in person. Maybe never even had a face-to-face call on Skype, Zoom, or whatever.

If open source can yield such wonderful software without “jumping on a call” every time an obstacle arises, maybe that’s a clue as to how important face-to-face conversation really is.

Frequent communication is important to be sure. I’d just contend that asynchronous communication tends to work better as the first option for development teams. And that much of the push for frequent face-to-face communication is a suboptimal relic of a bygone era where everyone worked in the same building.

Summary

Agile has been transformative to software delivery. However, there is a problem with the Agile Manifesto.

Specifically with the principle that face-to-face conversation is the most efficient and effective way to relay information.

Granted this may be the most efficient way to communicate, yet it is not the most effective. Especially given the highly distributed development teams that are commonplace today. 

What asynchronous communication may lack in efficiency it more than makes up for in effectiveness. 

Asynchronous Communication

by

Asynchronous Communication

How many times have you sat in a meeting where people just took turns talking past each other? Asynchronous communication is underrated and underutilized in the Enterprise. It’s an invaluable tool to help solve our aforementioned meeting malaise as well as many others.

Old habits are hard to break of course. And the Enterprise as a whole has a bad synchronous communication habit. Fortunately, the rise of remote work is helping to change this for which we as developers should be very grateful.

Synchronous is Still Useful, But…

Synchronous communication has been the default for a long time. Any time an issue arises in the Enterprise, “let’s get everyone in a room and solve it.” Though we can no longer get people in the same room because companies are almost all distributed now. 

But the bigger problem with this approach is especially relevant to us developers and technologists. That is, the problems we routinely deal with are highly complex and deterministic. Compare this with other domains where outcomes are much more non-deterministic.

This is a shortened way of saying that tech problems we solve generally have an algorithmic solution or solutions. Whereas problems in other domains, such as Sales that are governed by human psychology, are much more intractable when it comes to finding algorithmic solutions.

Moreover, meetings can be very useful in domains like Sales, while often being very fruitless in other domains like Tech. Sales will rely much more heavily on a trial and error iteration approach to solving problems. In Tech, this kind of approach is horribly inefficient for most problems.

As developers we need to build complex mental models of our problem domains. Trying to then share this information verbally in a synchronous exchange is very ineffective. This is the kind of thing that needs to be translated to a durable medium and then provided to others in an asynchronous manner. 

A follow-up synchronous exchange then would have some benefit. In practice however, Enterprises generally favor skipping straight to the synchronous meeting. This omits the most crucial part of the problem solving and allows other interpersonal attributes to dominate the exchanges.

Asynchronous Promotes Iteration

All complex systems in Tech and elsewhere are the result of iteration. This is the greatest feature of asynchronous communication in my opinion as well. It promotes iteration. Iteration of understanding to individuals as well as iteration to the durability and robustness of solutions.

Consider when you’re trying to learn a new technology. You choose your favorite learning platform between Pluralsight vs O’Reilly Safari and start watching a video tutorial. Do you immediately retain every bit of information you see and hear? Or do you need to think, build something yourself, and re-watch some parts before everything starts to sink in?

If you retain everything immediately, you are amazing! You’d also be great in synchronous communication and should by all means favor it whenever possible.

However, for us mere mortals, it’s going to take time. Time to absorb new information and incorporate it within our own mental models of the technological and business domain landscapes.

Like learning a new technology, trying to solve a complex development problem is similar. We benefit from having time to digest and understand the problem on our own before collaborating on a solution. The collaboration is where the value of iteration comes in, but without the asynchronous problem digestion phase this value is drastically reduced.

More Efficient

Asynchronous communication is simply more efficient in most cases. Especially when it comes to developers and our usual workflow. Much of a developer’s time is spent in deep concentration which is difficult to achieve and whose interruption is extremely costly. 

Barring a pants-on-fire PROD emergency, it’s usually best to let developers manage their own time without forced interruptions. Promoting an asynchronous communication policy within the team is important. This way developers are empowered to respond to non-critical items on their own schedule and allow them to optimize for when they are most productive.

Contrast this with your average dev team whose manager schedules regular meetings scattered throughout the day and week. A developer in this environment is not in control of her time and cannot possibly optimize for her most productive times due to the cavalcade of interruptions foist upon her.

Simply put, by providing an asynchronous and empowered environment for your developers they will be more productive. They will also undoubtedly be happier and more likely to stay with your organization long-term as they are empowered to do what they love without needless encumbrances.

Summary

Asynchronous communication requires a durable medium and is therefore durable as well. Contrast this with synchronous communication which is inherently ephemeral. 

As developers, we work with complex systems that generally have deterministic solutions. With asynchronous communication, a developer has time to fully understand a problem before collaborating and iterating on solutions with her peers.

A dev team that optimizes for asynchronous communication has a tremendous advantage over traditional dev teams. This method of empowering developers to control their own schedules is highly undervalued and underutilized. 

It’s remarkable that this simple approach is so rare given its ability to drastically improve dev team productivity. Old habits are indeed hard to break.

Listening is a Superpower

by

Listening is a Superpower

They say listening is a superpower. 

Whoever they are, I think they’re right. 

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

It’s hardly our fault though. 

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

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

The Default

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

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

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

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

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

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

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

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

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

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

The Superpower

Listening is a superpower that can be developed.

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

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

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

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

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

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

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

The Benefits

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

We all work better with people we like. 

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

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

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

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

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

Another massive benefit to listening is how much we learn. 

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

This is especially important for us remote workers. 

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

Listening is an absolutely critical one to develop.

Summary

Listening is a superpower.

It requires conscious effort.

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

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

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

People will like working with us more.

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

Remote workers especially should develop our listening skills.

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

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.