Remote Java Dev

Remote Java Dev

The Many Hats of a Java Developer

by

The Many Hats of a Java Developer

Back in the olden days on the mainframe, programmers wore one hat. There was basically one stack and it was highly transferable from company to company. In contrast, the many hats of a Java developer in today’s world is staggering. It’s never been a more exciting and in some ways more difficult time to be a developer or consultant.

I’ve found there to be a significant overlap between working as a Java consultant and working on a small development team as an FTE. In these types of situations you’re often working understaffed. This results in having to work up and down the tech stack which brings us to the many hats of a Java developer and consultant.

The Cambrian Explosion

If there’s one thing we in the tech industry can agree on, it’s that rate of change is accelerating. The expansion of technology and software into all corners of our daily lives continues unabated. This reverberates into the Java world as we increasingly need to solve novel problems or old problems at new scales.

As a result, we’re in the midst of a Cambrian Explosion of new tech in an attempt to solve these problems. Which has likewise led to the many hats of a Java developer increasing dramatically in number. In other words, if you’re a Java developer in today’s world, don’t get too comfortable.

Learn Quickly

Our rapidly changing landscape means we, as Java consultants or small team developers, need to learn quickly. It’s no longer feasible to deep dive into all tech we use on a weekly basis in a quest for mastery. 

In order to deliver real business value, we need to get up to speed quickly on the fundamentals and implement. Because there will always be another part of the tech stack that needs our attention just as much if not more. 

This necessarily puts a premium on our ability to prioritize. Moreover, this can actually help us as it prevents us from going down engineering rabbit holes. Common ones being premature optimization and over-architecting where simple solutions would be best.

The Hats

Today’s Java consultant or small team developer does a lot more than write code. It’s routine for us to bounce between coding, analysis, project management, team leadership, architecture, infrastructure, and testing concerns all within the same week.

It all depends on the makeup of the team. And being chameleons of the Enterprise Java world, we step into whatever role is needed. Some teams have no QA, so we do QA. Some teams have no DevOps, so we fill the DevOps role. 

It’s a huge challenge to be sure, and it’s also a lot of fun! You never get bored, there’s always a thousand interesting things to learn, and you get to make a big difference for your clients/employers.

Summary

Today’s rapidly changing tech landscape requires Java developers to adapt constantly. This is especially salient for consultants and small team developers. 

It is most important for these populations to learn quickly. The Cambrian Explosion of new tech necessitates we prioritize our attention skillfully.

The many hats of a Java developer include analyst, architect, coder, DevOps, DBA, platform engineer, production support, project manager, QA tester, scrum master, and more. In the coming years we will no doubt add to this list with regularity.

The Corporate Standup

by

The Corporate Standup

Sometimes I think about the misfortunate developers who worked in a time before Agile. They had no daily corporate standup to turbocharge their velocity. It was common for them to fill out status reports as well, how primitive!

In all seriousness though, the corporate standup is now a staple in the enterprise. Everyone is now “Agile!” You can hardly blame the enterprises though. When a marketing tsunami like Agile sweeps over the landscape, everyone tends to hop on or risk being regarded as a legacy IT shop.

Daily Status Meeting

Why do we have daily standups? It’s all part of being Agile, right? Well, Agile does indeed promote having daily standup meetings, but the reason for them is the issue. 

The corporate standup in my experience does not revolve around a cohesive project. It is instead a rebranded daily status meeting. A meeting where management routinely attends and impacts the discourse.

The focus of the daily meeting then becomes telling a good story to the manager. And avoiding the unpleasantness of publicly calling out gremlins that may be lurking.

Ultimately the meeting just becomes a synchronous way to report what each person is working on to the manager. Most importantly, it’s not focused on delivering better software more quickly.

Unfocused

Its nebulous focus is one of the biggest problems of the corporate standup. This results in meeting members working on vastly different things that have no relevance to others.

It’s a common occurrence for two people in the corporate standup to dive into minutiae that is wholly irrelevant to others. This is a telltale sign that your standup is unfocused and operating at a deficient layer of abstraction. 

It takes an iron-willed scrum master to prevent the constant side-tracking that occurs and quite frankly, I have yet to see one in action.

Carrot and Stick Management

Moreover, the daily corporate standup smells an awful lot like carrot and stick management. All the direct reports must gather every day and give a verbal accounting of their actions to the manager!

This is basically what the corporate standup consists of in far too many places and is far removed from the real aims of the Agile approach.

Do you think the manager or director or VP is having a daily standup meeting reporting what they’ve done to the CTO? Is the CTO having a daily standup meeting with the CEO or Board of Directors? Yeah, right!

The daily accountability charade is reserved for the line level staff. The Agile approach can be fantastic for delivering better software more quickly. However, in the corporate world the ceremonies have been hijacked to serve a far less useful purpose.

The Costs

The corporate standup has many costs. It is first and foremost a huge waste of time. Calculate the cost to the organization of 10 people wasting 30+ minutes a day in a status meeting and it’s staggering! 

Usually a quick IM or email would easily replace the standup milieu and save everyone a massive amount of time. If you absolutely cannot get rid of the daily standup meetings, then making them asynchronous is likely to help.

See tools like Standuply as a means to restore sanity into your development team’s existence.

Another big cost of the corporate standup is it encourages slow progress.  Too often people wait for the standup to communicate issues.

In other words, it becomes too convenient to talk about things at the standup which deserved immediate and focused attention. This is bad process run amok and is endemic to the corporate standup.

Finally, the daily corporate standup occurs in an ephemeral medium. It’s a verbal exchange, therefore most will be forgotten or ignored by the majority of the participants. If the meeting was focused and quick, this would be less of a problem. 

However, we all know that corporate standups are not focused or quick. Moreover, any signal in a daily standup will likely go unnoticed amidst the vast amounts of noise. The signal to noise ratio here is awful and so people will often miss things.

Summary

The corporate standup is generally Agile in name only. It’s most often a daily status meeting masquerading as an Agile ceremony.

Daily corporate standups tend to be unfocused. In short, too many people working on too many different things. 

Carrot and stick management is anathema in the tech world. Yet it’s become ubiquitous under Agile auspices.

The costs of the corporate standup are significant. Wasted time, encouraging slow progress, and the substandard ephemeral medium are all detriments endemic to the corporate standup.

Like anything in tech, Agile ceremonies are tools. They work very well in some scenarios and very badly in others.

Back in Office

by

Back in Office

What’s a Remote Java Dev doing back in office you might ask? Well, as a consultant I recently started a new client and so I’ve been working on site for the past month or so. Going back in office for a time is…interesting, I’ll say.

The Good

There are some good things about being in office. It can definitely be a little easier ramping up at a new place when you’re in the same location. It’s also much easier to get to know your coworkers when you can meet them face to face. 

Chatting about non-work related activities too is much easier and more organic. Building rapport is important at any workplace, but is especially so for a consultant. As our time at any one client is limited, we operate under a strong time pressure.

Likewise, it’s easier to build comradery when you’re together with people in the same room. Whether it’s team lunches or gathering at the coffee machine, it’s just easier to talk with a colleague about his or her interests. 

You also share common experiences such as bad traffic or weather in getting to the office. It may seem trivial, but the shared annoyances help form bonds and ultimately trust between people. This pays off down the line both on a personal and a professional level. It’s easier to work with people with whom you’ve built trust.

The Bad

This will be nothing new to those who’ve read some of my past posts regarding remote work. One of the biggest problems is almost always the work environment. 

A wide open floor separated by cubicles is a horrendous location to do development work. It’s unfortunately extremely common.

If you put 100 people in an open space, it’s going to be disastrous for productivity. Maybe companies feel what they save on real estate can compensate for this, but I have my doubts. 

It’s the constant cell phones ringing. The person two cubes over who warms up leftover fish and eats at her desk every day. The unfortunate guy on the other side of the cube wall who has a terrible chronic cough. They all serve to make the work environment extremely unpleasant.

It’s almost never a result of malice. It’s just the gathering of many humans in a small area will inevitably lead to countless distractions.

The Ugly

The meetings. A meeting that runs long while you’re remote is not fun. However, you can at least get something productive done while people drone on. No such luck when you’re sitting in the same room as the other meeting participants. 

When the daily corporate “Standup” lasts 45 minutes, it flat out stinks! Standing there in a room while two people dive into minutiae irrelevant to the remaining group is a huge waste of time and energy. 

Meetings also seem to go much longer than necessary when in person. This is just my anecdotal observation, but I’ve found it to be fairly consistent. The meeting may start about one topic, then is quickly veered off course by several other orthogonal concerns. 

Everyone’s in the same room, so might as well handle that too right? Usually not right, because what may be germane to two people will be wholly irrelevant to the other five. 

It all boils down to time mismanagement. It takes pretty iron-willed leadership to recognize this as it’s happening and stop it. These things are just easier to avoid or mitigate when remote, I’ve found.

The Future

It’d feel a little odd running a blog called remotejavadev.com for very long while not working remotely. Happily, I’ll be switching to working remote only starting in June of next year. My family and I will be moving to the Kingdom of Tonga at that time and we’re beyond excited about it. 

I’ve worked remotely from Tonga a couple times before, but this one will be much easier. Easier because we’ll be living there beyond a few months at a time so I can really settle in and set up a nice work environment. 

Relocating permanently overseas will be a whole new challenge. So if anyone has any advice for soon to be US-Expats, please feel free to reach out!  I’m on Twitter @RemoteJavaDev or can be reached via email at dan@remotejavadev.com

Flow State

by

Flow State

Everyone wants to get into flow state these days. That magical mental space where your fingers can’t type fast enough. Everything compiles on the first try and unicorns fly out of your ear! 

On a serious note though, it is a great space to inhabit. It’s just a bear to get into. I’ve found it often comes down to managing my mental state.

Managing Mental State

What does mental state have to do with entering flow state? Everything, I’d contend, at least for me personally. 

A poor mental state can easily prevent clarity of mind. With no clarity of mind, flow state becomes impossible. 

So how do we obtain clarity of mind? Take out the rubbish. Our minds are home to an endless stream of thoughts, so much so that we often struggle to focus on any one thing.

A good place to start is managing your external environment to the degree in which you can.

External Environment

It’s difficult to focus when we work in a place full of distractions. This is one place where working remotely can be far superior to working in-office. We’re more in control of our external environment and so we’re better able to manage our mental state.

There’s little risk of Bob, the overly chatty coworker, stopping by our home to regale us with his latest battle against his neighbors over property lines. When we’re in-office, no such luck.

For occasions when we have to be in-office, it’s critical to have noise cancelling headphones. As they can help block out the cacophony going on around us in the average corporate office, all serving to distract and prevent us from entering flow state.

Mindfulness

If you find it difficult to achieve flow state I would highly recommend looking into a mindfulness practice. I’ve found it tremendously helpful to deal with the endless stream of thoughts careening around in my mind.

Just taking the time to notice the thoughts floating in and passing away is very beneficial. It helps to realize that I don’t need to latch onto them and derail my concentration down a rabbit hole of rumination or anxiety about the future.

Even just taking a minute to focus on your breathing can cause a whole raft of negative thoughts to dissipate. The more practiced we get in repelling these rabbit hole chain of thoughts, the easier it is to concentrate on what we want to.

Moreover, by removing mental distractions through mindfulness we can achieve flow state more easily.

Summary

Flow state is a wonderful mental place, but often hard to attain. We give ourselves the best chance to enter it by managing our mental state.

The primary things we need to manage are the external environment and the machinations of the mind. Working remotely is great for managing the external. However, in-office workers can utilize tools such as noise cancelling headphones to approximate this outcome.

Finally, mindfulness is a wonderful tool to help manage our minds.

Simply focusing on your breath for a short time can help cleanse away distracting thought chains. By removing the distractions, our minds are more free to focus on the present moment and thus achieve flow state more readily.

How to Get the Least Out of Your Consultant

by

How to Get the Least Out of Your Consultant

This week we’ll flip the coin and talk about how to get the least out of your consultant. It’s the companion post to last week’s. Knowing what not to do is often even more important than knowing what to do.

What not to do may may seem pretty obvious. You might be surprised. Surprised at the lack of a clear direction, a general unwillingness to change, rampant micromanagement, and an addiction to aimless meetings all readily found in Corporate IT. Or more likely, this will all sound familiar.

No Clear Direction

Few things crush a consultant’s soul worse than having no clear direction at a client. This is a problem that should really be solved for on the front end. In reality however, it’s still common to run into these situations. 

Situations where people are lining up to get a piece of your time and client management has no answer on how to prioritize them. The more common scenario is having a crystal clear direction on paper. Yet being constantly diverted to look at other “small things” that in aggregate form many large unruly things.

It’s just scope creep in disguise. As consultants we know the scope is going to creep organically and it’s not a big deal. It’s just the nature of our business that we’re going to uncover new requirements and invalidate others as we go along.

However, the inorganic scope creep is what creates the real problems. It’s always difficult to walk the fine line between wanting to help and avoiding getting derailed by orthogonal issues.

Unwilling to Change

A strong unwillingness to change usually stems from budget concerns. We can certainly empathize with this as budgets are of course finite. It’s not easy to sell fixing tech debt to non-technical management as adding value to the business. It feels like a net loss and a voluntary one even if the reality is much more nuanced.

However, if we’ve been brought in the client has shown a willingness to change something. The amount of change is usually the sticking point.

Whereas the client may want you to just duct tape on new features to their unmanageable old application, it’s usually better in the long run to pursue a different approach. For example, isolating new development in modern tech outside of the old hairball as a strategy to move away from it over time.

This approach usually results in significant push back. Surprisingly this sometimes comes from the client’s technical leadership who view it as simply adding to their workload by having to manage another environment. It’s an extremely tough sell when client management and technical leadership are resistant to modernizing.

Micromanagement

As a manager there’s a fine line between being engaged and being a little too engaged in a project. You want to make sure all the necessary details are handled, but how do you do it without undermining your people? I’d contend it’s all about minding the levels of abstraction where everyone should be operating.

The most fine-grained abstraction is the technical detail level. This is where your developers and often consultants will be working. While the full anatomy of a project’s levels of abstraction is a post for another day, we can safely say that a manager shouldn’t be interjecting herself at the technical detail level.

When your developers and consultants have to spend time justifying implementation details to management it’s a sure sign the project is in peril. Either the timeline will be crocked or the project itself. Unfortunately this is quite common in the enterprise IT world.

Overmanaging Consultants’ Time

The final piece to the how to get the least out of your consultant puzzle is time management. Consultants generally have to be chameleons. We have to fit into a client’s organization as best we can while avoiding unproductive norms that may be common there. 

Striking the right balance is challenging in and of itself. Doing so while client management fills your schedule makes it almost impossible.

This usually manifests itself as a never-ending cavalcade of meetings. While meetings themselves are certainly capable of being productive, it’s probably the exception and not the rule at most places. 

Also, when a client needs to bring in consultants it’s generally because they’re not able to handle a project with their in-house team. This could be for any number of reasons. Maybe they’re too busy with other projects or have tried the project and been unsuccessful previously.

It makes little sense to force your consultants into a structure that’s proven unsuccessful in the past. The client’s problem may not be that their development team was incapable, rather that they were put in an intractable situation. 

This is a good reason to give your consultants some leeway. Just on the chance that a previous unsuccessful project attempt was the result of environmental deficiencies. 

Corporate “Standup”

And finally we have the corporate “Standup.” It’s in quotes because it bears little resemblance to what the Agile Daily Standup is supposed to be. 

Consultants are often compelled to join the corporate “Standup” meetings at clients. It’s usually just a big time sink to be quite honest. If I’m billing 40 hours a week at a client, I can usually count on about 2-3 hours wasted in this venue.

A much better approach is to allow the consultants and requisite project stakeholders to form their own Standup. I’ve seen better success when a consultant acts as Scrum Master as they tend to stay focused and avoid some of the common pitfalls of the Corporate “Standup.”

Summary

As a manager you probably don’t explicitly think about how to get the least out your consultant. But it’s just as important to know what to avoid as what to do. 

Clients are well advised to give clear priorities and then protect your consultant from being pulled off onto other things. 

An unwillingness to change is another surefire way to hold your organization back and waste a consultant engagement in the process. 

Micromanagement is not only soul-sucking, but also horribly conducive to producing slow, substandard outcomes. 

Finally, the practice of over managing consultants’ time should be avoided. There’s little better way to torpedo your project than to bog down your highly paid consultants in a raft of endless meetings.

How to Get the Most Out of Your Consultant

by

How to Get the Most Out of Your Consultant

Being a manager of software engineers is a tough business. Especially when you need to call in outside help and are forced to wrestle with how to get the most out of your consultant. 

If you’ve been around awhile you’ve likely heard all kinds of stories, some victorious and some disastrous. While you can never guarantee that bringing in a consultant will go perfectly there are things you can do to stack the deck in your favor.

I’m primarily referring here to consultants who are brought in to solve a specific problem or work a project. As opposed to consultants who are brought in as staff augmentation.

Clear Objective

Having a clear objective just makes sense, right? Well, unfortunately too many people struggle to adhere to this simple precept. I’d venture to guess that a great many bad consultant engagements were caused by unclear objectives.

It’s also important for managers to let their team members know what the consultant is brought in to do. This insures that everyone is on the same page. Nothing derails a project quicker than the key stakeholders being unaware of who they should be working with.

Simply put, a host company should define a clear “what” the consultant is there to accomplish. The “how” should be the consultant’s purview.

The host company can of course choose whether or not to implement the consultant’s “how.” Ultimately, being crystal clear with these distinctions up front can save a lot of headaches and failed engagements.

Willing to Implement Change

It’s a story as old as the software industry. Some legacy software is running in Production and has some big problems. Maybe it’s buggy or too slow and is generating a lot of support issues. 

The code has grown too complex so the developers are hesitant to push even the simplest of changes. Regression testing takes weeks and a release takes months. This is usually when consultants are called in to reign in the beast.

The consultants pour over the unruly code base and propose decomposing the massive hairball into more manageable services. This will be a major effort. The host company tends to seize up at this point and kick the can down the road.

It’s understandable though as a large code refactoring seems to offer no immediate business value. It’s the opportunity cost wherein lies the value however. The more tech debt accumulates, the harder it is to adapt to the always changing business climate.

Any company that engages consultants will only benefit maximally if they are willing to implement change. This can be a tough sell up the ladder.

Too often the C-Level personnel fail to appreciate the long-term cost of attempting to stand pat when it comes to software. If you’re not advancing, you’re falling behind in the software world.

Clear the Way

Once you have a clear objective and a mandate to implement change, the next step is easier. Clear the way! 

Consultants generally like to move quickly. So the faster the host company can clear roadblocks the better.

This means having business and technical domain experts available to answer questions promptly. There’s no good reason for your $200/hr consultant to be waiting around for answers on simple business domain questions.

Also, it’s important to give your consultants the freedom to operate. It may feel natural to treat the consultants as part of your host company team and include them in your regular meetings. But I’d contend this is counterproductive. 

Surely the consultants should attend the daily development team Stand up, right? Usually wrong. The consultants should and generally will organize their own Stand up based around their clearly defined project objectives. 

This avoids the Corporate Stand up madness. That’s a post for another day, but if you’ve worked in corporations of any size you likely know what a Corporate Stand up is and why it’s such a disaster.

In short, let the consultants do their thing with a minimum amount of extraneous obligations. Most consultants I’ve found are high performing and self-motivated. You don’t need to worry much that they’re surfing the web all day like some disillusioned FTEs may do.

Summary

How to get the most out of your consultant sounds so simple. The reality is it can be a big challenge. However, if you prioritize the following three points you’ll be ahead of the game.

Have a clear objective that is also well-defined. When consultant and client are clear about what will be delivered, engagements tend to go very well.

Be willing to implement change. This is a hard one, but can be done with good, strong leadership.

Clear the way. At this point your consultants should be off to the races and it’s management’s job to help them move fast.