What's something you learned on the job that no tutorial ever prepared you for?
Posted by Pure_Relationship809@reddit | learnprogramming | View on Reddit | 21 comments
Tutorials are great for syntax and concepts, but there's a whole category of things you only pick up once you're working on a real codebase with real constraints and real teammates.
For me it was reading other people's code — specifically, old code written under deadline pressure with no comments. Tutorials always show clean, well-structured examples. Production code is... different.
What's yours? Could be technical (debugging, testing, architecture) or non-technical (communication, estimation, requirements that change halfway through a sprint).
aanzeijar@reddit
I specifically mention that often here. Reading code is a skill that should be practiced, and not only for legacy projects or as an end in itself. You will find constructions and tricks in real life code you wouldn't have found on your own, and you'll learn what the common solution to many problems is just by reading lots of real life open source code.
Only learning from tutorials is like being a carpenter and never having seen a table in real life.
Hayyner@reddit
I felt that school and tutorials never really teach you to think about the real implicactions behind many decisions we make when implementing solutions.
Like performance, security, UX, maintainability and extensibility, etc.
ItsVoxxed@reddit
Not a programmer but kinda adjacent field.
They try to tell you but no one can prepare you for the amount of shit held together by prayer and duct tape.
EliSka93@reddit
You guys got duct tape? Oh man you must work for a high class place...
We only got prayers, and we're all atheists.
Express-Channel-1686@reddit
no tutorial covers how much of the job is reading code that someone else wrote 5 years ago and quit. tutorials always start with a clean repo. real work starts with 'figure out why this thing nobody understands keeps breaking on tuesdays'
also: how often the right answer is 'just delete it'. removing code is underrated
lifeistoolong_007@reddit
bro i'm still in uni but this whole thread is making me nervous ngl how do you even survive reading old code with zero comments 💀
mizukagedrac@reddit
A bit of praying. A bit of hope that there are some unit tests. And a willingness to get down and dirty and break things for a bit (just not in prod) to figure out how things work together.
When I first started as a junior SE, one of my first tasks to write the unit tests and that actually helped a lot in trying to understand what functions did or what the expected inputs/outputs were meant to be.
lifeistoolong_007@reddit
bro the praying part got me 💀💀 never thought about unit tests that way actually that's kinda genius ngl saving this for when i am in that situation
Kane_ASAX@reddit
Most companies that hire you understand that you cannot realistically build anything for like the first 3-6 months. This period is used so you can learn the codebase. Expect someone to help guide you into it for example.
If its a company that does not have someone to explain shit, its your chance to shine. It means you have leverage once you learn the codebase.
The codebase im working in now ill use the AI to help me nagivate sometimes😅 like if i call this function, where does the functions inside it live. What payload does it expect, or what table does it connect to etc. 4 months in and I already co-developed a gnarly learner management system
lifeistoolong_007@reddit
4 months and already building a learner management system bro that's actually insane and that point about using AI to navigate the codebase not write it is actually a different way of thinking about it never thought of it like that
Kane_ASAX@reddit
Oh ive been working for like months already. So that feature is already in production and being used. Im still adding more features as our client gets ideas though(like using the same concept but for performance reviews)
Did I mention I'm doing all of this on whatsapp?
AWS_CloudSeal@reddit
Great question. A few things nobody warned me about:
Juniors think the job is coding. It is not. It is understanding what the business actually needs versus what they said they need. These are almost never the same thing.
Estimation is a trap. Every tutorial teaches you to build things. Nobody teaches you that when your manager asks "how long will this take?" the real answer is always multiply whatever you think by 3 and you will still be late.
Legacy code is the real world. Tutorials show you clean greenfield projects. Real jobs are 80% reading and understanding code written by someone who left the company 3 years ago with zero documentation.
Communication beats technical skill at junior and mid level. The developer who explains their work clearly gets promoted faster than the one who writes perfect code but cannot articulate what they did or why.
Tests are not optional extras. Every tutorial treats testing as a bonus section at the end. In real production code untested changes break things at 3am on a Friday and it is your phone that rings.
Requirements change. Always. You will build something perfectly to spec and then be told that is not what they wanted. Learning not to take this personally took me longer than learning any programming language.
The biggest one overall — soft skills compound faster than technical skills after your first 2 years. The best developers I know are great communicators first and great coders second.
HolyPommeDeTerre@reddit
Reading someone's else code is the hardest thing.
I want to insist on your comment about pressured dev outputting code. At this point, the dev just project their mind into code and outputs the solution. When reading their code, you're going to have to enter their mindset.
The most structured it is, the easiest it is to review. That's why we generally add up some architecture to force all devs to write the same code. This aligns the mindset.
But reality is a b*tch, this architecture will change over time. And old code will be from an old mindset. Reviewing it will become harder and harder with time. Especially for new hires.
You can feel that very strong when you read your own code from 3 to 6 months ago. You generally sayl "oh wow, what a mess".
AntiDynamo@reddit
The need to keep changes minimal and targeted. In interconnected systems, the more things you change, the more will go wrong. Every PR is its own scream test
The need to communicate with people and understand what they need and what the business needs. Oftentimes people don’t ask for the most reasonable things, or even necessarily know what they want. Different design choices have trade offs, and the most obvious/simple solution right now could mean a lot of pain later on. You have to think ahead
Code is communication. Other developers need to be able to read it and understand it. It is often better to do something in a slightly less sexy way if it makes it easier to debug and maintain
434f4445@reddit
Nothing in programming CS IT certs or anything can prepare you for the mess that is any existing IT system and integrations real environments are messy despite and are only messier the older a company is.
NationsAnarchy@reddit
Deadline management + communications
Striking_Rate_7390@reddit
conversation skills*
Unlikely_Studio_5115@reddit
Can't stress this enough. The amount of time I spend explaining why certain approaches won't work in production environment vs what looks good in demo is wild
Also learned that sometimes the "ugly" solution that works reliably beats elegant code that breaks under load. Military systems don't care how pretty your algorithm is if it crashes when you need it most
sf_d@reddit
how to understand real-life business requirements and translate into technical terms.
Zesher_@reddit
Project architectures can be very unique and noval, participating in design meetings teaches you a ton on how to think about going about crafting a new project or feature
John_8PM_call@reddit
I was going to say reading other people’s code too. Also, knowing WHERE in this massive codebase the fix needs to be made. In school you have toy projects. In big companies you have codebases that are millions of lines in length. How do you know that bug fix X needs to be in class Y?
Oh, also, I didn’t learn certain git commands or how to deal with certain git issues in university. Like when doing real work there are a lot of merge conflicts, rebase conflicts, that sort of stuff.