> 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.

> 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.

> But, in a generation publishing their every 2nd gym workout on instagram, who am I kidding anyway.

This is the issue. The latest generation has been told to constant work on their personal brand (ugh), and blogging is one way to do it. Though if we're working together, keeping the engineering wiki up-to-date is probably more helpful for the team than a some Medium fluff piece.

Don't get me wrong, there are some great blogs out there (e.g. A List Apart), and there's a benefit to a blog post reaching 100 people versus a Stackoverflow answer relevant for 10, but I think those that will blog well will do it naturally ("hey, people have been asking about this a lot, I should share a write up").

If everyone just contributed more by answering questions, or updating wikis, that'd would already be hugely beneficial, but to tell people sit down and write long-form is asking a lot. And JCDenton2052 also mentions the possibility of fucking up the signal-noise ratio.

I actually miss the days when engineers blogged more rather than accumulating karma on Stackoverflow. When Stackoverflow emerged it was a great source of knowledge but these days you have to sift through the comments to check if the solutions are still current after api changes. For a lot of stale answers github issues can be more helpful.

The benefit of blogging isn't just to broadcast your knowledge but creating a place to discuss the subject and learn something yourself.

I find it strange that this is the top comment on a forum that wouldn't exist if engineers didn't write publicly. This site is curated from a wide pool of writing and and would benefit from more people writing. Whether something is worth saying is a very subjective call and I don't see how your opinion should dissuade someone from writing.

>I actually miss the days when engineers blogged more rather than accumulating karma on Stackoverflow.

100% hit. I do write sometimes on StackOverflow to give back some help to the wonderful minds over then Internet, because, sharing knowledge is what makes the whole engineering better. What percent of clickbait attention-craving blogging does share some useful insight and/or knowledge?

>I find it strange that this is the top comment on a forum that wouldn't exist if engineers didn't write publicly.

Maybe because you didn't understand the core meaning of the comment? (I address this equally to my writing skills: English is not my first language). It's not "engineers shouldn't write", at all.

Your explanation is very different from the interpretation I made from what you wrote. Yes I agree that clickbait only adds noise but your comment seemed dismissive of engineers writing unless they were exceptional engineers.

Not so, regular engineers should write, it's a question of what they write. I'm a regular engineer, my colleagues are as regular boring folks as possible, yet we're writing stuff from time to time.

Look, here's an example, which emerged this morning as a pure coincidence:

I have a almost-finished blog post draft in front of my eyes my colleagues and I have been writing some time now. It outlines a problem we've stumbled, and, we believe, many other engineers have stumbled or will stumble upon quite soon (while migrating their code from Go 1.3 to 1.6 and further). The problem is exceptionally boring and stupid. We took extremely boring un-brilliant way to solve it.

The engineer who first encountered could've just written something like 'go memory management sucks', or 'how go moves forward and breaks my stuff in production', a million-and-first post about minor opinion. This is what I call useless noise, and, when used for self-promotion, quickly becomes click-bait out of desperation to get at least some attention.

Instead, we've fixed the issue, and in spare time have been slowly adding detail, reproducing cases and generating isolated statistics exactly for this case, and it grew into useful piece of knowledge for regular engineers (like we are) not to repeat the stupid mistakes we've done.

It is not as immediately rewarding, to sit on it longer until your writing has at least some utility for others, and will pay them off for the time and attention and context switch they've invested into you. This is what matters, not the "exceptionality" of engineers who are writing this.

Though they could document what they do or learn with brief posts that are not technically deep but still provide value to those learning. Even sharing one link is sometimes enough to provide value to others. Long form is not required.

Also, writing is a skill. The more you write the better. That means you will sometimes write shit. Thankfully, you can go back and rewrite your early work when your skills improve.

I normally write short posts and then revise them afterwards as many times as required. In fact, I edited this post to add more info.

Yes. The last thing the world needs is more half-baked self-promoting drivel.

I love writing. I put more than half of mine in a drawer. A drawer is a wonderful place for of unfinished drafts that aren't ready or aren't working.

I don't know if everyone should write; that feels presumptuous. But if you do, I highly recommend a drawer.

Bad writing hasn't ever hurt anybody.

I say - write as well as you can and as much as you can, and don't worry about quality. And if putting it online helps to motivate you - go ahead, use every tool you need to keep moving forward, because that is what matters, this is the only thing that matters.

There's been so many times when I was not sure whether my post was worth publishing, and then have received overwhelmingly positive feedback. And then there's been plenty of times I've written something I'm really proud of, and nobody cared.

So don't worry about the drawer, and don't worry how good your writing is, or "whether you should be a writer". All that's gonna do is make you insecure and stand in your way.

Just put yourself out there, even if you're feeling uncertain. Writing always has positive value, to you and to people around. Worst case scenario - nobody will read it, so by putting it in the drawer, you're guaranteeing the worst case scenario.

No, what makes you insecure is pretending youre a writer, when you know you arent. Thats why writers are perpetually insecure, in a nutshell. The advice youre giving is bad advice, as in, literally bad for you.

This is nonsense. What does entitle someone to be called "a writer" other than, you know, writing things? If you're writing - you're a writer. If you've practiced enough to develop good skill - you're a good writer. If you've found a way to make money with it - you're a professional writer.

Writing is never bad for you. It's like saying that you shouldn't be pretending to be a programmer, when you know you arent. What the fuck does that even mean?

First you aren't a writer/programmer. Then you pretend to be a writer/programmer, by attempting to do what writers/programmers do. Then, if you keep doing it long enough, you become one.

Yes, you can become a good writer, but dont pretend you are one.

And yes, writing can be bad for you. You sound like someone whos very attached to the idea that writing is good, but maybe lacking in reasons.

Writing, like everything, takes work. For a lot of people its a complete waste of time.

To me, most writing has no value.

You do realize the irony of your statement. Or do comments on HN not count as writing and therefore not a waste of time?

I would like to know how writing could be bad for you. Please elaborate.

Theres no irony in my statement. Youre just not (intentionally or unintentionally) trying to understand me.

I don't understand you either. Please elaborate.

Im not saying all writing is bad, so his comment just wasnt even relevant.

He seems like he doesnt even know why he thinks writing is good, and if i were him id be a little embarassed.

I'm not really trying to be abrasive or argumentative but your logic doesn't make sense to me and your comments are dismissive and you resort to ad hominem attacks which don't add any value. Which kind of proves your point if you take yourself as an example.

Please do elaborate and explain how and why I should be ashamed of myself because I really don't know how writing can ever be bad for anyone.

On the other hand, publishing publicly will force you to fix every little detail.

For example, the most popular article on my blog is about the TCP "time wait" state on Linux. I knew for years how it worked and wanted for people to stop blindly use some sysctls. Therefore, I thought, what's best than a blog post to spread some awareness on this? But, for every sentence, I had to be sure that this was true. So, I checked, I tested. It took me a lot of time. I would never have done that if this was just for my drawer. My drawer never sets random sysctls and my drawer doesn't know better than me, nor it would shame me for telling incorrect stuff.

It's like publishing as an open source project: you have to be more rigorous in what you publish. There is some balance to find.

I agree.

The open source analogy is actually pretty good. Some projects you know you how to go about right away. But when you're not sure, start anyway; rough drafts are like prototypes. Dropping a few (not all) can be part of the process.

Many times you don't know what's useful to your colleagues until you hit publish. Writing is useful as experimentation that way.

Agreed, I tend to take the number of times I'm asked a question in person by someone new as a signal that a topic is worth writing up.

It's also easier to sit down and come up with a well thought through answer that you can link out when asked again. Opposed to paraphrasing each time and potentially missing key points/clarity.

For example, I wrote this up after meeting lots of clients when I was freelance who were regularly questioning why they couldn't find technical co-founders > https://hackernoon.com/developer-risk-profiles-why-you-wont-...

Writing is, publishing and noising the channels isn't. I'm afraid I find experimentation like that at cost of other people's time and attention to be a bit petty crime.

Do you want people who have a happening social media presence over productive and competent people? It rocks to have both, but one should be prioritized over the other. The moment soft-skills are more important than actually being able to deliver is the moment the game becomes politics.

Unfortunately, this is already the case. People do judge books by their cover.

before we jump in to analyse the content of an article, I think its useful to know who wrote it and what their agenda is.

Many want to sell their services and write long articles because its not as spammy as short snippets. But we should able to tell clickbait.

I mean there are too many clickbaity articles on the internet, arent there ?

It's really unfortunate that people do read my comment as "engineers shouldn't write". Engineers should write. I actually write a lot of stuff, because I like it. There are some pieces of your own research you can't understand unless you write it down in a readable, less formal way.

Some small grain of my writing becomes decent enough (English is not my main language) that my employer takes it and uses somewhere.

Because, I believe, writing is important. Noising everything around with your writing isn't important and isn't even OK.

There's even nothing wrong with using writing for promoting yourself, if there are great things you can share with the world. There are a few dozen blogs I read over weekend, some of them are obviously self-promotion driven to attract attention to services or products; but they give me insight into new things in extremely polite fashion, and I love it. But only when the first phrase of my initial comment is valid:

Engineers should blog publicly when they have something to say.