I still remember the relief I felt after submitting a major data structures project.
The code worked. Every required test case passed. I had spent days debugging it, rewriting sections, and trying to make sure nothing broke before submission. When the grade came back, it was good enough that I didn't think much about the project anymore.
That changed during a conversation with my teaching assistant.
While discussing the assignment, she mentioned that although my program produced the correct results, the code itself had problems. Some methods were doing far too many things at once. Similar logic appeared in multiple places. Certain variable names were confusing, and parts of the implementation would become difficult to maintain if the project grew larger.
Her comments caught me off guard.
I had assumed that working code meant good code.
Apparently, those weren't the same thing.
The more I thought about it, the more uncomfortable I became. I had managed to complete the assignment and earn a respectable grade, but I wasn't sure I was actually developing good programming habits. I started wondering whether I had been focusing too heavily on getting assignments to work instead of learning how to write better software.
When My TA Said My Code Worked But Wasn't Good
My first instinct was to find a tutor.
I signed up for Codementor because I thought additional explanation would solve the problem. I expected more theory, more examples, and more discussion around programming fundamentals.
What I found was slightly different.
Instead of only explaining concepts, mentors often reviewed my actual code. They pointed out places where I could simplify logic, improve organization, or make my programs easier to understand. They discussed design decisions, suggested alternative approaches, and explained why certain programming practices mattered.
For the first time, someone wasn't just teaching me concepts. They were showing me how those concepts appeared inside my own work.
That experience changed how I viewed programming.
Lectures and textbooks had taught me algorithms, data structures, and syntax. Code review showed me how to apply those ideas more effectively. Seeing feedback attached directly to my own projects made lessons feel far more practical.
What Codementor Actually Taught Me
But after several sessions, another issue surfaced.
Mentors naturally assumed I had time to revise, refactor, and iterate on my code. Under normal circumstances, that was reasonable.
College, however, rarely stays normal for long.
As the semester progressed, multiple projects, quizzes, and deadlines started overlapping. I could clearly see the improvements my mentors recommended, but I didn't always have enough time to implement every suggestion. Some weeks, I wasn't struggling to understand programming concepts. I was struggling to manage the sheer volume of work.
That was when I realized I had been treating very different problems as though they were the same.
Understanding concepts is one challenge.
Improving code quality through feedback is another.
Finishing large projects while several deadlines collide is something else entirely.
For a long time, I assumed that if I understood the material well enough, everything else would automatically fall into place. Experience showed me otherwise.
When Feedback Alone Wasn't Enough
Learning, feedback, and delivery operate on different timelines.
While exploring different workflows, I came across AssignmentDude. I didn't view it as a replacement for tutoring or mentoring. It simply appeared while I was looking at how other students managed heavy workloads and technical deadlines. More than anything, discovering different support models helped me realize that no single approach addressed every problem I was facing.
After that, I stopped expecting one resource to solve everything.
When I needed to understand unfamiliar concepts, I relied on lectures, independent study, and mentor discussions. When I wanted to improve the quality of my code, feedback sessions became extremely valuable. At first, this felt disorganized. Over time, it started making sense.
Stopping Expecting One Tool to Do Everything
I became less concerned with finding the perfect platform and more focused on understanding what problem I was actually trying to solve.
Was I confused about the theory? Did I need feedback on my implementation? Or was I simply overwhelmed by deadlines?
Answering those questions honestly changed how I approached both programming and academic support.
What I Actually Learned From All of This
My biggest mistake wasn't writing messy code.
It was assuming that passing tests and earning decent grades meant I was becoming a better developer.
Good grades matter, but they don't tell the whole story. Writing maintainable code, understanding design decisions, learning from feedback, and managing academic pressure all represent different skills.
Recognizing that distinction made a real difference.
I still use outside help when I need it. The difference now is that I spend more time asking what kind of help I actually need before looking for it.
Sometimes I need someone to explain a difficult concept.
Sometimes I need feedback on my code.
And sometimes I simply need support getting through an unusually demanding week.
Understanding those differences has taught me far more about learning to code than any single assignment ever could.
Sign in to leave a comment.