RailsConf CFP Outline
Article Table of Contents
- Idea 1: “Junior” Developers are the Solution to Many of Your Problems
- Desired Outcomes
I’m pitching some ideas for RailsConf. I only heard about it a few days ago (oops) so this is a bit rushed:
Idea 1: “Junior” Developers are the Solution to Many of Your Problems #
Our industry telegraphs: “We don’t want (or know how to handle) ‘Jr. Devs’.”
Jr. Devs, or as I call them: Early-career Software Developers, or ECSDs, have incredible value if their team/company/manager doesn’t “lock themselves out” of accessing this value.
Whoever figures out how to embrace the value of ECSDs will outperform their cohort. 📈💰🤗
I will speak to:
- Executives (CTOs/Eng VPs)
- Senior Developers/Dev Managers
- ECSDs themselves
About how to:
- Identify which problems are solvable because of ECSDs
- Get buy-in for these
- Start solving these problems with ECSDs
For Review Committee: #
This content will be visible only to the review committee.
Details (Include any pertinent details such as outlines, outcomes or intended audience.) #
I tried to get the important stuff in the abstract, like:
- Executives/senior leadership
- Senior developers/developer managers
- Early-career Software Developers (ECSD)
Desired Outcomes #
I’d like to start with a skeptical audience, or an uncertain audience, and move all of the audience to feeling equipped to “drive change” at whatever degree of influence they have within the organization.
if representative members of each of the three groups from the same company attended the talk, they could make all these changes in short order.
I scare-quoted “driving change” because it implies a degree of coercion or force-of-will, but the tools I want them to have will sidestep that coercion entirely, and instead equip them to deliver more value to their organization by perceiving the role of the ECSD differently.
By way of analogy: forcing someone to eat a certain way is coercive. Cooking a delicious meal for them that they enjoy? That’s a gift. Same result, very different method.
desired outcome for an executive/cto/vp engineering: #
“I can explain to my department and other business units how improving the experience of ECSDs at my company will guarantee hiring/promotion pipelines inside of my organization, allowing me to spend less time and opportunity cost on trying to get the right people, while also reducing my exposure to the risk of a bad hire”
desired outcome for a senior developer/developer manager: #
“I can explain why my direct and effortful contributions to the learning, well-being, and safety of my team’s ECSD unlocks growth and value at several levels of the organization, including, but not limited to:
- the experience of ECSDs (duh)
- speed of feature development
- change in overall technical debt in the application
- error rate (be it bugs, outages, missed deadlines)
- increases my own influence and reputation within my organization”
Desired outcome for an early-career software developer (ECSD) #
“I understand specific ways that I can bring value to my organization, and I know how to leverage my own inexperience to produce valuable artifacts that will lead to my own growth as a developer, and can speak confidently to those values, while understanding that I am part of a system, for better or worse, and am not the only individual with influence over the value I bring to an organization.”
Talk Outline: #
- Evidence that the industry is not welcoming to ECSDs
- Kinds of opportunity that is lost by not being welcomeing to ECSDs, in:
- speed/quality of onboarding
- growth in skills of ECSDs
- growth in skills of more experienced developers
- lost opportunities to connect ideas across domains and industries
- Levers available to (executives|sr engineers|ECSDs) to do something about this
I’ll be relying upon scientific and non-scientific literature like:
- William Khan: Psychological Conditions of Personal Engagement and Disengagement at Work
- Why Tacit Knowledge is More Important Than Deliberate Practice
- Structural Holes and Good Ideas, American Journal of Sociology, 2004
- Hiring is Broken: What Do Developers Say About Technical Interviews
- The 2 Sigma Problem: The Search for Methods of Group Instruction as Effective as One-to-One Tutoring (Benjamin Bloom, 1984)
- Conditions for Intuitive Expertise: A Failure to Disagree, Kahneman & Klein, Princeton, 2009
- The Secret of Our Success: How Culture Is Driving Human Evolution, Domesticating Our Species, and Making Us Smarter
- How Complex Systems Fail
- Leading/lagging indicators of success
- There’s lots that can be used for benchmarking “where you are” and “where are you going”, and speak to indicators of success for all three target audience cohorts.
The industry is growing quite quickly, with “junior developers” being an “ever-present problem”. (Ugh, I’m channeling words others have said, not my own actual thoughts.)
So many ECSDs go through tremendous effort to get into the industry, hit it wide-eyed and excited, only to be told “you’re not good enough because you’re new”, or “only once you’ve spent time here will we treat you like a valuable contribution to our company”
I don’t think that recommending experienced developers “be more welcoming” is going to effect meaningful change. Those who are amenable to this suggestion are already implementing it, and those who are not amenable don’t really care. ¯_(ツ)_/¯
So, I want to explain in extremely clear language the benefits that accrue to persons at various levels of the engineering organization if they start acting like ECSDs have unique and meaningful contributions, partially because of their newness.
There’s very real money to be made, industries to be transformed, individuals to be impacted, by persons adapting this thinking. The more senior the person is who gets onboard, the more impact this kind of thinking will have within an organization.