Remote Java Dev

Remote Java Dev

General

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.

My Tech Journey from the Mainframe to the Cloud

by

My Tech Journey from the Mainframe to the Cloud

My tech journey from the mainframe to the cloud has been an interesting one. I certainly expected I’d be working in Java fresh out of college, though it was surprising how I got there. Specifically, by taking a brief detour to the land of the mainframe. 

While unexpected, it was a great introduction to the enterprise and the sheer enormity business domain could be. Ultimately it proved beneficial as a much needed reality check for the career I was embarking upon.

The Mainframe

My tech journey from the mainframe to the cloud began with wrangling COBOL for a large insurance company. There’s nothing quite like your first S0C7 and receiving a 500 page print out of the abend the next day. 

The tech was your standard mainframe fare of COBOL, JCL, DB2, IMS, and Casegen. The sheer size of some of the COBOL programs was incredible! It was common to see hundreds of thousands of lines of code in a single program. 

It was a far cry from implementing a bubble sort in Java 1 in college. The ISPF editor is still probably my favorite I’ve ever worked with, sorry vi.

Enterprise Java, Pre-Frameworks

After a quick couple years on the mainframe I started my enterprise Java career. They were simpler times. So simple in fact that we used little more than the raw JDK!

Struts had just come out, but that was a little too unproven for a cautious insurance company. And so we wrote all our Servlets, JSPs, and JDBC calls the hard way. 

The real fun began with the IBM tool suite as things were a bit less ergonomic in those days. The main culprits were WebSphere, VisualAge for Java, and Rational ClearCase. 

I still have no idea how ClearCase works(or didn’t work) and moreover how it passed itself off as a VCS for as long as it did. It was a valiant effort in the early days at least.

EJB World

I feel like I should have to write a pointless interface before beginning this section. The transition to the EJB paradigm was the beginning of the modern era of Java development in my mind. The era in which framework choices are one of the biggest decisions in an application’s life cycle.

Mercifully I had little exposure to pre-EJB 3.0 code bases. That is aside from cruft left over from EJB 2 to 3 porting efforts. If you can get past the boilerplate with EJBs, it wasn’t a terrible approach for the monolith world.

Humans cannot live by EJB alone though. JSF to the rescue! Err…in hindsight I should have waited for a different rescuer. JavaServer Faces was interesting to work with, I’ll say that much. It made some things work pretty easily and obfuscated many many other things. 

JBoss Seam was another common framework to be found in the EJB/JSF ecosystem. Seam wove together the two unruly beasts into a monster beast! Though a more manageable beast than EJB and JSF would have been without it to be fair.

Spring World

The transition from the EJB world to Spring was pretty easy. I guess when you’re used to rubbing two sticks together to make fire, switching to matches is trivial.

The Spring MVC and Spring Data projects in particular were revelations. The simplicity in which we can accomplish things in the Spring ecosystem still amazes me. It’s easy to see why Spring has taken over enterprise Java and is leading the way towards the next revolution.

Cloud Native Java

Finally, my tech journey from the mainframe to the cloud brings us here. I’m still very much on the learning path when it comes to cloud native Java development. However, it’s been by far the most interesting and fun path on my long and winding road.

The enterprise market’s move to cloud native development is still a work in progress. At its core is the shift away from the monolith and towards a microservices architecture. A primary reason for this being to take advantage of the elastic scaling offered by the major cloud providers.

Working with Spring Boot and Spring Cloud have been the latest epiphanies spearheaded by Pivotal and the numerous Spring teams. The ease in which we can create new Spring Boot apps with sensible defaults via Spring Initializer is extraordinary! 

It’s now entirely doable to stand up a functional API in a matter of minutes or hours. Compare that with trying to accomplish the same via JavaEE or an EJB/JSF app and it’s really no contest. Even if you’re not creating microservices, the Spring Boot project offers an immense improvement in developer experience.

Add in the docker containerization piece and it’s very easy to create applications ready for a cloud native deployment. As a developer it’s become extremely accessible to build microservices with Spring Boot, throw them in docker containers, and have them ready for a PaaS.

It will be interesting to see how broadly the enterprise shifts to cloud native development in the coming years. Will the majority of applications be moved away from monoliths? Will the microservices approach be reeled back in to a certain set of use cases? We’ll all have to stay tuned to find out.

The Consultant Disadvantage

by

The Consultant Disadvantage

If you read last week’s post, you might think it’s all sunshine and lollipops in consultant land. As you surely know, that’s not exactly true. The consultant disadvantage is a real thing and is full of challenges too.

In truth, most of the advantages and disadvantages of being a consultant come down to personal preference. So even though these characteristics are being tagged as disadvantages, they could just as easily be considered advantages depending on the person. Some people will love it and some people will hate it.

Small Margin of Error

Do you remember the guy who walked across those skyscrapers on a tightrope?  Not that guy, the other guy, Nik Wallenda. Phillipe Petit of WTC fame was the first guy. That’s kind of what it feels like to be a consultant at times.

Like the tightrope walkers, there’s no safety net for us. We have to make things work and do so quickly. Clients aren’t going to give you 3 months to learn their system. Nor their beautiful mosaic of a tech stack featuring outdated technologies from each of the past 4 decades.

You might have to integrate with a 15 year old SOAP service with a malformed schema that no modern library can handle. Just make it work, Consultant! Aye aye, captain! Sometimes you just have to ask WWMD.  What Would MacGyver Do?

You’re an Other

There’s a distinction between you as a consultant and a full time employee. It’s usually subtle in our day to day work lives. I’ve noticed it mostly rears its beastly head in times of stress. 

For example, upper management at the client starts pressuring the client project owner on timeline or deliverables. Next thing you know the project owner who was totally with you “as a team” on the project turns into a drill sergeant even if you’ve been delivering like a rock star. 

 It’s times like those that you know where you really stand. As a consultant, it’s easier to bring you on board and it’s easier to push you overboard. Your existence within the context of a client company is transient. Most people at the client will be great to you. In times of stress though, it’s easier to blame the short-timer.

Constant Change

This brings us to the related topic of constant change. While change is not always a bad thing, the amount of change consultants deal with can be a disadvantage.

As humans, uncertainty causes us stress. As consultant humans we’re forced to become more resistant to this added stress. We become stronger because of it, but it’s still a challenge to manage from a mental standpoint. 

I’ve found it’s difficult as a consultant to accept that I can’t become a comprehensive business domain expert at a client. Especially when working at large corporations whose vast business domain is beyond even internal employees’ full understanding. 

We just have to accept that we’ll need to focus on a specific slice of a business domain that our project covers. We simply don’t have time to learn the ins and outs of the whole business. It’s far more important that we learn what we need to know quickly and then expand as needed.

An added challenge is sometimes business domain experts may not even be available at the client. It’s not unheard of to find situations where the only discrete business rules are found in code, whose authors left the company long ago. Digging through code for answers to business questions is extremely common.

We as consultants also live an uncertain existence within the context of a client. As mentioned earlier it’s easier for a client to get rid of a consultant compared to an internal employee. 

It’s also common to not know what your end date at a client will be. We’ll often be extended at a client any number of times. It’s usually fine, but definitely adds additional uncertainty into our lives which can be a disadvantage.

More Challenging

Generally speaking, clients with their own IT teams don’t bring in consultants to work on easy projects. Unless you have a very specific technical niche, you as a consultant will be working on projects that are failing, have failed, or are beyond the internal IT team’s capabilities.

Coming on to a project that an internal IT team has failed to deliver can be especially challenging. Not only due to the technical challenges of a project, but the IT team may also resent you being there. 

A similar resentment often results if client management went straight to consultants for a project instead of giving the IT team a chance to deliver it first. In short, the politics of consulting can be very challenging. 

Likewise, technical challenges are abundant as well. You may have great ideas to fix technical deficiencies in the code base, but if the client’s tech lead stubbornly resists them you may just have to let it be. Sometimes it’s better to just lose a few battles so you can win the war of delivering the project successfully.

Summary

Like everything in life there are trade offs. As such, the consultant disadvantage is comprised of several factors. A small margin for error, constant change, being an other, and more challenging projects are prominent ones.

Ultimately it’s up to you whether or not this kind of existence is appealing. Some developers enjoy and thrive in this kind of environment. Some might not even consider these things disadvantages at all. But make no mistake they do make things more difficult, even if we enjoy the added difficulty.

The Consultant Advantage

by

The Consultant Advantage

All other things being equal, a consultant usually has a big advantage when it comes to delivering a project. And it’s not necessarily because consultants are better developers than in-house developers.

I’d contend it’s mostly because the context in which a consultant operates is different and more favorable to successful outcomes.

Outsiders

When speaking of consultants here, I’m specifically talking about outsiders to the client who are brought in to work on a project. This feature of consultants provides immediate advantages.

Chief among them being outside of internal client politics and not connected to any previous unsuccessful attempts at completing a given project. Though it is extremely important for consultants to be empathetic to all at the client.

It’s also much easier for a consultant to give an unvarnished opinion. Whereas an internal developer might understandably hesitate to give the same blunt opinion to all but the most progressive of management. In short, often things just resonate more when coming from an external source.

Consultants also have the advantage of bringing a fresh pair of eyes to a problem. Being too close to a problem for too long can make it harder to solve.

It’s only natural for people’s minds to focus on one approach and miss much better alternatives. A consultant analyzing a problem from scratch often leads to our next big benefit, clarity.

Clarity

Simply engaging consultants about a company’s problem can bring great clarity. The act of defining exactly what the problem is and answering questions from consultants about it often reveals a good solution. This is very much the same principle as Rubber Duck Debugging which will be familiar to many here.

Likewise the process of project definition will bring clarity to how much a solution will cost. Seeing the actual numbers of hours plus bill rates or project dollar amount in a written proposal has a way of clarifying how important a problem is to a company. Put simply, it stamps a tangible dollar amount on a given problem.

It’s also not unheard of for management to be hesitant to accept their internal staff’s time estimates to fix a vexing problem. An external consultant coming in and giving the same time estimate tends to be taken more seriously. This can also serve to validate an internal assessment’s veracity to management which can be useful for particularly expensive problems.

Focus

Once consultants are retained to fix a problem they have the luxury of focusing completely on it. Contrast this with internal staff who will often be pulled in different directions supporting other systems. It’s much easier for an outside consultant to avoid the distractions an internal developer has to juggle.

Another component of focus that benefits the consultant is having a specific project scope and deliverables. Again, our internal counterparts are less likely to have focused project deliverables laid out in advance. The premium an external consultant demands however, makes it imperative for the client and the consultancy to have clearly defined KPIs. 

This focus on deliverables also serves to prevent Feature Creep. Quite simply, it’s a lot easier to pile on feature requests to internal developers than it is to consultants. In the latter case, non-trivial feature additions will require a scope change process and be duly estimated in time and dollars. This tends to filter out the busybody requests as the price tag will be evident up front.

Motivation

The consultant advantage definitely extends to the realm of motivation too. The consultancy and the client will naturally be motivated to complete the project successfully so their incentives are appropriately aligned. This is highly important.

However, the real differentiating advantage for a consultant over an internal developer comes from the client’s motivation to clear obstacles. No client management wants a $200/hr consultant waiting around for an answer from surly Bob the IT guy. 

As a highly paid consultant, you get answers to your questions and fast! It’s ultimately good for the client as well. The higher cost of a consultant’s time can motivate internal management to do what needs to be done to see the project succeed.

Summary

The consultant advantage takes many forms. As an outsider we have more freedom to diagnose root problems and propose robust solutions. The mere act of diagnosing a problem as an outsider can bring much needed clarity. 

Once engaged, consultants are able to focus completely on a given project. The absence of ancillary duties at a client is a further benefit that internal employees often aren’t afforded. 

Finally, consultants are motivated for the project to succeed. Though the more important thing is client management are highly motivated for the consultants to succeed. They will clear obstacles quickly to keep the project progressing often much more so than if internal staff were performing the same duties.