4 ms·

It's funny how my experience is exactly reverse. Since I joined startup I learn much less, since we can't afford experimentation and there are no other front en

It's funny how my experience is exactly reverse. Since I joined startup I learn much less, since we can't afford experimentation and there are no other front end devs here, so I don't get a chance to learn backend stuff, since someone has to do front end part. I also hoped to learn some business stuff, but most of it happens behind closed doors between founders and investors while you code boring crud application.

rjeli 8y ago
> most of it happens behind closed doors between founders and investors Lack of transparency is bad. If you care about it, leave. Find a founder who doesn't think they're better than you.
- enraged_camel 8y ago
  That seems to be quite a leap from “meetings with investors happen behind closed doors” to “the founders think they are better than you.” There are certain things that should be discussed in the open, and certain things behind closed doors.
  - InfamousSub 8y ago
    >and certain things behind closed doors. Such as?
_II__II_ 8y ago
I couldn't agree more, I've just left a start up for a traditional company purely because here I have opportunities to learn. It comes down to the culture of the company a little bit, for example this place likes it's devs to do R&D/experimentation to scope out opportunities to add value to the business. The point remains though that such a thing just wasn't possible at the startup I was at, there wasn't time.
grosjona 8y ago
I've been back and forth between startups and corporations. I think I know what you mean in technical terms; that corporations use more advanced (rigorous) processes and tools and so it feels like you're learning more (it feels more precise/correct) - That said, I think that a lot of the stuff that you learn in big companies are anti-patterns when you consider the big picture; a lot of the time, you learn technical solutions to problems which don't really need to exist to begin with. For example, one reason why many corporations push really hard on having 100% unit and integration test coverage is because they have such high employee turnover that they can't rely on their engineers to maintain their own code; corporations have to assume that engineers who work on their projects are completely unfamiliar with the code - In this case, automated tests are the only way to maintain the integrity and stability of the code base. The time cost of maintaining all these trivial unit tests is ignored (even though the cost is actually very significant; not to mention that these tests lock down the code and thereby discourage refactoring and experimentation). Corporate processes are designed around the assumptions that engineers don't care and can't be trusted. This is a very inefficient approach to building software. Personally, I'd rather my project have code with 0% unit test coverage written by a team of involved engineers than code with 100% test coverage written by a team of indifferent engineers.
- plicense 8y ago
  > For example, one reason why many corporations push really hard on having 100% unit and integration test coverage is because they have such high employee turnover that they can't rely on their engineers to maintain their own code I'm in a similar situation as yours and have switched between big corporations and startups and now at a big co again. I used to have the opinion that unit tests are a time sink, but what changed my mind was the iteration speed unit tests gave me. Without them, to test that my code actually worked, I would either deploy to a test environment (or prod in the worst case) and if it didn't work, then that just meant a longer feedback loop. What I realized after starting to have solid unit tests was that I catch issues much earlier in the pipeline and when I finally release code to test, it works 99% of the time. The only time I've had bugs in test env was because of some implicit assumptions in my mocks in the unit test. If you think about it, that lets me iterate faster by pooling in lots of changes and releasing with confidence. I think its natural to be biased towards testing in a real environment as opposed to unit tests, as it is more rewarding to see your code work and do what its supposed to do versus seeing it work in a stubbed out environment. Unit tests to me are more about iteration speed and release confidence, than about corporations not trusting engineers (which is also true).
scarface74 8y ago
And another anecdote. Not necessarily “startups” but everytime that I work for a small company, I get to do everything. I’ve learned a lot from working st small companies and small IT departments at larger companies. I would never have had the experience I have from front end, back end, databases, cloud architecture (I’m one of the AWS admins) from netops, devops, to development and to work directly with C-level people.
akoncius 8y ago
yeah, quite similar situation in my experience too. Usually you need to implement features ASAP, so rarely you have time to do it properly, so you cut corners , implement it , and move on to another burning task just to meet deadlines for next investment round or something like that.

rjeli 8y ago

> most of it happens behind closed doors between founders and investors Lack of transparency is bad. If you care about it, leave. Find a founder who doesn't think they're better than you.

enraged_camel 8y ago
That seems to be quite a leap from “meetings with investors happen behind closed doors” to “the founders think they are better than you.” There are certain things that should be discussed in the open, and certain things behind closed doors.
- InfamousSub 8y ago
  >and certain things behind closed doors. Such as?

_II__II_ 8y ago

I couldn't agree more, I've just left a start up for a traditional company purely because here I have opportunities to learn. It comes down to the culture of the company a little bit, for example this place likes it's devs to do R&D/experimentation to scope out opportunities to add value to the business. The point remains though that such a thing just wasn't possible at the startup I was at, there wasn't time.

grosjona 8y ago

I've been back and forth between startups and corporations. I think I know what you mean in technical terms; that corporations use more advanced (rigorous) processes and tools and so it feels like you're learning more (it feels more precise/correct) - That said, I think that a lot of the stuff that you learn in big companies are anti-patterns when you consider the big picture; a lot of the time, you learn technical solutions to problems which don't really need to exist to begin with. For example, one reason why many corporations push really hard on having 100% unit and integration test coverage is because they have such high employee turnover that they can't rely on their engineers to maintain their own code; corporations have to assume that engineers who work on their projects are completely unfamiliar with the code - In this case, automated tests are the only way to maintain the integrity and stability of the code base. The time cost of maintaining all these trivial unit tests is ignored (even though the cost is actually very significant; not to mention that these tests lock down the code and thereby discourage refactoring and experimentation). Corporate processes are designed around the assumptions that engineers don't care and can't be trusted. This is a very inefficient approach to building software. Personally, I'd rather my project have code with 0% unit test coverage written by a team of involved engineers than code with 100% test coverage written by a team of indifferent engineers.

plicense 8y ago
> For example, one reason why many corporations push really hard on having 100% unit and integration test coverage is because they have such high employee turnover that they can't rely on their engineers to maintain their own code I'm in a similar situation as yours and have switched between big corporations and startups and now at a big co again. I used to have the opinion that unit tests are a time sink, but what changed my mind was the iteration speed unit tests gave me. Without them, to test that my code actually worked, I would either deploy to a test environment (or prod in the worst case) and if it didn't work, then that just meant a longer feedback loop. What I realized after starting to have solid unit tests was that I catch issues much earlier in the pipeline and when I finally release code to test, it works 99% of the time. The only time I've had bugs in test env was because of some implicit assumptions in my mocks in the unit test. If you think about it, that lets me iterate faster by pooling in lots of changes and releasing with confidence. I think its natural to be biased towards testing in a real environment as opposed to unit tests, as it is more rewarding to see your code work and do what its supposed to do versus seeing it work in a stubbed out environment. Unit tests to me are more about iteration speed and release confidence, than about corporations not trusting engineers (which is also true).

scarface74 8y ago

And another anecdote. Not necessarily “startups” but everytime that I work for a small company, I get to do everything. I’ve learned a lot from working st small companies and small IT departments at larger companies. I would never have had the experience I have from front end, back end, databases, cloud architecture (I’m one of the AWS admins) from netops, devops, to development and to work directly with C-level people.

akoncius 8y ago

yeah, quite similar situation in my experience too. Usually you need to implement features ASAP, so rarely you have time to do it properly, so you cut corners , implement it , and move on to another burning task just to meet deadlines for next investment round or something like that.