Replace WHY_*.md with WORKFLOW.md

[samhstn]

Describing how I like to work would be better than trying to explain why I use particular tools.

A single file summarising how I like to work would be better than partitioning how I work into different places - this is important as I use tools together and don't use my text editor, the terminal or the browser by themselves, so why would I talk about them in isolation.

I should write this up so that when I am working intensely on a project, I have thought out workflow rules to follow as well as general principles to apply when I use new tooling.

Thoughts to address:

Automate as much as possible.

• Record your answers so you will only improve on your how you think and you won't have to re answer/rethink it.
• Reviewing code mistakes which can be caught by a linter is a waste of time - automation is the answer.
• Fixing typos/addressing simple grammar mistakes is a waste of time, there is tooling for this.
• Testing - what to test - thoughts on coverage.

  Importance of documentation

  How to write documentation (https://hackernoon.com/why-senior-devs-write-dumb-code-and-how-to-spot-a-junior-from-a-mile-away-27fa263b101a) Nothing should ever need to be explained.

  Why preferences for open source?

  Git workflow

  Workflow in the terminal

  (Importance of a linter, but not to lint on save. Why I don't like the noise of a directory tree on my screen? Thoughts on autocompletion. Thoughts on syntax highlighting).

  Importance of UX and UI, grammar, well written code, comments, technical debt, deleting work, broken window theory.

  Importance of not rushing

  (https://github.com/elm/projects/blob/master/roadmap.md#what-is-the-timeline)

[nelsonic]

@samhstn a mark of a craftsman/craftsperson is deliberately considering both their tools and workflow. While I don't even pretend to be as good at writing code as some of the great devs on this list git.io/top, one thing I learned early on is that writing beginner-friendly code & docs is the difference between success and failure in Open Source and thus in a "career" as a programmer. I often see people trying to use terse code when more verbose (i.e. readable) code is much more maintainable. A clear sign of the noviceness is thinking that code is only for the machine to run ... https://stackoverflow.com/questions/522828/is-code-for-computers-or-for-people

All of the topics you have listed are worthy of individual essays with examples. I look forward to reading further. 👀