If you want feedback on your blog then there are four options:
You can review the work yourself.
You can publish it online and read the comments.
You can join a group where writers share drafts with each other.
You can hire someone to read your work.
#1 only works if you can figure out what is wrong, which you can’t. Besides, you already have published 50 posts on your blog (and written who-knows-how-many drafts) over many years without making progress. #2 tells you useful information but not how to structure a post. #3 might or might not fix your problem. Not everyone’s personality is suitable for writing groups. #4 makes sense if you have money and can find the right teacher.
I have trouble deciding how to structure posts (or whether I should split them into a series), and I’m terrible at writing introductions and conclusions. I’m also not particularly good at headlines, although I consider this a less-important problem.
I read the five most recent posts on your blog. Your self-assessment is correct. Your posts do have structural problems. Your introductions and conclusions are terrible. Your headlines aren’t great either. These issues mostly stem from your posts’ lack of a clear objective.
“Etherium GPU mining for paranoid noobs” is written like story but the meat of the post is instructional. The objective (what the reader is supposed to get out of this) is confused. You should turn it into a story or you should turn it into an instruction manual.
“Indexing and sorting to find data quickly” could be better than it is. The sentence-level writing is fine. The technical information is fine. The post is unclear about what value the reader is supposed to obtain by reading the post. Your post should be a systematic tour from low-level to high-level but it reads more like list of n things. One level should flow naturally from the last by solving a problem in the previous level. The introduction and conclusion of this post are bad because they digress from the meat of the post.
“How to write examples for documentation” has an unambiguous objective. It needs at least one example. Multiple examples would be good. A single example would be better. The post should start with a bad example and then show the user how you iterate the bad example into a good example. Delete the last paragraph.
“Easy mistakes when writing OCaml C bindings” does use examples. If the mistakes are random then it should be a list of n things. The post shows more promise than a list of n things. Instead of listing mistakes you should structure this post as a sequential checklist of how to debug your OCaml C bindings.
“How to use Core.Command.Param” should be written either in the format of random access technical documentation or as an introductory guide.
I have lots of experience teaching things and I am available for hire. If you would like to hire me to help you learn how to write better then PM me and maybe we can work something out.
Thanks for the in-depth feedback! Your points make sense to me, and I think you’re right that I probably need to join a workshopping group or hire someone. Publishing and reading comments would probably work (seems like the way most people do it) but the feedback loop is just too long.
Something I’m realizing from your comments is that I need to decide what type of article I’m writing and then structure it based on that. I think I’ve avoided the “list of n things” because it feels Buzzfeed-y, but I should probably embrace it when that’s the kind of article I’m writing.
I think I’ll try going over these articles again and probably contact you via DM to see about hiring you to give me pre-publishing feedback in the future.
If you want feedback on your blog then there are four options:
You can review the work yourself.
You can publish it online and read the comments.
You can join a group where writers share drafts with each other.
You can hire someone to read your work.
#1 only works if you can figure out what is wrong, which you can’t. Besides, you already have published 50 posts on your blog (and written who-knows-how-many drafts) over many years without making progress. #2 tells you useful information but not how to structure a post. #3 might or might not fix your problem. Not everyone’s personality is suitable for writing groups. #4 makes sense if you have money and can find the right teacher.
I read the five most recent posts on your blog. Your self-assessment is correct. Your posts do have structural problems. Your introductions and conclusions are terrible. Your headlines aren’t great either. These issues mostly stem from your posts’ lack of a clear objective.
“Etherium GPU mining for paranoid noobs” is written like story but the meat of the post is instructional. The objective (what the reader is supposed to get out of this) is confused. You should turn it into a story or you should turn it into an instruction manual.
“Indexing and sorting to find data quickly” could be better than it is. The sentence-level writing is fine. The technical information is fine. The post is unclear about what value the reader is supposed to obtain by reading the post. Your post should be a systematic tour from low-level to high-level but it reads more like list of n things. One level should flow naturally from the last by solving a problem in the previous level. The introduction and conclusion of this post are bad because they digress from the meat of the post.
“How to write examples for documentation” has an unambiguous objective. It needs at least one example. Multiple examples would be good. A single example would be better. The post should start with a bad example and then show the user how you iterate the bad example into a good example. Delete the last paragraph.
“Easy mistakes when writing OCaml C bindings” does use examples. If the mistakes are random then it should be a list of n things. The post shows more promise than a list of n things. Instead of listing mistakes you should structure this post as a sequential checklist of how to debug your OCaml C bindings.
“How to use
Core.Command.Param” should be written either in the format of random access technical documentation or as an introductory guide.I have lots of experience teaching things and I am available for hire. If you would like to hire me to help you learn how to write better then PM me and maybe we can work something out.
Thanks for the in-depth feedback! Your points make sense to me, and I think you’re right that I probably need to join a workshopping group or hire someone. Publishing and reading comments would probably work (seems like the way most people do it) but the feedback loop is just too long.
Something I’m realizing from your comments is that I need to decide what type of article I’m writing and then structure it based on that. I think I’ve avoided the “list of n things” because it feels Buzzfeed-y, but I should probably embrace it when that’s the kind of article I’m writing.
I think I’ll try going over these articles again and probably contact you via DM to see about hiring you to give me pre-publishing feedback in the future.