Remote Java Dev

Remote Java Dev

The In-Office Developer’s Biggest Curse

by

The In-Office Developer's Biggest Curse

“Hey Peter…what’s happening?”

The in-office developer’s biggest curse is what’s happening. The thing torpedoes developer productivity. The thing that causes missed deadlines.

I call it the “drop-in.” The act of someone stopping by your in-office desk, uninvited, while you are working. Immortalized in the film, Office Space, the drop-in has been the bane of the in-office developer’s existence for far too long.

Endemic to In-Office Life

The drop-in is endemic to in-office life. For many years, in-office work has been the default so some of its lesser “features” have just been accepted. The rise of remote work is changing this.

Now we have a legitimate alternative to in-office work and its many drawbacks. Software development just happens to be an occupation where remote work not only makes sense, but I’d contend is usually more optimal than being in-office. 

Ours is knowledge work and as such we need to think deeply on a regular basis. Constructing mental models and reasoning about the complex systems we deal with requires extreme levels of concentration. 

We can do this far better when we’re in control of our working environment. And we’re far more in control of our work environment when we work remotely. 

Working in-office inevitably subjects us to more distractions, drop-ins being chief among them. While it’s nice to see and chat with our coworkers, ultimately our work can usually be done more effectively remotely.

Concentration Killer

If you agree with last week’s post about the detriments of task switching this will come as no surprise. Any time someone drops by your desk with a request, it’s going to break your concentration. Along with causing your mind to switch focus from the task at hand to whatever the requester wants to talk about.

Flow state is hard enough to achieve. Trying to do so with a parade of people stopping by to chat can make it downright impossible. 

Noise-cancelling headphones can block out some of the environmental din. However, they are no match for a drop-in towards whom you are obligated to divert your attention. The inevitable loss in concentration leads to a decline in productivity.

Productivity Decline

Tasks that should take 2 hours start to take 4 or more with the constant interruptions. Sprints deliver fewer features and bug fixes. The knock-on effects of this kind of environment permeate the entire development team’s productivity.

A team where drop-ins are the norm can also be incredibly demotivating. We developers tend to hate inefficiencies. And while we may genuinely like and respect our coworkers, it’s hard to avoid frustration. Especially when we’re trying to solve a difficult problem and get interrupted 5 different times in the span of an hour.

It often feels like we’re trying to do our jobs well and being actively prevented from doing so. You can’t prioritize your time when anyone can stop by and derail you onto some other task. 

While you could always tell them “no, I’m busy” that’s fraught with its own perils. You risk becoming a pariah and creating a toxic relationship with coworkers. Few would consider this a better approach.

Ultimately, you’re kind of stuck. You either indulge the in-office developer’s biggest curse, the drop-ins, and watch your productivity tank. Or you tell the drop-ins to bugger off and get your work done, but end up being the office jerk. In short, you have two ways to lose and no way to win.

Summary

The in-office developer’s biggest curse is the drop-in. At least it is for any developer who wants to get her work done effectively and efficiently.

It’s inevitable you will experience drop-ins while working in-office. They are endemic to the nature of in-office work. 

Our work requires us to concentrate deeply. The breaks in concentration caused by persistent interruptions, i.e. drop-ins, cause inevitable declines in productivity. 

No good developer enjoys being actively prevented from being productive. Yet this happens routinely to in-office developers and it’s just accepted because it’s been the default. Thankfully, we now have a better option in remote work to solve some of these long standing problems.

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.

SpaceX Starlink is Full Speed Ahead

by

SpaceX Starlink is Full Speed Ahead

SpaceX Starlink is charging full speed ahead in the race to offer high speed internet from above. While the number of Low Earth Orbit(LEO) Satellite Internet contenders has grown over recent times, SpaceX looks well positioned to win the race to viability.

SpaceX’s Primary Advantage

SpaceX has a huge advantage with its satellite deployment capabilities. No other LEO Sat contender currently has the ability to launch their payloads on their own rockets. And for this reason it was always going to be extremely difficult to beat Elon Musk’s team to the first viable deployment. 

Simply put, SpaceX can iterate much more quickly than the competition. The only major obstacles in their way are funding and regulatory approvals. Neither of which have significantly hindered them to this point. 

The other contenders also have these obstacles to overcome, of course. But they do not have the in-house satellite delivery systems at their disposal.

30,000 More Satellites

SpaceX has filed paperwork to add 30,000 more satellites to its LEO Starlink constellation. This is in addition to the 12,000 already approved by the Federal Communications Commission(FCC).

It remains to be seen if SpaceX will be granted approval for the full 30,000. It is however encouraging that SpaceX Starlink is bolting full speed ahead.  It’s likely there will be regulatory challenges given the scale SpaceX is targeting.

It’s going to be very interesting how the FCC and the International Telecommunication Union(ITU) resolve the competition for spectrum and satellite approvals in the coming years. Especially with other contenders such as OneWeb, TeleSat, Facebook’s Athena, and Amazon’s Project Kuiper all jockeying for space in this arena.

60 More Starlink Satellites Deployed

Roughly one week ago, November 11th, SpaceX successfully launched 60 more satellites. This is the second deployment and was launched aboard a Falcon 9 rocket.

If all goes according to plan, we should see launches occurring with increasing frequency in the coming months. SpaceX Starlink is targeting an initial constellation of 400 to offer minor broadband coverage and 800 for more moderate coverage.

Some 12,000 to 40,000 satellites are in the long range plans. This presumably would be a full deployment and offer the ability to cover the globe with broadband connectivity.

Service Starting in 2020?

SpaceX Starlink is full speed ahead on offering broadband service in mid-2020 according to company President and COO, Gwynne Shotwell. This will require 6 to 8 launches of operational satellites, of the type just launched one week ago(Nov. 11). 

There are significant challenges to meet this target however. The user terminals have yet to be fully baked and could certainly introduce delays in the ambitious mid-2020 time frame.

On a positive note though, the user terminals do not have to be launched into orbit. So it should certainly make for quicker iterations towards a robust design that works well.

It would be remarkable if SpaceX can offer broadband service to the general public, even if small in scale, in 2020. Though I would be surprised if we see this by the mid-2020 target timeframe.

But then again it’s hard to bet against Elon Musk and company given all they’ve accomplished.

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.