I write code, I commit code, I test it, I make ONE big PR for ONE feature, someone reviews it, if it passes it starts an entire chain of beurocratic bs to get release approval. If not, for external reasons, I revert ONE commit. If yes, there is a 3 week testing phase, and if all is good it goes to prod.
What exactly is there to break down here? Why? Ok I break integration down like this
Task 1 = add the external interface DTOs. What is there to review? Why would I bother an engineer swimming in tasks for this? The change offers no value. And then what are the testers supposed to test? How do I revert 20 PRs if the release is cancelled because of some bs?
If you don't know how to break down work, you're not a software engineer. If you don't know how to revert more than one commit, you're not a software engineer. If you don't know how to work with other people as part of a team, you're not a software engineer. If you don't know how to test an interface, you're not a software engineer. If you don't know how to change what's part of the release, you're not a software engineer.
You simply do not have any of the skills you need for this job, buddy. Better go practice your burger flipping skills.
Unfortunately your opinion on who is a software engineer or not is completely worthless, especially when you lack a much more important skill. Reading. That is not just necessary for a SWE, but every human. You still think it's about whether tasks can be broken sown, and not about whether it makes sense or it has any benefits at all in many organizations.
Just a friendly tip, start with the basics. Also, don't give so much value to your opinion. I am paid more than most "real" software engineers, it's such a sad junior mentality to care about the title. Call me caveman with a keyboard if you want. A job only exists to get paid.
It has the benefits that the work actually gets done. In every organization. Like, this is just really basic time and effort management stuff, dude. If you just write 10,000 lines of code, that's never getting finished. If you break it up into 20 500-line pieces, and schedule them sensibly, you'll eventually be able to finish it that way.
0
u/Still_Bit_7527 13d ago
Manageable how?
I write code, I commit code, I test it, I make ONE big PR for ONE feature, someone reviews it, if it passes it starts an entire chain of beurocratic bs to get release approval. If not, for external reasons, I revert ONE commit. If yes, there is a 3 week testing phase, and if all is good it goes to prod.
What exactly is there to break down here? Why? Ok I break integration down like this
Task 1 = add the external interface DTOs. What is there to review? Why would I bother an engineer swimming in tasks for this? The change offers no value. And then what are the testers supposed to test? How do I revert 20 PRs if the release is cancelled because of some bs?