You might think that most programmer's prefer the dark safety of a hoodie and a basement cubicle in order to really get into that extreme focus mode where reality turns into binary. Where the only sound is the clickity clack of a mechanical keyboard and of the 80's synthwave blasting through the headphones.
I am one of those people. Solving complex coding issues is a challenge in it of itself. Add to it a loud and colorful open office space with people walking past your periphery every 5 seconds and you are asking for trouble.
I like cubicles with high walls and some form of sound proofing material. And I'm not alone. Most programmer's that I've worked with prefer this type of environment to the more open-space environments that have gained popularity during the past few years.
But being a professional programmer involves more than just writing code. Alot more.
There are meetings...
You don't just typically sit down and just start coding once you get a job. There's the whole issue of "What do I code?". And getting an answer to that question pretty much involves meetings. Lots and lots of meetings. Most of which you'll question why you are there to begin with. Many of which truthfully, you should probably skip as deadlines pile up. But you won't. Mandatory meetings are a part of the job and they are included in your paycheck.
At some meetings though, you are the star of the show. Every question is directed towards you and every pen and paper trembles in people's hands as you speak and they attempt to scribble down whatever sense they can make from the conversation.
You have to realize that as a programmer, a big part of your job is to essentially translate code into business logic that a non-technical person can understand and vice versa. Your entire job is to code what product managers, project managers and business development teams need in order to hit their KPI's for the month.
And that involves clear and concise communication on almost a daily basis. But it also involves those quiet hoodie-worn moments when you keep your down and just type in order to complete your work on time.
There is agile development...
If you haven't heard the phrase 'agile development' before then realize that at some point in your career your will.
Agile development is a software development paradigm that revolves around short bouts of development, often referred to as sprints, with consistently updating requirements as they enter the picture.
This is different from the more traditional model, in which requirement gathering is typically completed (or close to completed) first before any development is begun.
Agile development typically requires a very collaborative environment. This includes things such as daily standups, in which every developer on a team essentially informs the rest of the team what they worked on the day before and what they are working on that day, or plan to work on. This is also a time to address any issues that anyone may be having. This keeps everyone accountable to their tasks, but more importantly, it let's your teammates know where you are in your personal development cycle.
This is typically the most difficult step for any introvert out there. Yes the code failed to compile for 3 days straight, and no you don't want to talk about it. Well, you have to. Because that's probably going to hold other developers up in their own work. So you suck it up and you inform your team that you need help.
Communication is a huge part of this project management style. At least if you want it to go well. Things are just moving at much too fast of a rapid rate for you to keep up alone. The more introverted 'leave me alone to code' mentality will not work well in a highly team oriented agile environment.
There are admins...
Your personal website that you host on a free cloud platform probably has 1 developer. Yourself. And for the most part, that works just fine. You make an update, you commit and sync the update, and some continuous deployment process ensures that it gets online for everyone to see. It works.
Your companies websites on the other hand? They probably have teams of people and each team handles a different arm of the project.
One subsection of those teams are the admins. That includes the system admins, the network admins and the database admins. And a big part of your job as a programmer, is to work with them to ensure that everything is running in order.
And believe me, if you've never worked with a system admin before, then your first few encounters might not go as planned. They typically have their own vocabulary and their own software to deal with and probably a slew of tickets they need to resolve.
In my experience, it is vital to have a good relationship with any of these people or groups of people. Not because they will ignore you or your requests if you don't, not at all. Their job is to assist the developers in whatever ways that they can. That includes all developers at a company, not just you. And that's why I mentioned that it is important to have a good relationship with them. Sometimes you need something that takes seconds to do. The traditional route is to make a ticket with that request. That ticket goes to a manager, which then prioritizes it, which goes in a queue, which might get resolved 2-3 days later.
Long story short, if you build good relationships in life, a 3 day waiting period can turn into a 3 minute waiting period. I've made it a point to get to know all the admins at my previous jobs and I don't typically abuse the power and bombard their inboxes daily. But on those few times when I needed a configuration file changed, the process was a 2 minute walk down the hall.
There's your team...
One of the highlights of my career so far has been getting to meet dozens of other tech enthusiasts and programmer's at different companies. More specifically, going to lunch with these people and getting to discuss things that typically don't come up on a day to day basis.
Initially however, in my early days, I was not that person. I would eat lunch at my cubicle while perusing the early web. If anything I could catch up on work and get to go home early, I told myself while teams of people walked by on their way out. While true, there was definitely a disconnect between myself and my co-workers. Lunch isn't just a time to eat typically. It's also a time to discuss project timelines, roadmaps and challenges.
Eventually though I decided to say 'yes' to a team lunch and never really looked back. It was cool to chat about what projects everyone had on their table and in general about the landscape of programming. Different people work on different technologies usually, and often times you get locked in to your own small echo chamber. But there's alot more happening outside of that.
Programming is a social job...
Coding itself is a solo endeavor best suited for 3 walls and a good pair of headphones, absolutely. Any programmer can get behind that statement. But as a job? As a job, this field is incredibly social in its nature.
I've spent many days at work in which meetings outnumbered the amount of code written by a long shot. People would show up to my desk with a pen, paper and a list full of questions to discuss. And 3 hours later we'd be done just in time for lunch with the team.
But that's alright. As I said earlier, it is a part of the job and it is included in your paycheck. The more you communicate with those around you effectively, the less mistakes everyone makes so that everyone can go home on time and enjoy their weekends.
But when meeting ends, it's time to put the hoodie on and turn the music up.