A Programmer’s Guide to Combating New Workplace Challenges

Getting a new job can feel energizing. Think of it like a honeymoon period you earned yourself.

The software industry is creating unique city cultures across the world. You have an opportunity to to settle in a new career atmosphere, enjoy vibrant cafes and pubs, expand your network, and also get a refreshing look at your life.

However, like any other industry, new software workplaces have also got their fair share of workplace challenges. Those challenges become real blockades that impede your productivity, topple your work-life balance, and eventually kill your motivation for work.

Here are some common ones — and how to get over them.

Lack of Information

Every IT organization has got processes. Those processes are governed by IT systems. Even if you are non-tech person, being an employee of an IT organization requires you to have a chain of login credentials —be it workflow management (e.g., JIRA), payroll, knowledge base, LDAP, or source control.

Unfortunately, many small-to-medium-size companies — those with fewer than 100 people — still haven’t digitized these processes. Even if they have, new employee acquisition happens on a case-to-case basis.

You will find yourself scrambling between cubicles to obtain the information that must be jotted down. You will be thanking squirming faces that do not necessarily deserve your gratitude.

As a newcomer, there is very little you can do about it. But you can use it as an opportunity to earn some brownies. You can begin documenting everything in Post-its.

Your existing coworkers may not appreciate it, but you’ll feel good sharing it with future newcomers. And they will be thankful to you too.

Lack of Integration

This is deep. And if you are junior-level employee, you are more likely to feel it.

You will feel it when your team goes for lunch together, leaving you out. You will feel it when they curtly observe you during your check-ins and check-outs.

They may say “good morning,” but you still feel their lack of interest on their faces and in their tone.

Your pull requests will be neglected. Your documentation updates will be reversed without reason.

The crudest form of this neglect is visible during team meetings.

If you are an introvert, those initial meetings are an endless abyss for you. Being a beginner, you are eager to contribute your first thoughts — about the product function, about the best technique to implement it, or about the scheduling.

Every time you open your mouth, you are shunted out by that One Developer Who Must Not Be Named. You must raise your voice, at which point, you are marked as impolite and unwise.

Your team lead/scrum master might lend an ear to you — not out of respect for your opinion but to make you feel respected. Your opinion will not be weighed in.

Not at this time. Not at the expense of that senior loudmouth.

If you are an extrovert, there is a way. You can fill into this void by passing petty remarks about weather, politics, or a laughable guy in another team. In about 4–5 months of this, you will gain yourself a speaking slot with your charming wit and half-rotten ideas.

For the introvert, however, the only way to circumvent this awkwardness is to contribute passively. Avoid volunteering ideas in meetings until you have personal rapport with every team member in the out-of-meeting-room environment.

If you feel it is absolutely necessary, make a formal pitch to the team lead/scrum master. Make yourself heard first, then present your thoughts calmly.

Think about it this way: You aren’t losing out by staying silent. They are.

Extra-Cheerful Coworkers

There are colleagues who will eagerly come up to you. They will become your bridge to mingle with the team. Even if you are an introvert, you can become comfortable with them in no time.

The problem is they seem bit too enthusiastic to be believed as truly selfless.

They will drag you to lunch even before it is ready. They will ensure you return to your desk 30 minutes later than everyone else. They will drag you five times a day for coffee breaks, even though you are OK twice a day.

A new codebase is a mountain of complexity. You have decided to spend more than eight hours in the office during the first two weeks just to familiarize yourself with it. Because as programmer, you learn and code in chunks. But those cheerleaders will prevent you from your task at hand.

You will sometimes feel it is for your own good. You are devaluing their empathy toward you. They are the torchbearers of the almighty work-life balance.

But there is only one thing they are perfect in: distraction.

There is a stronger chance you may observe them sabotaging your work (and credit thereof) during team meetings. The longer you take recognizing them, the more harm they cause. Their friendliness will last till a newer programmer joins the team.

There can be exceptions. Some people are genuine in their enthusiasm — but only you know which habits help you give your best.

As a programmer, your best comes in chunks, not in linear time slots. You know when you are in your most productive chunk and when it’s fine to let that dreaded hour pass without a line of code.

Enclose your productivity inside a safe boundary. Only you can break that enclosure. No one else.

Give them everything you can outside of that boundary.

Let them know about it, politely and firmly.

Conclusion

Being a novice at an IT organization seems like an enormous technical challenge. In reality, it is a series of work-psychology challenges.

As a programmer, you are capable of building abstractions that make a robust product. As a software professional, make sure you build the right ones that make you a robust workplace individual.