The issue with small companies is that people are too free to do what they want. Want to fix a feature? Just go ahead and fix it. Let’s not put things through QA, let’s not test anything, just do a code hack and put it right in production. Like I said, small companies promote the “hero syndrome”. Everyone is going to save the day, but really they’re just patching the problem. It’s no mystery why smaller upstarts are generally poorly ran, or have poor business models. They have a great idea, but rarely have much planning and structure behind it.
The issue with developers is that the write code and think they can just forget about it. They aren't thinking about all the support people, and the users who use these products in production. I know oftentimes, developers don't want to fix their own mistakes and rather move on to the next cool thing. But unfortuantely, there is a product that has errors based one how the software was designed. You remember in school how they taught you about exception handling? You know how many developers don't put any sort exeception handling in their code? I read source code all the time with absolutely no comments in them. Poorly written code is pretty common in smaller companies. After all, in small companies is pretty much tunnel vision. Get it to work, get it to work now, who cares if your code is maintainable and supportable.
I like structure. I think there is a benefit for break fix developers to only work on break fix stuff, and have back end developers only work on back end stuff. I certainly don’t see the point of having one guy do 6 things. IF you’re doing everything, then something is surely lacking. The shops I’ve worked in have very complex pieces of software, highly distributed, and talks to multiple applications. There is no way in hell some guy making the business logic should be also writing servelets. Makes no sense, and not even realistic, when you think about the overall scale of the application.
But I’m rambling. The good thing about big companies is that you learn maturity. That’s really important, and you learn how to be accountable (something that is definitely lacking at smaller shops). I’ve spent most of my career in big companies (a few fortune 500, one fortune 100), and they’re overall better. I’ve definitely have been with smaller or mid sized companies, and while they grow pretty fast, they are literally all over the map. I worked for one company, a decent midsized company, who sales force was way too aggressive. We wrote bank software, which was to ensure users got real time balances. Not only was the sales force pulling in big banking names, but they were promising them some ridiculous uptime percentages. Oh, did I mention that they were running these off of Petium III Xeons which were already pretty old at the time (2007!). Again, that’s what small companies do, try to appear bigger than they really are. Needless to say, that company is in the middle of being acquired, simply because it was so poorly run, and tried to expand too far out of banking with no real model to do so.
I think a smaller company is a place you go later in your career. At least at that point you know better, you’re more mature, and you have many years of good practice. Bigger companies are restrictive, but they’re trying to maximize resources. On one hand, there is a lot of red tape in bigger companies, but on the other hand you don’t want people just freely doing anything they want to software that generates millions in revenues. It’s a shaky balance. But at the very least in big companies you are accountable. You write bad code there, and trust me you’ll have QA and a support staff trying to get you to fix it. And since you go through all sorts of change boards, needing to have you code promoted and peer reviewed, you’ll think twice and do the proper testing before you try to put your bad code into a release. It’s REALLY hard to learn that importance of that in a small company.