Work & Study

2025-07-05

3 min read

This semester I landed my first freelance job. Ive worked before but never related with coding or engineering. These past few months have been intense: I’ve learned valuable lessons, gained real-world experience, felt overwhelmed, ridden highs of excitement, and—even—considered quitting. Most of the time, though, I woke up eager for the next day, excited to build and ship.

My job started off as something pretty small and short-term: just a simple website where users could read digital magazines. As time went by, the project became more complex, from front end to back end. We ended up with user accounts and automated email notifications, integrated payments and subscriptions on two different platforms, an admin page with login, and even a little mini-game inside the site.

Of course, by industry standards it’s still a small, manageable project—but since it was my first time collaborating with others and trying to meet their expectations while also attending uni, it felt challenging. I’m studying Software Engineering at ITBA, in the second semester of my second year. I still have many tough subjects ahead, so studying demands a big chunk of my time. I had to make choices and learn to manage my time as effectively as possible.

I’m not perfect at time management—I’d say I’m pretty bad—but I’m improving. This experience taught me two key lessons:

First realization: There are two kinds of responsibility-yours to yourself, and the one others demand from you.

I learned this shockingly fast in the first few weeks. I realized I felt more pressure to ship and deliver code than to study—and I knew why. When you study for a test, you’re accountable only to yourself: you want a good grade, and if you fail, you alone bear the frustration. It’s your effort, your result, and you accept both—even if sometimes bad luck plays a role.

But when you work for someone else, your output affects other people. You receive tasks, opinions, judgments, and—most importantly—expectations. You realize your code now impacts teammates or clients who rely on your knowledge, communication, ideas, and commitment. That shift hit me philosophically. I found myself prioritizing the project over classes—attending fewer lectures and pouring my energy into delivering for others. If I failed an exam, I’d be the only one suffering; if I missed a deadline, my teammates would feel the consequences. Work done on behalf of others felt more significant than work done for my own benefit—and it drove me to grind harder on the project.

Second realization: Half the work is done if the scope is well defined from the start*

A mentor warned me of this before I began: “Clarify requirements up front, thats the most important task.” I thought I’d nailed it—I even wrote a doc listing every feature my boss wanted, with dos and don’ts as specific as possible. Yet I could have been clearer. Its not only defining well what your boss tells you, but also you telling your boss where your job ends.

My advice: Be crystal clear about what your client or boss expects, and define exactly where your responsibility ends. That clarity protects everyone’s time and prevents unnecessary rewrites.

I had many calls and meetings where things changed and I had to re adapt or even delete code that fitted perfeclty for the first iteration of the product. I had to change things from week to week because my boss changed its mind. Im not blaming her, I know its part of working and life, Im blaming me, for not expecting it.

Back