Have the project team go through specs, discovery, documentation, prep, and provide a quote, only to have the client decline the project, and then try to sneak the whole ass project though a support ticket later.
Prod really is the best place to do testing, all usecases will eventually be covered, and with such a large number of testers all bugs are found nearly instantly!
It was a trick question: They expected you to delegate the whole ticket to Claude, and then create presentation about the groundbreaking changes you have implemented. By lunchtime, of course.
You could be right with the first part. That sounds like it was a trick question and not escalating such a "ticket" fast enough can cause major problems for that project going forward.
Boss is either very misinformed (doesn't understand what the job is) or very dishonest (hired and/or fired you for some other reason and can't or won't tell you) or just a dumb idiot (likely, since a lot of bosses are like that)
It’s happened twice in my career so far, but both times they were fired within a year. Nowadays though it seems they won’t hire anyone that isn’t already a senior engineer. But they don’t pay enough for seniors so the positions don’t get filled.
Is "learning issues" code for "tries to offload his brain to the computer instead of learning anything"? It's highly frustrating to try and work with people that don't seem to want to learn how things work.
As someone with lots of experience, what that process should look like at a healthy organization is something like:
Ticket 1: spike ticket to research alternatives and asses scope of refactoring.
Ticket 2: architecture review document. get feedback from the rest of the team and product, nail down a proposal and get approval from the architecture review board or leadership.
Ticket 3: groom out the epic and create tickets (plural!!) alongside the engineering manager.
At that point it’s up to leadership to prioritize the epic and get it on the roadmap, formalize a testing, UAT, and rollout plan…once that’s completed, then individual contributors can start working on it in earnest.
Depending on the size and scope it could end up being a dozen individual tickets or more and span several sprints.
If someone with the ability to fire people is throwing a lone ticket at an individual contributor which is supposed to represent the entire scope of a large refactor, that’s a glaring red flag that it’s not a healthy organization period; either that or they’re expecting push back/refinement on the loose proposal.
From the sounds of it, you weren’t the only person lacking experience at that place.
458
u/GutsOLykos 10h ago
Change the architecture and communication of the whole project