I am a software engineer.
Being asked if I prefer frontend or backend has always been one of the most difficult questions to answer for me. It often comes from a difference in opinion on what "frontend" today means. I don't see the differences between the two to be so wide that I would have a preference between one, the other, or both.
I can build a clean, usable and accessible UI. But I don't have the designer mindset and skillset to build a brand. Design, like engineering, is a career that takes years of training, constant practice, and keeping up to date.
Frameworks like React are very logical and declarative. When we write what looks like HTML, we're actually writing logical functions. "<div/>" resolves to "React.createElement('div')".
This is a subtle but important difference. Frontends have taken on the responsibility of routing, conditional rendering, handle their own caching and are built for edge deployments in which they run on their own servers near the user separate from a dedicated backend. Frontends today are built to have their own dedicated backends separate from traditional dedicated backends. Modern frontend is full stack.
The overlap between frontend and design work is similar to the overlap between backend and database administration work. Working with CSS layouts and stacking contexts is like working with SQL and database fetching on the backend.
Backend work does not imply database design in the same way that frontend does not imply brand design.
Similarly, I am comfortable with the development duties around SEO regarding static HTML, performance, accessibility, schema markup, etc. However much of SEO work is around things like analytics interpretation and backlink building which is handled through long-term business relationships.
For cloud services, I am familiar with many AWS API's and services as they pertain to software engineering work. But much less familiar with designing an infrastructure and managing it. I've used Infrastructure as Code tools, but most of these are built to use simple YAML files that can be put together more easily and competently by people who have chose the career path of Network Engineering.
Database administration, network engineering, marketing and design are all careers in their own right. Each require years of training, and a lifelong dedication to improvement. I have chose software engineering as my career path. I am happy to try to fill in as much as the Venn diagram middle points as possible. But to be a polyglot in software engineering and keep up is nearly impossible as it is and I can't fill every role.
TDD can be a scary term that prompts images of a cult obsessed with a very specific way of doing everything. For me TDD isn't necessarily writing tests before code and taking a specific Red/Green/Refactor approach. Although I would agree this is the ideal form.
Rather, implementing TDD to me just means not depending on hot reloading, debugging, and manual testing as you go. Rather, I want to record the steps I take and write an automated unit test for everything.
It is only after I feel everything is done that I want to start up the server and check everything is ok with manual tests.
This creates a few positives. One, all of my debug steps are recorded and automated. I have proof that everything is working as intended, and something that will throw a red flag if later work down the line breaks it. This means I won't have to say, "I'm pretty sure I tested everything, I don't know why there's a problem now."
Second, tests become documented specification. Tests are generally very readable in a English, imperative sense. Long test descriptions, and writing tests in a way that any domain expert can read through them and see everything looks correct instead of having to look at code saves time and solves problems.
If TDD is how I write code, BDD is how I handle the business side of software engineering. Meaning, I prefer to work with tickets that describe the behavior of the user and their expectation. This is a perfect middle point between what an engineer needs and what a QA tester needs.
Thinking of tasks as behaviors creates a clarity of intention that you don't get from pseudocode. The Gherkin template is a great way to help create this. Although I wouldn't say it's an entirely necessary tool, if it helps, it helps.
BDD creates a common understanding for all members of the team whether they are doing development work, testing, or business analysis. It means everyone is working from the same goal and have the same understanding of what a particular task means and what it's goal is. Less surprises and less miscommunication.
For the Scaling JS Playbook - One preferred way I have for starting and scaling projects as they grow. (As opposed to big up front architectural design.)
How to Use Local Storage with React State - A good example of how React is often misused and misunderstood.
Making Prisma/GraphQL Better - How I made Prisma and GraphQL play nice with each other to build out an easy to scale API gateway.