In my experience when showcasing at the end of a sprint it pays to leave the visuals very unpolished and focus on functionality. Even if it’s trivial to use a UI library or other standard components. I deliberately make it look basic to help management / uses accept “it’s working but needs polishing”. That polish might then be me spending 10% of time on neatening UI, and 90% of time refactoring / fixing tech debt.

Just remember: imposter syndrome is real. Everything you learn exposes you to ten things you don’t yet know. Successful devs are comfortable with this reality - the job is one of constant learning. Best of luck!

I have worked for financial institutions that have variations of the last one. If I saw it I wouldn’t even blink. Semi realistic reasons might be:

Status attribute - because the project is using the base library of [project whatever] which was the brain child of eNtErPrIsE aRcHiTeCt whose hands on skills are useless and the off-shore dev team who assigned [random newbie] because that’s who was available at the time. They used a status attribute because they didn’t know how to get the status of the http response. No-one with budget control is interested in hearing about technical debt at the moment. Everyone has to use it now else the poorly written test classes fail.

Message code: because “we need codes that won’t ever change even if the message does”. Bonus points if this is, in fact, never used as intended and changes more frequently than…

Message: “because we still need to put something human readable in the log”. Bonus points x2 if this is localised to the location of the server rather than the locale of the request. Bonus x3 if this is what subsequent business logic is built on leading to obscure errors when the service is moved from AWS East Virginia to AWS London (requests to London returning “colour” instead of “color” break [pick any service you never thought would get broken by this]).

I have seen it all etc

Had to contact support this week because (on top of an already infuriating week of marketing cloud bullcrap) an exit criteria in Journey Builder was firing when it shouldn’t. Basically amounted to a string comparison of A = B? But one was from Contact Data and the other from Journey Data. And you know what their response was? “Yeah… that won’t work, you have to do B = A”. I kid you not. What’s worse is that actually fixed it! What a joke of a platform. How shit do you have to be at coding to end up making a string comparison non-commutative? Like…I don’t even know how you’d screw up that badly accidentally. It’s a veritable kaleidoscope of shitty infuriating bugs.

I’ve been pulling my hair out with the totally unrelated but also awful Marketing Cloud (owned by Salesforce). This article made me feel better.