Remote Java Dev

Remote Java Dev

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.

The Hardest Part of Consulting

by

The Hardest Part of Consulting

The hardest part of consulting is surprisingly not working with old tech. Nor is it working with difficult personalities or being an “other” in another organization either. While these can certainly be challenging, they aren’t the toughest.

Instead, I’ve found the hardest part of consulting is seeing the root causes of problems and not being allowed to fix them. The reasons for this vary but usually revolve around an expectation that you should “stay in your lane” so to speak. 

Especially if the reason you were brought in was not explicitly to fix the root problem.

For example, a company brings you in to fix Application X. You discover that X is a minor symptom of a much bigger Problem Y. However Problem Y will not be solved for reasons such as political, financial, or otherwise.

Consultant or Software Pro?

Erik Dietrich, who runs the fantastic Daedtech blog, has a great post about the Taxonomy of Software Consultants. In Erik’s parlance, much of what is referred to as “consulting” these days would fall in the Software Pro bucket. 

I’ve found this to be true in my experience working for a great consulting firm here in the Twin Cities. The local market just seems to want Software Pros more than it wants Consultants. This seems to hold even when clients pay for Consultant level personnel and then have them do Software Pro level tasks.

Marketing is no doubt a big factor here. Acme Software Consulting sounds better than Acme Software Contracting.

So the natural tendency will be for contracting shops to pitch themselves as consulting shops in order to charge higher rates. While time and reputation tend to sort these things out eventually, it still muddies the waters for clients seeking help with their IT departments and projects.

Suboptimal Engagements

This nebulous environment can lead clients towards suboptimal engagements. For example, a client who has serious problems with their development process hires a Consultant. The Consultant then identifies several areas to improve the dev team’s velocity, yet the client resists any such changes. 

In reality, the client only wanted a Software Pro to keep an old hairball of an application running, because their own dev team could no longer handle it. This is unfortunately all too common. Solving the root cause of the hairball would lead to a better outcome, yet this is not what the client has contracted you for.

One of the big advantages of being a consultant is looking at a client’s development team and processes with fresh eyes. You’re not tied to past decisions that may have fared poorly.

It’s this clarity and independence that makes it much easier to see what can be improved. Convincing the client’s management to do so however is another matter.

The Minefield

This leads into one of the minefields of consulting. That is, navigating the politics of host organizations and coaxing them to solve the root causes of their issues. 

This can be especially tricky when these issues may be caused by the client’s management or technical leadership. How do you gracefully tell a client’s management that their FTE Architect has built their app into a Rube Goldberg contraption? Particularly if that Architect has been in the role for some time and is well regarded in the organization. Not an easy sell.

Likewise, imagine the client’s management is a mess and is the core reason their dev team can’t deliver. If you’ve been engaged by said management, it’s not likely to go well if you inform them that their approach needs an overhaul. Especially if they’ve brought you in to fix what they perceived to be a software problem.

These are all emblematic of the hardest part of consulting. In short, identifying the root causes of a dev team’s problems and not being empowered to fix them. Instead, you’re often expected to stay in your lane and fix only what the client wants, though it may be of far lesser impact.

Summary

The hardest part of consulting I’ve found is not being empowered to solve root cause problems. Sometimes clients just want specific tasks handled and are not interested in more comprehensive solutions. 

One cause of this is the muddied waters of what a software consultant is these days. Software Pros and Consultants have become largely synonymous. So clients often expect their consultant to stick to Software Pro level tasks.

This often leads to suboptimal engagements. Largely due to far narrower scopes of work than would be ideal. 

Trying to bridge the gap between what the client wants fixed and what really needs to be fixed can be a minefield. Navigating the politics of a client organization is difficult even in the best of circumstances.

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.

Drinking from the Fire Hose

by

Drinking from the Fire Hose

We all love drinking from the fire hose of new tech. Almost as much as we love hearing the phrase repeated ad infinitum. It is a reality however that we’re bombarded with constant change in this industry.

As developers and technologists it’s imperative that we stay abreast of the quickly evolving software landscape. How best to do so? Well, I expect what’s best will depend heavily on your individual learning style. 

I’ll share the approach that I’ve adopted and maybe it will be of some value to others.

Overcoming Overwhelm

One of the biggest challenges I’ve found in drinking from the fire hose is overcoming overwhelm. There’s just so much on so many fronts for us to learn that you’re tempted to just throw up your hands.

In all honesty, it’s crossed my mind that some days I’d rather just go back to programming COBOL on the Mainframe. At least in that world, it felt like you had a stable platform that wasn’t changing drastically every couple of years. 

But most would agree that stapling yourself to a legacy platform is not a good long-term strategy. So we can at least take solace in the fact that we’re in the same boat as our fellow technologists who also struggle with our rapidly changing world.

I’ve just had to accept that I need to get comfortable with being uncomfortable. Uncomfortable in the sense that I’m not going to be able to master all the new tech that I’ll have to work with. Oftentimes this means learning the macro concepts of a tech in order to work with it and then Googling like mad when it comes time to write the syntax.

Choose a Lane

After pushing past the general malaise of overwhelm, I’ve found it helpful to pick a general area I want to learn. For example, do I want to learn Microservices or Machine Learning or Grid Computing?  

While there will certainly be plenty of overlap in these more general categories, it helps identify a specific tech stack to focus on. I use this as a reducing valve. In other words, I need to eliminate a huge swath of the tech fire hose spray in order to leave myself with a manageable portion that I can digest.

While I’d love to learn Python and Machine Learning and LISP and Q#, I just don’t have the time. Not with a full time job and a family and other obligations. I suspect most readers will also have similar time constraints.

Build a Roadmap

Once you’ve picked your general lane, it’s time to map out what tech is most important within it. For example, if you wanted to learn Cloud Native Java development you’d start building a tech list. This list might look something like this:

    • Cloud Providers
      • AWS, Azure, GCP
    • Containerization
      • Docker
    • 12 Factor Principles
    • Microservices
      • Spring Boot
      • Spring Cloud

Once you have a roadmap of tech, then you need to prioritize. What’s the most important tech to learn first? What are the dependencies? For example, does it make sense to try to start learning AWS without first learning about Containerization and Docker?

You’ll likely run into some circular dependencies at which point you just need to pick an order and go with it! It’s easy to fall into the trap of doing nothing because it’s not clear what the priority ordering should be. You can always reprioritize later if needed.

Do!

I’ve found I generally need to do in order to learn. This means building things myself and not just passively consuming content. I suspect this will be the case for most others as well.

For example, if I want to learn Quarkus, then I need to build my own app using this tech. Simply listening to a podcast or reading a book about Quarkus is not going to get me very far. What little I retain from such endeavors is quickly forgotten over time.

However, if I build my own app with Quarkus, even if it’s fairly basic I retain far more. I need to discover the gaps in my knowledge by solving them on something I’ve built. I’ve also found this to be a far more efficient way for me to learn. 

I do listen to podcasts and use other resources that are passive in nature. However, I like to use these as high-level introductions or reference materials. Mostly to be done while doing other things, for example listening to podcasts while at the gym or during drive time. 

I know I’m not going to retain a huge amount from these mediums, but they can give me a head-start when it comes time to build on my own. 

Finally, I like to keep a consistent cadence to my learning. For example, I know I’m going to be busy most weekdays so I accept that I won’t be working on my projects during this time. 

However, I can carve out hours on the weekends to dedicate to my projects so that’s what I do. Even if it’s only a small commit or two on my projects, I strive for consistency.

Summary

Drinking from the fire hose of new technology is a fact of life to a software developer. Moreover, we should devise a strategy to do so as effectively and efficiently as possible.

It’s important to overcome feeling overwhelmed by the endless change in our industry. We can accomplish this by filtering and prioritizing well. Our time is limited, so we must decide what will give us the most bang for our buck.

Picking a topic of interest and building a road map of the critical technologies can serve as a reducing valve. By doing so we can learn at a manageable pace while accepting that we will never be able to learn everything the fire hose shoots at us.

Many favor active learning by doing over passive learning activities. I would agree with this approach. We tend to retain more by doing and iterating than passively consuming content.

The Hybrid Meeting

by

The Hybrid Meeting

It seems to be the norm these days. The hybrid meeting where some people are in an office and some are remote. In fact, over the last decade of working in the Enterprise, it’s hard to recall any regular meetings where all participants were in the same physical location.

The technologies that enable the hybrid meeting have improved dramatically in recent years. Yet I’ve noticed a rather curious irony in how these meetings generally play out. One that flies in the face of what has been “conventional wisdom” when it comes to employee engagement.

Meeting Technologies

If you’ve been in the Enterprise world for any length of time you’ve no doubt used a wide array of meeting tech. Starting with the plain old phone-based conference call and extending to modern video conferencing software.

Over the years I’ve had the pleasure and displeasure of using Cisco Webex, GoToMeeting, Skype, Skype for Business, Microsoft Teams, Lifesize, Slack, and Zoom. I’ve probably forgotten several others too. In general they seem to be improving over time.

Not surprisingly, the most reliable is still the plain old audio-only conference call. Of course there are a lot fewer bits to move around when it comes to audio than video. Video conferencing is always vulnerable to one bad network connection spoiling the experience.

Maybe in the future we’ll have VR headsets with which to conduct our meetings. Then we can all pretend we’re sitting around a table on top of Mt. Everest while discussing the latest TPS Reports. 

The Irony

I’ve noticed a curious trend over the past several years when it comes to hybrid meetings. That is, the in-office network connection is often the worst of the lot. In other words, meeting participants may be connecting from all over the globe, yet the in-office internet connection is the choppiest.

We’ve reached a point where our home internet connections are often much faster than at the office. I know this has been true for me personally at every place I’ve worked for at least the past decade. 

At one client we routinely have people connecting to the meeting from the UK, India, North Carolina, and remotely in the MSP area as well as the company’s corporate office near St. Paul, MN. When I work remotely, I can see and hear everyone around the world perfectly…except those at the corporate office where team members gather in a conference room around a laptop. 

Tell me again why it makes any sense to compel people to trudge into a specific location where the equipment and environment will be worse than you have at home.

Body Language Tells All

Compare the body language of in-office meeting participants to those working remotely and the difference is dramatic. One group is generally engaged and attentive. The other can’t wait to bolt for the door.

The in-office folks of course are the ones who can’t wait for the thing to be over. Their body language screams “get me out of here!” Arms crossed, feet pointing towards the door, pulling out their cell phones every minute to sneak in a quick 15 second scroll escape. 

Then there are the remote participants. These are the ones who are actively engaged in the conversation and generally trying to make the meeting a productive endeavor. 

This makes sense. Remote workers are conscious of being thought of as “out of sight out of mind.” And so when the opportunity comes via meetings to be seen and heard, remote workers naturally want to make the most of the opportunity.

Whereas in-office workers, developers in particular, tend to view meetings more as intrusions. At least the type of meeting common in the corporate IT world, and I can hardly blame them having attended a fair number of them over the years.

Summary

The hybrid meeting, where some participants are in-office and some are remote, is prevalent in today’s corporate world. In all likelihood it is the most common type of meeting.

Meeting technology has advanced over the years. Though the biggest improvement to the experience has mostly come from better internet speed and reliability.

This advancement has led to many people having better internet connections at home than they do at their company’s office. As home internet connections have improved faster than their corporate counterparts. 

Ironically this has led to remote workers having a much better meeting experience than participants who are in-office.

Body language often reflects this reality. In-office meeting participants seemingly can’t wait for the meeting to end, while remote workers tend to be more engaged.