Member-only story
The Unwritten Rules of Software Engineering No One Tells You About
“You’ll figure it out as you go.”
I remember hearing this phrase during my first month as a software engineer. Back then, I thought it meant learning new coding languages or mastering a tricky framework. Little did I know, it was more about figuring out the unwritten rules — the things no one explicitly teaches you but can make or break your experience in the world of software development.
Let me share a few lessons I wish someone had told me when I first started.
1. You’re Not Paid to Write Code. You’re Paid to Solve Problems.
I had this one all wrong in the beginning. I used to think my worth as an engineer was tied to how much code I could churn out. The more lines of code, the better I felt about my productivity.
Then one day, I submitted a 500-line code change for a new feature. I was proud of myself, thinking I’d crushed it. But when my senior engineer reviewed it, he said, “Great job on functionality. But can you make it simpler?”
Simpler? I didn’t understand at first. But after refactoring the code and reducing it by half, I realized it was easier to read, less prone to bugs, and more maintainable. That’s when I learned: it’s not about the quantity of code…
