creature

They were setting up a non-profit arts space. I don't feel like the customer/business relationship is a good fit there.

If a company holds some information internally, and an unauthorised third party surreptitiously obtains that information, wouldn't you call that stealing?

Neither, in this case. Under the GDPR, you'd be expected to reply something like "As described in our privacy policy we use Stripe for processing payments. The data you enter on our checkout is transferred directly to Stripe, and is not stored by us." You're expected to make sure that third parties your company works with are GDPR compliant, but that's just a case of "ensure Stripe's privacy policy reads as GDPR compliant".

There's a number of techniques you can use, but most come back to fundamental principles: keep things small and self-contained as possible, try to decouple elements of your program, try to keep things consistent (and have one standard way of doing things). There's also the craft-level principles too: use a framework (one framework, and use it consistently), write tests for things, leave helpful comments, automate what you can (like code listing, minification, and asset packaging).

Frameworks are a big help – partially for the tools they provide, but also for the consistency. "We have a lot of code, but it's all structured in a standard way" makes things easier to understand. It's also a way of having confidence in the architecture: you know many other people have built successful apps with it, rather than something you've invented yourself.

The concepts in Redux are very appealing to me: your application has one state, and that state gets changed via actions. You have a function that, given a state and an action, produces a new state. Your application can render itself from that state. This makes testing straightforward: your business logic tests boil down to "Given this starting state, and this action, my output state should look like this." Similarly, your UI is now easy to test: "Given this state, my component should render like this," covers displaying information, and "When I interacted with this element, was an action emitted?" covers user interaction. Traditionally hairy areas are now more straightforward: "I need to test with a logged-in user" or "I need to test a successful payment" is all about the data in the state.

Another technique you can use is a publish/subscribe architecture: individual parts of your application publish events, and can subscribe to events they care about. Now, your InboxCounter widget doesn't have to know anything about how messages are received or displayed; as long as it listens for "message:added" and "message:removed" events, it can display an accurate count. Similarly, the AJAX polling for new messages doesn't need to be coupled to the message display or the counters or other elements; it just has to check for new messages, and publish events when new ones are received. This should make it easier to add new components and refactor old ones (as long as you're emitting the same events, nothing else should have to be updated), but it can be hard to figure out what events get emitted, and where they come from. Tests help.

On a much smaller level, using promises instead of callbacks can help reduce "pyramid code" - sections of the codebase with extreme indentation. They also make it easier to handle failure cases; writing "Make these 3 co-dependent AJAX requests, and if any fail then display an error message" will be more concise and clearer with promises.

Finally, don't over-complicate things. Frameworks, dependency injection, and the like add a lot of upfront complexity to a project, but reduce it later on. If all your application needs is an occasional "When X happens, show/hide this DOM element" then simple jQuery event listeners will be a lot quicker to build and easier to understand. Don't build a Swiss watch when what you needed was an egg timer.

I use Siri fairly frequently, but in certain narrowly-defined situations: when I've got my hands full, or am doing something else.

The two that come to mind are when cooking ("Hey Siri, set a timer for 15 minutes") or when I'm trying to get everything together for leaving the house ("Hey Siri, how cold is it outside?"). I'll also use it if my phone's in my pocket, I'm wearing headphones, and it's awkward to get my phone out ("Hey Siri, text Tom." "What do you want to say to Tom?" "I'm running 10 minutes late but will be there soon. Sorry!")

Go to university & get a degree. A degree opens a lot of doors in the future, even if you think it shouldn't matter. That's both simple things like "Getting your CV past a clueless first-screen HR person", and complex things like "Applying for a visa to live/work abroad".

Also, if you're working as a developer already then the first year of university is likely to be straightforward for you. Depending on the hours, you could probably keep the part-time job and study (but out of the two, you should prioritise the study).

Finally, I'd recommend you use your free time in university well. Volunteer for charitable organisations; help out with your student union; take up a sport; keep learning things not on the curriculum. All of these are fulfilling in and of themselves, but will also benefit your future too.