Every CS student knows the drill. You get an assignment, write your code on your laptop using localhost, zip the folder, and submit it before midni...
For further actions, you may consider blocking this person and/or reporting abuse
Point 4 suggests a useful course exercise: swap projects with a classmate and fix one bug using only their README and logs. Then have them deploy your fix from a clean environment. That would expose a lot of the assumptions that disappear when the original author is sitting beside you.
The CORS + missing env vars combo on first deploy is basically a rite of passage 😅
Point #4 is the one I wish more students heard. "Reading code you didn't write" is half the actual job, and almost nobody puts it on their resume — even though "debugged and fixed X in an inherited codebase" is one of the strongest things a fresher can show.
Great list — sharing this with a few students I know.
I love the resume tip, never really thought of putting inherited code fixes on there but it makes so much sense. Thanks for sharing it with them!
Glad it clicked! Fixing inherited code is real-world proof, and recruiters love seeing 'debugged and shipped someone else's code.' Keep the posts coming, Maame!
Will sure do! Thanks for the read Madan :)
APIs are notorious for sending webhooks twice, late, or without some fields. My code has to handle the possibilities. Testing locally doesn’t cover them.
also applies to Cloudflare Workers. You may think you have an environment that works, but then it fails after deployment.
Limits and bindings are different between the two. What was the first platform you deployed your code on?
Totally agree. Local testing only shows you the happy path. My first deploy was on Google Cloud Run, and it failed straight away because the container wasn’t listening on the port Cloud Run expected. Worked perfectly on my machine, of course 😂
Great! Indeed that's how real life works, and it is very well relevant to any sphere of life. One thing when you messed up with CORS and completely another when for example house project you've created after uni without real life practice caused issues to this house after it was constructed.
Thank you! You’re right, it applies everywhere. With code you can fix a mistake and redeploy the same day, but with a building the mistake stays there for years. That’s why real practice matters so much before you’re trusted with something that big. Thanks for reading Vitaliy
The point about reading code written by other people stood out to me. I think it's an underrated skill, especially when working on real projects. Getting your code to work is one thing, but understanding and fixing problems in an existing codebase is a different challenge altogether. Really enjoyed reading this.
well said Akintayo! thanks for the read :)
the localhost gap is the one that hits hardest on first deployment because nothing in a CS curriculum tests the assumption that your machine represents reality. you debug locally, it passes, and then you learn that the prod database uses a different collation, the CDN caches your 404, and your env vars never made it to the container.
the mental model shift I would add to your list: code is not software until someone else runs it. until then it is a script that works in the right conditions.
which of the five hit you hardest on your internship? my guess is deployment but the networking piece sneaks up on a lot of people.
Haha yes, deployment got me the worst! The first time I deployed, my backend kept crashing and I thought my code was wrong. I spent hours on it. In the end, I had just forgotten to add my database link to the server. It was only on my laptop 😅
I fixed that and felt happy for 5 minutes. Then CORS stopped my frontend from talking to my backend. That never happened on localhost.
Also, I love the statement “code is not software until someone else runs it.”
Currently doing an internship and relate to every one of the points.
Exactly Ayesha!
Yes, this is spot on. You might not run into this challenge until you start building real world projects. Liked
exactly Richard
The 'breaking things is how you learn' point seems strongest when recovery is part of the exercise. A first deployment assignment could require deliberately shipping a bad configuration, recognizing the failure from logs, and restoring the previous version without losing stored data. That adds something beyond getting the app online once: knowing what to do when the next change breaks it. Would you put rollback practice alongside deployment in the course you wish you'd had?