When you are learning to code, you often receive a lot of advice. Some of it you ask for, but there is also some advice given freely without request. Some of the advice you receive will help you structure your path to meet your goals. Some of the advice will not be helpful to you, but it’s up to you to decide what that looks like.
Learn as Many Languages as You Can
I think this person had good intentions when they told me
"Learn as many languages as you can. Learn the whole stack, top to bottom!"
I mean, I'm fairly sure they did. I was studying Ruby on Rails with the goal of becoming a web developer. Web development in Ruby on Rails has a ton of moving parts, which you can see for yourself here or more succinctly in this tweet:
It would serve any web developer well to understand how each of these layers work together and which languages are responsible for building each layer. This advice is even echoed in one of my favorite programming books, The Pragmatic Programmer:
You shouldn’t be wedded to any particular technology, but have a broad enough background and experience base to allow you to choose good solutions in particular situations.
—Dave Thomas and Andy Hunt, The Pragmatic Programmer, p. xviii
I think this is great advice, but I'm not sure if it's the right advice for the beginner developer--especially if the goal of that beginner developer is to become a programmer. I think the right advice for the beginner developer is this section from one of my other favorite programming books, Apprenticeship Patterns:
Pick a language. Become fluent in it. For the next few years this will be the main language you use to solve problems, as well as the default skill you hone whenever you are practicing. Making this choice is a challenge. It is important that you carefully weigh the options, as this is the foundation upon which your early career will be built. -David H. Hoover and Adewale Oshineye, Apprenticeship Patterns, Ch. 2
If you're interested in finding work as developer, I'd recommend focusing on learning one language and one stack really well. Fortunately for web developers, modern web development is compartmentalized in a way that makes it easier to do this. I would try to figure out what you enjoy more, backend or frontend,and focus on that section of the stack. This allows you to fully learn one language and eventually fully enderstand its features and nuance.
If you can learn one language fully, you can always teach yourself another. Since programming is a daily practice in humility and learning, I think that's the skill employers are looking for that's often hard to describe, not some small knowledge in many different languages or stacks. Once you decide what you prefer, the compartmentalization of modern development will allow you to punt on the other pieces until you have time to really focusing on learning them.
Start a Business
Once, very early in my learning, someone told me that I should start my own company. I didn't have any particular passion or interest for entrepreneurship, but this person posited that if I started my own company, I could be CTO which would look very good on my resume to impress prospective employers. While starting a company is an impressive endeavour, my goal was to become an employed, paid software developer, not an entrepreneur. Because of that, I ultimately decided to eschew this advice and focus on learning how to program. (This mainly seemed like weird advice to give someone who was just starting to learn to code and it's too funny not to share.)
Build Something You Are Passionate About
Another piece of advice I received was:
"Build an app around something you're really passionate about, then you'll always want to work on it!"
This is definitely very good advice for anyone trying to start a business or build a specific app. However, I think maybe better advice for a new developer trying to learn to code is to build something you understand. This took me a long time to come to terms with. I thought I needed to create new and unique applications to impress interviewers, but really, truthfully I needed to practice writing code. Writing code is much easier when you don't have to do the extra mental strain of defining or creating an unfamiliar domain.
Know what's mundane and what the world doesn't need more of? To-do list apps, calculator apps, online drawing apps. But I bet you know exactly how those work. When you're practicing writing code, don't complicate your work by spending a lot of time defining a new domain. Choose a domain you understand and spend your time practicing writing idiomatic code and learning when to use certain design patterns (and when not to use those patterns).
Letters to a Young Developer
This is part of a series of posts where I'm outlining good (or in this case bad) advice I got or wish I'd gotten when I first started writing code. I don't mean for any of the advice in this particular post to be prescriptive, some of it may be opposite for you. When I first started learning I felt overwhelmed by advice and like I'd never have time to do all of the things people recommended I do. I'd hope that anyone reading this post doesn't take away "don't learn a ton of languages!" or "don't start a business!" but instead that when you take advice, take into account your goals.
My advice to you: define your goals (mine was to work as a software developer) and let that guide your path. Find out what it takes to achieve your next goal, such as a portfolio of work you can point to as experience or maybe a really good understanding of a system or language that you can explain in an interview. As you receive advice, apply it when it furthers your current goal in-progress, or maybe just stash it in your notebook for now and revisit it later (or throw it out altogether).
Great Wide Open has always been a great friend to the Atlanta tech community and to Rails Girls Atlanta. By providing a low-cost (and for scholarship reciepients, free) high-quality conference in our city they have greatly increased access to technology education and open source contribution to all Atlantans.
What you may not know is that Great Wide Open was one of the first conferences I ever attended as a developer.
At the time, everything was kind of scary because I wasn't familiar with the tech conference format but I really appreciated the steps taken to include everyone. For me, getting to come back to this conference that was so welcoming to me as I was just joining the tech industry felt amazing. I got to meet even more kind people dedicated to increasing access to open source.
Transitioning from non-technical work to a technical career like software development is difficult.
Getting help and advice shouldn't be though. There are developers in every community who believe that a rising tide lifts all boats and want to help you lift your boat.
When you think of learning as a journey and attaining a developer job as a destination, this metaphor can be extended. Even with a rising tide, a boat needs direction and motivation. It's easy to overcomplicate things for yourself and unintentionally make your journey more difficult.
A boat with sails but no motor or rudder, It could go far but only with a big push in the right direction.
Similarily to Tenderfoot in Pamela Vickers’ "Crossing the Canyon of Cognizance" presentation, you are standing on one side of what seems like an impossible to cross canyon, but you see someone like you on the other side. Maybe you can just ask them how they crossed and you can do the same.
"Hi. I have read your blog and noticed that you taught yourself programming. I am also teaching myself programming and would like to transition to a career in software development. Would you mind telling me how you got your first programming job?"
Maybe at the outset, this doesn't look like a really big ask. This person is just asking for a little bit of information.
"Would you mind telling me how you got your first programming job?"
When I hear this question though, I hear "Just tell me the secret formula you used, so I can use it too." Unfortunately there is no secret formula.
When I receive this question, I see two ways to answer it: a lengthy but accurate response or a short but sweet response. The lengthy but accurate response won't be very helpful because the take away from that story is "be in the right place at the right time."
I did have a little bit of experience with programming which may have given me an edge, but I also was looking for internships at a time when many others weren't. The market I work in didn't have any local code bootcamps when I started learning so I didn’t encounter groups of 20 cohorts graduating at the same time, all applying to the same positions.
The short but sweet response is that I applied for every job I thought I was qualified for, showed anyone who would look my small "portfolio", and answered every single recruiter message no matter how shady it appeared. It's not very accurate though because like I said before, timing was on my side. But more importantly, I had the help of a lot of kind people.
Now that you have this information, maybe you realize that my story (and most of those you might collect) doesn't reveal a formula you can replicate exactly for exact results. You have more information, but it probably hasn't made your transition to software developer much easier. Not to mention, it's a bit taxing to write out everything that happened and explain why those things matter, so it’s not a great question if you want a timely answer.
What you probably wanted to learn was what specific things you could or should do to become a paid developer.
A boat with a motor but no rudder, It could go far but far in what direction?
After going to some meetups you finally met some of these kind developers who want to help, so why not "leverage your network" like people online are always recommending? That's how most people get their jobs now, right?
"Hi. I see that AtlantasMostFunDevShop has a job opening. I'm really interested in working there, can you connect me with the correct person?"
This is definitely more specific. Narrowing your scope to a job available at my company is certainly a smaller set than all possible jobs. So simple, all I need to do is connect you with the correct person.
"can you connect me with the correct person?"
The correct person for what though? The correct person to tell you their experience in that job or team? The correct person to help you get an 'in'? I'm really not sure who the correct person is for you but the intentional vagueness does make me suspect you'd like to bypass the traditional application process. I really want to help you, but sort of backdoor/under the table type things make me pretty uncomfortable and hesitant to help or expose my coworkers. If you're looking to get more information about that role, just ask!
"Hi, I saw this job opening at your company and I'm really interested in learning more. Do you know someone on that team I could speak to to learn more about it?"
“Hi, I saw this job opening at your company and I'm really interested in learning more. Would you be interested in grabbing coffee to chat about AtlantasMostFunDevShop?”
Hey! I can definitely help you with that. By being explicit that you're looking for more information and not a way to bypass the system, I'm comfortable introducing you to my coworkers because I know you won't put them in a position of discomfort or pressure. By meeting my co-workers with the intent of discussing the role and seeing if you find common ground instead of "leveraging" them like a resource, you can expand your network of people interested in helping you.
This is a sailboat with a rudder but no motor, it has direction but only given the right wind.
You know that having a network of developers can help you, so you reach out to one who works at a company where you are interested in working:
"Hello, I was looking at AtlantasMostFunDevShop's website and came across this posting for a WorldsBestLanguage job. Can you tell me anything about the job?"
This is a little bit better, the question is referencing something specific but the question itself is very very broad.
"Can you tell me anything about the job?"
Dang, the answer to that could really be well anything. I know what I would want to know about the job. Do they value test driven development (not necessarily test first)? Are all members of the company treated with equal respect regardless of experience level or technical ability? Does the company value learning and give everyone space to learn and teach? I could list off all of the things that compelled me to take the job, but I don't want to bore you with details, so I would probably provide a broad response to this broad question.
This might help you get an idea of why I chose to join this company, but you hopefully are looking for more specific, actionable information for yourself. If you're thinking about applying for jobs and not looking for more specific and actionable information, I'd recommend reading through this presentation by Britni Alexander to help you firm up what your career goals are and what you're looking for in a job.
If you're looking for something specific though, why not just ask? You probably want to know if this job will be a good fit for your skill and experience level.
"Hello, I was looking at AtlantasMostFunDevShop's website and came across this posting for a WorldsBestLanguage job. Do you mind if I ask you a few questions? I noticed that the experience level is pretty ambiguous, do you know if they are considering junior level developers? I am still learning and studying a lot, are you given time at work on new skills? Is there a mentoring program at your company?"
Hey, I know the answers to some of those questions! I can definitely speak to my experience with those things you're concerned about, and the things I don't know are simple questions for me to find the answers to.
A boat with sails, motor and rudder. This boat has direction and its own source of motivation.
"Hey, I saw that AtlantasMostFunDevShop is hiring WorldsBestLanguage developers. I've been writing WorldsBestLanguage and really want to work on SpecificSoftwareOrCultureIssue, I was reading an article in Interesting Publication about it just the other day. If you didn't read it, I recommend checking it out! Do any of the teams at AtlantasMostFunDevShop do anything like that?"
Hey there, this one is actually pretty great! You mentioned something specific you are interested in working and you're excited about it. If my company isn't working on that problem, I bet you I know someone at another company that is.
Let's say we do work on SpecificSoftwareOrCultureIssue. I love how excited you are about it and how much information you gave me. It'd be really cool if you applied to work with us, and I'd definitely mention your interest in SpecificSoftwareOrCultureIssue when you do. Let me know if you'd like me to read over your cover letter or if you have any questions about the application or interview process, I'm here to help!
Letters to a Young Developer
This was part of a series called "Letters to a Young Developer" where I'll share the great advice I got, or the advice I wish I'd gotten when I first started learning Ruby.
Speaking at Eurucamp was an eye-opening experience. I feel very much like a stereotypical American college student who visits Europe & returns to the U.S. "enlightened". So, forgive me if I gush too much. Eurucamp this year was a single track conference with a good mix of non-technical and semi-technical talks. This was very nice because I was able to see all of the presentations. I could tell the organizers were extremely thoughtful in curating the selections and the order in which they were presented.
The conference was held at the University of Potsdam, located just outside of Berlin on the Griebnitzee. We stayed in the Avendi am Griebnitzsee and enjoyed beautiful views of the river from the hotel.
As I mentioned before, all of the talks were truly great. There were a few that especially spoke to me though.
I, at least, hear all the time from product managers, project managers, sales engineers and the like claim to be "not very technical" then reveal that they have a CS degree or explain to me a complex technical system. Just because you're not writing code every day doesn't mean that you aren't a "technical" person. You probably are, and you should embrace it and give yourself the credit you deserve!
Rebecca Poulson presented "The Junior Jump" and gave us all ideas for what we can do to help jr. developers be successful. This was a very refreshing perspective for me because I hav always felt that organizational change must be supported by actions of those at the top or those with authority. Many people (myself included) often provide all the advice to jr. developers and none to those who manage and mentor them. I think that if you're really interesting in fostering talented people you really need to hear this talk.
Katherine Wu (you can call her kwu) presented on Ask vs. Guess culture. Chances are, if there is someone you have trouble communicating with, they are probably using the opposite communication style as you. Highlighting and understanding these differences can help very different people understand each other.
The best advice I believe I have ever been given about public speaking is this: "Believe that your audience has no knowledge about your subject but all of the capacity in the world to learn."
When I presented this talk previously at RailsConf in Atlanta and at the Athens Developer User Group I was able to rely on the assumption that many of the audience knew who Amelia Bedelia is. At Eurucamp I found that she wasn't as widely known and further, that I couldn't expect everyone to know exactly what I meant when I said "idiom". I did the thing I was afraid of, and swore I'd never do, I rewrote the introduction to my talk while at the conference! Too close for comfort for me, but if I wanted to get my point across I had to do it. Once I was presenting, I was really glad I decided to do this. Explaining a bit more at the beginning meant I didn't have to worry if my audience had read enough Amelia Bedelia to find the talk engaging. They didn't have experience with this particular book but given a little bit of information they had the ability to comprehend how the story worked and why I wrote it.
like all my best work, this talk re-write is being haphazardly thrown together the night before in a hotel bar
While I didn't enjoy rewriting my talk the night before, I did enjoy the opportunity to get to know the audience better and create an experience that would be both enjoyable and instructional for them. This is a personal belief, but I feel that's what I owe each audience I am presenting to, an enjoyable and instructional experience.
Here are the slides I used to accompany "Amelia Bedelia Learns to Code" at Eurucamp:
and here is the recording by ConFreaks (thanks to Eurucamp + sponsors for paying for this service!):