Many of the writing samples below are from my upcoming academic | textbook, Material in Chess. Despite its name, Material in Chess contains over 350,000 words of non-chess technical writing. Check it out here:
CM H4S1: Sub.portfolio-main #
My first technical writing credential comes from the creation of a pitch deck, and business plan, that garnered $7-mn Series A funding from 4 different investment groups, documented on Crunchbase with the company, Distractify.com. Distractify.com was selected among thousands of potential investments for lead investor Lightspeed-VP in 2014, a firm that has over $1-bn AUM, validating the market valuation of my work, in the millions. If you have a project that you believe will be similarly valuable, then you should hire me as your technical writer.
More extensive, in terms of page count, than my pitch deck, was a more recent project, which I was triggered to start by my head chess coach, and founder of Chessable, IM John Bartholomew: Material in Chess: Effect, Tactics, and Calculation, a comprehensive textbook, and manual, that instructs the technical aspects of chess, from 0 to 2,000 rating, which corresponds to a post-doctoral level of ability, in this field. Clocking in at 700,000 words, MIC is the lengthiest chess book in history, and one of the longest non-fiction works in the history of the English language, featuring, unlike the epic novels and religious Scriptures that are its peers, over 1,000 academic citations, rigorously documented in MLA-9. MIC features significant research in over 30 academic subjects, including nearly every STEM sub-subject, and connects them to chess, historically, and theoretically. See my portfolio for samples from this project.
In addition to book-writing, I have applied my technical writing ability to my work as a software developer<see-portfolio>, by creating rigorous | documentation. My WAMP(Windows, Apache, MySQL, PHP) documentation comes in 2 forms: 1) research of official documentation, provided by Oracle Corporation, PHP-group, Google, Mozilla, etc., and summarize categorically 2) testing documentation, as well as planning, with definitions of done<Scrum>, in the process of development. In addition to WAMP, I have detailed knowledge in WebRTC, WebSockets, JavaScript, C, React, Node, HTML, CSS, Firebase, AWS, CDNs, cloud computing, quantum computing, chess engines<Stockfish, Komodo, Alpha Zero>, other web protocols<HTTP, SSL/TSL, STUN/TURN/ICE>, video codecs, and 10+ file formats. I have the ability # to research, and quickly learn, other subjects, for long-term integrations.
Other areas of academic expertise, in which I have A-level course credit, and can provide transcript proof: organic chemistry<Columbia University>, general physics<CU>, biochemistry, genetics, Calculus I/II, formal logic, international business, evolutionary bio, anatomy, graduate physiology I/II, micro-biology, infectious diseases, French I-IV, Chinese I-VI, linguistics<MIC>, polynomial algebra, cell bio, biophysics, quantum mechanics<MIC>, electromagnetism, entropy, psychology, theology, philosophy, expository writing, European history<AP>, US history<AP>, government, gen-chem, accounting I/II, music theory<MIC>, music performance, applied math, applied logic, statistics, grammar.
H3S1: Invention of the H2/3/4.S-System:
H3S2: STEM writing samples:
H3S3: Chess writing samples:
H3S4: Comp-sci:
H3S5: Business:
H4S1: Business plan:
H4S2: Marketing analysis:
H3S6: White-paper:
H3S7: Technical-proposals:
H3S8: Granular analysis:
H3S9: Material in Chess:
Ultimately, none will speak more volumes than what I did from my own fruition: the authorship of a 700,000 word epic volume, containing over 1,200 computer analyzed exercises, academic citations numbering 1,000+, connections to over 30 academic fields, at a college undergrad writing level.
H4S1: 50+ hour lecture playlist:
Below, is a technical-speaking playlist that I made, based on the aforementioned book, with UCF comp-sci junior Ahyeon Cho, who was gracious enough to play the part of the student. In the series, I coached Ahyeon to a 1,000 LiChess puzzle rating by the end of ch-17, using the technical knowledge in the book. We’ve also solved difficult, Nobel prize tier reasoning problems, provided by Columbia University STEM professor Dr. Deborah Mowshowitz, discussed marketing, and explored other applications of chess in tangential fields.
H3S10: Programming documentation:
H4S1: Personal dash:
H5S1: Problem: Despite only having 300-350 lines of code, personal-dash is a very difficult project due to the sheer number of inter-dependencies, among the coding objects. This creates an inherent technical debt, but not insurmountable, with adequate documentation. One issue that can be faced # in such cases is that a single syntax error can cause breaks of multiple programs, as well as latent issues, that do not break the page in which the feature is in development, but wreaks havoc, unbeknownst, to dependent pages and function calls. As a result, I implemented multiple levels of testing veracity and documentation 1) before working on any program, I created a backup of that code 2) functions that are likely to have a high number of dependencies are moved to an includes folder 3) larger features are tested, off live, in a dev-environment, before push 4) test cases, including dependency testing, were documented, before development began.
H6S1:<WP.MIC-H2S40>: Hu: The importance of constructing an internal library<WP.MIC-H2S38> is not a luxury, but a requirement, for any project that hopes to scale, and have passable | documentation<WP.MIC-H2S37>. We have certain expectations # about how we have expected the language to perform, and when these expectations are not met, there is a more manual, hard-coded | solution, that simply looks hideous, if that in fact, accounts for 80% of our code, by length. Most likely, this is the codebase of Google; a small number of simple functions, elaborated into extremely verbose documents, especially when the cop out # by, every year, switching to more primitive, “easy to use” programming languages, which simply demand even lengthier conditional chains, to accomplish what a more well-documented language can do, in concise terms, artificially jacking up work for their already overpaid staff.
H6S2:<WP.MIC-H2S39,H3S6>: Hu: A high quality troubleshooting and prophylaxis should result in at least a 90%+ rate of expected behaviors, on the part of code, and the dev.test-level; if one is experience a lower rate, then this system needs to be improved, before significant development can continue<Turing!><^H3S3>: Hu: Develop an internal | push-process, in which all new features, and the smallest levels of sub-features, are first developed in a testing document, and is bulk-pushed to the dev-doc, in a completely reversible manner, such that the decision to keep, is binary. In other words, you will leave the dev-doc in a working manner, and one click, copy paste<not-that!><rap!><fbno> the code update, from the test–doc, where it was working. H5S1: A staging test-doc: to test compatibility between the new code, and existing code, should be implemented, and keep in mind, even the transition between this, and the dev-doc, needs to be tested. H5S2: Clearly define the working condition, before initiating the testing phase. H5S3: Place all the testing-progress docs into a separate folder, to remember, which docs are dev-ready, and which are still being tested.
H5S2: The solution:
H6S1: Introducing a testing archive:
<WP.MIC-H2S39>: Theory: In the modern state of programming #, conciseness is a luxury, that, due to the constraints of software | design, and various internal | content incompatibilities, it pays # to be extremely verbose at times, even copy pasting hard-coded, un-scalable solutions, and detach the hooks, only when you’re confident, that the feature is working at the core thread<Turing>; we cannot be frivolous when it comes to, even, being extremely redundant, but this can always be resolved, with an internal | library<Turing>
H4S1: Mental Preparation For False-Surprises:
Hu: A false-surprise in troubleshooting is when you write a line of code that works, but the fact that it works, indicates a fundamental flaw about the programming system. However, if you attempt to preclude yourself # from false-surprises, which can do, as a chess-player, you may never find the “practical | solution“<sued>, so in programming, we have not reached the level of ethics, that is inherently built-in, to chess. H5S1: A slight variation of this, is expecting to something not work #, as you cringe, but it may be the only way, that it can work<max-red><colloquial!>
H4S2: Modularized build-flow:
H5S1: Hard-code the fundamental | action, especially when this action, affects the db, or some other script; test of your hard-coded implementation can have, regardless of the content, the category | of E that you wish to have<McLuhan> H6S1: You should be able to boil down the fundamental–E to a single line of code, a bottle-neck<Turing> H5S2: Test the E, now, with a variable, rather than a hard-coded value # H5S3: Make the updating of the variable dynamic, by making the variable’s value, determined by, a db-call, or form-entry; H6S1: 2 possible dynamic | inputs # to a variable’s value are db-call, and form-entry. H5S4: Dynamic form/db-input, from a different | file containing the trigger H6S1: After we have the dynamic | flow down within a single file flow, we can then segregate the trigger from the processing by moving the form, for example, to a different file, and use the action attribute, to trigger the processing | file, and re-test.