Remote Java Dev

Remote Java Dev

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.

Two Kinds of Developer Tasks

by

Two Kinds of Developer Tasks

There are two basic kinds of developer tasks. Those that take a linear amount of time to complete and those fall into the nonlinear classification.

The basic difference between the two is how predictable they are or are not. A linear task is one whose time to completion can be reliably predicted. Conversely, a nonlinear task can not be estimated with a high degree of confidence.

Linear

Of the two kinds of developer tasks, linear ones are the least interesting. This is where the drudgery lives. Moreover, we didn’t get into this business because we like going through the motions on solved problems.

Sending emails, attending meetings, writing documentation, and some coding tasks are primarily linear tasks. These are things whose time to completion is highly predictable if not particularly enjoyable. 

To illustrate, if you’re answering an email there is little chance it will take you much longer than you think. Likewise with documentation or simple one-line code fixes. It’s just a matter of spending the time to complete the task. Dragons are highly unlikely to be hiding in these contexts.

Nonlinear

Solving nonlinear problems is where we deliver most of our value. Mapping real world business processes onto a digital medium is extremely challenging. While our tools have improved over the years, business complexity has increased markedly as well.

This increasing complexity has certainly been good for our job prospects as developers. Though it also means our jobs are becoming more difficult on the whole. With the raft of technology changes it means we’re regularly solving novel problems in new contexts. Hence the increasingly nonlinear nature of our work.

This is why estimates are increasingly difficult. As we’re faced with more nonlinear tasks, it’s inherently more difficult to know how long it will take to solve them.

Implications

The implications of this task duality for developers are many. Raise your hand if you’ve ever been pressured to provide an estimate for a nonlinear development effort by a manager or product owner. Everyone, right? It’d be far more surprising if you haven’t experienced this with regularity as a developer.

This very situation leads to the common practice in the IT World of taking a developer’s best estimate and arbitrarily doubling it. It’s done as a means of protecting against the nonlinearity of the request. Human psychology surely plays a big role too as it’s perceived as far better to beat an inflated estimate than miss a tighter one.

The Agile methodology really shines is this area. By insisting on sufficient granularity we can break down many nonlinear tasks into linear ones. It then follows that our ability to accurately estimate improves dramatically and it’s easy to make management happy with more reliable information. This assumes a fully empowered Agile team of course which is not always the case.

Summary

Developer tasks fall into two basic categories, linear and nonlinear. Linear tasks are easy to predict because they simply take time to accomplish. They are procedural. 

Nonlinear tasks on the other hand are likely to contain unknowns. We can’t routinely predict them accurately because the problems may be unknowable until we’re solving them and they are revealed. Simply put, they contain emergent properties.

We as developers implicitly know the difference between these two kinds of tasks. However, non-developers will not always appreciate this and can sometimes conflate the two. 

This leads them to mistakenly believe nonlinear task estimates are wildly inflated. Though usually these estimates are simply an acknowledgement of the dragons that are likely to be hiding ahead.

3 Simple Ways to Differentiate Yourself as a Developer

by

3 Simple Ways to Differentiate Yourself as a Developer

You would think these would be obvious. And in fact they are. You already know 3 simple ways to differentiate yourself as a developer, but you forget sometimes and so do I. Sometimes we just need a reminder. A reminder that the obvious things like these are very important.

If you think back for a moment about coworkers past or present who were an absolute joy to work with. Dollars to doughnuts these coworkers were outstanding in these 3 areas. I’ve certainly found this to be true in my career. 

Is the suspense killing you yet? I didn’t think so. The bold subheadings kind of give away the plot anyway, don’t they.

Take Ownership

One of the best ways to differentiate yourself as a developer is to take ownership. This can be done in many different ways depending on the context. Doing so is incredibly valuable and makes you indispensable to not only your team, but to your company or client as well.

What does it mean to take ownership in this context? Essentially it means taking accountability for the completion of something, whether it be a task, a project, or an application to name just a few examples. 

Granted, this can feel like a risky move. Especially if you’re taking accountability for something that resides outside of your immediate area of expertise. However, it’s important to note that taking ownership of a task doesn’t mean we have to complete it ourselves without assistance!

It’s natural to feel like we want to do everything ourselves. Particularly when we’ve publicly taken ownership of a task. This is where our egos can cause unnecessary pain by trying to heroically solve everything ourselves. Obviously, this is not beneficial to anyone least of all ourselves.

It’s much better to take ownership of a task and then shepherd it to completion. This usually means facilitating collaboration among coworkers to accomplish the task in a more efficient manner. 

For example, imagine a task that would take you two weeks to do completely on your own. Now compare this same task that would take only two days to complete if you enlisted help from others. It’s easy to see which approach is better for your company and yourself. In both scenarios you’ve taken ownership of the task completion, but one approach saves a huge amount of time.

Be Reliable

After we’ve taken ownership it’s equally as important to be reliable. While being reliable can mean many things, in this context it primarily means following through with what we’ve said we will do. We all want to work with reliable people so we too must be reliable ourselves.

Taking ownership and being reliable are two concepts that are very tightly coupled. It bears repeating that it’s much more valuable to reliably shepherd tasks to completion than it is to do everything ourselves.

We should also strive to be reliable in our communications. If we say we’ll send an email to the project team by noon on Monday, then we must do it. Likewise, showing up late to meetings is unacceptable without a good reason. 

If you have Stand-up at 8:30am every day, you can’t often miss it and say “I forgot” and expect to be taken seriously. This is just common sense, yet you’d be amazed at how often I’ve witnessed this level of flakiness in the workplace.

Moreover, your coworkers aren’t likely to confront you over these unreliable acts unless they’re particularly egregious. However, these things tend to add up over time and erode trust in you as a colleague that could be easily avoided. We have an endless number of software tools that will nag and remind us of important events so we might as well use them.

Be Considerate

Of the 3 simple ways to differentiate yourself as a developer, being considerate may be the most routinely ignored one in practice. We all have our own idea of what it means to be considerate in the workplace which complicates matters. It’d be far easier if there were a codified spec so we all could adhere to the same definition of “being considerate.”

However, there are a number of behaviors that most would agree are not considerate. For example, if you’re on a conference call and not talking, put your phone on mute!

I can’t tell you how many times I’ve seen someone not do this when calling in via a cell phone. Said person will have vibrate notifications on so every minute or so the buzzing comes through loud and clear over the bridge. 

Obliviousness is not a good look. You may be a 10x Engineer, but if you leave your vibrate notifications on and don’t mute your line on conference calls, you will look like a turkey to your peers. 

Similarly, just being friendly goes a long way in the workplace. Nobody wants to work with a jerk. It’s so much easier to get things done when we don’t dread having to collaborate with a surly colleague in DevOps.

It’s just human nature that we tend to avoid unpleasant people. The easier we can be to get along with, the easier it will be to work with us.

Trust is crucial. Considerate people are perceived as more trustworthy. Trustworthy people are easy to work with. People who are easy to work with make collaboration easy. Easy collaboration means work gets done better and faster.

Stephen Covey’s Speed of Trust illustrates these concepts well. You may need to overlook the overly corporate packaging of the ideas though to be fair.

Summary

3 simple ways to differentiate yourself as a developer are to take ownership, be reliable, and be considerate. These are fundamental characteristics of any good professional. However, it’s easy to overlook them with the mountains of technical minutiae we deal with as developers.

Consciously incorporating these 3 principles can make us invaluable to our team and our employers. Can you imagine a workplace that wouldn’t highly value someone who takes ownership and is both reliable and considerate?

The good thing is it doesn’t take any innate skill to exhibit these behaviors. Just a conscious acknowledgement of their importance and a commitment to embodying them.

Further Reading

How to Get Hired Without an Inside Connection

by

How to Get Hired Without an Inside Connection

If only there were an easy answer to how to get hired without an inside connection. Most all of us have faced this situation at one time or another during our careers.

While it’s definitely easier to have an in, it’s not a requirement. With some preparation, I believe it’s a hurdle we can overcome and ultimately improve ourselves in the process.

Sales Call

Finding a job is essentially a sales call. But not the sleazy used-car salesman kind of sales. Instead it’s the kind where we have to find out what the prospect(Hiring Manager) needs. And then clearly show and explain why we are the solution.

A manager has a very difficult job when it comes to hiring. Especially when the candidates are unknown to her and her colleagues. It stands to reason that as an unknown quantity to the hiring manager, the bar to getting hired will be higher.

We can certainly understand this predicament. A hiring manager will be judged on how well she hires. And if she consistently hires turkeys, the pock marks will be on her record. 

Moreover, it’s not only critical to impress the hiring manager, but to also be someone the hiring manager can confidently present to her boss for final approval. Primarily we’re selling our skills to the hiring manager and technical lead. However, we also need to keep in mind the ultimate decision maker who may not be present.

Trapdoors

I expect every manager has some version of a trapdoor in her hiring process. A trapdoor being something that candidates might do or say that would instantly disqualify them. Some common ones are badmouthing former employers or overt arrogance. 

Most of these come down to emotional intelligence. In other words, recognizing what’s appropriate behavior in the interview process. It’s of course unwise to regale your interviewer with your drunken exploits on a boat cruise this past weekend.

Given our context here of how to get hired without an inside connection, the numbers of trapdoors we must avoid will be even greater. This includes being likable, knowing when to talk and when to listen, and not boring your interviewer with irrelevant stories and details.

Stock Behavioral Questions

This mostly arises when you’re asked the “tell me about a time” stock behavioral questions. Tell me about a time when you had to deal with a difficult coworker and so on. There are endless resources online for these and given their popularity, it’s time well spent to prepare for the most common ones.

One thing I’d emphasize is to be focused and brisk with your answers. You don’t want to drag this part of an interview out if you can help it. These are mostly trapdoor questions with a bad asymmetric risk profile. Meaning, you can easily fall through a trapdoor and disqualify yourself on these questions, but hardly ever win a job based on good answers.

Bad Online Presence

If you do nothing else when searching for a job, please make sure your social media presence is clean! And by clean I don’t necessarily mean deleted. However, if you have anything that might be embarrassing or controversial, it should be made private.

You may love to talk politics on Twitter or Facebook, though if I’m your hiring manager I’m going to Google your name and look up your social media accounts. The interview process starts before the interview. And if you haven’t taken the time to scrub or lock down your socials before job searching, I’m going to be unimpressed with your attention to detail.

A hiring manager is going to present you to her boss after all. If her boss finds your Twitter account with you ranting like a lunatic about politics, it’s not going to go well for you. Doing such legwork is part of the hiring company’s due diligence. So make it easy on yourself and your new boss by privatizing anything you wouldn’t want out in the open on your socials.

Good Online Presence

Now to the good online presence that can help as much as a bad social media presence can hurt. In truth, having a good online presence is crucial these days and becomes even more so the less the hiring company knows about you. This is especially relevant for those seeking remote roles.

A filled out LinkedIn profile is table stakes in this realm. LinkedIn will probably be the first stop for any prospective employer when encountering your name so it’s worth taking the time to do well. There are plenty of resources available for crafting a good profile, so definitely do some searching if you feel yours could be improved.

Github

Everyone may and should have a filled out LinkedIn profile. A Github presence however can provide a way to differentiate yourself from the pack.

It’s an unfortunate reality that as developers, most or all of our work will be proprietary. Meaning, we can’t very well share all of the brilliant code we’ve written, because it’s been written for a business and we do not own the code.

Our personal Github repositories provide the means for us to publicly share code we’ve written freely. It also helps answer the biggest question an employer is concerned about when hiring a developer, specifically “can this person really code?” There’s no better way to answer this question than having examples of your work available to a hiring company right up front.

This also provides a great opportunity for us to learn new technologies and show our competence in them. It’s just not feasible to wait for our employers to adopt the latest tech stacks before we start learning them. We have to do it on our own and Github serves as our public proof of having done so.

I’d contend this is also a good way to minimize the impact of the less enlightened developer interview mainstays. Specifically, white-board interviews or live coding tests which are far too common these days.

These much maligned practices survive largely due to the absence of clearly better alternatives. If you have some real code in a Github repo to discuss in an interview, you might even avoid these altogether.

Other Good Online Options

There are many additional avenues to create a strong personal brand for yourself online. A personal website or blog is a great option though it requires a bit more work than some of the others. Dev.to is a growing platform that makes it easy to get up and running.

Being active on stackoverflow can also be a great way to establish technical credibility. I’d also recommend Twitter as a great way to connect with the leaders in the developer world. Twitter can be a wonderful place if you focus on the tech world and avoid the cesspool of politics.

Contributing to open source projects seems to be highly regarded as well. I haven’t personally done it, but it’s definitely something that’s on my radar as I believe it could easily open up future opportunities.

Summary

Developing a strategy for how to get hired without an inside connection is important. Most crucially we must make it easy for a hiring manager to choose us for an interview in the first place.

Crafting a professional online presence is a great way to do this. Equally important is to avoid online behaviors that would deter a prospective employer from considering us.

Once we’ve secured an interview we should have strong credibility built from our online presence from which to proceed. This should inspire confidence in our candidacy and allow us to focus on interviewing the company as well as them interviewing us. Additionally, with good preparation we should easily pass the common trapdoor questions.

Ultimately we want to make it easy for a hiring manager to present us to her boss for final approval. The hiring process begins long before we ever submit a job application. Acknowledging this fact can help overcome the disadvantage of not having an inside connection.

SpringOne Tour Minneapolis

by

SpringOne Tour Minneapolis

The hardest part in writing about the SpringOne Tour Minneapolis is filtering out what not to mention. This post would otherwise turn into an unruly eBook. 

In truth, all the speakers did an outstanding job and the two-day conference on the whole was more than worth the $150 I paid. Considering other popular tech conferences in the area charge 2 to 7 times this amount, the SpringOne Tour was an absolute steal. 

One large benefit to attending conferences is to expand our perspective on the tech landscape. I’ve found it’s very easy to get tunnel vision in our world as developers.

Likewise, we get too focused on the tech stack and business domains in which we’re working, ultimately to our detriment. Attending an event such as the SpringOne Tour is a great way to learn what’s on the horizon and what are peers are up to elsewhere.

Reactive

While the Reactive model of programming is not brand new in the Java world, it still seems very much in its infancy in the enterprise space. This is likely to change in my estimation. 

For instance, the rapid transition to microservices architectures seems to warrant a closer look at the reactive programming model. To illustrate, imagine a number of backend microservices that all use blocking I/O calls. It’s easy to see how quickly performance can degrade in this scenario. Especially as more services are added to the application over time.

But, don’t take my word for it. Take it straight from two Pivotal Jedi Masters, Josh Long and Mark Heckler, in this video: Reactive Spring. **Note: this talk was done at a different conference. Both presenters gave separate talks at the SpringOne Tour Minneapolis event and were fantastic!

Pipelines

Another major theme of the presenters centered around the DevOps pipeline space. The transition to microservices has made it a necessity to build robust pipelines to manage complexity. This makes perfect sense as you can imagine what a nightmare it would be to require manual processes to build and deploy hundreds or even thousands of microservices.

Kubernetes has won the container wars by most accounts. Therefore it was not surprising to see multiple conference sessions dedicated to the topic.

The Spring Cloud Kubernetes demo by Ryan Baxter in particular made historically difficult things look incredibly easy. Although I haven’t personally tinkered with this project, it’s definitely one I’m looking forward to testing out in the near future.

Architecture

And finally, It wouldn’t be a proper developer conference without several talks on software architecture. Fortunately, SpringOne Tour Minneapolis delivered with quality in this department. 

In truth, it’s just a very difficult topic to cover well in my opinion. Any good architecture discussion basically boils down to “it depends.” As of course a good architecture all depends on the context in which it’s deployed.

Both Nate Schutta and DeShaun Carter gave very insightful and engaging talks on the big topic of architecture. Striking the right balance between pragmatism and useful heuristics is challenging, but done well by both speakers.

Bonuses

There are a number of bonuses to attending the SpringOne Tour apart from the main talks. The Pivotal Conversations session allowed for easy conversation directly with the presenters, all of whom were very approachable. 

Except for Josh Long, whose Intellij’s Nyan Progress Bar nyan progress barmade him seem intimidating. Totally kidding, Josh is very friendly and watching him give a live demo is performance art from a master.

We also had plenty of opportunities to chat with the presenters and other attendees. Whether over breaks or during the Monday evening networking and social hours, it was easy to talk tech with some of the leaders in our field.

All in all the SpringOne Tour’s price to value ratio was exceptional.

Additional Content

Presenters' Twitter