Remote Java Dev

Remote Java Dev

General

Multitask to Spike Productivity…Right Into the Ground

by

Multitask to Spike Productivity...Right Into the Ground

It feels like only yesterday when everyone was expected to be a great multitasker! Most have since come to realize that we only multitask to spike productivity…right into the ground. The mythical benefits of multitasking however, live on in the enterprise to a large degree.

I think it’s safe to say developers hate wasting time and effort. Our major value proposition after all is to automate, i.e. prevent waste and create efficiencies. So it’s not surprising that developers would be largely opposed to multitasking as it creates serious inefficiencies.

The Cost of Task Switching

Task switching is fundamentally hard on the human mind. Trying to hold a massive business domain model in working memory is difficult enough, much less doing so and then switching to an unrelated task and then back again. Horribly inefficient.

This is a surefire way to spike productivity…right into the ground, of course. Yet this is often the life of enterprise developers. They’re expected to be a jack of all trades type handling support, maintenance, and new development on a variety of systems.

The end result is usually all areas of responsibility suffering. It’s inevitable due to the required task switching inherent in the position. This ultimately suggests it’s a management issue and to be fair, some companies avoid this practice to their credit.

We’re Agile Though

Theoretically the Agile methodology should prevent this kind of inefficient task switching. Anyone who’s worked in the enterprise however, knows too well that “Agile” is often just a buzzword in this context. 

Enterprises tend to faithfully have all the meetings. Yet when it comes to the fundamental principles like self-organizing teams, they take a back seat to other things. The most pernicious of which is not allowing developers to focus on tasks in a serial manner. Thus the task switching malaise.

In short, Agile should prevent this, but does not because most enterprises are not really practicing Agile. They tend to dress up their own bureaucracy in Agile clothing so the methodology provides no protective barrier as it would if it were faithfully adhered to.

The Biggest Problem

The biggest problem I’ve witnessed is that developers are seldom empowered to control their own time. Enterprise developers are not easily able to decline superfluous meetings. Nor are they allowed to resist external pressures such as competing support personnel vying for them to fix separate issues.

This lands our developer square in the middle of the task switching conundrum. She can’t focus on developing a new feature without being pulled off into meetings or support tickets throughout her day. Management then puzzles over why their sprints take 8 weeks and hardly anything gets delivered.

To be fair to management, budgets are understandably limited. Most companies can’t or won’t pay for separate developers to do support, maintenance, and new development. Even in these common situations though, there are things management can do to help mitigate problems.

What’s Better

First and foremost, developers should be largely in charge of their own time. Management should certainly set the high level priorities, and then developers should be empowered to accomplish their tasks how they work best.

It ultimately comes down to valuing your developers’ time and trusting them to get their jobs done. This certainly requires a level of trust from management, but if you need to babysit your developers you’ve got a bigger problem than task management.

It’s crucial that management is not only on board with this approach, but actively works to protect their development teams from outside pressures. For example, there should be a clearly defined process for reporting and prioritizing development tasks, whether support or otherwise. 

This is necessary to prevent the common practice of people going straight to a developer and putting implicit pressure on her to drop what she’s doing and fix an issue. Management can prioritize all they want, but if they don’t actively prevent this it’s going to force your devs to multitask and spike productivity…right into the ground.

Summary

Task switching is cognitively very difficult. It’s also inefficient and most would agree should be avoided when possible.

The Agile methodology should prevent much of the multitasking problem. However, Agile’s core principles are often ignored in practice in the enterprise. Most “Agile” teams in the enterprise exist within a strict hierarchy and there is scant evidence of self-organization.

The biggest problem of developer productivity can often be caused by one thing. When developers are not in control of their own time, they will be forced to multitask.

Ideally, developers will be empowered to accomplish their work how they see fit. Management should also protect their development teams from those who might try to end run around the work intake process. This is a guaranteed way to multitask to spike productivity right into the ground.

Java is Still King

by

Java is Still King

It’s remarkable that Java is still king in 2019. It’s been roughly 20 years now and the language we mostly love is clearly not going anywhere. 

We’re certainly in the midst of a great transformation in enterprise software right now. And the Java ecosystem continues to evolve and embrace the changing landscape thus ensuring its continued viability. I’m referring to the transition to Cloud Native architectures that take advantage of the robust cloud computing platforms.

The TIOBE Index

The TIOBE Index will likely be familiar to many. Its primary purpose is to track the popularity of programming languages. Their methodology is listed in detail here: TIOBE Programming Community Index Definition.

Java once again retains its spot atop the leader board in November 2019. Java’s precursor, the C programming language, is as usual nipping at Java’s heels. In fact Java and C have occupied the top two spots in the Index for the vast majority of its existence.

It comes as no surprise that Java is still king to anyone who’s worked in enterprise software. The TIOBE Index just confirms what we already knew. It is however reassuring to have metrics like this to verify that our main programming language will be in high demand for the foreseeable future.

Java’s singular dominance has come and gone over the years. It would not be surprising if Python were to eventually challenge Java for the top spot. Though the continuing evolution of the Java space reassures us that we likely won’t see a dramatic plunge in popularity for a long, long time.

Java’s Evolution

Java has evolved significantly over the past 20+ years. So much so that if we unfroze a cave woman Java programmer from 1996, she’d be agog at the current incarnation of Java. 

We can imagine her being highly confused about the magic of annotations or the barking IDEs when she attempted to use raw types. She may well just club the computer to smithereens in frustration.

Some of the most notable changes in Java include version 1.1 giving us inner classes. The Java 5 update delivered annotations, generics, and for-each loops. Java 8 offered us streams and lambda expressions.

There have been countless other improvements and features added along the way. The sheer enormity of the Java community has been invaluable in continuing to keep the language strong and viable. Both of which are critical when it comes to choosing a technology to deploy in the enterprise where missteps can be very costly.

The Frameworks

It’s hard to imagine Java becoming so popular without our favorite frameworks. Whether Spring, Hibernate, or one of the countless Apache Foundation projects, we stand on the shoulders of giants when we write Java code for the enterprise in 2019.

The latest disruption to our industry is the transition to Cloud Native development. By this point, most of us will have implemented this new paradigm or at least started learning it. And how are we building 12 Factor Apps? Using frameworks, of course.

The Spring ecosystem and Spring Boot in particular are dominating the enterprise implementations of the Cloud Native paradigm. At least this is what I’m seeing both locally here in the Twin Cities in addition to my extended network at major corporations throughout the US and worldwide.

Likewise, there are other frameworks in this space such as Micronaut and Quarkus that are worth keeping an eye on as well. You don’t even need the absurd 10 Years of Quarkus experience to do so either.

In short, we have a vast number of production grade frameworks available to us as Java aficionados. And the numbers and quality of the frameworks are only increasing and improving. This is another big reason why Java is still king and is likely to remain so for some time.

Summary

Java has dominated the TIOBE Index for most of the last 20 years. This popularity has been especially salient in the enterprise software world.

Java has continued to evolve since JDK 1.0 was released in 1996. While this evolution has been occasionally disruptive, it’s ultimately made the language and platform more robust.

This is proven out by the fact that enterprise customers continue to confidently deploy large numbers of new applications written in Java.

Java’s rise has been well supported by a large number of frameworks. These frameworks have provided the scaffolding for Java’s widespread adoption. Many have done this by baking in enterprise patterns and making it much easier for developers to solve common problems.

Reentering the Workforce as a Developer

by

Reentering the Workforce as a Developer

It’s a scary time when you’re on the outside trying to get back in. Reentering the workforce as a developer can definitely feel overwhelming. However, many have navigated these rough waters and there are things we can do to increase the chances of success.

I do have a bit of experience in this department. Personally, I spent way too much time doing the wrong thing before I finally stopped beating my head against a wall. I changed my job search strategy and it was key to ending my extended involuntary sabbatical. 

I like to think of the approaches to job searching in terms of passive vs active. If you’re currently reentering the workforce as a developer it is much more critical to skew towards an active job search. What makes a job search “active?”

Active Job Search

The most critical element of an active search is having a public component. Meaning, some of what you’re doing is publicly available and easily verifiable. Some good examples of this are having an active Github account, contributing to open source, or volunteering.

In these examples you are demonstrating initiative and taking accountability. I suspect most hiring managers would greatly prefer to have more people like this on their teams. 

Fortunately, it has never been easier to run an active job search as a developer. You don’t need anybody’s permission to show what you can do.  

Imagine you were an HR Generalist and were trying to get back into the workforce. How would you publicly demonstrate what you can do? Aside from sparse volunteer opportunities, your options would be extremely limited.

Now in our case as a developer, you don’t need anybody’s permission. You can create a Github account and repository in minutes.

Then bounce over to https://start.spring.io/ and create a project in another minute. Commit and push and there you go! You’ve already started a public resume adjunct in less time than it takes to fill out a job application.

Connect

Connecting with 500 recruiters on LinkedIn might feel like you’re doing something productive. However, I’d recommend prioritizing deeper connections which I’ve covered here in more detail: Managing Career Risk as a Remote Developer.

Becoming active in your local tech community is far more likely to yield opportunities. If you live near any major metropolitan area there are bound to be many user groups. Just click on over to https://www.meetup.com/ and search for your area and tech and voila!  

You don’t need to be an expert to show up and learn. The vast majority of developers don’t show up. By simply showing up you are increasing the surface area for opportunity to find you.

Why Does it Matter?

You may wonder why this stuff matters. It matters because we have to overcome the gap on your resume. And one way to accomplish this is by doing things that most developers don’t do.

The average corporate developer does not have an active Github account. He doesn’t contribute to open source, work on volunteer projects, or come to meetups. He does his work and goes home and does other things. 

The average developer can get away with this because he has a job. If we’ve been out of the workforce for awhile, we can’t afford to appear average. 

We must be mindful that a hiring manager will have to sell you to her boss for approval. The hiring manager needs a compelling story to tell her boss about why your resume gap doesn’t matter. Make this easy for her and your chances of a job offer improve dramatically.

What Most People Do

They do a passive job search. They scour the internet for job postings and apply through the company websites, never to be heard from again. 

Then they spend a lot of time studying and running through tutorials. These feel an awful lot like work so they must be helpful, right? Not particularly. The main problem is that nobody knows how many hours you’ve poured into these activities.

Where on your resume are you going to put that you spent 100 hours reading about Reactive programming in the past two weeks? Or that you did 5 tutorials on implementing the Netflix microservices stack?

Getting a job takes more than answering tech trivia questions. Don’t fall into this trap! The trap of thinking that studying in and of itself will get you a job.

Knowing more certainly can’t hurt, but you’re wasting your time if you’re doing this instead of much more productive activities. Like creating public examples of your code or connecting at a meetup. 

Studying is an accessory activity to a job search, not a primary one.

My Story

I left my corporate Java Developer job back in 2005 to join the Peace Corps. I completed my service in 2007 and continued mostly living abroad until early 2009 when I arrived back in Minnesota. The financial meltdown was in full swing and almost nobody was hiring. 

So what did I do? If you look up at the “What Most People Do” section…that’s what I did. As you can guess, it didn’t go well for me. 

I studied and studied and filled out countless job applications for what few jobs were available. I managed to get a couple scattered interviews that went alright, but not well enough to get a job offer.

Volunteer Project

After about 8 months of this I finally stopped banging my head against the wall and did something different. I started a volunteer project. I had been tinkering around with Perl for several months and decided to actually build something with it. 

Over the next few months I built my volunteer project to help an organization back in Tonga, where I served as a Peace Corps Volunteer. Maybe it was all a coincidence, but shortly after putting this on my resume I started getting responses to my job applications. Soon thereafter I had two job offers and a third was likely on the way. 

I don’t think it was simply having a current volunteer project on my resume that made the whole difference. It likely helped get me interviews, but having a current project to talk about in the interview was hugely beneficial. 

It’s very useful to be able to tell a story about how you initiated a project. Likewise, how you solved some interesting problems along the way. Moreover, I think hiring managers just like to see that you are doing something proactively. 

In retrospect I wish I would have started my volunteer project far sooner than I did. Some lessons take a little pain in order to really stick though unfortunately. I hope you will all be much smarter than I was and avoid the unnecessary pain.

Summary

Reentering the workforce as a developer is always hard. Yet in some ways it’s never been easier. 

Conducting an active job search requires doing work that is publicly available and verifiable. Popular ways of doing this are through Github, open source, and volunteer projects. 

This is a permissionless way of showing your skill as a developer and your willingness to take initiative and accountability.

In contrast, conducting a passive job search is not smart and not recommended. Filling out countless job applications and studying only is an inferior strategy.

Seek out local tech user groups and meetups for opportunities to learn and connect. 

In order to overcome a resume gap it’s important to stand out in other areas. These extras, Github/open source/volunteer projects, will help you get a job more quickly in the short run and in the long run can open up many more opportunities.

The 40 Hour Work Week

by

The 40 Hour Work Week

The 40 hour work week is an odd thing for a developer or any knowledge worker for that matter. Even the simple question of “when are you working?” is not easy to answer. When the output of our labor is not mechanistic, it’s very hard to quantify what value we provide and how we are performing it.

Since our work is very hard to quantify, management needed a different way to evaluate it. They settled mostly on a location-dependent attendance model augmented by their intuitions. It’s easy to see why a few problems might arise using this approach. This is one big reason the shift towards remote work has the potential to make a huge difference in productivity and job satisfaction.

When Are You Working?

Is it when you’re sitting in your office in front of your computer? What if your mind drifts off for 10 minutes to a relative who has health problems, does that count as work? You are sitting in the office chair in front of the computer after all. 

How about when you take your evening walk around your home neighborhood and you spend 30 minutes thinking about how to solve a problem for work. Does that count as part of your 40 hour work week? 

These are silly examples. Silly because they highlight the absurdity of how our work is tracked and ostensibly how we are paid as knowledge workers. In truth nobody tracks every minute of the day that they worked or thought about work. 

It’s the fundamental difference between knowledge work and mechanistic work. Non-linear work vs linear work, in other words.

The Shift to Remote Work

Transitioning from in-office work to remote work is more than just changing the physical location of work. It tends to shift the primary evaluation of a worker from attendance based to output based.

When you’re working in the same physical location as all your coworkers, it’s too easy for cognitive biases to overwhelm everything else. 

For example, John is socially awkward and has bad BO. He also has some health problems, so he’s not able to sit in his office chair for 40 hours a week. But his coding is bulletproof and he completes stories with amazing efficiency. Yet he’s still likely to be treated by management as a “difficult employee.”

Todd on the other hand is always impeccably groomed and easy to talk to. He’s always in his office chair for the whole 40 hour work week yet his output is poor. In the in-office world, Todd is more likely to get promoted.

Remote work gives us a better, while not complete, solution to this problem. In a fully remote company, John is far more likely to be correctly recognized as a high performer. While Todd will not be unduly elevated merely by having good attendance and grooming habits.

Managing a remote development team also becomes easier to evaluate. In short, it’s easier to recognize whose output is high and whose needs improvement. This is achieved by removing an impediment, i.e. the cognitive biases as shown in the John and Todd examples.

To wit, this is the Via Negativa principle in action. Nassim Nicholas Taleb covers this at length in Antifragile.

The Future

It’s always perilous attempting to predict the future. But what the heck, let’s have a go! 

I believe the 40 hour work week will continue to wane in importance. Particularly as more development teams go fully remote. Removing the butts-in-the-seats imperative of in-office work will free up workers and management to focus on more important things like output.

I don’t expect the compensation model to change, at least not imminently. The 40 hours times an hourly rate seems too ingrained in the enterprise world. 

Using an output based model we can more accurately determine who is adding more value to the team. However, that’s still a far cry from being able to translate output to value added to the company. This is a much more difficult problem that I don’t anticipate will be solved any time soon.

Summary

The 40 hour work week is not well suited to knowledge work. It largely endures due to inertia.

Quantifying what counts as work for developers is very difficult. We are not simply making widgets, therefore counting hours to task completion is rife with ambiguity. Our tasks vary widely in both complexity and value addition.

Shifting to a remote work model has the potential to improve this situation by focusing more on developer output. This can help mitigate human cognitive biases which are inescapable in co-located work environments.

The future of the 40 hour work week may diminish in importance for developers. This is assuming the shift towards remote work continues to accelerate. Both would be welcome changes for us knowledge workers.

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.