Ask HN: Not enjoying working at my 1st large company, are there any good ones? | Hacker News Reader

Ask HN: Not enjoying working at my 1st large company, are there any good ones?

8 pointsMrHeartBroken11 comments

I was working at a startup before that had to fold. Luckily in the Bay Area you have many companies that need engineers. I had multiple offers from big corporations. I took up one of them. The code here sucks. There are some talented people but barring them most are "Java developers".

Do all big companies suck? By suck I mean any two out of three of the following are true:

  1. Shitty code and a lot of tech debt
  2. Lack of hacker types
  3. No design work or challenges as everything has already been done
     and you just service these parts or reuse them

Sometimes I don't get why do we need so many employees to being with.

Some more things to rant about:

  1. How the whole systems works is a mystery
  2. May people use Git as the new SVN
  3. Code review is a thing that's done at a later point or sprint end
     while it may have gone live and broken things in between that
  4. There's layers on top of layers on top of layers built

Thanks,

Mr. Heart Borken

Corporations are there to make money, not to make beautiful code.

If you want to create code with love and care, do it at home. Or we'll have to do without money (= debt), and without corporations (= economic entites based on the money). Instead let's have a resource based economy, and realize that you don't need a lot of resources to code, as long as you don't have to get money to pay taxes to pay for being spied upon. http://thevenusproject.org

You will find this sort of thing in big and small companies, and find really good practices in both big and small companies. You will find tiny companies (< 20 engineers) with no code review, no unit tests, long lists of unfixed bugs, a resistance to source control not spelled "svn", broken custom written solutions when there are excellent open source or low cost alternatives, people that won't talk to each other, and so on.

In general I'd say you have a greater chance of changing things in a small company. But really, don't judge by company size but by the groups you talk to. Learn to interview better. Ask them about the workflow. Ask to see the code base. Ask about the balance of process vs pragmatism. Ask about the challenges (both in terms of interesting work, and then annoying stuff you deal with). If you seem to have it together more than the majority of people that you talk with, run away. If you don't think you can learn from them, run away. If you find yourself thinking "man, I'm really going to have to step up my game" take the offer.

One possible solution is to find a reasonably isolated, independent small group within a company. For example, groups that make custom software tools that other people in the company use can be more interesting, perhaps, than the main stuff the company works on.

So is this a common thing at big corporations? For instance, I was mid-process at Google but was not in a position to go wait to see where it goes. Then you hear about a story on HN about how the dl.google.com server was shitty and would take 24 hours to boot and was full of bugs.

I want to agree with @thenerdfiles in that you should make somewhere a better place to work in. It only takes one thing: the potential there that will make you "able" to achieve this goal.

believe me, I worked at a very dynamic, fresh startup for 4 years but with no room given to me for introducing stuff. Moved to a very large organisation but with the potential given to me. I'm very happy now.

Startups are usually so concerned with launch that the time to learn or implement new things is seen as a negative downside of the things to be implemented, indeed. Then one has to argue how the time afforded after the implementation would make up for the time spent during implementation.

On top of the virtues afforded of the thing itself. Like LESS.

Look at it this way, if you are charismatic enough you can install new standards where they do not exist.

I tried to get people to code review before merge and nobody cares. Nobody cares about clean code either. Everyone is worried about getting something working somehow even if it's bug-ridden and slow.

I would say get into the process than the code. this way you can justify your actions better to PMs and managers. People don't like their code to be watched, but they will eventually fix their coding-standard issues each time a red light comes up after they check-in. (styleCop is the tool for .NET community).

The product is about the people. You have to demonstrate caring for the people before you can get them to share your views on what makes a better product.

Always remember that everyone disagrees on the details. As the old adage goes: Quot capita tot sensus.

Google?

Reply on news.ycombinator.com