SnoopDougDoug

This is a job for Perplexity:

MERN (MongoDB, Express.js, React, Node.js) stack. Here's why:

The MERN stack is a highly popular and versatile full-stack JavaScript solution that allows you to build modern web applications efficiently as a solo developer. It provides several advantages:

1. Full JavaScript Stack: By using JavaScript across the entire stack (frontend with React, backend with Node.js/Express), you can leverage your JavaScript skills without having to learn multiple languages. This reduces the learning curve and increases productivity.

2. React for Frontend: React is a powerful and widely-adopted library for building user interfaces. Its component-based architecture and virtual DOM make it efficient for developing complex and interactive UIs.

3. Node.js/Express for Backend: Node.js, with Express.js as the web framework, allows you to build scalable and high-performance backend services using JavaScript. This eliminates the need for a separate backend language.

4. MongoDB for Database: MongoDB is a popular NoSQL database that integrates seamlessly with the MERN stack. Its flexible schema and scalability make it suitable for various types of applications.

5. Large Community and Ecosystem: The MERN stack has a vast and active community, ensuring abundant resources, libraries, and tools for efficient development. This can significantly boost productivity for a solo developer.

6. Isomorphic/Universal Rendering: With the MERN stack, you can implement isomorphic/universal rendering, which allows you to render the same code on the server and client-side, improving performance and SEO.

I've been creating software developer docs for decades. Most contain the following content:

About X Installing and configuring X Using X X Reference

Typically developer docs are created from the bottom up. The devs create the preliminary reference docs using special comments in their code.

Once they are through, I go through their comments and wordsmith them.

After the reference topics are written, I start adding a "guide" section. I like to call this the "How-to" section, which answers questions like: * How do I create Y * How can I ... and so on.

I try to answer two classes of questions: * Tasks that everyone does (create a client, ...) * Tasks that flummox a lot of people (talk to the folks manning the help desk)

Once I'm happy with these task-based topics, I'll create a simple "Hello world" tutorial. This topic helps the user know that they've successfully installed and configured the software.

Finally I'll write the installation and configuration section.

It's possible to work on more than one section at a time. In fact, I typically write a bunch of sample code to try out ideas before I create the guide and tutorial. If possible, I'll tidy up these code snippets and add them to the docs. Developers always ask for more code examples.

And speaking of which, if you do create a code example, please create an accompanying unit test. Don't make your users find out that version 1.1 broke your code example. That's your job.

doug in Seattle

My favorite:

In theory there is no difference between theory and practice; in practice there is.

Benjamin Brewster Yale Literary Magazine, February 1882

Ah yes, toxic bosses. I once left a gig after my boss convinced me to take over as lead, and then blamed every problem with the schedule/features/etc. on me a few weeks later.

Another terrible boss told me one day I was spending too much time on a task, and the next day that I was not spending enough time on a task. I did learn to ask pointedly in hiring interviews whether there was any sign of micro-management in the role.

Location: Seattle

Remote: Only

Willing to relocate: no

Technologies: Go, Rust, technical writing

Resume: https://www.linkedin.com/in/doug-schwartz-19161910/; see Doug-AWS on GitHub

Email: snoopdougiedoug AT gmail.com

I've decided to back away from full-time work next year. I've been a senior technical writer for decades, love writing code examples in various languages (although Go and Rust are my favorites), and spent a couple of decades contracting before joining AWS six years ago.