Hacker News new | past | comments | ask | show | jobs | submit login
Writing about what you learn pushes you to understand topics better (addyosmani.com)
707 points by twapi 11 months ago | hide | past | favorite | 158 comments



I started publishing "TIL" posts a few years ago and everything in this post here resonated 100% with my experience of writing those.

The great thing about TILs is that once you form a solid set of habits around them they can be extremely quick to put together: the majority of my TIL posts take between 15 minutes and half an hour to write.

I make extensive personal notes on everything I'm doing (in GitHub issues threads or VS Code scratch documents) - turning those into a TIL is mainly about pasting those notes into a Markdown file and tidying them up a bit.

https://til.simonwillison.net/ is my collection so far.

I get a huge amount of value out of these. I don't particularly care if other people read them, the value is in helping me better understand the material and enabling me to refer back to them in the future.

I refer to some of them multiple times every week! This one for example, about Python packaging with pyproject.toml: https://til.simonwillison.net/python/pyproject


I have this odd fear that sharing what I learned today will make me look stupid.

“Look it’s 2023 this dude just learned about http error codes”. Silly example but you get the idea.


This is one of the reasons I'm so keen on publishing this kind of thing - I like to make the point that you can have 20+ years of experience and still celebrate learning something basic like how to write a for loop in Bash.

No-one knows everything. I respect anyone who is constantly learning new things, no matter how basic those things might be.

Here's the most basic one I published recently: https://til.simonwillison.net/html/scroll-to-text


I love this post for this exact reason:

https://overreacted.io/things-i-dont-know-as-of-2018/

It's written by Dan Abramov who has been instrumental in React's development


That is such a good read.


Such a great post.


The TIL-framing is not integral to writing and publishing little snippets. You can always omit a framing and stick only to the information.


Don't be afraid to take advantage of Cunningham. if you try asking or looking something up and it's not accessible, you'd be surprised how many people would come swarming once you start writing about it, departed to correct you ad show you links to valuable tribal knowledge.


Turn off the comments ;) Or just publish anonymously.

I was actually considering doing this on gemini, because I've got that fear too. An append-only log habit is definitely helping me lately, why not make it (semi-)public?

I think there's a single meachanism underneath both this and rubber ducking. There's something about getting your thoughts in order at a verbal (or textual) level that aids understanding.


Anyone who thinks they don't have gaping holes in their knowledge, and criticizes others for it, is probably suffering from a severe case of Dunning-Kruger.


Yeah, if I see someone criticizing others because "that's so obvious, everyone knows that" the person I lose respect for is that critic.


Obligatory XKCD : https://xkcd.com/1053/


If you always take yourself as being stupid, you will never have this fear in the first place ;)


You don't need to fear looking stupid. You gotta learn about it sometime ;)


You mister Simon, you are the inspiration! For TILs and Py modules.

I wonder what's drives you to make so many Py modules? Do you see reusing modules for your own projects or do you have some other grand plan?


For me, the single most important thing about Open Source is that it means I can solve a problem once and then /never have to solve that problem ever again/ in the future.

So any code I write I like to open source, because that's the best possible way I know of ensuring I won't have to waste time solving that same problem again.

The other thing that helps is that I think I've found a cure for project guilt.

I used to feel guilty about my projects - each one was Yet Another Thing that I should be spending more time on.

The fix I discovered was to make sure every single one of them has good test coverage and comprehensive documentation.

Effectively I treat each one as something which can stand on its own if I effectively abandon it - the thing works, and is documented, and other people can use it as-is without me feeling guilty that I'm not constantly actively working on improving it.

I wrote more about that here: https://simonwillison.net/2022/Nov/26/productivity/


How often do you go over these notes and review or study them? I don't mean ones you need and hence use, but all of them? I have an issue where I feel I have so many notes that I forgot what's in there, and sometimes I remember or find out when I don't need it, and I seem to lack a habit of reviewing my notes.


Some of them I remember and refer back to often. Others I completely forget even exist.

I added "related TILs" to my site a while ago - here's a TIL about how I built that: https://til.simonwillison.net/sqlite/related-content - and as a result occasionally I'll post a new TIL and the related ones will remind me of an older one.

Occasionally I'll completely forget the subject of the TIL itself! I was delighted to randomly stumble on this one here https://til.simonwillison.net/html/datalist the other day (after clicking my "html" tag from another TIL) which reminded me of the HTML datalist element, which I had forgotten existed.


I think it’s a great habit and an effective method for consolidating what one learns … at least until someone cheats themselves using GPT to write up a TIL essay.


I remember an old PhD comics strip where a professor says “Remember kids, the only difference between fooling around and science is writing it down.”. In the context the goal was obviously for it to be funny but it is actually a very good and wise advice.


Not sure which came first or if it’s an even older saying, but Mythbusters said the same thing. https://youtu.be/BSUMBBFjxrY


Wow, that's actually deeper than it sounds. I do wonder though: did a lot of famous scientists (like Einstein, Feynman, Turing, etc) use writing as a vehicle for learning?


> When historian Charles Weiner looked over a pile of Richard Feynman’s notebooks, he called them a wonderful ‘record of his day-to-day work’.

> “No, no!”, Feynman objected strongly.

> “They aren’t a record of my thinking process. They are my thinking process. I actually did the work on the paper.”

> “Well,” Weiner said, “The work was done in your head, but the record of it is still here.”

> “No, it’s not a record, not really. It’s working. You have to work on paper and this is the paper. Okay?”, Feynman explained.


First we augment/externalized calorie storage from our fat cells to our livestock/crops.

Then we augment/externalized our short and long term memory from our minds with writing.

You'll always find a symbol covered napkin next to someone who's working out something difficult, without any writing paper.


See "inventor's notebook": https://en.m.wikipedia.org/wiki/Inventor%27s_notebook - some good examples of famous notebook habits are linked to from there (Einstein and Tesla and Edison and da Vinci are all mentioned).


I wish I was better at thinking in handwritten notes. I've been using computers my whole life, so typing feels very natural to me, while handwriting feels slow and cumbersome. I've become pretty proficient at thinking in code and moving things around in text editors, but whenever I try to do something on paper with equations it feels like there is a mental block there. This has prevented me from learning as much math and physics as I would like to have learned.


Though he wasn't an eminent scientist, I worked with someone who had gone through engineering school back in the 1950s. He kept volumes of meticulous notebooks and saved a great deal of time because he never had to waste hours on "I know I figured this out in October 2022 but I can't remember how".

A real inventor's notebook today has a space to sign and date each page, and you should X out any space you don't use. That helps it have legal force.


> That helps it have legal force

Could you elaborate on this point?


Presumably this is about intellectual property claims.

If you get into legal issues around patents, being able to prove when you made notes on something could be important.

Signing and dating each page helps demonstrate that you've been taking notes at specific times.

Crossing out the areas of the page that you don't use helps in case you get accused of deliberately leaving blank space in your notebook so you can backfill it later on a page that you already signed and dated.

Of course, this is predicated on the idea that you use pen and paper for notes! All of my notes have been digital for over a decade at this point.


I saw one in a stationary catalog some years ago. It was exactly as you describe it.

There was space for a notary seal as well. I think the idea was to have it notarized once every so often so that the notary was affirming the date on the page, and that location of the X-ed out areas.


I thought this was a myth


I still have the bound, page-numbered notebook issued to me by Microsoft in the late 90s for this exact purpose, along with a lecture explaining the methodology above. (A rather misguided effort by an IP attorney who was apparently new to software…)


Still being sold:

https://www.amazon.com/BookFactory-Black-Inventors-Notebook-...

for example.

Notice some of the features: pages are sewn in, so it will be obvious if one is removed, tamper-evident archival paper, space to sign each page.

Paper documents I think still have the most standing as evidence.

This doesn't look like size for a full notary seal but space for a witness to sign. I suppose a notary could stamp it someplace.



Also, see the Feynman algorithm:

https://proftomcrick.com/2011/04/26/feynman-problem-solving-...

> 1. Write down the problem.

> 2. Think very hard.

> 3. Write down the answer.

The first step is crucial.


Feynman was famous for stealing his coworkers’ pens and pencils so I have to assume he was writing useful thing down.


Einstein was really good at thought experiments... and if I remember correctly, he said once that he sometimes had "trouble" to express thoughts in words.


If you can't explain it simply, you don't understand it well enough.

Albert Einstein


It's both flippant and surprisingly deep, which I think is a nice combo. It's also the opening quote in my PhD thesis.


I think you could probably consider mathematic notation as a form of writing.


You absolutely can; it's just a formalized shorthand for words.

That said, people don't publish papers that are just math notation. There's surrounding words to explain and motivate concepts.


The only difference between fooling around and science is p < 0.05 ?


It's still science even with a low p value! It's just a negative result instead of a positive one. Such results really ought to be published, even if they aren't usually.


Well, not all of them deserve to be published. But I understand your meaning.


True, but not all positive results deserve to be published either!


No, because p < 0.05 can be achieved by simply dropping inconvenient variables from the estimation model.

The results dont have to be conclusive for science, they just have to be documented.


That's in the context of recording data from experiments, though


Not only. Just like when actually coding to implement a given specification you find yourself refining the specification and discovering edge cases that weren't taken into account etc., when you actually start writing for other you need to make everything clear and to actually develop your thoughts, and it also "debugs the science", if I may. See also the concept of rubber duck debugging which is another instance of the same kind of effect.


People working in science have employed this process for a long time. Hit your local academic library and look for periodicals called "Annual Review of whatever". More generally, look for review articles and you'll see their work product. Some of these articles are stunningly informative: Feynman's approach works.

Review articles are not the same as meta-analyses; they aren't attempting to evaluate novel hypotheses using existing experimental data, but rather to understand the state of knowledge in a field.

When an academic worker, especially one on the publish-or-perish treadmill, wants to get into a new corner of their field they sit down and write a review article to both get up to speed and to rigorously explore their personal approach. And everybody who cares about the field is better for it.


> People working in science have employed this process for a long time. Hit your local academic library and look for periodicals called "Annual Review of whatever". More generally, look for review articles and you'll see their work product. Some of these articles are stunningly informative: Feynman's approach works.

When you referenced people in science, I thought your example would be a laboratory log. That would indeed be an example of writing about what you learn, while you are learning it. Lab log is also a genre where the intended audience is the author himself, much like a diary. A lab log does not require originality - you may be documenting in it how you performed a certain bench technique that thousands upon thousands of people have done before you.

A review article is a different genre altogether. It has an audience other than the writer. It requires some originality of thought. There is no need to write a review article if a similar one has just been published. Nor would working through a particular protocol from an established book of protocols (aka the docs) be considered worthy of a review article.


I have learned so much writing my Substack. I refer back to my articles all the time when I need a refresher on certain topics. Plus it’s another feather in your cap when you are in a job interview. If you say you know xyz and you can point to a place where you wrote about it, it lends more credibility.

I too have struggled with making writing a habit. But I’ve overcome it in a few ways.

1. I make a clear goal for the year. This year it was 52 articles. I’m on track with 38

2. I evaluate that regularly so I stay on track

3. I find the pressure of having subscribers to a weekly newsletter gives me the impetus to keep going

4. I regularly take time to appreciate all the work and articles I’ve made along the way. I celebrate when I hit little milestones

5. I talk about it often with the people I care about. That way I know it will come up in conversation, and I don’t want it to be one of those things I just say “oh yea I’m not doing that anymore”


I will form my thoughts as a reply to you, since it's in a similar vein. To me, writing is always a tedious process. I can ** out articles quickly, but 52 articles a year? This reminds me of people who say "Read a Book a Day"^tm. If you are really writing articles on topics you have a weak understanding of, while working full time, with the articles being somewhat original/new, how in the world are you writing one a week?

To go back to the generic - journaling (and writing articles) seems very useful until you contrast it with the amount of time it takes to put out something good.

For example, when I have "real" questions, I can't even find a Stackoverflow / Google article on them to even start researching, let alone have my own article out in a week. Unless you guys are writing "Here is the 5001st article on how FastAPI routers work", "Here is how z-level in HTML works!" or something.


I have a full time job so writing 52 technical articles a week would be too much. To give you an example of the type of articles I've written, here are the last 10 articles I've created.

1. Berkeley’s Digital Legacy: The Evolution of BSD and Its Influence

2. Tracing the Lines: From the Telephone to Unix

3. My experience with Pop!_OS Linux Distribution

4. Enhancing Emacs Efficiency with Xah Fly Keys

5. Learning to Touch type again

6. The Complexity of Open Source and AI

7. Racket: The Lisp for the modern day

8. The XML Connection: How docx and odt Share Common Ground

9. An Ode to Emacs. The Greatest Operating System

10. How to Fine-Tune Your ChatGPT Interactions for Better Results

I try to create a backlog of easier articles that I can queue up. Then when I have a few weeks worth of articles in the pipeline, I can work on one deeply technical article that will take more than a single week to write. I've been pretty busy these past few weeks, and am about to go on vacation so I'm working on some lighter stuff. I just finished two back to back posts on Operating Systems (Unix and BSD). The next one will be on Plan 9, but as that one will require more extensive research it will be put on the back burner for a bit until I get through the rest of August.

I read a lot of stuff on Hacker News, Substack, and Lobste.rs, Tech Twitter, and Mastodon, so those are great sources of things to write about. I have also spent the last couple of months updating my Emacs, switching up my keyboard, and focusing more on ergonomics, and those experiences ended up being articles. Once you get into the flow of it, you start seeing all sorts of things to that you can write about.

> "Here is the 5001st article on how FastAPI routers work", "Here is how z-level in HTML works!" or something.

I have done articles like that. An example of that is my article "A soft introduction to working with XML in C#" I've found that the people that are subscribed to my newsletter enjoy my "voice" and the way I write thing. They don't mind a simpler article every once and awhile. I wrote that article around the time I was working with XML in C# and I refer back to it every time I need to refresh myself. It's great because all the tutorials work for my workflow and are in my words so it's those articles end up being the easiest to follow!


I just read the touch typing article. I do know what you mean by "people just enjoy things in a particular voice" and I agree with that, but I guess my main "complaint" is that you probably also didn't learn much from the touch typing article, nor introduce anything new. That sounds like a critique, but it's genuinely not - probably 90% of popular content is rehashing. I am just emphasizing that it's where my issue lies - to really LEARN something is very tedious and potentially not that interesting to the mass audience.


No offense but I think you've gotten lost in your thoughts and wrote down a response mid-conversation with yourself. Your "complaint" has been responded to already. The author finds it useful in the moment for himself, to better understand the topic. The author finds it useful in the future, to reference. Some other people may find it useful, and if you are not one of those people, no problem. If you haven't tried this method, it's likely you are overly skeptical of it. It seems like you have an extremely high bar for anything that deserves to be written down - only that which is new, original knowledge, not written down anywhere in the total extant written history of humanity. There is an argument to be made against spam but I think you're erring on the other side. I honestly suggest you in particular try this method. It will address your underlying concern of "rehashing" which we are doing, right now.


None taken - I wanted to ensure I reply since Decabytes put in the effort to reply in detail. In replying "to reply and acknowledge the response", I was largely redundant. I also agree that I am likely erring on the side of wanting too much from articles.


> 52 technical articles a week

I think GP wrote "a year", not a week.


I started writing a book to teach myself Rust but ended up teaching myself how to write. I've found that I have a much deeper understanding of the language now because I have to actually explain things in detail, and not just get the program to compile and move on. But I would say that the biggest side effect has been learning to write well. That has turned out to be much more impactful to my career than learning Rust.


> That has turned out to be much more impactful to my career than learning Rust.

Could it be that people assume you know rust if you write a book about rust?


I would also assume so but then I suppose that it's basically impossible at this point to avoid a leetcode interview where you have to prove that you can solve Fizzbuzz, even if you've literally written a book on the language. But my goal wasn't to get a job writing Rust in the first place.


I've tried to create a tech blog for a long time. But because I'm quite OCD about my writing, it took ages to create a post.

In the end, writing became such a chore that I stopped altogether.


My blocker was in infra shaming (from myself). I had started on WordPress years ago on a t3.micro instance, and all was well. Then I wanted to self-host since I have a substantial homelab and at the time, was an SRE. But I knew that my K8s (k3os technically) cluster wasn’t great, and I wasn’t using Helm correctly, and… all of this made me think I had to get everything perfect, exactly how I wanted it, before I could use it for publishing tech opinions.

A few weeks ago I found out you can have GitHub Pages with a custom domain, so I extracted my posts, converted them to Markdown, and now I run Hugo. So much easier, and I don’t fret about what imaginary people might think about me.


I have this exact same problem.

Went from GHP/Jekyll (2012), to GHP/Hugo (2013), to GHP/Hexo (2014), to headless WordPress/React (2017), to Ghost (2018), to Netlify CMS (2019), to Vercel/Gatsby (2020), to Astro (2021), to custom Elixir/Phoenix (2022), to Micro.blog and Substack (2023)... (dates are approximate within ~6 months)

I'm still debating what to do next. My motivations go back and forth between "learn some new tech" and "write the dang thing".

Either way, I'd really like to stick to something for more than a year. Ideally I'd separate my "site" and "blog".


What made you stop fretting about that? Did you make the GH-hosted blog anonymous?


Nope - you’re welcome to see it if you’d like (but there’s a huge gap in content, the only new stuff isn’t pure tech, and I make no guarantees about the accuracy of the older content) - it’s my username.dev

It was purely self-loathing/projection (idk, not a psychologist), where I was convinced that if _I_ thought my setup was bad, then surely others would judge me and ignore the content as well. I have no idea how I snapped out of that absurd belief, but I’m happy I did, because I really enjoy writing.


Read the first couple of posts and found them very insightful. Thank you for leaving them public.


I’ve had similar issues and recently made a big step forward by doing one thing: I publish my posts but don’t list them and block search engines from scraping /posts via robots.txt.

It’s not a safe way to hide content by any means, but is just enough to stop myself from worrying about what others still think about my writing. I can still share links with individuals if I want.

I have been trying to get myself to write more for twenty years and this was the first thing that helped.


I don’t really worry about it. Consider so many people spend a lot of resources and strategies to SEO optimize, our hobbyist blogs are probably showing up in the 20th page of some random search.


I write a lot but don't publish anything anywhere. It's kind of like that bo burnham song "look who's inside again". I feel like when I share anything I think, no matter how revised, detailed or not, whatever advice followed, all I find is "another reason to hide again". feeling like having too much to say is a lot like having nothing at all to say in that it amounts to the same thing.


Same. I had a blog for awhile (on blogger lol), and a number of posts on early iOS programming. Some posts had a lot of hits and positive comments. The problem was that every post took me forever. I was so worried about having even a minor error that the stress caused me to stop.

I'm older now and care less about what people think and have more wisdom that the vast majority don't care about what I think, so maybe I'll start up again. It would be fun to share my ~25 years of tech stories and experience for at least myself.


I was like that, assuming people will just throw barrages of virtual tomatoes to my blog posts, then I read a quote from a famous writer: "Your first draft will always be bad. Just revise" (or something similar).

Then I started to write my drafts when inspiration hits without thinking and stopped the moment inspiration ran dry. Then revising/extending as I feel like it. I publish the post the moment it feels complete. The result is https://blog.bayindirh.io.

The gist is, I write about what I want, for myself. It's out there and available. I also submit to here and send to a couple of friends. If I get feedback, that's nice. Otherwise, eh.

Give it a try. There's no need to be blocking yourself out of something you might enjoy.


My problem is time and being in the right headspace. Between family, work, and a plethora of other hobbies that get neglected, not to mention often crippling anxiety, it is astoundingly difficult for me to work up posts on my project blog simply because I am either too busy or not where I need to be mentally to write due to general and pervasive exhaustion. I have been trying to kickstart a space where I can talk about my projects and repairs/restorations for years, but never quite found the secret to balancing life and writing.


I have the same problem, but I also have a suggestion: write down the stuff just for yourself. Like personal notes. Don’t think about publishing it anywhere. For me, this works really well for learning purposes. Although I would also like to publish some stuff, some day, maybe…


This was the solution that worked for me. I started writing things on Notion or Apple Notes because it’s just always at hand. I also started to use Microsoft To Do to constantly write down random ideas for things to experiment after I read a post about training our minds to constantly come up with new ideas to experiment with MVPs.


I'd say that is mainly an issue with people, they think it needs to be published.

Writing becoming a chore is wrong use, because one should not write for "writing" and article we discuss here has nice points on practical use of writing for other means than simply "writing".


An old manager of mine introduced me to the concept of ”not letting perfect get in the way of good” (presumably from the aphorism "Perfect is the enemy of good"). Nobody else knows what your version of perfect is. Your post/blog/PR etc. is ready already.


I’m having this problem now. I want to publish a post about recent months of progress on my project, but while writing it I found the solution isn’t complete and still has some flaws, so I feel I must put some more weeks of work into the code first before I can publish the post…

I’m trying to practice writing “this doesn’t work yet” acknowledging in the post that it isn’t fully done, and publishing the bloody thing. We will see how it works next time I sit down to write!


Same. I want to limit myself to creating posts that are 2 or 3 paragraphs long, but I find that when I start, I expand and clarify so much it becomes another long post.

I always need to have an entire free afternoon to write some prose.


Huh. I've always felt that my posts aren't big enough to warrant publishing. I've been working on a few posts for weeks now but it still feels like they're too insignificant to publish.

Are long posts frowned upon?


Tweets get published, your posts are long enough.


Are you expanding and clarifying for yourself or for others?


The problem will be a useful differentiator to other tech blogs.


Depth. Depth would be a useful differentiator. I need a few thousand words that actually teach me something, not three paragraphs that vaguely gesture in the direction of an idea.


THIS. My favorite example is Jeremy Cole’s blog [0], especially the stuff on InnoDB. You want to take a deep dive into the murky internals of MySQL? This is it. Tons of other stuff as well, but those are my favorite. He wrote tooling to visualize .ibd files FFS.

[0]: https://blog.jcole.us/


+1. Jeremy is well-informed and excellent at explaining technical topics. He and others like Jeremy Zawodny were major forces for good in the MySQL community back in the days of MySQL AB.


I agree. Depth creates much more evergreen content than just "news commentary" or similar.


A workable trick is to write smaller blog posts, come back and add/edit later ;)


I don't recommend applying this technique specifically when reading this article, or you could become entrapped in an endless cycle.


Love this. Ha


See one, do one, teach one is the mantra in medicine.

In the military it was common to hear, "you don't know something until you can teach a class on it." So there was an expectation that everyone should be able to pass on the skills they are responsible for.


To add to what I said in another post - I have found this very difficult to apply to code. Military skills, while underestimated, virtually always have very, very clear steps. Perhaps this is also true of specialized medicine, though probably not outside of quickly troubleshooting certain conditions (stroke) or certain common procedures (clear airway). Basically, combat medicine.

In programming - good luck, literally everything you work with is new, all the time. I guess that's why FAANG tests on useless algos - it's at least something you can memorize and pretend it applies to everything.

Maybe I am just using excuses, but I have never used things I wrote articles on: RxJS, Angular Route Resolvers, Modern CI/CD, Web Components - all of these things either died or I used them once in my career and even the articles themselves are useless.


Not necessarily. To teach somthing you need to understand it very well. The core of it. The essence of it. When I studied I was helping others with the material. I felt how much that improved my understanding of it.

So they might have meant that you don't just need to be able to teach it. You'll understand it only after you've already taught it to someone.


I think it's also important to understand where the practical understanding cut off is. When you tell someone to npm i some_package, you need to pretty much tell them not to worry about how that works under the hood. When you are teaching someone to load a rifle (to follow the initial example used above), you need to pretty much cut them off when they start asking about the composition of modern smokeless powder vs black powder or something. My point is that knowing how deep NOT to go is key to practical knowledge or teaching it.


I dunno how prevalent this saying is, but I’ve heard medical students talk about “watch one, do one, teach one” as the best path to really solidly learning a Procedure. Writing about something is ostensibly teaching. I’ve adopted it, particularly with the robotics team I mentor, and it striking how well it works.


The hardest class, in terms of failure rates, in first year CS in my university was Discrete Mathematics. I got an A- and was pretty proud of myself.

In third year, I became a TA for the course, marking assignments and hosting tutoring office hours. That's when I discovered that apparently I had learned nothing when I got that A-.

Teaching a subject requires you to actually understand it, and not just know enough to pass the test.


"try explaining something makes you realise how well you really understand it."


aka "rubber ducking"


Completely agree. I wanted to learn Python, so I decided to write a book about it. In the end I published it and now I have two achievements: knowing python and having written a book.

I would have never learned so many things up to this depth, if I didn't have to teach them.


I write my thoughts in table and for each abstraction/concept in a cell and ask myself if I need to understand a sub concept to implement it? And put it in a cell in the next column one row below. Sorta like: https://pasteboard.co/GJUcTLVI8jEn.png

I keep breaking down the concept until I am happy with the level of abstraction and I can open it up tomorrow and not be like: " Hmm this sub concept is opaque and it should not be"


This was why I started writing about unintended consequences (unintendedconsequenc.es). I'd choose something I became interested in and would try to explain it to myself. I mostly moved on from the topic, but am using this technique for the next thing now. One note about the way that worked for me -- don't write for anyone but yourself. I went as far as to keep my name off what I published for a year so I wouldn't be self-conscious about it.


I definitely find this to be true. I started with a little notepad calculation on the question of "what if we replaced all gas cars with EVs?" I started adding some details and eventually put it out for anyone to see https://www.capsulel.ink/capsules/what-if-all-the-gasoline-c...

Kinda an amateur "publication."

It seemed so simple but the more I work with the question it gets more detailed and nuanced and I also keep finding errors in what should be an embarrassingly simple calculation. I think putting things like this out in the world and getting feedback is another valuable tool. I guess the author talks about attempting to teach it, which is part, but I also think getting criticism from people that know about what you are writing about is very valuable too.


Where is the best place you've found to receive this feedback?


Hey, so honestly, from sending it to friends. Sometimes I can get feedback online but it's a pretty crowded, noisy place. :) I made this capsule site as a way for more casual publishing of ideas by "regular" people. I thought it might be a nice way for getting more quality, well researched articles online. I plan to add commenting and other "peer review" type features eventually. It will depend on the feedback from users, though.


I've found this to be true, in my case.

I did this series[0], as I was learning Swift. It helped a lot.

[0] https://littlegreenviper.com/series/swiftwater/


Yes. And then share with the world, and who cares if anyone pays attention.


It's a paradox. I'd rather no one reads my ramblings, but then why am I writing them? Somehow I feel it is a shame that most of my inane ideas only exist in my head.

The freeing approach is just to write, know you're a terrible writer, and persevere. I guess that's how you become good, eventually, or maybe you get a following of other idiots that agree with your dumb thoughts :-)


This is why I don't blog, and instead take notes that are publicly accessible. They're for me to refer to, but others may find them useful and I may want to share examples with my coworkers and friends, so I make them public.

EG: https://danielhoherd.com/tech-notes/exiftool/


That's quite neat, but I would say that's more effort than a post, at least for me.

A post is a synthesized idea that has been going on in my head for a while. Write it and forget about it.

Your tech notes are a labour of love that need constant maintenance, which I'm not prepared to do.


This is really quite neat. Love both the idea and the execution.


This is super cool.


You need to refer to your own ideas as inane and to your following as a band of idiots because you know that is how the average reader likes to think of those, how they think of you as a random person on the internet.

I've had more than enough feedback. Only one item remained that was useful, it boils down to: If you think topic X is worth exploring go do the f* work so that you can have a conversation with people who know something about X. They shouldn't care for your thoughts if you know nothing about the domain, they will bother to listen if you know the basics, they will give you time, attention and wonderful feedback if you know the topic well. They don't want to be your helpdesk, they want an exchange of thoughts. You will also be able to judge how great their expertise is which helps a lot ignoring and avoiding [negative] feedback from people who know nothing, are unwilling to learn and/or unable to think constructively about that what is important or precious to you - like exploring your imagination.

I have a thousand great ideas that exist only in my head. At any time at least 999 of them are not progressing.


And the weird thing is you'll find people that care about things you never expected anyone to care about.

Looking through my analytics, things that gets clicks are never what I expected them to be. They're never what I think is the coolest or what I consider to be the best written. They're just random shit I put out there just for the sake of updating my website.


I totally agree. In 2014, I wrote a blog post on a similar subject too.

Original post in Turkish: https://www.phpr.org/neden-blog-yazmalisiniz/

English translation: https://www-phpr-org.translate.goog/neden-blog-yazmalisiniz/...


Early on, this was a motivator for me to contribute to StackOverflow.

I'd look at questions that I sort of maybe knew the answer to, but the question was a reasonable excuse to dive into more details and understanding so I could better communicate and answer the question. It was great way to get some arcane details about how things work.

It's also related to that phenomenon of the process of writing out a sufficiently detailed question to a problem ends up answering the problem for you.


Seems to be a tradeoff between depth and breadth.

If you write an essay about each thing you come across, you'll have to learn the stuff to some depth. That of course takes time, so there's fewer things you can learn about in a given time.

OTOH one can also take the view that learning things properly enables more learning of higher concepts that depend on knowing your stuff properly, and so actually taking your time makes more learning possible.


> If you write an essay about each thing you come across, you'll have to learn the stuff to some depth.

I took the author to mean a much more active pursuit when they spoke about learning — applying the technique to the stuff you're consciously trying to understand better, rather than just any new info you come across.

That said, the depth/length of "write about what you learn" could be tailored to how much weight you want to put behind it — writing could be as little as a thoughtful comment on HN or a tweet as well as a blogpost/essay.


When I’m in a long message thread about an issue our application is having, a little “this would make a good blog post” bell rings in my head once the discussion grows beyond a certain threshold.

I’ll copy/paste the text into my notes and will later generalize it and turn it into a blog post.

Even if the topic seems simple and self-evident, there’s always someone out there who will benefit from learning from your experience.


writing in general is a beautiful tool to give structure to your own understanding of anything.

i'm also genuinely convinced that people do this quite naturally, but that school beats this habit out of you as it replaces what you would normally do with what you're required to do. once you take people's free will out of the equation, their own natural talents suffer the consequences.


Extra bonus for writing about your learning journey . . .

Even for potential readers have been in the field for a long time, these posts can be supremely informative. It's great to hear about newcomers' shortcuts, some of which are mind-stretching for the old guard. And expressing a sincere interest in getting better is a great way to get support from existing experts who are glad to share.


I enjoy writing down thoughts, the writing down the idea is really satisfying. I've been writing down ideas since 2013. I just use markdown README.md on GitHub, they're all public and open to people to read.

I think writing is part of thinking.

I frequently reread my notes.

I would like to go into more depth with more thoughts but I am usually in pattern matching and permutation searching mode.


I like writing but I think the whole “write it and you’ll get it” doesn’t work for me.

It’s just extra effort. Writing is fun for the sake of writing. But I’ve not ever found it helpful for me to remember stuff or whatever.

Either the subject matter makes sense on first pass, or I just need to practice it like math or something a few times and it sticks.

Either you get it or you don’t. And write for fun.


Sometimes I learn something and think I understand it. But when writing about it (without looking it up again) or teaching it to someone, I often find gaps.

I can fill this gaps by reading it again or looking up another source.

I like to think this method of filling the gaps is faster then just reading the material again, because it forces me to recall it first and therefore sticks in my memory longer.


I always wanted to be able to teach what I'm learning, so from the beginning of learning about a new topic is try and rephrase the information I receive and place it within the world I already understand. It's not so easy, but after years thinking about e.g. algebra I've become a good teacher.


That's what I try to do with my personal blog. When I find learn or discover something interesting I try to write an article about it. It helps me understanding if I do really understood the topic (and frequently it's not true), and it also is something really useful for my future self


most of the benefits of writing are pretty clear to me but I'm still unable to improve the efficiency of writing i.e ability to put down thoughts properly and quickly rather than spending a lot of time on structuring the blog, very rarely it feels like english knowledge is the bottleneck


For the past 10 years, I've documented everything I've learned on any topics, most often non-technical ones. Whenever I revisit a topic, I refine and update my knowledge base. I use a private github repo with textual files. This has helped to increase my knowledge tremendously.


Don’t write about it; use it. The real world application of a new skill fleshes out your understanding in a way that is less vulnerable to your own blind spots, is absorbed at a pre-lingual level (closer to your bare metal), and might actually produce something of value along the way.


using it is the first step. explaining it to others the next, and finally to really understand, writing about it so others understand it really embeds the knowledge.

This is why written cultures in engineering organisations are so powerful, especially if you disseminate the responsibility of writing.


I guess I’d say “using it” should be steps 1, 2, and 3. Explaining it and writing about it are generous ways to share your understanding, but in my mind that’s a different goal.


I have found that using "it" is a lot easier than writing about "it". It is not about being generous it is about deepening the knowledge in your mind and structuring it. different strokes and all that. In my engineering teams I enforce a "Written culture", from the bottom up (so mids and juniors are forced to write), as much as possible.


This is basically the whole premise around the "creator economy". Learn what you're interested in, write it down, preferably in public, repackage/repurpose into something of value for the person one step behind you in knowledge/skill.


I was always interested in building an application that helps with this process (not just a writing application but something that guides you through this process). Does anyone know if such a service exists? If not, I might just build it.


But it takes ages


Learning anything properly, in general, takes ages


My experience is that the more I write, the faster I get at writing something that I feel is good enough to publish.

The great thing about self-publishing on the internet is that you can pick the quality you are comfortable with. No trees were harmed in the publication of this blog post!


there's no shortcut to knowledge


another similar concept i have found to be effective is to “teach what you learn”, i have noticed that it takes some good understanding of the topic you want to teach in order to communicate that effectively as well.


Not only a deeper understanding, but to retain the mental state of when you first didn't understand and be able to empathize that in your student's mind.

Some problem domains simply becomes so hard to teach, because once you learnt the domain, you tend to forget what made it confusing or hard, and thus unable to "teach" it to someone who hasn't understood it.


In a similar vein, I find trying to explain something to someone gives you a good feel for how well you understand it. Often I find that I don't understand things as well as I thought after such an exercise.


Yep, only when you try to teach someone do you really understand something.


When you blog, the world is your rubber duck.


This is a big part of the reason students are given homework. It really shouldn't come as a surprise to anybody.


Writing about what you learnt about in bite-sized flashcard systems also helps enormously.


I think I can speak for everyone when I say: heck yeah, knowledge!


but do not make the mistake I have: to believe doing this will get anybody to accept that you understand, or at least this has been my experience so far.


I believe at uni they called that 'exams' :)


True, but at what cost?


^ this.

It may be true that if you write about something, you will understand it better. Sounds logical, you spend more time with a topic, likely it won't confuse you or make you forget it. But is it also true, that this is efficient? Maybe if you don't write about it, instead just reread it, you can understand it even better, in less time?


I think it's because of how memory works so it's like asking "okay but what if I had a different brain" I wish. Retrieving what you learn is the best way I know to remember what you're learning, so writing about it would help. Unless everything I was told is wrong?


Writing is fine, but publishing is another story. Makes me think of Eisenhower's "plans are useless, but planning is indispensable". Write, but then throw away your shit.

IMO and I'm sorry to say it so bluntly, but articles like this are just adding to the already omnipresent noise. I am constantly blasted with tidbits, noobs' their "tutorials" and summaries of summaries.

I'm a louzy writer myself. So it's not like I am actively looking for Pulitzer prize material, but here I find no elaboration, no personal reflection, nothing that elevates it beyond mere scratching of surfaces that have been scratched too much already. What remains is the harsh screeching of soulless abstractions screaming for some life blood.

> "In a landscape where information is abundant, the ability to learn deeply, articulate clearly, and persevere consistently stands out as a valuable skill set."

I'm so sorry, but this makes my skin crawl. This feels like the empty soul of Google itself has somehow found a host to incarnate into and it's now spewing forth bland insights in an attempt to somehow SEO-spam itself.

I actively looked for anything besides regurgitation of obvious cliches and zingers such as "how to deal with burnout: knowing when to rest and recharge is as crucial as knowing when to push forward". I came up empty handed.


I disagree. Without the pressure and scrutiny of publishing, you won't scrutinize your own ideas. Others won't scrutinize your ideas and give you feedback.


I would be inclined to agree if the author had enabled comments.


In my experience I pay attention to every social media place my stuff gets posted. I learn a lot that way.


> IMO and I'm sorry to say it so bluntly, but articles like this are just adding to the already omnipresent noise. I am constantly blasted with tidbits, noobs' their "tutorials" and summaries of summaries.

In the 90's it struck me that the entire internet was trying to be page 1 of something and every article assumed the reader knew nothing. I optimistically hoped that, like when writing a book, multiple pages would be written. Something better than replacing the chapters of a book with domain names would eventually be found. Hell, books would find their way onto the internet as html documents.

I've been wrong before.


Don't lecture people online on what they should or shouldn't do. It makes you sound like an asshole


Somehow, you didn't take your own advice.


I appreciate the irony.


[dead]


in retrospect, sometimes don't write about what you learn about




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: