13 comments

[ 4.9 ms ] story [ 41.2 ms ] thread
This is why when you search for a solution you get pages of people's blogs who rarely know what they're doing.
At least they try?

And share their findings.

...and these posts more than once saved my ass or gave a clue to find a solution or at least gave some context where to look.
True, there's a lot of crap blog posts out there, but I dare say that that's a good thing. An important part of learning how to write code is developing code literacy, which includes being exposed to bad code as well. If the internet were a repository of nothing but reliable information, there would be no need to learn how to recognize code smells.

Moreover, it's good to be exposed to scenarios where the code is technically correct, but the attitude of the author ought to raise red flags - for example, unnecessarily representing a solution as authoritative, discounting other approaches for dumbass reasons (such as preferring fewer lines for its own sake), saying that a problem is "simple" to solve, you "just" have to do this, etc. They tend to have the effect of shutting down critical inquiry, and that's a good thing to learn how to recognize.

In other words, you can learn a lot from hamfisted tutorials and toxic teachers.

Learning in public can't be the fastest way to learn by definition. It takes time to write and publish. It takes A LOT of time to write well.

Learn and get paid for it asap. Learn what your client/project/employee needs and everything around it - this is the fastest and most rewarding way.

> Learning in public can't be the fastest way to learn by definition.

What definition are you referring to, because that statement doesn't make sense.

If you equate "consuming information" with learning, yes you are right that learning in public is more time-consuming than learning in private.

However, there are several studies[1] that show dramatic improvements in retention and understanding from material vs. just studying it. So if you consider retention and understanding to be the goal outcomes of learning, forcing yourself to structure your thoughts about the material enough to communicate it with others has clear benefits to learning rate.

[1] Example: https://www.sciencedirect.com/science/article/abs/pii/S03614...

This is from the same guy who I believe said "systems > goals" (or least repeated it), forgetting the fact you need goals to accomplish before you can build systems to accomplish them.

I believe in writing a technical blog when you're starting out because it can help you help a job early on in your career. A message to a Linux User Group got me an interview and my skills got me the job.

I work on a lot of opensource side projects that may be of interest to some and thought it might make sense to livestream it. I can usually set out to do a specific new thing and close it out in one session so might fit the format.

Does anyone do livestream development? How has it been?

I considered doing this at one point and spent some time on Twitch to see if other people did it. I found a pretty active community but in a lot of cases was overwhelmed by the streamer's desire to demonstrate how smart they are. I think it would be an enjoyable format otherwise.
That's' too bad. I would've thought that the 'time between interesting insights' would be too low to maintain interest.
Further reading on a related notion: Bloom‘s (revised) taxonomy. The idea that mastering a skill means producing new content related to that skill, which is considered the highest order skill. Lower order skills would be „understanding“ and „applying“ (using).

https://en.m.wikipedia.org/wiki/Bloom's_taxonomy