How To Become A Developer (4 Part Series)
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.
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.
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.
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
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.)
Along the way, you're going to think to yourself: "If I only knew that thing, I'd be a real programmer."
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.