Introduction

It’s going to be a while working as a web developer in this crazy fast growing and emerging industry. Next to the web development, there are hundreds of different types of programming jobs that are highly in demand requiring people working in teams.

As I’ve worked in a few teams already, I noticed a couple of similar issues, that each team went through. And I’m willing to take a bet, that other teams working in the other non-coding industries going through kind of same problems as I’m going to write about down below.

Here we go

Lack of communication

Communication is probably the most important thing in a team full of developers. When communication is not perfect, inefficiences start to occur. A new member requires a lot of time and a lot of information input from the very beginning - it takes another member time that he’d probably spent better (from the short term point of view). The whole team is supposed to help new members. Sometimes, there is so much work to do, that no one is able to focus neither on helping newcommers nor on tasks they have to do. Especially at the end of a sprint or at the release and so on. The new member’s lack of information leads to inefficient work, working on the wrong thing, endless searching and trying to understand source code or maybe the new member is sometimes so confused, that he isn’t able to do anything at all.

Communication between advanced members are even more important. If information isn’t delivered correctly, it can lead to situation like this:

• One of the member starts doing things differently, leading to inconsistencies later in a project. therefore not completing task in time or worse, adjusting source code to fill the gap in these inconsistencies. This is dangerous. It leads to different kind of technical debt and to not understanding source code correctly - “Why this was implemented this way?” - a lot more WTFs than usual.

Excess of communication

If you’ve ever been in a team doing scrum, then you’ve probably experience this:

• Sprint planning
• Retrospective
• Every day sprints
• Ad-hoc meetings
• Another meetings like product demo, brainstorming and others…

Did I forget on something? - one of your HR wants frequent meeting to know how you’re doing.

Don’t get me wrong. Mentioned things are important, but sometimes, they aren’t efficient. They’re sometimes done because this is what “process” tells team to do. A lot of time is wasted and very few pieces of information is sometimes gathered/received.

Long code reviews

Maybe this is the thing that minority of programmers experience, but I’ve been experiencing this a lot of times since I started to work as a programmer.

When you implement a new feature successfuly, test the code, there are no eslint & build warnings or errors, you are good to go and create new pull request. You think how fast and good you are. But then the perfectionist (Reviewer A) came in and starts throwing comments onto your pull request. Some suggestions are valid and the code really should be improved. Another suggestions, you may think, are just too much? Who they are going to help? You just don’t see the added value. You can’t waste another minute by glamourizing things so the reviewer (A) is finally happy.

While reading these comments, you’re already in another branch focused on another task - because you thought you are free to go to another task. Your PR seems perfect. Switching back to the previous branch. Oh, you need to commit/stash your changes on this current branch to be able to switch. Successfuly switching to the correct branch, add changes, so the reviewer can be happy again. Commit. Push. Switch back to new feature branch. Stash pop. Implementing again. Multitasking, focus and context lost. Goodbye

Switching focus and context could be more draining than everybody ever could possibly imagine. Really. It is

Notification: Reviewer B requested changes on …

The second reviewer comes in… shit..

The next eye-rolling thing is, when the reviewer requests another changes after you already applied changes for the first request. Neverending context switching is the killer number one of programmer productivity.

I don’t think code reviews are bad thing. They are better than nothing. But the team should define when to stop roasting the author for small imperfections. This is not the last commit before deploying to the production anyway, things can be improved later. Teams should use pareto’s principle as a rule of thumb. Solving the last 20% of the quality requires 80% of the effort. Don’t waste energy on the last 20%. Your or other’s features will probably be rewritten to another framework anyway - so don’t waste the time (and money) on bullshits and approve the PR. You and other members need to move on.

Lack of a proper plan

I encountered this problem a couple of times. The issue is that the team doesn’t know what they’re going to work on. Or at least doesn’t know exactly. The guy on the higher position explains the problem on a meeting. The business problem is clear, everyone nods. It shouldn’t be problem. The manager is happy, we are going to have the new feature in a few weeks.

As programmers start to working on a new features, it is no surprise that most of the times some problems are encountered. Database model, API skeleton, external services, structure of something else, you name it. Something will always hit you, when you don’t have specific plan for it.

• Sometimes, coders workaround their new codes so they could work with the existing code base and existing solution. So they don’t have to fix older things and rather focus on new ones (Not good)
• Sometimes, coders start to actually work on a proper solution, communicate in slack. A lot of things must be written in a different way. Manager or person managing the team doesn’t really understand why developers are doing different things. He don’t understand, why it is taking so much time.
• Sometimes, new “sexi” feature is not so useful for end client at all. A lot of resources are wasted pointlessly.
• Sometimes, an abstract problem needs to be decomposed and written down. A proper thought process should be always present and really think about what, why and when.
• Sometimes, product owners or whoever comes with the new idea, has things written in a lot of text. We, humans, know how to read a text. But it is not the best source to get information from. It is often slow to gather and understand information from text, and also often ambiguous. What about diagrams? They are easier and pleasurable to look at and at the same time faster to understand the flow of information and behaviour of whatever you are going to implement.

I’ve worked only in one company, where the “boss” was implementing these diagrams. But it was not worth looking at it. It was like 3 diagrams crowded with boxes and labels. The diagrams, unfortunatelly, were never updated and later forgotten laying somewhere on google drive.

Diagrams are a good source of information, if made correctly

Also, diagrams are often considered as exploration tool. You are forced to think about your system and how your new feature will be implemented. It often shows you what really should be done. If it’s possible to be done and how big effort is needed to complete it.

Devil is hidden in details

• Sometimes, you are so sure, that the feature will not take much effort. Because it’s so easy, so small, so tiny. And a very small thing in it, can break everything. I’m explaining it in general. I’m sure, you were in the situation that you thought some task will take you half an hour, but ended up solving the bug for another day. It is sometimes like that. The devil is hidden in details.

Laziness

It can happen to everyone. You just don’t have energy to do anything. It’s raining outside. You had tough night with 4 hours of sleep or maybe you just don’t have mood to do anyting.

Meetings

Meetings. I don’t want to waste my words here. You probably know what I’m talking about.

Lack of cafeteria (space for a distraction)

A programmer is a human being. You wouldn’t believe it. It’s alive and it has feelings. It can’t work 8 straight hours like a robot. If a programmer tells you that he had 8 straight productive hours in a work, then he is probably lying or he is not a human. I can’t imagine any programmer coding for 8 full hours.

For example, when I’m in the “zone” I’m totally focused and I’m feel I’m actually producing something. Then, my brain needs to shut off for a while. I need to go to the kitchen, grab an apple, drink some water, have a lunch or just looking out of the window at the people walking outside.

I couldn’t imagine a workplace where coffee is not the option. If you don’t have a coffee machine in the workplace. Leave. I would. Coffee is the main psychical energy boost for programmers to cope with mundade boring tasks, annoying colleagues or anything else. Maybe you even don’t want to stay in the company any further but caffeinate brain somehow convince you that free coffee is not a bad option at all. Programmers do need a little distraction and a cup of coffee! Give it to ‘em

Open space offices

Until now, from companies I’ve worked for:

• 1 company required to be onsite each day (Open-space office)
• 2 companies allowed work from home (but often they required to be in the office)
• 1 company allowed to work from home and it haven’t specified for how much, but required to meet once in two weeks
• 1 company doesn’t have office at all, we worked only remote

Mostly, I’ve worked in companies that required to be there. I was lucky enough, that I ended up in the job, that doesn’t require anything.

In one, productivity was at very low level, because people were talking loudly, playing games or inviting others to play a game. In the next, people were very silent and enclosed all day. Social contact was absenting in all ways.

Think about it. You pack 5 or more programmers into the room. All of them needs concentration and silence, therefore talking to them is not a good idea. In my opinion, it is so contraproducive to require programmers for being there every day. They have to travel to work, enclosing themselves with headphones to give a signal to others that he doesn’t want to be bothered. They must sit in an uncomfortable chair in an uncomfortable suit often in a loud and unfriendly and unpleasant environment.

Maybe one of the reasons why you are packed in this offices full of people is that your boss wants to check if you are really at your computer, working and being nearby so he can bother you with anything he wants.

Technical debt

Suppose the team lacks code reviews, CI/CD, tests and code smells are all over the codebase. Similar to real world environment, the longer you avoid paying the debt, the higher it gets (because of interest). Things can escalate very quickly and your team’s code can actually be a real nightmare to work in. Meanwhile, you may realize that you can’t even add another feature because bugs are everywhere and adding anything would made things even worse.

This debt includes bad variable names, inconsistencies across the code base, code smells, no code review, shitty bugs, output (console) logs, spaghetti code, weird or no indentation.

I was in a company where technical debt hit hard and they weren’t able to recover.

Rewriting to new sexi framework

The new framework is probably better than your previous one. It’s true, but rewriting your app into the new framework, because it can optimize things a little bit, is not worth in most cases.

When starting on a project, selection of these frameworks is crucial. I think that very new good-looking, but not fully adopted frameworks, are too risky to use. I would prefer more stable frameworks at least 1 year in use and the framework/library should be heavily adopted by community of coders.

What value would the new framework adds to your product? Is the rewrite worth it? Isn’t this going to be a risky investment? Keep in mind that the whole team needs to get familiar with the framework and learn how to use it as well. Is it going to solve the problem previous framework didn’t handle well? Is there a chance, that the new framework will brings different issues with itself?

Sometimes, rewriting is really inevitable. Sometimes, it’s just now worth it. Make a right choice, because a product, customers and your team depend on this decision.

External failures

Have you been in the situation, when your cloud provider got into some issues and you weren’t able to do anything? This can be resource and time consuming, because a lot of teams are fully dependant on these third party services or architectures and when they’ve got into troubles, then you (and your team) are in troubles too.

Fixing bugs while new being created

No comment

Shitty boss

Once I had a boss that always checks “his” team of programmers and doesn’t bother to tap on back, even when he saw that we’re focused with our headphones on. Also, anything like coming 5 minute late from a lunch or 5 minute late to the office was something unacceptable for him.

Being underpaid

This is something that makes coders feel crappy, but is fixable at least. If you feel you are underpaid and the raise is not coming, you can leave and easily find better paying job. Cmon, you are a coder. However, being a “coder” nowadays is not as hard as it was in the past. You can be “self-taught” programmer or have a degree. I’m not against any type of these. If you add the same value as someone with the degree, you should be paid the same.

Timezone & Different times people are going to work

I’ve never experienced working with people from different timezones. However, I experienced working with people with different work hours. I had the opportunity to work flexible. Usually, I started working between 11 and 12am. While some of the team members were early birds, our working hours differed quite a bit. The smaller intersected time was sometimes really challenging for solving things efficiently.

Under the line

---

I realized, this post got a little bigger than I expected. So I’ll end up the post right here. When it gets more views, I’ll update the post and write down more things including:

• Lack of technical knowledge
• Using bad tool / technology
• Poor (workflow) processes
• Lack of motivation (Some problems are harded to solve)
• Lack of documentation
• Lack of code versioning
• Lack of CI/CD
• Bad team
• Size of the team
• Over-complicating things (Big and complex architecture, but zero users)