Becoming a PHP Professional: Social aspects of teamwork

After discussing the general guidelines to reaching an Intermediate+ level in PHP development in Part 1 and the importance of others around you in Part 2, this article will focus on social aspects of teamwork and initiative, and will serve as an introduction into a more concrete and practical teamwork based article coming soon.

It's important to note that when I say teamwork, I don't only mean teams while working for a larger entity – a corporation or company in which you're a minor sub-group. A team is also a group of freelancers working together on a project – either close by, or remotely. Whenever you work with someone in any capacity whatsoever – that's a team. A loose team, but a team nonetheless.

Know your role

It's no secret we developers tend to be bigheaded sometimes – in all areas of life, not just coding – especially when being given (or succeeding in) a task of mid to high level importance. It gives us a sense of false security and we tend to forget that we don't, in fact, know everything.

It's only natural, then, that we feel like we're more important than our designated team role lets on. In times like these, it's important to step back, cool down, and look at things from a different perspective. Put yourself into the shoes of other team members and look at yourself from afar. Realize why you're there and what you're supposed to do, and respect the fact that every member of the team has a specific purpose.

You might be better at front end engineering than the team member they hired for the position, but if you're there doing PHP, consider the net gain of proclaiming such a fact publicly. While the front end dev might be mediocre, you were mediocre at one point too – without the experience of working on different projects, you never would have outgrown the mediocrity. Furthermore, what can be gained by replacing said member? If the member is actually bad at his job and does harm to the project, by all means, this should be brought to the team lead's attention. But if he's just "ok", replacing him could actually have a negative impact on the progress of the work, causing unnecessary delays.

Not stating the fact publicly could have even worse implications – it could sow dissent in the ranks, making the other team members take either a defensive stance against you due to your underhandedness, or taking an aggressive stance towards the person you have a problem with which, again, isn't healthy for the team as a whole. The healthiest solution is, by far, approaching the person in a friendly manner, giving advice, and discussing everything openly.

But what if it's the project lead who is so bad he does harm to the project? Well…

Respect superiors – to a degree

Superiors are like elders – they're to be respected, but to a certain degree. Of course I'll listen to what my grandma has to say. She's been around for much longer, she's bound to have at least passively absorbed some wisdom she can impart. But if she starts trying to brainwash me with old habits and attitudes, her close-mindedness will render me non receptive to her words.

It's the same with superiors in a team. Respect their decisions, accept their advice. If someone is higher up on the corporate or team ladder than you are, there's a reason for that – and more often than not it actually is skill and experience, contrary to many people's beliefs. Keep in mind that everyone you ever meet knows something you don't, and be receptive of their opinions, even if you disagree with them – there's often more to be learned from disagreement than agreement. A light difference in opinion can be researched and discussed productively, and someone is guaranteed to come out of the situation with knowledge they didn't have before.

Admittedly, there's a dark side, too. There are times when the only reason someone is superior to you is because they're better connected to the project owner. These circumstances usually aren't obvious at first, but in time, they always become fully transparent. Speaking from experience, the symptoms of incompetence can be anything from refusing to move away from PHP 5.2 in 2012 on a brand new project, to contradicting oneself in tasks just to cover up for previous errors in judgement. It won't be long before their bad calls start to harm the project – soon enough, everything that goes well will mysteriously be attributed to them, and everything that goes wrong will require an in-team scapegoat. This type of person is usually excellent at diverting attention and misdirection in order to keep their position as long as possible, because their high rank usually involves bonuses or other privileges – and if the project falls through eventually, it's just one black spot on their CV, but a thick bank account and lots of influence.

When you detect such an environment, there's no rational way to repair it. Going to the project owner usually makes no sense, because they're either too attached to the person (blood relatives, personal friends) or completely fooled – and the latter is usually worse, because the longer the situation lasts, the less willing the CEO or project owner becomes to admit that they've been duped all that time. Projects like that usually crash and burn after a prolonged state of plateau, so…

Don't be afraid to leave

When you realize this might be the case, it's important not to be afraid to leave. The temporary security the job offers at that stage is just that – temporary. Remember, the project will crash and burn, undoubtedly, it's just a matter of time. The situation is unfixable without a change in management, and changes in management don't tend to happen all that often.

You should always be on the lookout for better offers, but when you find yourself in a downhill situation, start actively looking. Go to interviews, apply for projects, just don't be passive about it. It's hard when you have dependents, and risking the loss of a regular paycheck can be very taxing on one's psyche, but trust me when I say that sticking around in such an environment can be even more taxing, not only for you, but those around you as well.

I write from personal experience. I was forced to leave my job due to these exact conditions, but instead of settling for a similar pay with another IT company, I opted to go freelance. Going freelance allowed me to pick my own projects and clients, to choose technologies I'm comfortable with or interested in, and to learn more than I would ever have learned having remained stuck in the faulty team.

Conclusion

While this article had little to do directly with PHP, it is the opinion and experience of someone specialized in PHP. It's also a precursor to the next article on teamwork which will cover remote work, pair programming, dealing with time zone differences, types of teamwork, and more.

What I'd like you to take away from this part is – don't be a slave of circumstance. Be courteous, professional and honest, but don't be afraid to leave a poisonous environment – it harms you, the people who love and support you, and finally, the project you're working on. I left and, personally, I have yet to look back with anything but relief.

Do you have any team based horror stories? Success stories perhaps? Attitudes differing from those exposed in this article? Let me know in the comments below.