

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

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 &quot;Java developers&quot;.<p>Do all big companies suck? By suck I mean any two out of three of the following are true:<p><pre><code>  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
</code></pre>
Sometimes I don&#x27;t get why do we need so many employees to being with.<p>Some more things to rant about:<p><pre><code>  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&#x27;s done at a later point or sprint end
     while it may have gone live and broken things in between that
  4. There&#x27;s layers on top of layers on top of layers built

</code></pre>
Thanks,<p>Mr. Heart Borken
======
informatimago
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](http://thevenusproject.org)

------
RogerL
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.

------
tjr
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.

~~~
MrHeartBroken
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.

------
valipour
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.

~~~
thenerdfiles
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.

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

~~~
MrHeartBroken
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.

~~~
valipour
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).

------
vermasque
Google?

