I am a programmer, and there have been times where I thought I was the best programmer - that I knew it all and that my opinions were facts. Eventually I learned that I wasn't the best programmer and that I will never be the best programmer. I also learned how to be nice.
I had a job a couple of years ago - I went into it thinking that I would change things for the better. Not a bad approach, but when you think you know everything, this will lead to disaster. It did, and I found myself in need of a new job very quickly. Instead of focusing too much on how much I hated it there and how much I despised most of my previous co-workers, I looked at myself. What could I do to improve?
This led me to many books and articles surrounding programmer stereotypes and how to break out of them. I realized that there is a cycle for these stereotypes that creates many of the people that I worked with. People like:
- Senior developers who talk down to juniors and discard any ideas thrown at them (like using git for version control. Yes, this happened to me. I was the junior dev.)
- Developers who don't have social skills and usually seem upset or angry.
- Junior developers who come fresh from college and assume they know everything (hello, that is me. Except I dropped out. Oops.).
- Junior developers who think all senior developers are dinosaurs who don't know anything about modern programming.
- Developers who undermine each other at every turn.
- Generally defensive developers.
- Developers who think that other departments of the company are stupid, that they don't know what they want.
- Senior developers who are bitter towards almost everything.
Take your pick. Mix some together, leave some out - if you're a programmer, you've probably worked with people like this. It's frustrating, isn't it? Now think about yourself. Has your frustration from these types of co-workers caused you to be trapped in that same bitter cycle, causing you to become one of those stereotypes? It certainly happened to me.
These stereotypes only add to confusion and drama between company departments and individuals.
Why should I be nice?
Consider the above more carefully. By adding yourself to the bitter cycle, by becoming a programmer stereotype that is hard to work with, you'll end up creating more variations because you influence other developers. Do you want to work with more of these kinds of people? I'd prefer to work with people who:
- Care about what they are doing
- Take steps to improve themselves and their code
- Think carefully and slowly about problems
- Actually want to contribute to a project
- Have an open mind and consider (or at least not discount) every idea
Those people sound lovely. Wouldn't you rather be happy at your job? Treat people with dignity, and they will likely do the same to you.
But if I don't know everything, I'll look dumb!
No, you won't. At least, not to people who are also nice. I would say that most people who realize that you're being humble will have a greater respect for you. Humbling yourself and realizing that you don't know everything is how you will continue to learn and improve. If you're closed off to ideas (new or old), you're stuck. Realize that most concepts are not black or white. They are gray. Most concepts have both positive and negative attributes. This is equivalent to the basic saying of that "nothing is perfect".
If someone expects you to know everything, that's incredibly unreasonable - you should talk to that person and help them to understand that you don't know everything and you're not going to pretend like you do. If they can't grasp that, to me that would signal a toxic work environment / personal relationship - it could be time for them or you to leave.
Step 1: Be nice
Is it really that hard to be nice? Yes. It can be very hard. I've had plenty of conversations with people who would greatly benefit from reading this post, and it's not easy. When you're speaking to people, try and talk a bit slower and more calmly than you would. Try to control your tone and volume, and try to make your points clear. When you are talking about something that you're not 100% sure on, make that known. Say, "I'm not sure on that, I'll have to check on it.", or "I honestly don't know enough about it, but I can check".
Being nice, textually
Many of the conversations I had at my previous jobs were done digitally via text. Therefore, it is incredibly important to understand how people read text conversations. Before I send off a long message, I typically read it once or twice, which usually makes me think about how it could be received. Most people I've met read messages differently, which makes it very hard to know how someone will take a message. Despite this, reading over your message (even if it's a simple one) before sending it can help eliminate misconceived notions.
If you're typing out several paragraphs, it's especially worth it to read through it before hitting send. Many times have I initially written emails with sarcastic quips, only to realize how that could sound once sent. Leave out personal details - if something is important enough to you, speak with that person on a phone call, or go see them in person.
Unfortunately, reading over your messages can create a version of yourself that analyzes received messages deeply and can possibly lead to anxiety about the unknown. You can try to fix that by thinking about all messages in a similar way - ignore any fluff and grab the core message. Even if they are being sarcastic or are trying to upset you, ignore that and look for any meaningful text. If there is none, the conversation is useless and can be ended (nicely).
Don't allow yourself to be manipulated
All that being said, if someone is actively being an asshole, don't allow yourself to be a part of it. It's good to go into a conversation with an open mind and proceed by ignoring sarcasm and false niceties, but if someone is seeking drama, don't allow it. Remove yourself from the conversation. "Can we pick this up another time? I need to go do X thing." is a perfectly reasonable thing to say.
Does the above happen all the time? Is that person your boss? To me, that would signal a toxic relationship, and I would consider finding a new job.
Stop being exact, and ask meaningful questions
Many senior programmers I've met that are stuck in their ways usually think of ideas as attacks on their code. I have received a lot of responses from people like this that are one-liners meant to discourage further messages. "No, we don't do that here." and "That won't/doesn't work." are examples of being exact and making a strict assumption. Stop thinking this way. If there is anything you take from this post, take this: Stop being exact, and stop making assumptions. You have a chance of being wrong. Hardware and software changes all the time.
To add to the above, make sure you ask good questions when you're talking to someone. Sometimes, marketing (or another department) may actually not know exactly what they want. You can help them by actually being a part of the conversation and by asking meaningful questions.
Paulla: Hey, can you make something that takes product titles and shows them as a list on a page?
What titles?Yeah, I can definitely do that. What products are you wanting on there?
Ask a meaningful question and actually be a part of the conversation.
Jim: Hey man, guess someone over there screwed up all the prices?
We haven't touched prices today.Hmm, I haven't had anyone mess with prices today. What products are involved? I'll check it out
Remember, you're working towards a goal. Ignore the assumptions and focus on the problem.
George: Hey, can I use X framework for this project I'm working on? It's really cool, has a ton of good features, and I really like it.
no, we don't use frameworks.I just looked at it, and it looks neat. But we will need to think about support for it in the future, and if the other team members want to use it. Let's talk in the group chat about it. :)
Don't disregard other ideas, even if it's coming from someone who is new. They probably haven't thought about any of what you replied with, because they're either new or excited. Even if their idea isn't your cup of tea, it's okay to be excited with/for them! Treat them as a team member, and discuss the idea.
Pull request review examples
This variable is useless.Hmm, what's this variable do? I'm not seeing it being used anywhere.
It's highly possible that you don't understand exactly what something is doing in new code. It may be a good solution, and you just aren't seeing it.
Remove this.You can remove this for now, there was an update where it's no longer required. See here for more info
Give reason(s) for the things you say - it helps everyone learn.
General chat examples
X sucks.I didn't like X when I tried it, but maybe it changed? What do you like about it?
Don't be such a bummer, and honestly? Don't ever speak negatively about another person's project. People work hard on their projects because they care about them. If you have anything to say, talk with the project owner directly and offer actual help or advice without sounding like a dick.
Nobody uses X anymore.Dang, haven't seen anyone use X in awhile. Have you tried Y or Z? They both offer more performance.
Just because something is old doesn't mean it's bad. That being said, things that try to improve on X usually do exactly that. Do your research.
New thing X is unstable.Hmm, has anyone had issues with X's stability? I'm a bit worried because it's so new.
Just because something is new doesn't mean it's unstable. That being said, do your research.
Learn to be nicer. Read articles aimed at the kinds of issues I've brought up. Books like How to Win Friends and Influence People by Dale Carnegie and The Mythical Man-Month by Frederick P. Brooks Jr are a great starting point.