I started my programming career as a software engineer/developer from a dev shop (I can’t find the right term for it, call it a dev shop, web agency, software house or web company anything that makes sense to you. An agency/ a company that takes up projects to survive and grow). It was a small web shop with fewer people, however, I was introduced to an open source web development MVC framework in PHP and a great deal to learn about how professional web and software development is carried out.
Image Source : BrazenCareerlist Blog
After that in the entrepreneurial drive, we gave our company a physical presence and put our heart and soul in building it, I worked there for 2 years plus in total and was involved in many projects. It was a fantastic learning experience and I could see my growth. Then I went for my masters and after that joined a company in Dubai which is a product company (The company and the product are same, there are no projects as such, all it cares about is the product — nothing more nothing less). I’ve been working with this company for over a year now. I consider myself lucky to be working with start-ups, they teach you a lot of other things, not only hard skills of coding and solving technical problems.
This is not a story about where I worked, instead, it’s a comparison of what I learned in the course of years of working as a developer or some other name to the role that involves at least some coding. Start-ups or established companies, small 2-people company or a company with hundreds of developers, the primary distinction you need to make is — does the company take up client projects and deliver them or builds its product to sustain itself in the market. Here are some of the differences you get when working for both the types of companies.
Working for a dev shop
When you work for a dev shop you would generally experience the things mentioned below:
You can decide on a new way of doing things from software architecture to design and data modeling as you start fresh you have all the decision to make. It is a clean slate where you draw the picture but in a team naturally.
In a single day you will work on 2–3 projects, code a feature for Project A, solve a bug in Project B and deploy (usually a git push and pull or upload files) for Project C.
In a new project, you can start fresh choose your framework (maybe this time you want to go with Symfony 2 and not Zend, use Angular.js instead of Jquery). If you are in a decision making position you can do it, this will also depend on what the client wants if s/he has a say and also the company policy.
Multiple projects might have multiple frameworks or even languages (as mentioned above) in use and then you need to juggle all those.
Sometimes even though you are a developer you will get to make your hands dirty with some system administrator (sysadmin) job of setting up the domain, domain name servers and space allocation for Project A.
Some other time the Front-end guy + designer is not available and you write 3 lines of CSS to fix that overflow in the image for client X. It happens like that ;). Same thing you should sometime open photo-shop and move that image 5 pixels to the right. (This will heavily depend on the team size and responsibilities, in a start-up it will be expected)
A project management methodology will be on paper many times, collaborating among teams (primarily front-end and back-end) becomes a challenge at times. Even release management is a myth ;).
You meet many people who voice their requirements and depending on if its a website or web app (a web software I mean), sometimes it becomes difficult to put a price to the effort.
On the management level, the company might lack a clear vision and goal (unless investors fund the company the first question is how to sustain the company if its a start-up).
Image: An illustration what a single dev-shop can do.
Working for a product company
Things are entirely different when you work for a product company, the company is the product, as well as a company like Facebook, Twitter etc. The company has multiple products it sells in the market to sustain and grow. The largest software companies are of this type like Oracle, SAP etc. The company does not have web projects (mainly websites and web app/software) to deliver to the clients, it generally has only one or maybe more products. The things you experience working for a product company are as follows:
You are provided with an already built software and you need time to understand how it is built, then you can code new feature in the software or solve bugs in it.
As a developer, there is not a way to completely change the software design, data model or the software stack as generally its already running. (May even be some legacy everyone is scared it would break if you tamper with it.)
All your ideas, solutions and energy is generally focused on one product, you even get to work on things like performance, optimization, and things that enhance the whole product.
The frameworks, languages, and guidelines for development are fixed and as a developer, you cannot decide if you want to use Angular Js and not Jquery. (You will not change 1000 lines of Jquery for your whim.)
Generally you don’t get your hands dirty with system administrator or designer and front-end things, that is usually a no go territory.
Project management methodology is part of the system, you cannot go far if you don’t have an issue tracking system. Release management, deployments and source code version control (like git our favorite) are backbones for any product company as products are generally big and many developers work on parts of it.
The Product Manager or Project Manager gives requirements and IT can be the central pivot to make the company roll.
On the management level, the goals and vision is clear. The company may not be a software house but how to sustain does not depend on how many projects you do and deliver so its much focused on the product.
Image: some big names in the software product company space
I don’t work for a pure software company now but without doubts its not a dev shop it is a product company. If you are looking for an internship or a job change, do think about the company you want to join is a dev shop or a product company. It’s a personal decision on what you want to do but now you are informed on generally what will be expected of you in a dev shop Vs a product company.
In conclusion, I think its better working for a product company than a dev shop for the structured and managed way of working in a product company.
Originally published at geshan.com.np.
Top comments (9)
It’s all a matter of perspective I suppose: I founded a software / product business and was a dev there for 10 years. I moved to an agency a year a ago and I love the diversity of projects I work on now, the learning opportunities and working with multiple clients.
I've worked with both and now I'm a freelancer, I have to say that I never seem to decide between either. They both are valid ways to increase knowledge and advance one's career. The issue present themselves when you're not working on something you're interested in. The advantage of the services company is that you might be able to switch to something else, it's a little harder in a mid sized company that has a few if not one product.
Probably a developer in its career should try both :D
Both why not :)
In my experience a dev shop (services company) will ship you from project to project and work you to the bone.you are shipped out to customers who pay a premium daily rate and expect 110% of you.
That is also true to an extent.
Yeah there's no absolute definition. I believe my experience was the extreme services company where you are not valuable if you are not billable to a customer. Put me off services companies for a long time. Still won't go back.
Mature product companies are more about stained development paces and long term maintainability.
Start up companies regardless of the sector are a different story. Just buckle up for the ride.
only a bad one.
Stay away from body rentals :D
One I disagree with in relation to Product Companies:
"As a developer, there is not a way to completely change the software design, data model or the software stack as generally its already running."
From what I've seen, it's far easier to refactor software for an internal project (and more opportunity to do so), then convincing a client to pay a fortune to change from jQuery to Angular when the site already works - and they see nothing wrong with it.