As I advance my web development career, I find myself spending a lot of time on things that don't involve actual coding. Consulting, writing documentation, research, and communicating with my team are just some of the non-coding activities that can take up most of my day. I find these non-coding activities to be just as important as writing code. Why? Because code by itself doesn't solve problems, people do! And effectively working with people requires developed soft-skills.
Meetings suck. Most developers will tell you that they are the bane of their existence. As someone who is socially reserved/awkward, I share that sentiment. However, it's important to be present at meetings, even if they feel pointless. It might seem obvious, but taking even shorthand notes and asking questions (when applicable) goes a long way!
Don't multitask in meetings
Even if taking notes isn't your style, or the meeting isn't designed for back and forth dialogue, paying attention will still serve you well. What doesn't serve you is trying to multi-task while in a meeting. All it took for me to learn this lesson was an instance of working on other projects on my laptop while being asked a question at a meeting. I was mortified and was the subject of ridicule for a while (and even earned a nickname). Aside from the social implications, it's a bad look and is just rude. Don't do it!
Meetings can contain unique information we need
In a perfect world, developers would have a complete scope of work (SOW) with the goals and timelines perfectly laid out in a central location accessible from anywhere at anytime (looking at you, Confluence ). But the world isn't perfect, so we have to scour emails and Hipchat messages to get the information we need to do our job. We must remember to include traditional meetings in the information gathering exercise! Remember, we don't live in a perfect world so that means we may miss an important detail about a project if we blow off a meeting.
Typically, the term "flexibility" in the context of web development is defined as the ability to recognize patterns of learned systems to facilitate quick adoption of new ones. This is important, especially in the agency setting where billable hours are everything. However, I think there's another angle: flexibility in how you work with people.
The vocabulary used among developers to abridge dialogue would (most of the time) confuse and frustrate non-developers. As a developer, it is important to recognize your audience and do your best to communicate in a way that is clear, concise, and helpful.
Even with a shared "language", developers (obviously) don't always see eye-to-eye. There will be disagreements about implementation, methodology, and of course granular stuff like languages and frameworks. While you might have a strong opinion, it's important to acknowledge the perspective of the other side, even if you don't agree with it.
As a former visual designer, I have given and received countless critiques and I've found there to be somewhat of a science to it which reveals valuable lessons in interpersonal flexibility. The one that stands out in my mind is the exercise of evaluating how closely the work aligns with the objective. Basically, critique the work, not the person!
As a developer, mapping actions to client goals while acknowledging dissenting viewpoints takes the subjective and personal elements out of the equation and has helped me get through many disagreements.
Empathy for your team
Having empathy is critically important to success as a developer but it can be hard in practice. I can't count the number of times I've been frustrated with project managers imposing unrealistic deadlines without giving me a chance to weigh in. When this happens, I have to remind myself that this comes with the territory and that the PM isn't trying to make my life more difficult, she's just doing her job. I also try to think about what it would be like in her shoes: carrying the weight of representing our company/team, managing client expectations, the endless emails and real-time correspondence with the client... it sounds like a nightmare and reminds me of how lucky I am as an introverted, sensitive person to have her on my team!
Empathy for your client
More and more, I find myself at the beginning of projects asking internal sales/account people for client correspondence to get a better sense of their overarching needs and goals. And also to gauge how the client is feeling emotionally. At the end of the day, clients are people with real, human needs. While it make not seem like it, I have found that tapping into those needs helps in clearing a path forward!