4 ms·

> It's been my experience that people generally produce their best work after the first year. It takes a while to get to know any business: what its strengths a

> It's been my experience that people generally produce their best work after the first year. It takes a while to get to know any business: what its strengths and weaknesses are, and it's only with that understanding that someone can identify areas to make meaningful contributions. My experience matches this, but I would add that the company shares some of the blame. It often takes a full year for the rest of the team, department, or company to fully integrate the new person and tailor their assigned tasks to their individual strengths and weaknesses. I remember struggling to contribute at a company for several months for no reason other than the people I was supposed to be working with would forget to invite me to key meetings. Teams can get very comfortable working with each other and are naturally resistant to bringing in new people. It takes time to break down those barriers.

Beltalowda 4y ago
I worked somewhere for 3 months and did pretty much nothing for all of it. Then I quit because I hated feeling useless – most stressful job I've ever had. I don't think I'm well-suited for $BigCorp jobs. In most of my other roles, I think I've often become a valuable contributor being able to "pull their own weight" within 1 to 3 months. On a number of occasions I think joining with a "fresh mind" who will say "you guys are doing what?! lol that's crazy, $this is so much better!" has been a real advantage, sometimes even in the first week. I'm not trying to paint myself as some sort of rock-star developer or anything, but in small teams people can get kind of stuck in a sort of an acceptance of the suckage they have, even when it's not needed. One example of this is adding a real database migration instead copying SQL queries from the company chat. Simple stuff really, but does make a meaningful difference. I do think longer tenures are an advantage because people will have to live with their choices. I have a former co-worker who brags about what he did when he worked for us as being brilliant to this day, but we literally threw it all away because none of it actually worked well; it was complete garbage. But he never stayed long enough to have to deal with any of that.
- tianzhou 4y ago
  >> One example of this is adding a real database migration instead copying SQL queries from the company chat. Simple stuff really, but does make a meaningful difference bytebase.com could be what you are looking for. Disclaimer: I am one of the authors.
  - Beltalowda 4y ago
    This was like 8 years ago and I no longer work there; all that was really needed was a "versions" table and a "for file := os.ReadDir("migrations")". Even that basic version was already a huge improvement. When I joined we didn't even have a CI, and everyone was committing to master, usually with undescriptive expletive-laden commit messages.

Beltalowda 4y ago

I worked somewhere for 3 months and did pretty much nothing for all of it. Then I quit because I hated feeling useless – most stressful job I've ever had. I don't think I'm well-suited for $BigCorp jobs. In most of my other roles, I think I've often become a valuable contributor being able to "pull their own weight" within 1 to 3 months. On a number of occasions I think joining with a "fresh mind" who will say "you guys are doing what?! lol that's crazy, $this is so much better!" has been a real advantage, sometimes even in the first week. I'm not trying to paint myself as some sort of rock-star developer or anything, but in small teams people can get kind of stuck in a sort of an acceptance of the suckage they have, even when it's not needed. One example of this is adding a real database migration instead copying SQL queries from the company chat. Simple stuff really, but does make a meaningful difference. I do think longer tenures are an advantage because people will have to live with their choices. I have a former co-worker who brags about what he did when he worked for us as being brilliant to this day, but we literally threw it all away because none of it actually worked well; it was complete garbage. But he never stayed long enough to have to deal with any of that.

tianzhou 4y ago
>> One example of this is adding a real database migration instead copying SQL queries from the company chat. Simple stuff really, but does make a meaningful difference bytebase.com could be what you are looking for. Disclaimer: I am one of the authors.
- Beltalowda 4y ago
  This was like 8 years ago and I no longer work there; all that was really needed was a "versions" table and a "for file := os.ReadDir("migrations")". Even that basic version was already a huge improvement. When I joined we didn't even have a CI, and everyone was committing to master, usually with undescriptive expletive-laden commit messages.