Njuškalo Technology is a company with a history as long as our product itself: Njuškalo, the most prominent Croatian classifieds and marketplace website. In this article, as a developer that has been working for agencies for about nine years and a developer on a single product for the last three, I will try to outline some of the key differences between working on a single product and working on multiple ones.
To preface, I believe that both types of companies have merit in today’s market, but let me tell you a story of how I made the switch and how, even three years later, my passion for our particular little corner of the interwebs is still burning a red-hot flame.
In the beginning…
… I wanted to be a developer. No, I am not going to bore you with the sordid details, it’s enough to say that my keyboard was finely tuned for agency work, as well as small projects based on clients’ needs and desires. That is how I stepped into the pond, so to speak, just to realize that what I thought was a pond, was actually a vast ocean of knowledge just waiting to be discovered.
So, for nine years, I worked for different agencies, dealing with different clients, different needs, and different cases that honed my abilities.
And then, I got a call from Njuškalo Technology’s HR through the most unbelievable channel: LinkedIn. Setting up a meet, we kind of clicked, and Njuškalo took me into its fold. That’s when my agency work stopped and I started a new chapter of my life.
Now, that all sounds very dramatic, but I assure you, it wasn’t.
In the last three years, I guess I had a bit of time to really put things into perspective, so I think I can share my findings with you.
What is in a project?
First off, let’s define what the word “project” means to agencies and product companies. Basically, for an agency, a project is usually a website. Or an app of some kind. You get a client (I know it’s not easy getting clients but bear with me here), and they have an idea. It is your job to turn their idea into reality. So, for example, a client may ask for a web shop one month, and another can ask for a digital warehouse tracking app the next. Even if, as an agency, you use the same programming language, heck, the same framework, or even content management system, you are bound to get different, very client-specific cases so that those differences pile up, and you get completely different products in the end.
Also, an agency project can have a maintenance contract on it and you could spend your time fixing the small bugs they report or handling minor change requests from time to time.
But basically, that is where the project ends. After you finish work for this client, other than maintenance, you don’t need to work for them anymore.
When you’re working on a single product, your projects mean something completely different. Projects are usually new features, or sets of functionalities made to enhance the product in some way. In that same vein, the latest project I worked on was PayProtect, effectively changing Njuškalo’s whole outlook as a product: it no longer acts only as a classifieds website, it is now a fully-fledged marketplace, enabling people to buy and sell items through the site. So, the team I work in effectively changed what Njuškalo means to a bunch of people, making it a whole lot easier to buy and sell things with just a click of a button.
And we are not stopping there. Our work on this project is not over. We are continually enhancing it, optimizing it, and giving it love. Because we know that we are bringing value to our users by doing it.
So, it’s a radically different approach to what a project means, if you see what I mean.
The approach to coding is different
I don’t think agency coding has changed much in the last couple of years. You probably use Git, you have a master branch, you code your stuff in a single branch which is based on the task you need to do, you push to your branch, and merge to the main branch when you’re done. Simple as pie. Tests? Well, you would probably really like to write tests, but who has time for those? QA (Quality Assurance) process? Why have a dedicated QA when you can do your testing on the staging server yourself?
With product work, as developers, we have a bit more time to refine this simple process. When I start working on a task, I do make a branch, I do code the solution to the problem, but I am also required to write tests covering my particular task. My task also goes through a QC (Quality Control) process, where other teammates check on my work and approve it (or disapprove it). After that, somebody else does the QA. Regression is tested automatically for all the critical features. On top of that, a dedicated QA team then checks the whole task, and tests my work thoroughly, trying to break it. Then and only then, if everything checks out, it goes to production and I can brag about it to people.
Now, this all sounds a bit much, doesn’t it? It’s not actually moving fast, it’s probably (for most of you) moving slower than you might like. But we have a basic responsibility to our customers to have the product work at all times, and there are a lot of moving parts. If one of those parts is out of alignment, the whole ship rocks.
And personally, I like that my code goes through as many people as it does to reach its destination. It means I am less prone to failure and that our product is as stable as we can make it.
Keeping in touch with the times
I cannot truly say how many projects I worked on used cutting-edge technology for their time, only to leave them as is after they’re finished, with the mantra: “Well, if it works, it ain’t broke”.
See, that’s the deal with agency work. Project after project, you try and use cutting-edge technology, but then you need to do some maintenance, and it all comes crashing down since the project you’re maintaining was finished several years ago, is so many versions old, has things sticking out, and you find yourself working on code written in a standard older than you’re used to. The shiny, new thing keeps eluding you, you find yourself wanting a new project just so you could try to do a better job. There is no time to refactor your old code, there is no chance to do it either, because a new project is just behind the corner, and you’re in a rush to finish the old one.
At Njuškalo, we might be a bit slower in providing a cutting edge on our project, but we get there. After such an upgrade, everything becomes shiny and new, and since we’re constantly giving love to our project, we have time for refactors. I can sit back and enjoy coding like I wanted to all my life, seeing mistakes I did a while back and fixing them, knowing I’m leaving a better landscape for future developers and my future self.
A candle burning on two ends
Let’s say you’re working for a very successful agency, and you have projects piled up to your neck. I argue here that you have a better chance of burning out than you do working on a single product.
It’s not a matter of different coding styles, it’s a completely different focus shift you experience when you work on multiple different websites, with their own specific issues, with their own needs, and with different versions of technology, which means different approaches to coding, etc.
With something as stable as a product such as our beloved Njuškalo, we might experience different needs for different projects as well, they might even be very different, but our code and architecture following the same course makes it easier to debug and solve issues without really shifting our focus. There are teams that handle different parts of the product, and one can always rely on their coworkers to help them solve the issue. After all, with as many developers as we have in our company, there’s always someone bound to help, even as a rubber ducky, while we’re solving the thing ourselves.
In conclusion
Working on different projects and handling them at the same time can be a daunting task, and it truly sometimes overwhelms you. So, I would definitely say that, when you’re a junior, or even a mid, just learning the trade, working for an agency definitely helps you learn to view a problem from different aspects. This gets invaluable later when you’re working on a product and you face other issues which are similar to something you already worked on previously.
Working on a product teaches you to slow down as well, and concentrate on quality work which stands the test of time if you apply yourself to it meticulously.
Reading this back, this whole article sounds like a pitch for developers. Like bragging that we have it good. And maybe, in a way, it is. If you like what you’ve read so far, don’t be afraid to reach out. Perhaps your own journey might be starting right now.
Top comments (0)