I'm not sure about your situation. But for me, I never got the opportunity to be a "junior" developer and have someone else be ultimately responsible. There was no one else available but me in most places I worked. So, I also felt this way throughout my career... that if I didn't get it working, the effort would fail. It's not so bad as a solo developer on a single app here and there, but I find the stress much greater when my decisions play a part in company strategy and people's careers. To be honest, I find myself in paralysis sometimes... endlessly researching to get a picture of how every corner of the architecture works together before I even take a step. In particular, I try to thought-experiment each detail to uncover the obvious trade-offs as early as possible. But time being finite, I often have to move forward with my best guess. I need to rediscover the playful attitude with which I approached this stuff earlier in my career to make it more fun. Although it remains intensely satisfying to have created something that works well and meets a need.
I believe that large spaghetti systems make it nearly impossible to justify a big bang rewrite. There is just no way to account for all the side effects that are baked into the system. (e.g. App A depends on App B setting some data, but only sometimes.) The new system will miss a lot of edge cases because they look like accidents and noise. Therefore the cost of creating the new system also extends to adding missed edge cases for a while after it is first deployed. And that only gets you back where you were before the rewrite, with maybe a few new things added. Plus your users are angry with so much change at once. The right way is to carve off pieces of the system. That gives you a chance to dig into that area and talk to your users. Then you can not only modernize things, but you can also add value while you do it, and let users adjust in small increments. That piece gets deployed separately and its responsibility removed from the legacy system. Rinse and repeat. Smaller is easier to throw away and rewrite.
this is similar to my experience so far. at my last job i was a team of one. i had people i could pester with questions, but they were on a different team (read: under a different cost-center in the company) so questions were definitely not encouraged.
at my current job, i'm largely independent again (although my team is fantastic!). i'd love to be in a situation with more expected collaboration. so maybe these experiences can actually be good things :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'm not sure about your situation. But for me, I never got the opportunity to be a "junior" developer and have someone else be ultimately responsible. There was no one else available but me in most places I worked. So, I also felt this way throughout my career... that if I didn't get it working, the effort would fail. It's not so bad as a solo developer on a single app here and there, but I find the stress much greater when my decisions play a part in company strategy and people's careers. To be honest, I find myself in paralysis sometimes... endlessly researching to get a picture of how every corner of the architecture works together before I even take a step. In particular, I try to thought-experiment each detail to uncover the obvious trade-offs as early as possible. But time being finite, I often have to move forward with my best guess. I need to rediscover the playful attitude with which I approached this stuff earlier in my career to make it more fun. Although it remains intensely satisfying to have created something that works well and meets a need.
I believe that large spaghetti systems make it nearly impossible to justify a big bang rewrite. There is just no way to account for all the side effects that are baked into the system. (e.g. App A depends on App B setting some data, but only sometimes.) The new system will miss a lot of edge cases because they look like accidents and noise. Therefore the cost of creating the new system also extends to adding missed edge cases for a while after it is first deployed. And that only gets you back where you were before the rewrite, with maybe a few new things added. Plus your users are angry with so much change at once. The right way is to carve off pieces of the system. That gives you a chance to dig into that area and talk to your users. Then you can not only modernize things, but you can also add value while you do it, and let users adjust in small increments. That piece gets deployed separately and its responsibility removed from the legacy system. Rinse and repeat. Smaller is easier to throw away and rewrite.
this is similar to my experience so far. at my last job i was a team of one. i had people i could pester with questions, but they were on a different team (read: under a different cost-center in the company) so questions were definitely not encouraged.
at my current job, i'm largely independent again (although my team is fantastic!). i'd love to be in a situation with more expected collaboration. so maybe these experiences can actually be good things :)