3 ms·

We are speaking past each other. I'm not talking about "paying your dues". It takes time to get up to speed and to build trust when you are performing high im

We are speaking past each other. I'm not talking about "paying your dues". It takes time to get up to speed and to build trust when you are performing high impact work on a medium-large project especially if you don't have prior domain knowledge. > Most of the important work done at my previous company was largely completed by one very productive intern > liberal in granting freedoms but also willing to fire someone if they turn out not to be able to deliver. I suspect we simply deal with different sized systems. The idea that an intern could do most of the important work implies you work for small companies. In comparison my current project has ~90 devs. Likewise you have this idea that you can quickly determine a good choice from a bad one. I'm still cursing design decisions I made 3 years ago that everyone thought were great at the time. If I had left after 6 months I would still be patting myself on the back. Again that seems to apply better to small companies.

sillysaurus3 10y ago
The company prior to my last had 50,000 employees. We were still able to design and implement a solution for a core aspect of the division. I had to push in the direction of Python + Redis, but when people saw the results, the higher-ups listened to our team. I think you're right that if a system is massive, there won't be many major changes to it. But that's true regardless of who has authority. It's always possible to solve smaller business problems with self-contained projects that can then be integrated into the larger system. But not if an environment is set up to prevent someone from doing this by forcing them to work within the constraints of the existing monolith. (It's possible to do this without creating a microservice, in some cases. The important part is simply to be allowed to experiment with alternate solutions, as long as it's not interfering with your main duties.)
- sheepmullet 10y ago
  How big was your team? How big was your project (kloc + timeframe)? How many other teams did you have to integrate your solution with? What effort did they have to put in to consume your work? Again I think we are simply dealing with different scales of systems.

sillysaurus3 10y ago

The company prior to my last had 50,000 employees. We were still able to design and implement a solution for a core aspect of the division. I had to push in the direction of Python + Redis, but when people saw the results, the higher-ups listened to our team. I think you're right that if a system is massive, there won't be many major changes to it. But that's true regardless of who has authority. It's always possible to solve smaller business problems with self-contained projects that can then be integrated into the larger system. But not if an environment is set up to prevent someone from doing this by forcing them to work within the constraints of the existing monolith. (It's possible to do this without creating a microservice, in some cases. The important part is simply to be allowed to experiment with alternate solutions, as long as it's not interfering with your main duties.)

sheepmullet 10y ago
How big was your team? How big was your project (kloc + timeframe)? How many other teams did you have to integrate your solution with? What effort did they have to put in to consume your work? Again I think we are simply dealing with different scales of systems.