As a junior developer, one finds oneself plagued with a multitude of difficulties. The manager’s role is to facilitate the setup, ensuring that all necessary tools, devices, and access are in place, enabling the dev to code and contribute. A mentor, in the form of a “buddy,” is assigned to provide guidance and assistance.

However, the junior dev is faced with numerous challenges, including determining the appropriate amount of enabling required to problem-solve independently, a lack of understanding regarding what constitutes a contribution, and the awkwardness that arises when seeking help and mentorship.

A crowded yet barren landscape of web development, it can seem hopeless, as programming evolves continuously. But such is not the case. While the leaders get consumed by the burden of learning new things and coordinating the adoption of new frameworks, they often disregard signals from others and focus solely on project management. They may adopt the mentality of, “If you can’t learn this, implement it, and solve it without my guidance, then you should just follow this spec.” This mindset creates a chasm between the lead and the junior, who is still in the process of learning to think in code, adapt to new systems, and develop semantic concepts. The lead may misinterpret the junior’s lack of progress as an inability to learn and adapt, when in reality, the junior is faced with a multitude of additional challenges, such as managing a complex codebase.

Self-doubt can be a developer’s greatest obstacle, and in the case of the junior dev, it is often exacerbated by a lack of acknowledgement from their peers. The dev may struggle with concepts that seem basic to others, such as shell commands or debugging tools, but they go unacknowledged. The dev is left to ponder, “Why do others blame others and create systems to overcome these difficulties, yet I am left to navigate these challenges alone?”

The onboarding process also presents its own set of difficulties. The dev wishes that someone had taken the time to explain the relationship between the codebase and the business or product offering, instead of simply handing over the repo and expecting the dev to understand. This lack of understanding cost the dev’s bosses three months of lost productivity, as they failed to schedule a simple 30-minute call to explain the project in plain terms.

After the onboarding process, the junior dev reflects on their shortcomings and the areas in which they were lacking knowledge. The dev confesses their ignorance in areas such as developing a website from scratch, network protocols, the purpose of an IDE, code execution and deployment, working with large data sets, bash terminal commands, collaboration on projects, debugging, programming languages and frameworks, APIs and microservices, libraries and packages, and configs and schemas.

The dev realizes that software is simply a mechanism for computing, generating, and manipulating objects, and reflects on the challenges they faced as a junior dev, wishing for a smoother onboarding process.

This experience, described with the haunting Kafkaesque style, serves as a reminder that the journey of a junior developer is not an easy one, but it is a necessary one in the world of technology.