Hacker News new | ask | show | jobs
by pcmonk 3397 days ago
> Engineers should blog publicly when they have something to say. Something useful for their colleagues.

This sounds a lot like saying, "You should only learn to code when you have something useful you want to build. Something useful for other people".

You can't write a good blog post without having already written some number of bad ones. If you think you might someday have something to say, you should practice blogging.

3 comments

> You can't write a good blog post without having already written some number of bad ones.

To add to this, I'd say: if you don't have a writing habit, the barrier to actually writing something when you do finally have something useful to say will be incredibly high.

I am willing, however, to give the GP the benefit of the doubt because they said "Engineers should blog publicly when they have something to say", not "Engineers should blog when they have something to say". Practicing writing does not mean that you have to publish everything.

So how do you get feedback for non-public work? On technical blogs, I always read the comments. Even for obscure/somewhat poorly written articles. Because someone who knows more than the author will sometimes leave feedback which will lead you in a better direction and expose you to more ideas.

And thankfully, technical blog articles don't attract too many comments on average. Quite often I find that a blog article on a technical point actually advances discussion on that idea.

All I would say is to make a honest effort. Try and do a basic rewrite before hitting publish.

People have been practicing privately and only occasionally getting checkpoints of public feedback across all kinds of skillsets for centuries. It's silly to act like we don't know how to practice in private.

Yes, you need a good guide, good general principles so that you're not practicing in the wrong direction. And yes, you need occasional "recitals" where you test audience reactions. But 99% of the work involved in developing any skill is just raw, rote repetition that most audiences are not only not interested in, but actively avoid.

>> People have been practicing privately and only occasionally getting checkpoints of public feedback across all kinds of skillsets for centuries. It's silly to act like we don't know how to practice in private.

Fair enough. I can see why my comment came across as if I said there were no other options.

But my point is to use resources at your disposal. One of the amazing resource at our disposal today is the ability to cost-effectively publish a half-baked idea on our website knowing that a) that could still be useful for a small section of people and b) its mistakes could be corrected by another small section of people who know the topic in greater detail and c) all this happens in such a way that everyone is, quite literally, "on the same page".

I also find that the second I hit publish, l tend to find errors and implicit assumptions, etc. Something about going public adds extra polish.
Embrace it like Philip Greenspun. The tag line to his blog: "A posting every day; an interesting idea every three months..." (Which is about right. Most of his posts these days are trolling but there are still gems in there.)
Perhaps one should refrain from posting their practice posts, then. Write bad blog posts to get better, sure, but it does not need to be published by necessity.
While I find value in writing things I don't ever intend to publish, that's a different sort of writing. For me, at least, a post written without intent to publish will be very different from a post written with intent to publish.

Writing a post without intending to publish is similar to writing pseudocode, never intending to compile. With great discipline one can learn to write good quality code without compiling it, but if you intend to compile, you actually think differently and produce better quality code.

The analogy doesn't work for me for a few reasons:

* That may be true for producing better code in a particular programming language or family of languages, but not designing better solutions. Designing software including prototyping and pseudocode independent of the constraints of a particularly development environment is invaluable. Too often I squish my problems to fit the tools I know best.

* Depending on the audience writing can be very different. This feels like a different spectrum of communication. I mentor teammates in improving all forms of written communication and this often starts with connecting with the audience of their email.

* Journaling (keeping a dairy) is being shown in recent studies to have all kinds of health benefits.

* Working out solutions free from the technicalities of the compiler and framework is a great technique, and one that I use often. Again, this is great for those who already know how to code, but if those technicalities still trip you up sometimes (as they do a beginning coder/writer), then you get a lot of value out of writing the code before declaring the problem solved (= publishing the blog post before declaring it written).

* For sure, and most people get a lot more practice with certain kinds of writing (email, technical documents, HN comments) than others. Blog posts generally have a certain audience in mind (you can specify at the beginning of the post which audience you're targeting, if you want), and it's a very different audience than most forms of writing. You should write blog posts if you want to get better at that.

* I don't contest the value of writing for an audience of one. It's just different from writing to an audience of a blog (even if that audience is mostly theoretical).

I should note that I disagree with the statement "every engineer should blog", as it has the usual failings of sweeping statements. However, if you wish to become a better writer, and in particular a better writer of content that can be widely understand by a relatively vaguely defined audience, then I highly recommend blogging.