3 ms·

> Have I just had the misfortune of working at particularly crappy companies, or are things really this bad across the whole industry? It's not universal, but

by duggan 2y ago

> Have I just had the misfortune of working at particularly crappy companies, or are things really this bad across the whole industry? It's not universal, but you might have to do a lot of searching. Personally, I think it's easier to find the right people in smaller companies, mostly because it's harder to hide in the crowd that way, but there are clever, dedicated people in companies of all sizes. You'll do ok. Keep the fire burning, and keep looking for people who either share your principles, or respect them.

fragmede 2y ago
smaller companies are more exposed to customer demands. whether that makes for better or worse code depends on the team and company culture. the demand to ship something right this second and is existential for the company tends to prioritize shipping over well engineered code. At the opposite end of the spectrum, being totally insulated from such demands can lead to some really nice design docs, and code that might be the epitome of software engineering, but it also takes forever to actually ship anything because there's less of a forcing function, which also leads to complacency. there's a happy medium between the two that's optimal, though finding the right one is challenging.
- duggan 2y ago
  > the demand to ship something right this second and is existential for the company tends to prioritize shipping over well engineered code. This is a challenge, though very early in my career I learned that one solution to this is to just get better and faster. Failing to deliver to your own standards becomes a motivator (with lots of caveats in regard to working environment, domain applicability, etc).
  - fragmede 2y ago
    also learning to say no is an important skill to develop. my current director asks the impossible just to get us to say no, and then we have a good back and forth on what's a realistic balance, like what features we can trade off for which time.

by duggan 2y ago

fragmede 2y ago

smaller companies are more exposed to customer demands. whether that makes for better or worse code depends on the team and company culture. the demand to ship something right this second and is existential for the company tends to prioritize shipping over well engineered code. At the opposite end of the spectrum, being totally insulated from such demands can lead to some really nice design docs, and code that might be the epitome of software engineering, but it also takes forever to actually ship anything because there's less of a forcing function, which also leads to complacency. there's a happy medium between the two that's optimal, though finding the right one is challenging.

duggan 2y ago
> the demand to ship something right this second and is existential for the company tends to prioritize shipping over well engineered code. This is a challenge, though very early in my career I learned that one solution to this is to just get better and faster. Failing to deliver to your own standards becomes a motivator (with lots of caveats in regard to working environment, domain applicability, etc).
- fragmede 2y ago
  also learning to say no is an important skill to develop. my current director asks the impossible just to get us to say no, and then we have a good back and forth on what's a realistic balance, like what features we can trade off for which time.