00:00:20.480
So our first talk of the morning is Ben Orenstein. Ben has been working with Ruby for eight years and currently works at Thoughtbot in Boston. He is the host of their podcast titled "Giant Robots Smashing Into Other Giant Robots." He got his start programming in QBasic and spent some time digging in the C code mines. He’s here today to discuss frequently asked questions.
00:01:10.479
Hello! Oh, I have some volume on this guy. How's everybody doing? Pretty good, I see! It’s a great turnout for the morning after those fantastic parties. It’s good to see all of you, and you’re looking well.
00:01:28.640
To start, I’d like to conduct a quick focus exercise. Could you please clap when my hands are together? We have some eager clappers over there—thank you! That was better. Let’s hold your applause for now.
00:01:45.440
Here’s a funny story to start with. This morning, when I went to print my notes for this talk, I accidentally used wedding stock paper in the business center of the hotel. When I printed out my stuff, two women asked me how many pages I printed. I said, ‘Five,’ and they replied, ‘You just printed on our wedding stock!’ So, this thick paper is the most unusual setup for talk notes, which means this talk is going to be awesome!
00:02:32.480
As this talk begins, I want to let everyone in this room know that you all have a job today. This talk is targeted mainly at beginner and intermediate programmers. If you are in that category, your job is to listen and hopefully learn something new. However, if you are an advanced programmer, your task is to listen and hopefully disagree with me. I enjoy when smart people contest my points because it provides an opportunity to learn and consider new perspectives.
00:03:30.160
So, if you disagree with something I say, I would love to hear about it. Please feel free to raise your hand or shout out your thoughts! Questions during my talks are my favorite. Alright, let’s get started with the main topic. This talk revolves around the frequently asked questions I encounter in my role as a mentor at Thoughtbot’s Learn service. I work one-on-one with beginner to intermediate Rails developers looking to land their first job in Rails, improve their job prospects, or launch side apps.
00:03:56.400
I have noticed that several questions come up repeatedly in these mentoring sessions. The first question that is really core to our profession is, ‘How do I become a better programmer?’ I genuinely love this question, and I have a couple of key points to share.
00:04:13.440
I believe that the best way to improve as a programmer is through pairing with others. Notice that I didn't say you should pair with better programmers. While pairing with more experienced programmers is fantastic and arguably the most effective way to learn, pairing with peers at your level—or even those who are less experienced than you—can also be incredibly beneficial. Teaching someone else reinforces your knowledge, and you learn things as you explain concepts.
00:04:54.000
Moreover, when you pair with someone who is less experienced, it gives you the chance to articulate your understanding. Often, you'll discover that your grasp of the material is fuzzier than you realized. This can lead to important revelations. Don’t hesitate to admit when you don’t fully understand something, even when it's tempting to hide that fact.
00:05:31.680
Next, I recommend spending time struggling with programming tasks on your own. While pairing is essential, solo struggle is equally important. As a newcomer, it’s normal to doubt your abilities and think that programming is harder for you than for others. Remember, programming is a challenging field, and it's not just you; it's hard work for everyone.
00:06:00.480
Don’t be too hard on yourself when you struggle; this is a normal part of the learning process. If you find a task easy, you may not be pushing yourself enough. It’s crucial to choose challenging projects and strive for growth, even if it involves overcoming difficulties.
00:06:37.680
In addition to struggling with challenging tasks, realize that it’s vital to admit when you don’t understand something. About two years ago, I decided to embrace this principle. If there is something I don't understand, I admit it right away rather than trying to maintain an appearance of knowledge. This practice has tremendously benefited my learning journey.
00:07:23.320
In our industry, we often measure our peers based on their intelligence, which leads to the temptation to misrepresent our understanding. This entails trading temporary perceptions for lasting comprehension. It’s crucial to ask questions when you don’t understand something and to seek clarification—sometimes being a little embarrassed initially can lead to better knowledge in the long run.
00:08:02.639
When it comes to coding, my favorite evaluation heuristic is this: how easy will it be to change this code later? It's easy to write code to satisfy an immediate requirement, but the real test comes when we need to adjust or enhance it later. Pay close attention to the effort involved when revisiting your code for modifications.
00:08:38.479
Mistakes often arise from duplicated code. While most developers understand they shouldn’t duplicate code outright, there are many subtle forms of duplication. One approach to manage this is understanding the Law of Demeter, which states that code should only interact with its immediate acquaintances. By minimizing duplication, it can be easier to maintain and adapt your code over time.
00:09:19.120
Duplication makes future adjustments difficult, as every time a change is necessary, it can become a tedious task. Striving for minimal duplication will allow you to make changes confidently in a single location. This overall focus on understanding and adapting your code will help you improve as a programmer.
00:09:57.760
Now, let’s transition to another topic. One common question I receive is whether it’s acceptable to duplicate test code for the sake of clarity. In my view, you can indeed achieve clarity without resorting to duplication. There often exists a balance in writing tests that are both clear and maintainable without duplicating processes or knowledge within them.
00:10:44.800
Meanwhile, test code, much like production code, should adhere to the DRY principle—‘Don’t Repeat Yourself.’ Many developers understand this concept when it comes to production code but fail to apply it to their test suites. Remember, test code is still code and should be treated with the same care and consideration as production code.
00:11:28.000
Furthermore, writing test code that is easy to understand and maintain ensures it can adapt as your code evolves over time. If your tests become cumbersome and confusing, it may be valuable to revisit how they've been structured.
00:12:11.600
In our quest for better programming practices, it’s important to maintain your network of industry friends. Most of my past job opportunities have stemmed from referrals and personal connections. Real friendships with people in your field can lead to opportunities and invaluable advice that can help in your career.
00:12:59.600
As someone working in San Francisco, opportunities are abundant, and it’s essential to stay connected with your network. As a practical exercise, I encourage everyone to turn to the person sitting next to you and introduce yourself. Establishing these connections is vital for professional growth and opportunities.
00:14:19.480
Let’s transition to a crucial topic concerning compensation. A recurring question I often get is, ‘Do you think I'm underpaid?’ The answer is usually yes, especially if you believe that the value you bring to your company isn’t reflected in your salary. If you feel underpaid, you are likely correct.
00:14:45.600
Many individuals are hesitant to ask for pay raises or negotiate salaries because of discomfort surrounding money discussions. Personally, I have become more assertive in this arena and have often been surprised at how simply asking for what I believe I'm worth has yielded positive results.
00:15:32.920
I would encourage everyone to pass what I call the giggle test when discussing salary. This means being able to state your desired amount without laughing or feeling overly awkward about it. Understanding your worth is critical, and the quest for fair compensation should be part of your overall career strategy.
00:16:20.320
Finally, I want to emphasize the importance of salary transparency among colleagues. Most employees do not discuss their salaries, leading to gaps in information. Understanding market value and sharing compensation information can help level the playing field and ensure you receive fair compensation.
00:17:07.520
Lastly, let’s touch on the topic of test-driven development (TDD). I frequently get asked how one can learn TDD. People often associate it with a daunting, all-or-nothing approach, which can be intimidating for beginners. However, the truth is, you can integrate some testing into your workflow without entirely adopting TDD.
00:17:58.880
Expressing that you can write code without tests while also emphasizing that any tests are better than no tests at all. It’s about making progress and slowly becoming more comfortable with the practice. As you grow more adept, you can continue to adopt more TDD practices over time.
00:18:43.760
To sum it up, while some tasks may prove difficult to test right away, it’s essential to strive for improvement as you adopt these new practices. Support from mentors and peers can be invaluable as you progress on this journey. Remember, every bit counts, and you can grow gradually in your understanding of TDD.
00:19:29.760
Somewhat related, I want to mention that Thoughtbot offers a learning service with one-on-one mentoring, workshops, screencasts, and eBooks that can help you progress. If you're interested, we have a discount code for those attending today: 'GOGARUCO,' in all caps, for 15% off your first month if you subscribe. Thank you all very much!
