00:00:05.040
Hi there! My name is Josh Thompson, and this is a recorded talk. It's a bit odd to record a talk like this, as usually when I work with people, I get to be in the same room or at least have some form of synchronous communication that allows for conversation, back and forth, questions, and hopefully some laughter.
00:00:11.400
However, we're in the middle of a pandemic, and everything is different. I wish I could be at RailsConf; I've never been before. I hope that next year we can all be together. The reason I mention all this is that this is not my first time recording this talk. Normally, when I give a talk and I'm done, I think of all the things I could have done better. But now, since I'm recording it, if I don't like how it went, I can just throw it all away and do it over again—which can become very time-consuming quickly.
00:00:37.920
So, we're going to do what great developers do: any bugs that arise in the rest of this talk, I'm simply going to say are features. Sound like a plan? I know none of us have ever done that—and if there were an audience, that would be a great point to laugh, but there's no audience here. Today, we'll be talking about Junior Developers, and I'm arguing that they are the solution to many of your problems. This is a bold premise, and I don't expect many or most of you to agree with me initially, but I hope that in the next 15 minutes or so, we can converge on a common understanding.
00:01:39.900
I'll have these notes and other slides available on my website, josh.works/railsconf. That's josh dot works, so you can easily find it. Additionally, you can find me on Twitter. Now, who am I? Before I got into software development in 2017, I spent many years in customer-facing roles, specifically in business-to-business software as a service applications. This background informs a lot of how I see the world and conduct my work today as a software developer.
00:02:18.660
In those roles, I did sales, customer support, and customer success. When the website broke, I was the one answering the phone for the angry customers, and at the time, I had no idea what was going wrong. Therefore, I have a lot of empathy for people in customer-facing roles. I believe software developers can also be effective in customer-facing roles. I've been working on Ruby on Rails since 2017, and I love those technologies. Lastly, I enjoy figuring out how knowledge transfer actually happens—a nuanced topic that we'll discuss later.
00:03:19.620
Let's talk about the software development industry's perception of junior developers. The industry often expresses its position on junior developers in various ways, but at the end of the day, it boils down to: 'We don't know how to handle junior developers.' Many companies claim that they're too advanced to employ junior developers because they are focused on changing the world and don't have time to be altruistic towards them.
00:04:02.159
I find the term 'junior' unhelpful. Instead, I'd rather use 'Early Career Software Developers' or 'ECSDs.' I'll refer to them as early career developers for the rest of this talk. So, our updated title is that early career software developers are the solution to many of your problems.
00:04:21.180
Why is this phrase chosen? Why not something like 'new developers' or just 'developers'? Well, there are several reasons rooted in different sources. Though I didn't coin the phrase, it is attributed to Patrick McKenzie, also known as Patty11 online. I read a couple of papers that show how this phrase, 'early career software developer,' gracefully combines core elements from those studies.
00:04:44.699
I'll be referencing three important papers. The first, 'Structural Holes and Good Ideas' by Ronald Burt from 2004, argues that individuals who connect across different organizational groups often generate disproportionately good ideas. In essence, people rooted in diverse domains or processes bring immense value. The paper highlights that people tied to multiple groups are more familiar with alternative ways of thinking and behaving, which isn't a groundbreaking idea, but it affirms that early career software developers may have substantial experience in other fields.
00:05:52.920
Next is the 'Two Sigma Problem,' a paper published by Benjamin Bloom in 1984 with a team. It demonstrates that with specific interventions, a class of 30 students can achieve results equivalent to individual one-on-one tutoring. Imagine if you had an early career software developer in the top two percent. If you feel that person could be a great fit in your organization, I want to emphasize that various interventions can help make anyone successful within your organization.
00:06:58.139
Lastly, from 2004, we have a paper titled 'The Psychological Conditions of Meaningfulness, Safety, and Availability and the Engagement of the Human Spirit at Work.' I don't know who comes up with these lengthy titles, but this research makes a crucial point: treating people well with dignity and respect leads to better outcomes. Engaged employees perform better at work as the literature confirms. This is why companies conduct employee satisfaction surveys.
00:08:16.260
The findings suggest that managers should establish safe working conditions and supportive relationships with their employees. The significance of these three papers lies in the audience I hope to address today, which includes executives like CEOs, CTOs, VPs of Engineering, and Directors of Engineering. Additionally, I aim to reach experienced developers or engineering managers who are working closely with early career software developers, as well as early career software developers themselves.
00:09:03.480
Each of these groups faces different problems, solutions, and challenges when it comes to gaining organizational buy-in. If at any point during this talk, you find what I'm saying interesting and would like to implement it in your organization or have someone care about it, I mention these papers because it can be beneficial when discussing funding for projects with your CFO. You can argue that creating a supportive environment leads to better performance and is financially responsible.
00:10:28.140
Now, let's explore how to identify the right problems, understand viable solutions, and—most importantly—how to gain organizational buy-in. Many good ideas fail to be implemented due to a lack of buy-in. This process doesn't have to happen sequentially; instead, I would argue that they should all occur in parallel and mutually reinforce each other.
00:10:49.740
The motivation behind these initiatives is clear. If you take action and succeed, several important metrics will likely improve, such as revenue and feature delivery rates. You’ll witness reduced regression rates, meaning fewer defects, and you'll foster an environment where people feel dignified, seen, and appreciated. Whoever can implement these changes first will certainly outperform their peers.
00:12:15.600
To illustrate, think about Gartner's Magic Quadrant. Organizations that take action on this will likely move up in the quadrant compared to their competitors. For senior developers or managers, you’ll outperform colleagues within similar job titles or industries. And for early career software developers, this knowledge empowers you to navigate your experience in a way that benefits everyone.
00:13:13.440
On the downside, those who fail to adapt will likely fall behind, leading to lower performance and higher dissatisfaction among employees. New cohorts of employees will emerge, and those who resist change will find themselves struggling, with declining trends and increased unhappiness.
00:13:54.420
It’s essential to understand that making a shift takes time. If you start paying attention to these principles, significant accomplishments can be achieved over time. I invite you to visit my website, josh.works/railsconf, to find links to all the papers I've mentioned today. You can also leave comments or questions there. I'll be available on the Discord Channel titled 'Junior Devs are the Solution to Many of Your Problems,' and I'd love to connect with everyone.
00:14:39.420
Now, let's dive into the problems. We shouldn't solely focus on identifying issues; also, we should actively seek solutions. We'll discuss traits of effective solutions and the importance of gaining organizational buy-in. We need to track both the solution's aspects and the buy-in process simultaneously.
00:15:19.699
When considering solutions that harness early career software developers, it is crucial that experienced developers work intentionally with these new team members. This collaboration is paramount. It closely resembles one-on-one tutoring, which has been proven effective.
00:15:38.040
Solutions should increase the capability of the entire team, not just one individual. While these solutions often require upfront investment, it’s important they yield meaningful returns relatively quickly. One common myth is that junior developers take too long to onboard.
00:16:34.360
People often claim it takes three to six months for a new developer to be fully productive, and they argue that the speed of their agile workflows can't accommodate that. However, I’m thankful for this perspective as it sheds light on the discomfort people feel about onboarding less experienced developers. Let’s discuss how early career software developers can help address the onboarding issues.
00:17:38.619
We'll approach this by focusing on the 'minimum viable buy-in' (MVB). Before solving any problems, it is necessary to get buy-in from your team, which can often act as a barrier to implementing good ideas. The title of a book 'The Obstacle is the Way' resonates, highlighting the importance of buy-in as the best path to enacting change.
00:18:20.340
If you cannot secure organizational buy-in, there are still ways to enact change, but it's essential to aim for it. Be prepared for resistance or pushback, as some might argue time constraints or existing commitments prohibit this. I recommend speaking with influential figures in your organization about this onboarding problem.
00:18:56.280
For example, if you are an executive, you might note that the long-term health of your company relies on a steady influx of new talent. If your organization can only hire senior talent, the pipeline is unsustainable. By creating a friendly environment for less experienced engineers, you're enhancing the engineering team's capabilities.
00:19:52.920
When it comes to onboarding, we should define good metrics to measure success. For new hires, a compelling metric could be the time it takes for them to go from accessing the Git repository to successfully pushing a ticket into production. A strong goal would be to achieve that within the first week.
00:20:45.840
Once a new engineer joins the team, they should pair with a more experienced colleague, focusing on the product environment while referencing the onboarding documentation. This ensures the procedures are clear, allowing gaps to be identified and filled collectively throughout the onboarding experience.
00:21:40.740
As organizations strive to improve their onboarding processes, they might look for opportunities to enhance their documentation. This could involve capturing and documenting lessons learned and pointing newer team members to essential resources, enabling them to find the necessary information as quickly as possible.
00:22:42.240
Following the completion of the onboarding process, those experiences can be formalized into constructive feedback loops. Each new hire can discover aspects of the onboarding that worked well or could be improved. Such contributions can be made directly into documentation, leading to evolving resources that accommodate future hires.
00:23:39.060
Conducting application demos can also serve to bridge the gap between early career developers and their experienced counterparts. By recording these walkthroughs and embedding them in a shared knowledge repository, effective onboarding can be facilitated, thereby hosting a streamlined process for sharing knowledge.
00:24:32.760
Finally, consider incorporating practical challenges such as past pull requests. New hires can learn from actual implementation work by reviewing past tickets or PRs demonstrating successful contributions, subsequently working through similar tasks themselves.
00:25:52.680
As your organization captures performance metrics, note areas where early career developers typically succeed in helping to ease the onboarding process. This assists in accurately measuring a willingness to adapt and identifying regions for training or improved resources.
00:26:54.420
Measure and celebrate successes. Metrics could involve reducing time to value for early career developers. For example, if your early career developers are cutting their onboarding time down to one week from three weeks, the considerable payroll saved becomes much more than just an efficiency gain.
00:27:53.640
Significant efficiencies arise from employees being able to bring others up to speed more effectively. Not only does this ease the immediate burden on senior engineers, but it also fosters a culture of collaboration and support in the long run.
00:29:22.920
By focusing on improving the onboarding process, you create more resilient, effective, and capable engineering teams. The stronger the onboarding process, the more confident early career developers will feel, which positively impacts internal promotion capabilities.
00:30:40.560
Finally, I would emphasize that addressing the onboarding issue concerning early career software developers is only one part of a larger strategy. Combine this with other efforts and you'll witness your team maturing into comfortable learning environments where knowledge can thrive.
00:31:38.640
I appreciate your attention today. If you find any of the content resonates with you and sparks your interest, I encourage you to reach out. I'd love to hear from you regardless of your position in the organization. Let’s work together to cultivate a welcoming atmosphere for early career software developers. I hope to see you all next year at RailsConf!