Remote Java Dev

Remote Java Dev

General

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

10 Years of Quarkus Required

by

10 Years of Quarkus Required

The average developer job description is absurd. “10 years of Quarkus required” and other such things are easy to find. Given Quarkus has only been around for a fraction of 10 years doesn’t matter. It is “required!”

While this example is a little extreme, it’s easy enough to believe isn’t it? I imagine you’ve seen all sorts of similarly comical tech requirements congealed together in one big hash of a job posting. It’s the first real test of candidate screening in my opinion.

Your First Test

Your first test is to wade through this morass of a job posting and deduce what they really want. Sure they’ve got everything from COBOL to SmallTalk to GoLang in there, but can you pick out the fact that they really someone to rewrite their SOA monstrosity?

This is one area where larger companies are especially egregious. It must be a law that the more hands a job description passes through the more likely it is to approach an Absurdity Maximum. This gives away that a Tech Lead, an Architect, a Manager, a Director, and HR all pitch in to make the job description goulash.

I’ve found smaller tech shops generally make a better attempt at reasonable descriptions. It makes sense too. A bad hire on a small team is much more impactful than a bad hire in a company of thousands. The blast radius of a Goofus at Gigantech is pretty small compared to at a small shop where Goofus might have Prod credentials.

Gatekeepers

And then there are the gatekeepers. The Human Resources professionals whose thankless job is to sift through dozens to hundreds of resumes. It’s an extremely difficult task and one I don’t envy them.

The sheer volume of applicants necessitate that HR has to resort to unfortunate tactics such as randomly picking a sampling to visibly skim over. Advances in HR software over the past decade have surely helped ease this burden somewhat, but it’s also easier than ever to apply for jobs so they’re still fighting a losing battle.

Then HR has to attempt to determine an applicant’s legitimacy without a huge amount of pertinent information. It’s not possible to check the veracity of resume claims, especially without the deep technical knowledge necessary to do so. At best HR can only disqualify the most egregious of pretenders and social misfits.

The HR phone screen is in place to do just this. I’ve found it’s virtually impossible to be culled during this process. As long as you can put together a few sentences and aren’t a complete jerk, you pass.

In the tech world, HR can’t be expected to do much more than this. Our domain is full of deeply contextual and specific knowledge. Even a seasoned HR IT recruiter will have a tough time making sense of the alphabet soup of technologies we deal with on a daily basis.

Acronyms

Which brings us to one of the most ridiculous yet important parts of a technology job description, the acronyms. The acronym game reminds me of dueling banjos.

The company starts the music by putting out a job description that lists every tech acronym used in the whole enterprise. The job applicant answers by including on her resume every technology she’s ever worked with for more than a minute.

It takes a showdown at the Ok Corral, aka the Technical Interview, to see who’s bluffing. Usually it’s both. The real trick is finding out whether the applicant and the company are bluffing about the less important acronyms.

This is the unfortunate state of tech hiring in many places. I’m positive both sides would much rather have a better system to save each other huge amounts of time and wasted efforts.

Summary

10 years of Quarkus required is the type of absurdity commonly found in developer job descriptions. Even discerning what a company actually wants from job descriptions like these is a puzzle.

Successfully navigating the job search requires a bit of luck and some skill in satisfying the HR gatekeepers. Ticking the acronym boxes of a job description is often an unfortunate requirement to pass the initial screening process.

I suspect the friction found in this process is at least a little deliberate. It serves to eliminate candidates who aren’t serious about the job and won’t dedicate the time to jump through a few hoops to get it.

Hopefully someday soon we’ll have a better system and will look back and laugh at the ridiculous 10 years of Quarkus nonsense we used to endure.

Why Meetings Fall Flat

by

Why Meetings Fall Flat

If you’ve worked in the corporate world, you’ve likely experienced exactly why meetings fall flat in many ways. In fact, if you’re a developer it’s probably one of your greatest causes of job dissatisfaction if you work for a company that loves its meetings.

The average corporate meeting suffers from a number of pitfalls. It’s hardly controversial to say that most meetings in the corporate world are ineffectual and wasteful.

We’re long overdue for an Agile-like transformation in the world of meetings to an approach that values people’s time and takes full advantage of diverse perspectives.

“The Medium is the Message”

Philosopher and author Marshall McLuhan said it best, “The Medium is the Message.”

“It means that the nature of a medium (the channel through which a message is transmitted) is more important than the meaning or content of the message.” – Wikipedia

And so it is with meetings. People gather in the same room at the same time to share information and solve problems quickly. That’s how it’s supposed to work at least.

Now, the meetings mostly take place over a phone bridge as most teams are distributed. How else are you going to communicate when the project manager is in New York and the IT support team is in the Philippines and the product owner is in Texas?

The fundamental problem of most meetings is inherent in its medium, synchronous verbal communication. While this modality is certainly useful in some contexts, it’s deployed far too often than is warranted.

We have much better technological tools these days that can help us collaboratively solve problems more effectively through other means.

The Biggest Problems

The biggest problems of meetings are centered around synchronous communication and the combination of personalities on the call. Add in the ease in which meetings can be completely derailed and you have a recipe for futility.

Synchronous Communication

Real time conversation can be tremendously efficient. Meetings however, rarely achieve this in practice. As I’m sure you’ve all experienced, when more than two people enter a conversation the effectiveness of synchronous communication craters quickly. As the number of people in the conversation grows, so does the propensity of non-speakers to become passive observers.

There’s also the social pressure element to meetings that encourage sub-optimal responses. For instance, when asked a question in a meeting you will naturally feel pressured to answer on the spot. Especially if the question is something in your realm of expertise. If the answer doesn’t come to you immediately, you’re much more likely to give an approximate answer which likely won’t be fully thought through. This is just the way the human mind works.

In order to avoid the embarrassment of saying “I don’t know” in front of a group of our peers our minds tend to give us a “good-enough” answer to move the conversation in a different direction. Usually away from us or towards a topic where we have more conviction in our answers. The amygdala is a powerful force and even the most resolute of us have to deal with irrational fear responses.

In short, synchronous communication is especially vulnerable to generating emotional responses. Add in the notoriously poor fidelity of the average human memory and it’s hardly surprising that it often takes many meetings to solve even the simplest of problems.

Personalities

Why then don’t we just build a team full of people who work well together to solve this problem? To be sure, hiring a cohesive team will absolutely be a goal of any leader. Unfortunately this alone will not solve the major problems.

Even if we manage to assemble a team with highly cohesive personalities, it’s inevitable that we’ll need to work with others outside of this core group. This is another way of saying it’s not realistic to solve this problem on the front end by simply optimizing hiring for interpersonal compatibility.

We’re going to have to work with people whose personalities don’t mesh well. And so it’s much more effective to build a fault tolerant communication system than it is to psychoanalyze prospective hires.

Introverts and Extroverts

Unsurprisingly the software development world is full of introverts. And a telltale characteristic of many introverts is the preference to avoid confrontation.

Give an introvert a little time and a different medium however and you’ll certainly get a better response that fully answers a question and avoids acrimony. Removing the emotional response triggered by meetings is far more likely to lead to better outcomes.

Combining extroverts and introverts in a distributed synchronous verbal exchange usually doesn’t go well. The extroverts are highly likely to take over the meeting and leave no breathing room for others to interject.

When forced to rudely interrupt to get a word in edgewise, it quickly becomes a toxic environment. This toxicity serves to totally defeat the purpose of collectively gathering to solve problems in the first place.

While most extroverts do not intentionally try to take over exchanges, it’s just natural for them. Especially when paired with introverts who are not as comfortable thinking out loud in a group setting. The best leaders will recognize this and set up a system to seek input from both the introverts and extroverts on the team.

Derailed

Stop me if you’ve heard this one before:

Today’s meeting is about adding a new feature to the app. It starts off well enough with discussion around the most important aspects of the feature.

Then the group “talker” chimes in and before you know it he’s left Feature World and starts giving a soliloquy on the original architect’s lack of foresight in designing some other unrelated part of the system.

He would have done it MUCH differently and as a result the app would be slightly easier to work on for the developers.

May I present Exhibit D in why meetings are vulnerable to futility. It only takes one such “talker” to completely derail any meeting.

In practice, you’re lucky if there’s only one of these in any meeting of more than 5 people. They may not all be quite so brazen, but having to perpetually nudge the conversation back on target is extremely tiresome and wasteful of everyone’s time.

It also takes an iron-willed leader of the meeting to do so and these can be hard to find. Few things cause meetings to fall flat quicker than dealing with a serial derailer.

Summary

There are many reasons why meetings fall flat in the corporate world. Meetings take place in a synchronous medium which has inherent drawbacks for yielding good decisions.

While not all contexts are inappropriate for the medium, meetings are too often utilized to decide things that would be better dealt with in a different format.

Meetings suffer from a myriad of deficiencies. The synchronous nature of meetings promotes emotional responses from participants.

Personality differences are also inevitable and can lead to poor decisions where an overconfident, yet incorrect, extrovert is more convincing than a docile, yet correct, introvert.

And finally, meetings are easily derailed as it only takes one person to dive into irrelevant minutiae and the usefulness of the meeting is hopelessly lost.