I recently moved into a role where programming is my full-time job. Before that, I spent about eight years in a position where programming was only around 20% of my work. It involved a low-code platform, and practices like clean code, version control, code reviews, and unit testing were not emphasized. Most of my coding experience came from occasionally writing scripts of up to roughly 500 lines.
The transition has been much harder than I expected. Tasks take me significantly longer than they take my colleagues, and I rely on Copilot fairly often to keep up. I have been working evenings and weekends so I do not fall behind, which has made me worry that I am slowing the team down or bothering the senior developers. The project itself is already messy, and even experienced team members seem frustrated with it.
I am self-taught and do not have a computer science degree, so I feel extremely lucky to have gotten this opportunity and worry that I will not get another chance if I am moved back to my previous role. When does this usually start to feel easier? Is my experience normal, and how can I improve without constantly working outside my scheduled hours?
4 Answers
The first few months in a large codebase can feel like studying a new subject every week. Navigating the repository, learning the build process, understanding deployment, and picking up tools such as containers all take time. Keep a personal notes file, record recurring commands and concepts, and make a map of the parts of the system you touch. Revisit it regularly instead of trying to memorize everything at once.
Your lack of a degree is probably less important than your ability to learn, communicate, and steadily deliver useful changes. You already have experience building and refactoring personal projects, which is a good foundation. Ask for regular feedback about priorities and progress, and tell your manager that the extra hours are a sign you need better estimates or support—not something the team should quietly expect. With consistent exposure, many people notice meaningful improvement after a few months and much more confidence after roughly a year.
This is a normal transition, but working every evening and weekend is not a sustainable solution. You may be comparing your learning speed with coworkers who already know the codebase and internal conventions. Ask your manager or a teammate to help break assignments into smaller steps, and agree on what a reasonable first version looks like before spending hours exploring every possibility. A short design discussion early in the task can save most of a day.
It would help to separate what is difficult. There is the general engineering work—understanding requirements, choosing an approach, debugging, testing, and designing changes—and there is the specific environment, codebase, and tooling used by your team. The second category can be slow for almost anyone when documentation is poor. Even experienced developers need time to learn an unfamiliar system.
The hardest part is often getting started. I can spend half a day figuring out where a feature belongs and which of several possible approaches the team expects. The unfamiliar tools also involve a lot of trial and error, and sometimes there is little documentation. I try to research before asking questions because I do not want to waste anyone’s time.
Also, asking a focused question is not the same as asking a stupid question. Explain what you tried, what you expected, and where you are stuck. That gives people enough context to answer quickly and often exposes assumptions you did not know you had.