I have been programming for almost 15 years now, and I really love most things about it. Some days I feel addicted to it as I quit work at 5pm just to spend the next 6 hours programming more stuff not work related. Other days I feel like opening a taco truck. Being in my late 30's, I've obviously have had other jobs in the past, and I realize that frustrations exist in other fields. However, maybe by talking about it, we, as a career field, can make it better. cue sunshine and rainbows

I used to teach programming for a coding bootcamp DevPoint Labs. I love teaching, and especially teaching programming. It's amazing to see all of the "Ah Ha!" moments that people have when learning something new. One thing I learned real quick from teaching was that you have to have tons of patience. You will be tested, pestered, unappreciated, and have to do it all with a smile. A student will ask a question on how to do the thing that you just got done talking about, then another student will ask that same question not realizing that someone else just asked it. This is super annoying, but the worst thing you can do is blow up on them and/or the whole class. There's proper ways you can handle this sort of situation as well as many others similar.

When you get in to programming, you need to decide early on which path you want to take as a programmer. Is this a 9-5 job for you, or is this a career lifestyle? Both answers are perfectly okay! When I worked at a sandwich shop, I wasn't going in to other sandwich shops and asking if they needed help, or offering advice on how they should make their sandwiches to cut cost. When I was a performing musician, I wasn't going to concerts and telling them how the chord progression would be better if they did it another way. Yet, as programmers, a lot of us feel the need to quickly bash and shoot down other dev's works. If your choice is to be a 9-5 developer, then just show up for your job, write your code, go home when it's done. Again, nothing wrong with that.

The programming lifestyle

As we get further along in our programming career, we are constantly learning new things. Some of us pick up these new things a lot easier than others. So many senior level developers forget this. A lot of people also forget that by learning all of this information, and choosing this as your lifestyle, you become a teacher. It's not really a choice at this point. If you want the choice to not be a teacher, then become the 9-5 dev. Don't advertise to the world that you're a developer with all this great knowledge of things.

Now, you don't have to be programming for decades to be a teacher. I don't really know ReactJS that well, but all of the students coming out of the latest bootcamp classes know it a lot better than me. I may need to go to them for help, and these are people that have been programming for less than 1 year. If you know the answer, and are actually willing to help, then you should do so.

The happy dev

Sometimes programmers will blow me away with how helpful they can be. People I've never met willing to take time away from their personal lives to work with me on the other side of the world. These are the individuals that I just truly appreciate, and the ones that keep me in this industry. In fact, I'd like to take a moment to recognize a few that really stick out to me:

1. Serdar Dogruyol. Lives 10 hours ahead of me, and has spent some late nights (early mornings?) helping me through some crazy ish.
2. Paul Smith. This dude is just a baller. Super easy to talk to, and always willing to help
3. Russ Smith. Can't forget my bestie! He may call me a jackass all the time, but I wouldn't be the programmer I am today without his help.
4. Jeff Casimir. Fellow educator, and gentle giant. Easily one of the most helpful people I know.
5. Nick Franken. If I'm ever in Nebraska, I'm definitely buying this guy a beer!

There's a good 20 other people I could add to this list easily, and I may just add them later, but I'd be here all day adding them. Sorry!

The qualities that these guys all have are none of them make me afraid to ask a question. Some people that have the knowledge, I get nervous about asking questions because their responses are so off-putting. All of these guys I can ask a question to, and get a very genuine helpful response. No stress or worries about just saying "hey ,what's up?". The key to being a happy dev is being chill. I don't know how else to explain it other than, just super chill and easy going.

The grumpy dev

The issues I've come across, and what feels increasingly more lately, is the grumpy dev. The developer who knows the answer, but for some reason is pissed off that you asked the question. "RTFM" is something you may have seen when trying to look up an answer to something. If you don't know this acronym, it stands for "Read The Fucking Manual". Thanks, Jackass... Maybe I did RTFM, and couldn't understand it because it was written by some other jackass that only put half the info in because they made the assumption that the reader knew the other half. This sort of mentality happens a lot in the VideoGame dev communities from what I've noticed. You see something like a quaternion function, or you have questions on shaders. The problem being you don't really know what a quaternion is or even what a shader is. You have to do a lot more reading, obviously, but if someone just quickly said "Oh, the quaternion method is going to be for rotating a 3D object", now maybe the "FM" that you need to go read will make a little more sense.

As someone that's creating a very large and prominent project, you have to put your mindset in to celebrity status. You will have your paparazzi wanting to get selfies with you at conferences. You will have people asking you the same question over and over and over again. You will have people that will take from you, and not give you any credit. You will also have people that will just hate you for some random unknown reason. If you're not ok with this, then maybe the limelight of an OSS Dev is not the place for you. Just go to being a 9-5 dev, or step down off the project. It's perfectly fine!

The other thing the grumpy dev does is jump in on a conversation to get their 2 cents in. They have to weigh in on a discussion to show their dislike for how another developer proposed a change. My favorite is a list of Github Drama.

Here's a list of some signs I've noticed on how to spot a grumpy dev. If you've ever done any of these, then recognize it, change for the better!

1. The "unhelpful". Finds someone started making a new web framework: "Why start a new framework when there's plenty of others already out there?"... Hmm, well, maybe they're doing it for fun? Maybe it's a learning exercise? Maybe they didn't know of the others? Who cares! Your comment was not helpful.
2. The "elite". Hears a question asked on how to solve a task: "Well, why are you trying to solve it that way?"... How is me telling you why I'm using this method going to help answer this question? Obviously my way is the only way I could think of, and it's obviously the wrong way. Are you going to help me or no?
3. The "downvoter". Sees a pull request on a repo they don't like: 👎 or 😕... Hey, thanks for downvoting or giving me the confused not-happy face. Should I just delete my PR that I spent the last 2 days working on?
4. The "annoyed". Sits in a chatroom / on twitter and tries to be the first to answer every question, but answers with a super advanced response that just leaves you more confused, then gets annoyed when you ask more questions as follow ups. (maybe I just will stop asking questions)
5. The "scrupulous". Reads an answer given by another developer, then quickly shoots down their answer as being WRONG... Ok, I don't know either of you, who's the person I trust?
6. The "controller". Comes across a reported issue, then tells them that it's not the place for asking questions, but only reporting issues... Now this one is funny especially on Github. Github has built in issue templates. These templates are designed for people to submit their issues in the same format. You can also use these issues to point people in the place where questions should be asked, if this isn't the right forum. Did you make an ISSUES_TEMPLATE.md? No? Did you update your README.md so people know better where to go ask questions? No? Ok, then STFU and answer the question, or just don't respond.
7. The "give-up". Gets asked a question. Responds. Gets asked a follow-up. Responds. Gets asked an additional follow-up, then gives up with a "well, I don't know". That's it? How about pointing me in a direction or something? If you really didn't want to answer questions, then don't start answering them. If you're out of time, or too busy, just say so! (Basically #4)
8. The "abrasive". Answers your questions like a heartless robot. Sees a "How do you..?" question, and answers with "you don't.". Umm, why not? "it won't work. It's not designed for that". Ok thanks, you technically did answer my question, but something tells me you're a dick.

Overcoming the grumpy dev

I'll admit, I've become a grumpy dev. I didn't used to be, and I would very much like to not be again. I've taken it upon myself to recognize this, and focus hard on changing that fact. So how do you change this? Well, it starts with deciding on which path you want to take as a programmer. If your choice is following the lifestyle (like I am), then the next step is how you talk to people.

1. See a new framework or something pop up and your language community is overflowing with them? How about asking the maintainer to add some copy to their project README that talks about what the goals of this project are? Maybe you can offer up a discussion on possibly linking similar projects and/or showing them where they find some helpful information that links to those other projects. You could also offer up assistance to have them help with one of the other projects instead. "Hey, if you're looking to work on a framework, we could really use some extra helper on [issue#4]!"
2. Understanding why someone chose to write something a specific way isn't really going to help you to give them a better answer. If you know the answer, just explain it. If you don't, then have them walk you through how they got to where they're at. That might give you some insight on how you can help solve what they currently have. THEN, and ONLY THEN, is when you say "great! it works, now let's refactor so you can clean it up, get some speed, and fix a few edge cases introduced".
3. Github should really just get rid of the thumbs down and confused face. They're not helpful. If you absolutely dislike the PR because it removes a very important thing, then respond with your reasons why you think that PR should not be merged. IMPORTANT: HOW you say things matters. This person may have just spent time and energy writing this PR. "Hey, I'm not too sure about this change. I have some projects that rely on this heavily, and here's a few others I found that do as well. Is there an alternative we can do instead of this?".
4. If you're constantly trying to be the first to answer questions just to show how smart you are, then you're a jackass. If you want to answer questions, you better be ready for ALL of them, and not just hoping they're super high level thought provoking questions by peers that are on your same level.
5. Just because someone was wrong, doesn't mean you have to be a dick about it and call them out. Embarrassing someone by being wrong makes them feel unwelcome, and makes you look like an asshole. You can either take time to send a private message to the person with the wrong info showing (not just telling) how their info is wrong. Or you can say something along the lines of "I've ran in to that issue before, and what worked for me was [alternate solution]". This gives the person the idea that hey, if one way doesn't work, I'll try the other.
6. If you really need to control every aspect of your repo, then use the tools provided. If github issues aren't the place for asking basic "how-to" questions, then make an ISSUES_TEMPLATE.md that says that. Make sure your README.md has all the links and places right there at the top. Lastly, if people still ask questions (and they will), then just respond with something like "Hey, thanks for using [my repo]! I would like to keep the issues area strictly for bug tracking, so could you ask the question [here]? Thanks so much!", then label the issue as a question, and wait for the response (or X no of days) before closing it out.
7. If you started trying to help someone, and you're at a loss on how to continue to help them, maybe you know someone that might be able to jump in? "You know, I'm just not really sure at this point, but maybe @mybuddydev can take a look?". You can also just tell them if you get too busy. "Hey, sorry to cut you off here, but I gotta run. If you still don't have a solution by the time I get back, I'll hop on and we can hash it out". No one is going to be like "hey asshole! I'm not done using up your free time!". They will more likely be like "Oh, no worries! Thanks so much for the help."
8. This is the most important. It's not always what you say, but also how you say it. I get that we work in a career that really interacts with many people that speak other languages. English is generally the common tongue between all programmers, so English not being your first language is perfectly fine. I'm sure I've said some phrases in Spanish that came off as a bit off-putting, but I didn't know how to articulate any better. If you know you're speaking to someone in a language you're not 100% comfortable with, just letting people know "Sorry, I'm not trying to be rude, I'm just not sure how to convey this properly".

Recap

Be welcoming with warm words. Not everyone knows the same information that you know. Be helpful and patient with people as they are learning something new. Over explaining something is a lot more friendly than under-explaining / short responses. And if you wrote "TFM", and are just going to tell people to read it, you better hope a 5yr old can understand it. If not, then be ready for some questions.

There's way more happy devs, than grumpy devs, but if you're grumpy, and recognize it, you can be happy again!