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 concepts still have value and merit, especially when the problem domain is well understood beforehand. Ultimately I find that good engineering practises will transcend paradigms, just get called different names.

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 / Cursor + 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.

I find that LLMs in a professional setting will make people only incrementally more effective, but A LOT more efficient. GIGO applies, and this may explain why some get better results than others. My theory is that it's less useful for engineers who historically underlooked communication skills, or have never cared about documentation / technical writing in general. Personally, when using LLMs I continuously find myself a good order of magnitude more productive. My take is that good engineering and communication skills transcend to this space very well: use TDD, communicate clearly and succinctly, prefer short feedback loops, write spec documents and manage context size (less is more). LLMs are not magic. They of course have limitations. But when applied correctly, it's very clearly not just a hype.

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. There was a time when I used to sway towards the client-side. Later got involved heavy in designing scalable, performant and production-grade systems on the backend/infrastructure. These days I stil do all of the above, plus lots of diagramming, delegation and organisational/comms work.

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.