3 ms·

> Learn what problems the company is solving and help them within their constraints, including using their tools and languages even if they look suboptimal. wi

> Learn what problems the company is solving and help them within their constraints, including using their tools and languages even if they look suboptimal. within reason and 'on day one', yes, agreed. However, if you're hired in because of your skills/accomplishments, but you don't measure up, and it's because their tools/process/code is demonstrably bad, those are constraints that should be on the table for discussion/improvement. In most cases I've seen, those sorts of changes have a net positive for almost everyone on the project (fewer bugs, faster turnaround, whatever), at the expense of being a negative for a handful of territorial people threatened by change. Not coming in on day one saying "you have to change everything to my approach!" - agreed. Toiling away in suboptimal situations when you know the poor results are improvable for fear of not wanting to look pushy... unacceptable (over a longer term).

marcosdumay 7y ago
Bad ways to point a problem that will make me think you are a 40 years junior with 20 times of 1 year of experience: - Your stack is bad. - You should use X. - Your process is wrong. A sure way to sound like an experienced senior developer: - Your stack has this flaw; we can live with it by doing X but that is at the expense of Y1. A migration to Z will cost Y2, that is much cheaper on the long run. But you'll probably conclude that Y2 isn't much cheaper on the long run anyway. If it's that case that it is cheaper, and even then people above you do not want the change, then you do have a real problem.
- bcrosby95 7y ago
  > ... that is much cheaper on the long run. > If it's that case that it is cheaper, and even then people above you do not want the change, then you do have a real problem. Not necessarily so. This assumes the long run is ever reached. I've seen a lot of developers that do this analysis still hop from tech to tech as the best in "the long run", and if you ever listened to them you would never actually reach that long run benefit. Regardless, a lot probably depends upon the current state of your company.

marcosdumay 7y ago

Bad ways to point a problem that will make me think you are a 40 years junior with 20 times of 1 year of experience: - Your stack is bad. - You should use X. - Your process is wrong. A sure way to sound like an experienced senior developer: - Your stack has this flaw; we can live with it by doing X but that is at the expense of Y1. A migration to Z will cost Y2, that is much cheaper on the long run. But you'll probably conclude that Y2 isn't much cheaper on the long run anyway. If it's that case that it is cheaper, and even then people above you do not want the change, then you do have a real problem.

bcrosby95 7y ago
> ... that is much cheaper on the long run. > If it's that case that it is cheaper, and even then people above you do not want the change, then you do have a real problem. Not necessarily so. This assumes the long run is ever reached. I've seen a lot of developers that do this analysis still hop from tech to tech as the best in "the long run", and if you ever listened to them you would never actually reach that long run benefit. Regardless, a lot probably depends upon the current state of your company.