In the previous two sections, we've covered technical and non-technical skills. However, a programming career can't occur in a vacuum! We need each other to thrive.
6: Connect With Other Developers
You've heard the saying, "iron sharpens iron". This is certainly true in the software development industry. I owe a huge majority of my knowledge to my fellow software developers.
Communities like DEV, GitHub, and Freenode IRC provide many opportunities to connect with other software developers. Being an active part of a community is more than just asking questions, however. Share your knowledge and opinions on topics, and accept feedback. Learn more about the backgrounds and ideas of others. Make friends!
Through these relationships, you will find a wealth of knowledge, support, and laughter.
Disagree Politely
While we're on the topic, you should definitely learn constructive debate techniques. Once again, this may seem tangental to programming, but it isn't; standards, coding practices, and project decisions are all bourne out of healthy debate. I have some background in formal Greek-style debate, but you don't need to go that far. Here's a few tips:
Debate ideas, not people. (This is the biggest reason internet discussions so often turn nasty.) When a disagreement comes up, the only thing that should be in question is the veracity of the ideas in question. All parties still have inherent value as human beings, and their value will neither go up or down as a result of the debate's outcome. Attacking a person as a means of tearing down an idea is known as an ad hominem (against the man), and it's dirty pool.
Check your facts. We're all guity of citing facts that turned out to be inaccurate. If the topic is important, you should take the time to be sure of your claims. If you aren't that invested, you should at least publicly admit to working off of memory.
Don't misrepresent the opposing idea to tear it down. This is called a "Strawman argument," and it is another form of dirty play in debate. You should assume that any opposing ideas have at least one point of merit, and that other people are rational human beings.
Learn to laugh at yourself. You're going to stick your foot in your mouth sooner or later. When that happens, resist the urge to get defensive. If you're first in line to make light of your own mistakes, it will make everyone more comfortable.
Walk away if you must. It's better to leave a conversation abruptly than to lose your cool. If you find yourself getting overly invested emotionally, walk away until you gain control of yourself. Unchecked anger is not condusive to reasonable behavior.
05:14
Video: Disagreements are learning opportunities 📹
Jonathan ・ Jul 6 '19
7: Ask Questions
Sooner or later, you're going to get stumped. That's when you can reach out to your network to get help!
Before you ask, there are a few things you should do first:
Follow the "20-Minute Rule". try for at least 20 minutes to solve it yourself, before you ask.
Share the details. Just telling us "X is broken" doesn't help us help you. We need to see your code, the exact error output, what you're expecting to see, and what programming language version and tools you're using.
Tell us what you tried. If you spent that 20 minutes first, you should have found some things that didn't work. Share that knowledge, so we can focus in on the answer faster!
By the way, if you're using IRC, be patient. Post your question and wait. Because of the nature of IRC, it can sometimes take hours before someone sees it. If you sign off, we can't help you! On that same note, don't ask if there's someone who knows <X> in a room before asking...just ask. It doesn't necessarily take an expert to answer a question about <X>.
8: Help Others
As you learn more, you'll be in a position to answer other questions...and you absolutely should! Personally, I've found that I learn far more from teaching others than I do from reading for myself. There's something about absorbing the knowledge, and then turning around and repackaging it for someone else, that just helps it stick.
Sure, it's intimidating to answer questions initially. "What if I get something wrong?" Of course, you can research the topic first, to check your assumptions, but sometimes you're going to get stuff wrong.
Don't worry about it. In the worst case scenario, you're going to give another young developer bad information, but sooner or later, they'll learn the truth. In the best case, another more experienced developer will come along and correct you, in which case you've learned something. In any case, don't come down on yourself for such mistakes. They're all part of the learning process.
StackOverflow is probably the first place that comes to mind when you think "answer questions," but it is by no means the only place. (These days, it's not even the best place.) DEV's #help tag affords many opportunities, as do many programming message boards and Slack channels.
You should also consider joining Freenode IRC and helping answer questions in channels related to technologies you use. I first joined the #python room on that network in my second year of coding, and I've been there ever since. (In fact, my "Dead Simple Python" series came out of my experiences in that room.)
9: You ARE a Real Programmer!
Along the way, you're going to think to yourself: "If I only knew that thing, I'd be a real programmer."
STOP!
If you've ever written any code in your life, and had it work, you are a real programmer. Don't ever question this. Even the developer who has been writing code for 30+ years has more to learn. As I mentioned before, that's the beauty of software development...you never run out of things to learn.
Your legitimacy as a coder does not depend on what languages you know, what tools you use, or what types of problems you solve. No two programmers have exactly the same experience, or look at a problem the exact same way. Everyone has something to contribute.
You are a real programmer. You're not faking it. The goal is never to become a "real" coder, it is to become a better coder.
The Recommended Reading list is coming up next.
Top comments (9)
When my organization discovers we've made a bad hiring choice, 90% of the time the problem is soft skills, not technical skills. You need to be able to work in a team, accept criticism gracefully, and give criticism constructively. You need to be able to share your work and help each other. I have room for maybe one or two absolutely brilliant developers who can't interact with people...and even then, I would rather have a somewhat less brilliant one who is able and willing to mentor others and explain why they wrote their code that way.
This!
#learnprogrammingis an excellent multi-language room. I also run##c++-friendly, although it tends to be pretty empty. (Please lurk there! Need to build that community.)I've also been hanging out in
##c++-generaland##c++-basicfor a few weeks. They seem to be pretty good. (I've NOT had good experiences with##c++however, so I'd avoid that.)I don't have any experience with
##c, so I can't say if it'd be good or not.In terms of other languages,
#pythonis excellent.##javais pretty friendly too.Out of interest, what is your view on Greek style debating ? :)
I believe strongly in it. I have some background in debate and in persuasive public speaking, and I have a deep appreciation for the civility and mutual respect they foster. It's a lost art.
I meant if you have any first-hand experiences from Greek debates. My bad, I phrased it poorly.
Interesting answer though. I had the Greek debating style as more...brutal in my mind (I am Greek, in case you are wondering). Though I totally don't have your exposure in public speaking.
Well, our experiences with it may vary greatly, as I'm especially familiar with the academic version of Greek debate. It can be a bit more brutal in one sense, but I think there are several components that ensure it is still constructive:
Interrupting your opponent is against the rules. Everyone is given time to speak, and everyone must actually listen to one another to have a chance at winning the debate.
Ad hominem attacks are considered dirty pool. At least in the circles I was in, these weren't acceptable. In any case, they waste precious speaking time, and make one look like a heel.
Everyone must be prepared to defend their position objectively. Personal feelings and opinions don't mean squat unless they are supported with fact and reason.
Limited time means one should not waste time on bickering; it just runs the clock out and makes the bickerer look uninformed.
I did take part in a number of debates in middle school and high school (albeit, most had to be internet-mediated because of where I lived, but that didn't make them any less structured). My persuasive public speaking was in HS and college, and then incorporated into my professional speaking. I was also a judge for a formal speech and debate contest on two different occasions.
Interestingly, the debates that occur in
#pythonand its auxiliary communities often (though not always) bear resemblance to Greek debate, just without the timekeeper or formal turns. Proof, logic, and pedantic accuracy are all chief interests of that crowd, so if you can't craft a good Greek-style debate position for yourself, you're basically toast in one of those discussions.Ok I get it now. Many thanks for your explanation, much appreciated. :)
Very helpful and interesting, I have learn quite a lot with all this tips, especially the no. 9 tip, I always felt that way when I tried to do something and is not working the way I want. Thanks