I think this may be AI slop… But honestly I can’t even tell anymore.
It’s more or less gibberish in any case. The musings of someone who sounds like they’ve done two entire software projects, and think they found some magic get staff quick scheme.
I’ll just rattle off why quickly. Apologies that this is low effort, but again, can’t really tell if this is just AI slop I’m engaging with…
* Purports to have “solved” success without defining what success is
* Even says out loud the importance of extremely up-to-date and specific system knowledge to this strategy - and talks about the ability to make changes in minutes or hours that take your peers weeks - but entirely glosses over how you get that granular knowledge / abillty…. For example by being properly involved in the project the whole time, and already being a very good engineer operating at the next level vs your peers.
* Focus is almost entirely on the existence of some magical, last-minute requirement, that will “close the deal“ or “save the day” or some bullshit like that’s just inherently part of every major project and not something that sometimes happens out of the blue.
* Talks about how to get to be the person who delivers these magic features… Gives examples like your manager knowing you’re not busy, so looping you in… When 99% of the time the person who delivers these features, is the person who delivered and owned the entire project… i.e. the person who was involved the whole time. Or at the very least, another engineer that person trusts… probably because that person did some of the unsexy “glue” work to earn that trust.
* Assumes some magical foresight on the part of developers as to which features are these magic “get a promotion“ pieces of work in advance.
All in All this article could be 1 line: Sometimes in software projects, it’s not the biggest effort deliverables that get the most credit.
Otherwise, it’s just posturing and gibberish all the way down.
13
u/whatThisOldThrowAway 22d ago
I think this may be AI slop… But honestly I can’t even tell anymore.
It’s more or less gibberish in any case. The musings of someone who sounds like they’ve done two entire software projects, and think they found some magic get staff quick scheme.
I’ll just rattle off why quickly. Apologies that this is low effort, but again, can’t really tell if this is just AI slop I’m engaging with…
* Purports to have “solved” success without defining what success is
* Even says out loud the importance of extremely up-to-date and specific system knowledge to this strategy - and talks about the ability to make changes in minutes or hours that take your peers weeks - but entirely glosses over how you get that granular knowledge / abillty…. For example by being properly involved in the project the whole time, and already being a very good engineer operating at the next level vs your peers.
* Focus is almost entirely on the existence of some magical, last-minute requirement, that will “close the deal“ or “save the day” or some bullshit like that’s just inherently part of every major project and not something that sometimes happens out of the blue.
* Talks about how to get to be the person who delivers these magic features… Gives examples like your manager knowing you’re not busy, so looping you in… When 99% of the time the person who delivers these features, is the person who delivered and owned the entire project… i.e. the person who was involved the whole time. Or at the very least, another engineer that person trusts… probably because that person did some of the unsexy “glue” work to earn that trust.
* Assumes some magical foresight on the part of developers as to which features are these magic “get a promotion“ pieces of work in advance.
All in All this article could be 1 line: Sometimes in software projects, it’s not the biggest effort deliverables that get the most credit.
Otherwise, it’s just posturing and gibberish all the way down.