When reading succinct technical documentation, I see how so many times the documentation attempts to cover everything possible. ~
Most developers want guidance instead of exhaustive details. Developers want to know where they should focus their time and where they can afford to skim over the documentation. And they want to know where they should expect to encounter problems and difficulties.
A simple framework to use when producing succinct technical documentation is to divide the documentation into three sections.
Maps: Identify what type of problems this documentation can assist you with
Defaults: Understand what the majority of people will experience and what to do about it.
Exceptions: Identify when to deviate from the default recommendations.
Succinct documentation does an excellent job of providing clarity by eliminating edge cases. The more clearly the user understands the documentation the more useful the documentation will be during the time where the user is experiencing the most confusion.
The danger is the temptation to simplify the information contained within the documentation to such an extent that the user is left with a large amount of missing information and no method for seeking assistance with incomplete information.
What situations have you encountered where the information contained within short technical documentation has been more helpful than official technical documentation? ~
I don't know if I'd call a book with 61 chapters "concise".
Popular in 2023 (215 points, 91 comments) https://news.ycombinator.com/item?id=36641634
Please provide a PDF as well. I cannot read books in HTML format because I need to keep track of where i left. That means I either have to leave the browser tab open (but this is prone to accidentally closing it) or I need to bookmark every progress, which creates noise in my bookmarks. With a PDF I simply leave it, the reader remembers my last page. I also have a sense of progress with pdf.
I was wondering what is the community's opinion on the official TypeScript Handbook
I know why typescript "succeeded", but always wonder what kind of web we would have if infact Haxe had become more popular for web in the early days. My guesstimate is we would have had bundlers in native code much, much earlier, and generally much faster and more robust tooling. Its only now we see projects like esbuild, and even TS being written in a compiled language (go), and other efforts in rust.
Also it would have been interesting sto ser what influence Haxe would have had on javascript itself
> Some of the benefits of TypeScript:
> Access to ES6 and ES7 features
> Cross-Platform and Cross-browser Compatibility
Damn, I wasn't aware that since I avoid TS, I cannot use ES6 and ES7, and my vanilla JavaScript doesn't run in all browsers :(
I guess over-hyping the technology that the book is about is to be expected, but it still leaves a slightly sour taste in my mouth when people oversell what they're talking about it.
Thanks for sharing, this is useful.
To the author, congrats and thank you. I have one piece of feedback:
When you are typing Typescript on your keyboard you are typing types using a strongly typed language.
Some definitions would be useful to novices: 'type' as a noun or verb, in the mathematical context + the notion of 'strong'.