These days I default to the functional paradigm whenever possible. Testing immutable and side-effect-free code is refreshing. The declarative and composable nature helps me write simpler, more elegant and robust components. I believe OOP and SOLID concepts still have value and merit, especially when the problem domain is well understood beforehand.

Unix over Windows. It's one of very few things I'm strongly opinionated about, although I'm yet to try WSL. Over last few years I've adopted a VS Code + VIM bindings setup, which I found makes me very productive. I default to CLI interfaces for most other common dev tooling (git, zsh, fzf, tmux, etc). Ultimately just because something works for me subjectively, does not make it objectively superior.

Tests go first. During development, tests run in the background for tight feedback loops. Tests should cover behaviour, not implementation. The less you mock, the better are your tests. Whilst I'm not dogmatic about coverage, in practise I find that due to these principles alone, most of production code I write will naturally end-up being close-to-100% covered.

Irrelevant, as long as it's consistent. Agreed standards should be enforced through automatic formatting and liting rules (ideally through IDE/Editor, pre-commit hooks and CI).

I keep up-to-date with OWASP Top Ten every year and generally try to follow common sense when developing (i.e. never trust the client, principle of least privilege, etc). Luckily, my better half is an Ethical Hacker, so she keeps me fairly grounded when it comes to these things.

I find full-stack teams are harder to hire, but easier to manage and work-in. I've been fortunate to have worked with some truly talented full-stack engineers, with an eye for design and a technical/analytical mindset. These people exist, just not in abudance. I used to sway towards the frontend and client-side development more, but recently having designed scalable, performant and production-grade systems on the backend I found it just as interesting.

Agile prescribes focusing on people over processes and responding to change. From what I have seen, in practise Kanban makes those principles easier to follow, but only if the business can afford not having to project months in advance. Scrum is naturally easier to plan with, which I've seen being optimised for the wrong metrics. Saying that, I've been fortunate to have seen Scrum done right and it can certainly be a very productive framework.