00:00:05.180
Hi, RailsConf, and welcome to my talk, "How to be a Great Developer Without Being a Great Coder." This is a talk I’ve been thinking about for about six years, basically since I started learning how to code. The title is a bit tongue-in-cheek, I’ll admit, but it will make a little more sense as we go. I also want to mention that this talk is very anecdotal to my personal journey, so your mileage may vary. However, I hope you can still get something out of it. Just keep in mind, I’ll be talking about myself a lot.
00:00:34.200
Let’s start here. I’m Nicole Carpenter, a principal software developer at a company called ApeLight, based in Chicago. I’m here because I’m a great developer. So, that covers half the title. This talk might not be for you; it wasn’t even written for this audience. I originally wrote this talk for a coding bootcamp I’ve called Code Platoon, which is a coding boot camp for veterans based in Chicago. I think this talk is great for junior developers, or people who are just learning how to code. Honestly, it’s a talk I would have wanted to hear when I was learning to code six years ago. I know this audience is full of RailsConf attendees—smart, confident, well-adjusted developers—so this might not apply to you, but hopefully, you can still take something away from it, as I believe the perspective is not widely represented.
00:01:17.040
Let me give you a little background so you understand why I am qualified to give this talk. I started learning to code in college, and to be honest, I didn’t really love it. Coming out of college, it wasn’t something I thought, "Gosh, I want to do this for the rest of my life." I didn’t think I was going to have a career as a developer, and a lot of that reason was that I really struggled with coding. I had to take a couple of programming classes just to get through my degree path. During those classes, I didn’t find the coding environment very supportive. A lot of times, I would ask questions, and the professors or my peers would give me this attitude like, "Nicole, you’re supposed to know this. This is incredibly easy; how come you don’t know how to do this?" There seemed to be an expectation that I should have known more going into the course than I did, and I found that really demotivating. It almost felt like being on Stack Overflow in real life.
00:01:48.780
At the end of that experience, I thought coding just wasn’t for me. However, when I Googled what kind of entry-level jobs were available for Information Systems Management graduates, I quickly learned that software development was basically everything Google recommended. So, I decided to bite the bullet and look for vocational coding, which led me to a coding bootcamp. I was part of Dev Bootcamp during its short run—may it rest in peace. Dev Bootcamp was actually a great program, and I’m sure there are a lot of alumni in the audience. I want to mention that Dev Bootcamp was probably the lowest point in my confidence journey. The bootcamp was designed as a nine-week course, split into three sections. Each section was three weeks long, and if you weren’t getting it, that nine-week course could turn into a 15-week course.
00:02:29.280
For me, that was the case. I repeated the first section, and I also had to repeat the second section because I needed more time to understand what was going on. I needed time to really take in what I was learning, and while it was frustrating, I was glad for the chance to have that extra time. One thing I noticed was that a lot of people around me were experiencing what they called "aha moments." They would say, "You’ll just get it eventually, Nicole. That 'aha' moment will rush in, and you’ll be like, ‘Ah, I’ve got it!’" I never experienced those "aha" moments; all those things that were promised never happened for me. While I was asking myself what I would do once I finished this class, I still wasn’t getting it.
00:03:39.540
I received some valuable advice from an alumni who visited. It was hard to hear initially, but he said the discomfort I felt while learning in that environment could very well follow me into my career. He absolutely didn’t mean that to discourage me, even though it may have sounded like that at the time. What he intended to convey was that I needed to be realistic about how I learned. I needed to prepare myself to adapt to situations and understand that I might not grasp things as quickly as those around me. I needed to work really hard to get to where I wanted to be.
00:04:54.600
Once I finished my coding bootcamp, I thought, "Great, I’m ready for my junior developer career now!"—which was absolutely not the case. Luckily, I went through an apprenticeship at ApeLight, which is well-known for its apprenticeship model. I was slated for a seven-month apprenticeship. Essentially, an apprenticeship is where you’re being paid to learn and to understand the fundamentals of what every developer should know about writing code. That seven-month apprenticeship quickly turned into a nine-month apprenticeship, which I was genuinely happy about, as it alleviated the pressure of becoming a billable developer. However, that had to come to an end eventually, and I’ve been working there for the last four years since completing the apprenticeship.
00:05:37.680
You’re probably thinking, "Gosh, Nicole, you just sound like you have imposter syndrome." For those who don’t know, imposter syndrome is a psychological pattern where an individual doubts their skills, talents, or accomplishments and has a persistent internalized fear of being exposed as a fraud. Does that apply to me? I don’t know; I don’t think I would accept that diagnosis entirely, but I recognize that many people feel that way. Imposter syndrome is very real; there are definitely high-achieving people who genuinely experience it, but there are also many average- or even below-average achievers who can still have successful careers as developers. But technically, they often feel like they’re just treading water while their peers swim laps around them. I have felt this way almost my entire career, especially while working at ApeLight, where I feel like I work with geniuses.
00:06:51.240
I know you’re not supposed to compare yourself to others—after all, comparison is the thief of joy—but it’s really hard not to. I received that advice constantly: "Don’t compare yourself to others," but I just didn’t know how to stop doing it. Especially when you feel like you’re on one of the polar ends of the spectrum. Returning to the idea of imposter syndrome, I think that the phrase itself can sometimes be dismissive. It doesn’t acknowledge that there may be systemic issues at play, such as racism, sexism, and classism. Even if we set those major issues aside, sometimes people just need to acknowledge that the struggle is real. Once they recognize that, they can begin to find ways to address the fact that this struggle genuinely exists.
00:07:29.220
For the purpose of this talk, let’s assume that the struggle is real and that you’re not a great coder—but you want to be one and desire to develop your skills further. So, let’s figure out how we can get there. This brings me to a quote I love: "Anyone can cook!"—this is from the movie Ratatouille. If you haven’t seen it, what are you doing? I love to think of this quote in terms of coding because I absolutely believe that anyone can code. Anyone can learn to code, given enough time, resources, and drive. Of course, take any of those elements away, and the story changes completely. For someone lacking resources, it would be really hard for them to learn, and someone without time will also have a challenging journey.
00:08:08.160
So how do I become less bad at coding? It’s definitely not an overnight change; you have to put in the work. Coding involves both time and exposure. Time means you learn as you go, and exposure refers to gaining experience through work or accessing different learning materials and learning from those around you. Importantly, coming out of a college program, a CS program, a coding bootcamp, or even if you’re self-taught, you are not expected to know everything. A junior developer in their first job will not be expected to lead a team, nor will they be expected to be the genius on the staff—unless, of course, you find yourself as the sole developer in a situation, then expectations could be a bit higher.
00:08:49.920
More than likely, your expectations for yourself technically may be higher than what an employer expects of you. The crucial thing is to enter your job eager to learn and contribute, and you will learn as you go. However, we have to address the fact that a significant portion of being a developer is, indeed, writing code. So, while we won’t come in as geniuses, how do we get better? I’ve learned a lot from mentoring. I mentioned that I work with students from coding boot camps, and there are a few fundamental things that every developer encounters on day one. The theme here is learning with time, so these are things that require time to master but recognizing the problem at an early stage helps you build those skills as you gain more experience.
00:10:06.660
One of the major challenges on day one is learning to break down problems. Breaking down problems basically means tackling them into logical steps a computer can execute. Capturing what the problem is that you’re trying to solve is key. A good example I like to use is tic-tac-toe—everyone knows how to play, but does the computer know how? No! The computer is dumb; you are the smart one. You need to tell the computer how to play tic-tac-toe: how to display a board, how to make a move, how to win the game. Those are all incremental steps that will have to be coded in your program for it to effectively solve the problem. Again, you will encounter this on day one, but you’ll improve over time.
00:11:16.500
Another struggle point on day one is code maintenance. I see many people tripping over coding issues. Different languages have various pitfalls; we have indentation for Python, mismatched brackets for JavaScript, and end delimiters for Ruby. I primarily write Ruby, assuming most of you here do as well. You’ll run into these little things, and while you won’t be a master of it on day one, as you learn more, you’ll realize how to write expressive naming in a language’s style, write clean code, and understand how to follow the program flow and comprehend what’s happening. These are all skills that will aid you as you grow, and after some time, you will improve.
00:12:31.320
Finally, on day one, you’ll have to learn how to read error messages. Essentially every developer sees errors daily throughout their career. This is something I wish I had learned on day one. It took me three or four days to realize that when I saw an error, I wasn’t being yelled at or screamed at by the code. Errors are there to help me! It’s important to understand that you shouldn’t fear errors; just read them, as they are trying to guide you.
00:13:51.540
Another crucial aspect is recognizing that people have different learning styles. You may not know right off the bat what works best for you, but there are plenty of options. While some may list seven different learning styles, I’m going to mention five. The first is visual learning, which pertains to using your eyes. Visual learning can involve diagrams such as UML. I’m glad I spent some time studying that in college, as it has been beneficial. Cheat sheets are useful; Googling the tool you’re learning and looking for cheat sheets can be incredibly helpful. Whiteboards are also effective, along with videos—YouTube hosts a wealth of educational content.
00:15:47.060
Auditory learning involves hearing, which includes podcasts and videos, again showcasing some crossover with visual resources. Another broad style is verbal learning, which encompasses words in various formats. This includes reading technical books and blogs. You might even write your blogs; it’s a great way to drive home what you’ve learned. Note-taking is a strong strategy, as is preparing talks and creating documentation.
00:16:37.560
The next learning style is kinesthetic. This deals with touch and movement—basically, the action of writing code. Tutorials and projects play a significant role here. For instance, many people use platforms like Codecademy and Free Code Camp to learn through hands-on experience. Participating in coding katas can also be beneficial. Katas are exercises where you start with a basic logic problem—say, converting Roman numerals—and gradually build upon it through writing tests and refining the code. They are an excellent tool for developing your skills.
00:17:57.720
Social learning is the final style I’ll mention. This includes meetups, hackathons, study groups, and mentoring. Mentoring is beneficial for both the mentor and the mentee, and mob or pair programming provides a social way of learning. In my experience, I’ve recognized that while I learn in various ways, technical reading is a significant struggle for me. I often read the same technical book page repeatedly, and I understand that this can be a symptom of ADHD. Many others face this challenge as well.
00:19:12.900
Lectures are another area where I struggle. If I’m not taking notes, lectures tend to go straight over my head, and I rely on recordings to watch later. While pair programming can be beneficial due to the collaboration of two minds tackling the same problem, I personally find it challenging due to anxiety. I worry about making a fool of myself and feel overly nervous, which typically hinders my contributions. Nonetheless, I remind myself that I need more practice and not to shy away from pair programming.
00:20:34.980
Here are a few strategies that have worked for me. I once dedicated an entire weekend to learning Bootstrap, and it’s a tool I still use today. I’ve mentioned blogging before because even though I dislike it, writing helps me retain information significantly. Mentoring is another strategy, as everybody you mentor is learning while you’re repeating foundational concepts, which solidifies your own understanding. Documentation is also crucial; on new teams, you often find that the processes could be better recorded. By noting down your steps for setting everything up, you’re helping future team members who encounter those barriers.
00:23:50.400
One lesson I was taught is to expose your ignorance—essentially ask questions. Don’t struggle in silence. We’ve all been where you are, and asking questions will help you and likely assist others who are afraid to ask their questions. When I feel insecure in asking questions, I try to reach out to people I know can help—texting someone I know specializes in JavaScript programming when I have a question, for instance. Building allies for support is vital, and finding a mentor can help tremendously. Remember, there are no dumb questions. Building these connections will lead to a strengthened learning experience.
00:25:39.840
We’ve rounded the corner and discussed improving your coding abilities over time. But let’s consider if time hasn’t elapsed, and you’re still not quite there. You can still be a great developer—that’s the moral of my talk. You can be a great developer even if you aren’t a great coder yet. I want to re-emphasize that this talk is very specific to my journey, involving lots of work and effort. Everyone has different strengths. My strength is my work ethic; I’m one of the hardest workers. However, that’s not the only path to becoming a great developer, and your journey may differ.
00:27:03.240
One of the strategies I leverage to be a great developer is that I don’t say no to opportunities. This was a lesson learned in the military, which contrasts with the advice given to not volunteer. I’ve volunteered for many things that have exposed me to experiences I wouldn’t have otherwise encountered. For example, I got to release doves at Clint Eastwood’s Manor—a unique experience! I’ve adapted this strategy in my career as a developer; I run two meetup groups and co-organize a third, along with helping to write a weekly newsletter. I dabble in many areas, so while my time is at a cost, the benefits of exposure outweigh that challenge.
00:28:46.080
You can also contribute while learning. One effective technique is learning something and teaching it to others. This could be through writing a blog or preparing a talk, both of which help solidify your learning. Additionally, hosting tech events is rewarding in that everybody benefits, including yourself. Mentoring is another great way to give back and should be prioritized, as many individuals supported me along the way. Whether you take on apprentices or find ways to mentor in your community, there are abundant ways to contribute and grow as a developer without solely dedicating time to coding tasks.
00:30:05.460
Beyond coding, non-technical attributes can also make you a great developer. For instance, having a positive attitude is essential; be the team member you would appreciate having on your own team. Excellent communication skills are crucial as well. This involves how you interact with colleagues daily—asking questions when you need help is key. Often, other people may have the exact questions you do, so your inquiries can aid multiple individuals. Providing constructive feedback on merge requests also contributes to strong communication practices. Documenting processes you find challenging can further enhance communication within your team.
00:31:49.560
Being intellectually curious is another vital attribute. It’s somewhat abstract—it’s like advising someone to be passionate. Intellectual curiosity drives you to explore new concepts, dedicating part of your day to reading or coding. Ultimately, that leads to asking, "What can I learn next?" Being responsible means following through and doing what you said you would. Good developers are empathetic, which means they care about their teammates. Lastly, the ability to be open-minded is important; there are countless experiences and insights to learn from the people around you.
00:32:58.560
Finally, it’s essential to preserve your sanity throughout this journey. Everyone is on their unique path, meaning what works for one person might not work for another. What makes me a great developer doesn’t mean it’s a one-size-fits-all approach; it’s a process involving time, energy, and effort, unique to each individual. You need to explore what makes you a great developer, as it might differ from my journey. You don’t have to work a 60-hour week to reach that level; it’s up to you to discover what truly aids your growth.
00:33:50.220
Thanks so much for joining me! You can find me on Twitter @nicolecarp or reach out to me on Discord. I appreciate your time!