Is “Experience working on large projects” something that I should strive for?

Question

This is in the context of job search.

There are fancy words such as "Enterprise software" (as opposed to a school project). Then there is the experience of developing/architecting large software products - something that some employers desire.

While large companies may pride themselves in being able to create the "nuclear power plant equivalent", I personally see little glory in that. Surely, individual things like the Google search engine, or MS Office, or .Net framework are impressive.

But then there are things less glamorous. I have worked for a couple of giants, and do not see what the big deal is. Surely, 50 programmers (+ 10 analysts and 5 managers etc.) can build something big over 4 years, but 2 programmers in 1 year can build a lot more than 1% of the comparable thing.

In fact, before I had my BS degree and worked for a lab in college, I put together some code that impressed me at the time ;), but I have not seen too many examples of great code since.

Long-term I think I want to gravitate to a small company. So, I wonder if I have an excuse to be opinionated about large companies, or do I truly have something to learn from working on a large project (other than: business folks do not understand software, politics sucks, we are moving too slowly, we are stuck with bad karma, we are supporting too many branches and customizations which should be dead by now, it ought to take less than 2 days to get a dev machine set up, it ought to take less than 4 hours to complete a build, unit tests would be nice)?

Have you worked on a large project and learned something invaluable, something that you would not learn in a smaller place?

Please share good and bad stories.

Answer 1

I think something to take from working on large projects is experience of how communication, knowledge transfer and processes are organized when more than three people are involved.

It is a big difference whether you work in a small team where communication is easy and decisions are only made between a limited number of people (which is not to say that coming up with a consensus is necessarily easy with just two or three people).

So, it's not that it's the project size that I think makes a difference, but it's a different way of working when more people are involved and you have to make sure that everyone knows what is happening and what they need to do, where to get information and where to put information.

The code might not be better, neither is a big project more interesting per se. Of course if the project is organized poorly and people are complaining all the time than you're not better off and it is likely that you can't really make much of a change. However if you're working in an environment with generally capable people and a working organization I think it's exactly that which you can take from it.

I wouldn't generally say that one is better than the other, but I would probably advise everyone to both work in a small team AND in a larger team just to make the experience at least once in their career and see the difference for themselves.

EDITED TO ADD: From my personal experience I've worked in a small team in a small company in a big team (together with multiple teams in Vietnam and England) in a medium-sized company and in a small team in a big company. Each experience has been a lot different from the other, each with its pros and cons. Working in a big team, though, has been the most fun so far, because it was a huge challenge and I enjoyed working with so many different people and working out problems on a larger scale.

So, what I think is one of the big advantages of a larger project is that you usually have to work with a lot more people which - although it can be a challenge - also provides you with the experience of dealing with all sorts of people with different backgrounds while still working for the same goal.

---

You should not strive for "Experience working on large projects", but for "Experience working on all kinds of projects in all kinds of teams". First of all for yourself. But also, on your CV it proves that you are someone who isn't focused on a specific kind of environment, but able to adapt and work productively in all kinds of environments.

Answer 2

Some (but certainly not all) of the things I have learnt from working on very large projects in a large-ish company:

• I thought I knew what a "large" project was when I started here. I was wrong. ;)
• How to work productively with larger (10-20+ member) teams, not just developers but also analysts, testers, architects, data modellers, managers, clients / project sponsors
• How to interact productively with other large teams under the same umbrella.
• How to prioritize maintenance tasks in terms of the "big picture".
• How to deal with things like "business folks do not understand software" (you help teach them), "politics suck" (it doesn't always have to, but it takes time to get good at this), "we are stuck with bad karma" (that's just a weak excuse)...
• How to deal with conflicting assignments from multiple managers/leads/projects.

Answer 3

Anne hit on the experience issue. You don't have to work for a large company to build an application that handles a lot of data for a lot of users.

You're right about the large company mentality. Part of that is always wanting to hedge their bet, they wonder about things like scalability. If we add 5000 employees, is this thing going to work?

Answer 4

First there is the quantifying of large here. Does working for 2 years on a Content Management system with a 8-digit budget count as large or are there projects substantially bigger than this? I don't know the answer for sure but I do know that one point you are missing is that there are a few different environments for developers. Here are my 3 general buckets:

1. Product development - This is where you'd be working on the software the company sells, either as a product or as a service. I have been here which can be different from the other cases as this could be seen as the heart of the company in a sense. Putting in features for customers or potential customers, resolving bugs, etc.

2. IS department - This is where you get to be working on various customizations that a company has on the off-the-shelf software so that this is "Acme's ERP" rather than the straight stuff that doesn't have anything fancy in it.

3. Consulting firms hired to bridge the two - This is where a company may have expertise in SAP or Oracle and thus sell services to help other companies install the behemoth software known as "Enterprise." Here the projects would likely be more contract-based and once the job is done someone moves onto something completely different while the other two cases can involve long-term support that may not be the case with the hired guns in a sense.

The people that may enjoy that third work environment may well want to see working on large projects as that is what pays the bills to some extent. On the flip side, don't think that just because you are in a small company that you can't find large projects or have complex issues where if someone has been there previously, they may have ideas on how to handle or not handle the situation.

Answer 5

I agree that the developer that use enterprise word in his CV gives far too much importance to himself. I think it's just a problem of poorly managed ego.

Here are some of the things I really love in enterprise project development.

• The project is exiting when everybody in the team has the same goal, is at the same level, and when they succeed together as a whole. Since the project usually take longer to complete, milestones and deadlines are a good reason to live the success all together. The feeling is just extraordinary.

• Challenges tend to be bigger in enterprise projects. At least in my experience. Which is one of the most demanding property of a project when you ask a developer.

• You learn fast when working in a such team. I had the chance to work with brilliant people allowing me to learn from them quickly. All advanced stuff I know is from enterprise projects I worked on.

• You have lot of opportunities to coach and share knowledge. You can develop skills not directly related to programming which is invaluable for your career.

• There is usually more money in big projects, so slow computer or bad tools is very rare. You get what you ask for.

• It's easier to work on enterprise projects (and being paid well) when you are freelance. For the previous reason. In fact, you can't survive as a freelance outside enterprise projects.

• The latest technologies were used in most projects I worked on.