How do I learn these essential skills that are not taught in school?

Great question! I love all these skills - They are all very important for a software engineer, and school is indeed quite bad at teaching them.

Writing In An Easy To Understand Way

• The best way to get better at this is to get feedback. Sometimes your audience will tell you that they have no clue what you wrote. If they don't, you can always ask. Find the most junior engineer that's connected to whatever technical writing you put out and ask for feedback.
• Honestly, I feel like going through the ELI5 subreddit is a good way to build up this muscle.
• For advice on how to do clear, accessible technical writing (like software design documents), check out this Q&A from a Microsoft engineer: "How to improve on non-technical skills like writing Software design document?"

Writing Code So Future You Doesn't Hate You

• The same feedback concept applies here. Find the newest engineer or the most junior engineer on your team (bonus points if these are the same person!) and ask them if your code makes sense (just put them on your code review).
• Of course, just revisiting your code helps a lot, and I wouldn't do it after 2 years, 3-6 months is probably enough. If you do this introspection properly, future you will definitely have thoughts on how this code could have been structured to make it easier to grok.
  • For me, I did this all the time with my side projects. I went for depth over breadth, so I copy-pasted code from old apps a lot. Since I had to read my own code constantly, I became very attuned to why it sucked.

How To Show Off Work You've Done

• Here's an excellent Q&A here that I highly recommend reading, which goes in-depth into how to make a great project update post: "How to get more visibility on work?"
• "How can I get my work better recognized by leadership?" - This Q&A covers other mechanisms on how to get full recognition/visibility into your work.

How Much Testing Is The Right Amount

• It varies a ton based on circumstance, and there's really no right answer here. While the previous 3 questions are more well-defined in terms of good principles, this one is incredibly hazy. I also came from Meta, so I'm sort of a black sheep here (Meta probably has far fewer automated tests compared to peer companies).
• I go in-depth on how I think about automated testing efforts in this discussion: "What's the best way to carry out an end-to-end (E2E) testing effort?"

I know it's an old thread, but I wanted to add another perspective:

Writing

• Writing is a form of communication. The biggest mistake people make is not tailoring their communication to the audience. The way you communicate to a junior, your manager and a PM will be vastly different. This includes any writing that will be consumed by these groups.
• How do you build this skill? Ask. Ask your target audience what they care about. Make a list of guidelines. Then do your writing. Ask for feedback and iterate.
• If you're doing technical writing, it helps to think about layers of abstraction. The single biggest mistake engineers make is diving too deep into details too early. So, for a technical design, you might have a high-level summary, followed by high-level design and low-level design.

Clean code structure

• A lot of this comes from experience. But a good place to start is looking at where you get hung up when looking at someone else's code. What are the areas that cause the most confusion?
• Then, do your research on best practices. Ask more experienced engineers or look around online for ways to address these areas. Then implement them.
• Ask for feedback. CRs are a great way to learn to write clean code. Try to tag people on the team whose coding skills you respect.
• Lastly, there'll be a good amount of trial and error. There are techniques I used as a new grad engineer that I wouldn't bother with as a senior engineer. Simplicity always beats complexity.

Showing off your work

• The best way is to take the focus off yourself. Make it about the impact and results. What is the impact of your work that someone else cares about?
• For example, if you want your manager to pay attention, find out what makes them look good and what they report to their manager. Then look for how your work affects that metric and give them an easy way to tie your work to that metric. Your name will naturally come up.
• Within the team, participate and/or create processes for everyone to showcase their work. Many teams do sprint demos just for this purpose. Again, make this about the team, not showing off your work.

Right amount of testing

• I agree with Alex's answer. The amount doesn't matter as much as the goal. Numbers like code coverage aren't that meaningful. It's about the combination of different testing methodologies (like unit tests, integration tests, load tests, and regression tests) and how they validate important dimensions of the software.
• At the launch of new software you should have coverage in all of these areas. How involved each area is depends on the system under test. Testability can also drive the design of software. It's much easier to test smaller components with clear interfaces than large complex systems.
• This also depends on the size of the company and business goals. The "move fast and break shit" mentality of startups will reflect differently in testing than the "maintain customer trust" mentality of established companies.