Search for a command to run...
Reflections on working as a software developer intern at a small company, covering technical debt, overtime, communication, and team structure.
Self-taught Software Engineer from Singapore (that eventually goes to school for it). Passionate about building new stuff that helps people save time!
No comments yet. Be the first to comment.
My stint with Apple Music has come to an unfortunate end. I’m not trying to make it sound like a huge breakup note reveal. I’m actually writing this to reflect on my time with both services. It was an
Why my RAG system failed using ChromaDB and local embeddings — and how better context and data structuring fixed retrieval accuracy.
How we used Roblox Studio and Lua to build a 3D cybersecurity CTF game for students — and what we learned from bugs, refactors, and live demos.
Is Swift worth learning for React Native developers? An in-depth comparison of SwiftUI, SwiftData, DX, performance, and ecosystem maturity.
How I built a personalized graduation website with Next.js, Redis, access codes, and a server-side countdown to stop cheating.
Since March of 2023, I've been interning as a software developer at a small company. Like small as in, 4 developers working on the project with direct communications to the boss, who acts as a project manager/supervisor. Working in a small company has its benefits such as not being too strict on the time you arrive at work (though, obviously, this is not universal, although highly likely). In the upcoming sections, I am going to talk about the things that I have observed and learned as a software developer intern.
First, you grow up in college (polytechnic) with the fact that the friends or classmates you have are well-versed in your course (or study). Everyone around you know what you mean by "debugging" and "fixing that one bug". And it was somewhat of a culture shock to me that in the real world, not everyone understands the "under-the-hood" processes that happen. This is highly emphasized when my supervisor (or boss) asks for the timeline and I have to explain that there will be some setbacks to the initial timeline because of technical limitations (in which I go in-depth) until the confusion sinks in their face and I realized that they do not understand a single bit of what I have just explained.
I find it easier to use analogies in real life or maybe a run-down version of what is happening.
Sure, we get pushed around as interns. But I do have to remind everybody that the position I signed up for requires us to have experience in React, Typescript, Nest.js and other frameworks. The lie in "no prior experience needed" is a huge lie and should be the biggest sin in this world.
Obviously, I'm joking. But the real fact is that we are expected to work overtime even though not explicitly said. I feel pressured because I am the project manager and am expected to be the man between my team and the boss.
That also means that I need to work overtime to compensate for the things that we didn't do in the office, such as creating and reviewing Pull Requests, merging them and ensuring compatibility.
And I'm not being paid for overtime (but who am I to complain, After all, I am an intern).
Small companies tend to not have the budget for their developers. And that is factual. When I entered the company, there was no structure. Everything was here and there and very disorganized.
This makes collaborating hard. Which is why I introduced structure within the software team. Some of them include using some elements of the Scrum methodology such as having a backlog, reviewing code, code review and retrospective. I also instilled the importance of VCS, Pull requests, branch naming conventions, conventional commits, atomic commits and many more. As a result of the policies I introduced, the software team became easier to manage. Especially for the current project manager who will be accepting PRs and merging PRs.
I am the project manager for this current sprint, which is the last leg before the release of the first version of the application. That also means that there is a strict timeline involved during this sprint.
First, this is hard. On top of the overtime that I have been doing, I also have to do more work past my working hours.
Second, managing the team must be stellar. In this last leg, it is obvious that there can't be any mess-ups and if there are any, it needs to be rectified immediately. I also had to delegate tasks to team members who specialize in them. This helps the team to make faster progress over time.
I believe that being a Project Manager allows me to on a power trip but I also realize to do it cautiously. Sure, you feel like you're managing the team but it is also important to consider the interest of the team and the goal at the end. Being on a power trip is beneficial if it benefits the team, boosts team morale while working towards our goal and should never be used to self-indulge in power (I learned this the hard way).
I have seen this first hand (and I am sure other people too!). You create a feature, you create the most bare-bones thing to get it working and by the time you want to clean up, you realise that you've used all of your time and have to push to the development branch.
Now there are two possible outcomes: Stay around to see the technical debt bite you in the ass or quit your job, find a new job and let the new people handle the technical debt.
Surely, being an intern for a year, we're on the former outcome. Yaouch! The technical debt in question is the "chat" feature that is enabled by Ably that is poorly implemented that bites us in the ass which caused slowdowns in the team's progress and productivity.
Remember, always write clean code and ensure you have time to clean up the code you wrote. If you do not have time, remember that you can always revisit it later, but make it your priority to revisit.
In a small company, things tend to get disorganized, with no structure and that is the new norm. You just have to deal with it. There may be days where the reviewer would give a green light on the feature and the next day might request additional features (that does seem easy to them) but between you and me, we all know it's gonna take time. Other processes might also not be done properly such as UI design review. For instance, the current project we are working on is based on the web version which means that the components on the mobile version of the app are copied from the web (with some pizzazz – such that it works on mobile) and we are working without wireframes (well, mainly because our company has no designers) and these UI decisions are instead made by the boss. The best way I could say it is this: "Some UI decisions are questionable".
So just keep in mind, that some processes that are taught to you in school may be switched up in the real world and these may be due to lack of manpower, costs or even time.
At the end of the day, we must remind ourselves that the projects we built are going to be used by our clients and not you, hence we don't need some of those trendy 3D things that are trending in UI these days.
I've never been at the other end of the spectrum, working in a big company with a relatively big software team. I'm pretty sure big companies' software team have more structure in them and does code review for real (rather than our role-play positions). But at the same time, these past months have been a great experience to learn and do (and also manage a team). Being at a small company with a half-assed software team has never been easy and will never be but at least we got some perks.
