I think that's a really sad and cynical view. I assume you don't spend 16 hours a day writing code. I assume you have hobbies and other interests. For some people, educating others about their favorite topics is their hobby. Writing about their projects is their hobby.
Here are entire blogs by people who are "doing":
https://perspectives.mvdirona.com
https://www.allthingsdistributed.com
Those are just a few I can think of in one minute. If I went through my RSS feeds and bookmarks I could find more.
He gets paid to write, yes, but that doesn't mean he's not also an engineer. I've worked with him, he does quite a lot of heavy engineering and then writes about it. His writing is so good sometimes he gets paid for it.
But OP said that tech blogs aren't written by implementers, and that's not at all true.
Not usually. Usually the way it works is the person who wrote the code and developed the technology decides to write a blog post about it and then writes it. Then they pass it around to their peers and other leadership for comments and edits.
Then, at least at Netflix, the next step was usually to publish it yourself on the tech blog. Sometimes if it was a big new tech it might get reviewed by PR or legal but not often.
At the other tech companies I don't know what their process is after that.
But what I do know is that I know a lot of those authors personally and they are definitely implementers.
It doesn't matter if it's sad and cynical, it matters if it's true.
That there is a certain number of engineers who have a mix of talent and resources (=time), so that they can exercise software engineering and high quality technical writing?
They are an exception. Almost all the engineers I know (with one exception), who also have a regular life (roughly 40 hours engineering/week), have little time to dedicate to technical writing. As a consequence, it's not unreasonable to state that, in general and in practice, software engineering and (regular) technical writing are mutually exclusive.
It's a fascinating experience. How being a good writer and software engineer go hand in hand. If my library is not easy to understand, my book won't be succesful. I'm constantly going back to edit the library to make sure the book / related concepts can be grokked.
I feel this is a fairly general truism. Great software engineers are often technical writers. Both involve understanding what the 'reader' expects to see, needs to understand, and how the whole narrative/program fits together cohesively. I'd encourage anyone who wants to up their software engineering game to work on their writing skills first.
What I meant is that in real world, due to times constraints, they are. As a sibling poster commented, working as a hobby ends up being a work in itself, so doing both things ends up being, effectively, overtime.
And as a consequence, all the general considerations about overtime apply.
For some people, their hobby is technical writing.
Saying that they are mutually exclusive would be like saying that being an engineer and doing puzzles is mutually exclusive because they both require a lot of mental effort.
Or being an engineer and a musician are mutually exclusive. It's a silly thing to assume that technical writing is somehow different from any other hobby.
Which is why it is not happening. The actual rest time and hobby is when you do it whenever you feel like and stop how you feel like. Once you make it project and treat it seriously, it is work.
Also, other stuff that is done after work: cooking, cleaning, shopping, picking up kids and talking with them, sport to be healthy. These amount to not exactly small chunk of time.
Not only this, but the most accurate business advice tends to be too boring to attract views and clicks anyway.
Link-sharing sites favor controversial opinions and stances that make the reader feel superior to their peers, so that's what the content producers deliver.
This is one of the most poisonous attitudes I have ever seen when it comes to tech content, and unfortunately it is really prevalent in the largest tech companies.
No wonder nearly all the documentation created by the tech giants is complete garbage and often out of date, with almost zero regard for people who actually read the documentation.
A natural consequence of documentation being a "good beginner task" in open source or being assigned to whoever cannot get out of it on the project team.
There are plenty talented, productive people also writing articles and giving talks. Hell, most of what I watch/read (not just skim) is content either from the main drivers of a given tech or people who are experts.
It isn’t that hard to differentiate.
I have a tendency to drop my nuggets of wisdom/analysis in chatrooms in Discord and Slack (and IRC prior) and let others adopt/evangelize them on their own if it makes sense for them to. I'm ok being in the background while my true value is appreciated by those who matter for my own career.
Paradoxically when NOT doing work I share less
Do you code 16 hours every day? Or do you do other things with your time in addition to coding? It's possible to spend your "free time" writing about coding instead of writing code. Humans can do both well if they choose to.
Exactly. You probably spend at least some time on a hobby. For some people their hobby is technical writing.
I can't really agree with this. I think it's worth noting that writing about something you have just learned is a really good way to solidify that knowledge, especially if you are able to get feedback from others. So a lot of people deliberately set aside the time to do it, even if it comes at the expense of greater levels of productivity.
How would you feel if I write a cookbook the first time my bread rolls didn't catch fire? ... to solicit feedback?
I think this depends on what you're learning and how you've learned how to learn. As a beginner, I don't have any business going right to the master to ask about how I can improve my skills, so that I can "level up" and get the best results right away. Then again, we Western folk like pills and magic solutions for everything. We want results now, now, now.
If you're a white belt, go chat with a yellow or orange belt. If you're a blue belt, go chat with the purple belt. You don't walk up to a black belt and ask about the best way to tie your belt. No, you go ask the other white belts who have been at it for a little longer than you have, the people who have a couple of stripes on their belt. These people are closer to where you are in the given moment. They were in your shoes not too long ago, so they can help translate your mistakes, and help make sense of what you're thinking, asking, or learning.
When you see a really great photograph that touches you in ways you cannot describe, you're not seeing the product of an expensive camera, or a filter, you're seeing the result of someone who has taken hundreds of thousands of really shitty photographs over the course of their lifetime. You're seeing the results of maybe decades of practice. If this person writes a tutorial about taking photographs, can you learn from it? Sure. But they're not going to make you a better photographer by osmosis, you've got to go take a lot of pictures and read the beginners tutorials along the way.
So yeah, if I've been burning my bread rolls for months, I'd love to know that one thing you did to not set the house on fire every time you put rolls in the oven.
Pretty much all motor skills like like Karate can be performed okay, good, better, really good, etc. Similarly, I can take gradual baby steps from being a bad photographer towards becoming okay and then good.
But for most programming things, it either works correctly, or it doesn't. There's very little middle ground in an algorithm. Either it works to solve your problem, or it doesn't. Accordingly, I don't believe I can learn much from someone else's broken example in the way that I could learn from a (mediocre but slightly better than me) photographer.
The algorithm can be slow, slightly faster, fast.
The intro into framework can be in the middle too.
Beyond introductory material, it's a trade off of complexity and time as it's hard to compress the factors needed to demonstrate anything technical.
I think it's useful to share my experience on this: there isn't a whole lot of content on it and I think people could benefit from it. It's also helpful for myself, because writing it down clearly means I understand it better too now.
My background here is that I've been programming in Go for over 4 years and have worked with the Go ast package before (though not the analysis framework). I'm hardly a renowned expert on it, but I'd like to think that I have enough background/experience to know what I'm doing and communicate that information others.
But the category of articles that I was criticizing here is when unemployed students pretend to be the authority on topic X to improve their chances of getting hired. Those articles typically do not disclose the lack of experience of the other. Quite the contrary, some of them even make up achievements and/or credentials.
The people actually doing the work don’t have time to talk about it and the people spending all their time talking about it aren’t doing the work.
Of course there are exceptions but I’m extremely skeptical of a lot of stuff I read.
Also that the HN bubble will always make readers feel behind when in reality 90% of the industry hasn’t even begun to catch-up. I felt behind with K8S in 2016, for example, not realizing we were just seeing the wave form when I felt like it was cresting.