We’ve all seen or experienced this in our lives one way or the other.

Disclaimer: Prepare yourselves for a big rant at the people who actually don’t understand what programmers do and how they feel at work. On a more serious note, this article is also meant to be just fun and definitely not to point fingers at any one.

Interruptions

Software devs don’t wear headphones because they love music so much and enjoy it more than anyone else in the world. They do it to shut off the world and all the distracting noise around them. It’s the same as having a sign on the back of their heads saying “LEAVE ME THE F*** ALONE! I’M BUSY!”.

These small interruptions are especially detrimental to any job that heavily relies on the mental model of the person involved. This post explains what I’m talking about.

Multiple studies have shown that it takes atleast 25 minutes of focus to become most productive after being interrupted. So, please remember this before you talk to someone in the middle of a neck-deep debugging session that you are going to waste 15–30 minutes of their time talking to them.

You may think that your interruption feels like this.

Image credit: https://commons.wikimedia.org/wiki/File:Chapters_meeting_2009_Liam_and_Rand.JPG

But to a dev in The Zone™, it feels like this.

Image credit: Social Network, the movie

All hope is not lost. There still are a few ways to mitigate this problem.

One more thing

You slave 4 months to get your multi-tiered chat platform ready and then your boss calls you up late night asking you to add a new feature to the app that shows you how to milk cows.

I know, I know, we are no longer in the realm of waterfall models in software development, where everything is planned ahead of time. But, the ridiculous amount of time spent on add-on features in modern day software development is quite simply unreasonable.

All I’m talking about is the last minute requirements and unclear additions, incomplete or missing user stories and feature creep.

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time. — Tom Cargill

Having too many last minute additions to a project can and will lead to feature creep. To prevent this, a team needs to understand that most devs love the Unix philosophy of “Keep it simple, stupid”. Most of Unix tools only do one thing and do that pretty well. Software, or at least the components of a software product, should do the same. One product can’t please everyone.

Image credit: https://uxplanet.org/design-principles-kiss-the-feature-creep-7eb84b09603f

Stereotypes

What most people think software developers are.

Movies and TV shows like these never realistically portray the job of a software developer or a security engineer. It just makes me wanna cry.

Being thought of as a wizard by general population is a curse. Managers think you can code anything, and most of your family describes your job as something to do with computers. Or worse, they ask you if you can hack the neighbor’s Wi-Fi, and when you say, “It depends,” they say, “Either you can hack it or you can’t!”

Dad: “Hey, you work with computers, right? Come help me fix my iPad!”

Your boss: “Hey, the printer’s broken again. Can you fix it?”

It doesn’t matter if you’ve only ever built CSS frameworks, people just assume that anyone who can write code can also fix anything tech-related. Sure, if you can help friends or family you’re usually willing to hear them out. But people go too far when they treat you like you’re a source for free 24/7 technical support.

Image credit: familygeeks.com

Horrible Bosses

Some bosses can be real pointy-haired bastards. Some of us have surely worked for them. They’re the ones who think that just because they know a little bit about a lot of things, they are experts in everything (even more so about UI/UX design). They make assumptions that make zero sense and have no basis in reality. These assumptions can result in arbitrary organizational constraints on language, platform, libraries, and other technical choices. Everyone understands that being a manager is tough, but some don’t follow basic principles that could make everyone a lot happier and more motivated.

Devs hate micro-management — where they are caught in nonstop meetings that result in lost time, constant direction changes in software, managers asking for time estimates every hour and trying to find out where every second of your day is spent. I’m not saying we hate management all in all, because without that, the team will totally be unstructured and out of sync with each other. But, just as the saying goes — “Too much of anything is good for nothing”. It applies in project management as well.

The good project managers of the world won’t set unreasonable deadlines; it’s usually the non-technical ones that do that. They will listen to developers and give them the benefit of the doubt, because the manager will acknowledge that they’re not the expert. Most importantly, good managers will give developers a good amount of autonomy without letting the team be completely structureless.

Image generated from: imgflip.com

Meetings

By now you’ve noticed that a lot of these items are not exclusive to software engineers. So if these issues are annoying to the rest of the world, then why aren’t they getting fixed? We may never know.

Maybe we should have a meeting about it? When should we have a meeting? Let’s schedule a meeting to discuss that? This actually happens. It’s not an exaggeration.

Too many meetings or inefficiently run meetings are just as detrimental to productivity as interruptions (probably more so in many cases). You’ve probably encountered all of these meetings:

• The meeting that could have taken 10 minutes, but took an hour
• The meeting that could have been replaced with an email
• The meeting without a clear objective or agenda
• The meeting where people keep bringing up new topics and extending the length
• The unnecessary motivational meeting
• The red tape meeting that you have to attend but has nothing to do with your work

Meetings and interruptions all throughout the day are common reasons for working late into the night. It’s the only time developers can get the isolation and long stretches of focused time needed to finish projects. Sometimes the amount of meetings gets so bad that developers look forward to the weekend, not because they get a break from work, but because they can actually get some work done!

Another side effect of badly run meetings is that it discourages participation. If meetings commonly run over their expected time, many team members will stay silent and not add to the conversation unless they’re required to. This is because anything they say can start a whole new tangent of conversation that drags the meeting out for another 15 minutes.

Meetings are one of the most hated things on this list, and the best resource I can give you on fixing the problem of bad meeting practices is this TED talk by Jason Fried: Why work doesn’t happen at work.

Technology churn

Churn is what happens when the bulk of the developers in a specific language ecosystem designate one framework or platform as the best and form a vibrant community around it, and then one or two years later the majority of developers decide that a new framework or platform is the best. They then all migrate to that community, leaving behind other developers who tied their software more firmly to the first technology.

The JavaScript and Node.js ecosystems are prime examples of this technology churn. “Flavor-of-the-week.js” some call it. It can be extremely stressful for developers — even the most engaged ones — to keep up with the churn of tools and APIs, which can require major changes to their applications.

There is often too much credit given to the shiny new thing when it is often just a reinvention of something that already exists and solves a problem very well (sometimes better). It’s true that developers shouldn’t get bogged in a declining technology for many years, especially since that can bring on its own set of frustrations. But it’s ridiculous when the veterans in the development community have to talk about how every few years, a new generation of developers tries to reinvent the wheel. It makes it seem like the development community goes through cycles where it forgets the problems it solved in past generations and sometimes does a worse job when it tries to solve them again.

Click bait articles

Don’t you just hate all the list articles (a.k.a. listicles) that start with a random number? One developer told me that they refuse to read any article that starts with a number in the title.

Personally, I would never write something like that. 😂

In general, just about everyone hates being tricked into clicking on an article with an eye-catching headline that has little to no substance. It’s annoying when authors keep using the same old gimmicks to try to get developers’ attention. All they have to do is write a controversial or short and cryptic headline and they’ll likely get thousands of views.

Let’s try an example: “AngularJS is Garbage”

You know the author is baiting you, but you really like Angular and you simply can’t let this aggression stand. You have to see what flimsy arguments they make against Angular and promptly refute them in the comments. “[X Technology] Considered Harmful” titles are my favorite.

That’s it for now folks. Merry Christmas and a Happy New Year.