> One person at a company with a compelling blog noted that a downside of having only one approver and/or one primary approver is that if that person is busy, it can takes weeks to get posts approved.
Heap CTO here. I'm pretty sure this quote is about me! Or if it's not, it would be equally true about me. This is why we rolled out the "buddy" system described in this post. That way 90% of the iteration can be between the engineer writing the post and someone else who will be a lot more available than I am. This matters a lot if a post requires three or four round trips to really get it right. Plus, in a lot of cases, that other person is better at technical storytelling than I am to begin with.
I'd also note that this post and HN discussion focus a lot on reducing friction, as if having a really good blog is the state of nature. In my experience, this has not been true. A good blog won't just happen if you get out of the way.
Someone senior at the company needs to actively prioritize the engineering blog. You also need eng leadership that respects that writing posts is real work and is willing to have engineers spend time on-the-job working on them. At Heap, we do this down to the level of taking this into account in sprint planning. Also, a lot of the good ideas for posts come from working with engineers to find the kernel of a story in something they're working on. This is an active process, not something spontaneous that you just have to permit to happen.
We also benefit from having a lot of legitimately interesting technical work to talk about. This is more true at some companies than others, and is a big multiplier on how compelling you can make your blog. The success of a blog post is pretty non-linear – either it gets wide readership or not much at all. Having something interesting to talk about is pretty important, and is hard to manufacture.
Dan, having been that exact same bottleneck it's common for many.
And echo everything your said. In terms of getting something out the door as soon as you do that you've diminished the impact of the post. It's similar to quality engineering you ship it when it is ready, not because you said it'd take a week and you spent a week on it. Most engineers hate artificial marketing deadlines, being able to work on a post to get it into a good state can be equally as unclear in terms of timing as engineering.
I've found that a dedicated mentoring process, similar to your buddy system can work well. As you're growing the people that are able to review/drive content having them follow along as I review posts and provide feedback helps for them to internalize some of the steps. In my experience after shadowing for about 5 posts they're able to start guide someone else with still some need for support and final reviews.
A final note, as someone that has written a lot of content I can crank out a post in anywhere from a day to an hour. For someone that has an interest in a topic you shouldn't expect the same output (time wise) as someone that does this more frequently, a quality blog post for someone not used to the process can spend multiple days up to a week in total on it. This comes down over time and with practice, so you shouldn't assume it's always that high, but it does take repetition.
Finally, everyone has interesting technical things to talk about. Anytime an internal email is sent to engineering@ about some interesting tip, how some problem was solved, or a guide to how to accomplish something it's a great candidate for a post.
> A good blog won't just happen if you get out of the way.
true, but if you get in the way, you have a lifeless/corporate-feeling blog, which is (subjectively) worse.
as someone who has worked in the blogging trenches, i can say that overzealous/overconservative processes can really stifle blogging flow and the primary alternative you're competing against is the engineer writing for their personal blog, which they know has long term career value as well. usually not all participants in the review chain are equally bought in to growing the blog and you eventually get your best writers self selecting out if you aren't careful
i do like the buddy system you propose, that seems like a nice solve!
what are your thoughts on having dedicated content writers - like technical writers or developer advocates - working on/owning the blog, vs "all engineers are explicitly encouraged to blog"?
Personally, I feel the main part where I face the most difficulty in writing blog posts (for companies), are illustrations which adhere to the branding guidelines/style of the company. I feel these custom illustrations are something that makes the blog stand out and the content easy to consume (attractive?) for a general reader.
Even if there are no direct instructions to follow the design principles/themes of the company, it kind of makes sense that there are some underlying design principles that all the tech blogs are adhering to (in terms of videos, animations, illustrations, code snippets).
I know about tools like [1] but they are fairly basic (afaik) in terms of visuals.
For instance, look at the amount of work in creating illustrations for [2], it seems they had someone assigned from the design team to help with these. Another example is in the blog post [3] linked in the original post.
We are really lucky at Cloudflare having a just amazing designer https://twitter.com/kkblinder who can create an illustration or diagram so fast I still don't know how she does it.
Could of years ago I wrote a blog post explaining Spectre and Meltdown (aimed at the relative layperson): https://blog.cloudflare.com/meltdown-spectre-non-technical/ She did the illustrations based on a really vague explanation by me of what was needed. I think they really made the piece.
One of the best pieces of feedback I got at Heroku was don't stress too much on it being perfect. In fact you can make it rough as if drawn on a napkin so it intentionally isn't visually polished and it accomplishes its goal. I in fact started doing some of this way back at Heroku 9 years ago and the approach worked well. Now I've leveled that up with an iPad and paper.
Yes, there are places that have designers and they're a great resource, but don't let that be a blocker. If a company has a designer that can be dedicated and support such awesome. If not just try something and see what works, then keep using it.
I'd say a consistent style or pattern is important, but illustrations, specifically, are not required. Check out the Harvard Law Review. It contains thousands of articles without an image.
Know your audience. Illustrations can certainly be helpful to a general audience but they won’t save poorly organized content. The written content should flow well enough to stand on its own.
If you are writing a blog where corporate branding is associated then commandeer a graphic designer from your employer. They are going to be more in tune with the company’s legally approved branding guide and likely to produce better quality visual products in less time.
The images at the second link are so nice! curiously enough, I wasn't seeing them because they were being blocked by Pi-hole (with default block lists)...
I definitely become more attracted to companies with high quality blog posts on things I'm interested in. The right blog is a really big signal that I'd be interested in the work at the company.
Besides picking the next company, great blog posts can be a real help in sanity checking the work that's happening in our team. I've noticed even senior engineers treating good blog posts from big companies as "See, we're not crazy".
Right now I'm operating in the data science platform space at my company, and have been reading a lot more company blogs than usual. Wayfair is a company I now know of after an engineer I really respect shared on Twitter "Bayesian Product Ranking at Wayfair"[1].
Lyft, on the other hand, disappointed me with "How Lyft Designs the Machine Learning Software Engineering Interview"[2]. That post sounds like it could have been victim to what Dan notes as:
> Approval/editing process mainly de-risks posts, removes references to specifics, makes posts vaguer and less interesting to engineers
I was the eng blog lead at Lyft until recently, and ran it for years. We have a really lightweight process: just needs to be approved by your director, and copy-edited by someone on the blog team. Process usually only takes a week or two. You should probably check out the other posts on the blog.
We aim our posts towards a number of audiences. Our posts related to our interview process are to let candidates know what to expect when they're coming in for specific interview types. We actually get very high traffic to those posts, and we've gotten strongly positive feedback from candidates about those posts, so we've written them for a number of positions.
We also have posts oriented towards working with non-engineering teams, mentoring, engineering processes (like writing tech specs), and other things that aren't only technical deep-dives, because we believe in diversity of content.
This post is totally accurate. I am a corporate blogger, and when I started at this company, we had a ridiculous approval process involving legal. Now, we just don't do that process, and focus on getting the engineering stuff right and doing absolutely no other content: engineering only, no marketing crap. By removing legal approvals, we went from publishing once a week to publishing once a day, and our hits have doubled in a year. Approval processes that extend past engineering are evil.
I think this doesn't account for what is, in my experience, the most common reason why engineering blogs fail: they have the wrong objective altogether.
In a former life, back when printed magazines were still a thing, I used to do some (pretty bad) tech journalism, so every time $crt_employer wanted to run, or expand their blog, I ended up going to meetings (I now do that professionally as well, actually -- it helps keep those programming-related brain cells sane). The vast majority of posts (and blogs) that I've seen were awful not because of a tortuous approval process or lack of high-level support. They were awful because communicating substantial, serious engineering information was not the main point. Or one of the main points. Or a point at all, really. It was usually just an excuse to push out some marketing and "establish a presence", and management felt that involving technical people writing on technical subject would lend that effort the kind of credibility that ads don't have.
This had repercussions over the whole publishing chain, and these efforts were doomed from the beginning. Topic selection was inadequate (topics were selected primarily so that they'd have the right "ring" to product/marketing/business development managers, rather than so that they'd be interesting for a technical audience). Editing was done with the wrong objectives and targeted the wrong metrics, and was often based solely on input from non-technical people who didn't understand what a technical audience wanted. Then this article -- on a topic that wasn't really interesting for a technical audience, and not really written for a technical audience -- was promoted mostly for a technical audience. Since the people who were doing the promotion were, inherently, in non-technical position, and they mostly consisted of a boring tech article with a mini sales pitch attached at the end, everyone ended up seeing them as marketing fluff.
It doesn't help that our industry is still stuck in this world where "technical" and "non-technical" is a very strict dichotomy, where technical people are basically like a 2020 Mr. Spock and non-technical people can barely type on a computer. That hasn't been then case in more than ten years. A lot of people who are seen as "non-technical" -- people in sales, marketing, or in management positions -- have grown up with computers. Lots of people in decision-making positions used to hold a technical position at one point. The kind of depth that a non-technical, but not tech-illiterate audience appreciates can be very surprising.
> people in sales, marketing, or in management positions -- have grown up with computers.
This doesn't mean anything. Have you watched some 15-22 year olds interact with computers lately? (I'm 23, for reference). They don't hunt and peck on the keyboard in stereotypical fashion but they're just as clueless for anything besides basic interactions. They -are- essentially tech illiterate once they step outside of google sheets, etc, or the web browser in general.
I'm tired of hearing people say "digital native" like it means anything with regards to tech literacy. We're going to have another generation come in and take power that has zero idea of how computers function. At least we understood this and factored this in about the last generation- now we just assume the new generation knows things because they grew up using apps.
If anything, the new generation is more illiterate on average, but with better mechanical facilities and understanding of typical modern UX for apps.
If you leave it to the marketing people you'll get buzzword fluff that provides no value or interest to anyone.
If you leave it to the engineers to write about interesting things, and get the approval process out of the way then you might put up something of interest to engineers.
> It doesn't help that our industry is still stuck in this world where "technical" and "non-technical" is a very strict dichotomy, where technical people are basically like a 2020 Mr. Spock and non-technical people can barely type on a computer.
It can still feel that way, though, especially if you have any intersection of cutting-edge software or hardcore engineering with corporate bureaucracy. It's really a question of roles-in-context not holistic identity. If you have corporate managers and project people spending a lot of time in meetings talking about the "ABC initiative" to each other without a single one of them even having taken the time to walk through a basic "Hello World" tutorial for the ABC itself, you are dealing with "non-technical" people.
Yeah, many engineering blogs fail because of content reasons, not organisational ones. In many of the smaller places I worked at there weren't any institutional obstacles to posting content to the blogs. It was a matter of not caring much about the blog or writing the wrong content (stuff that isn't helpful or interesting).
For a successful corporate blog (engineering or otherwise), writing blog articles needs to be a foundational part of the company culture, the different teams must work together to create the best/most useful content possible, and there must be a schedule beyond 'whenever we feel like it'.
The question on how to utilize social networks and platforms like blogs and connected to that Twitter etc is a recurring theme of all my employers so far. And it's an unsolved problem. The core question is who should create a text (or pretty much anything not resulting in a product), when and why? Obviously it would be a red flag if a company expects an employee to invest private time into something like this. But how much time is supposed to be dedicated? I have been blogging on data stuff for a while and a sound, well-written and non-trivial article takes longer to write than a work day. And that is an investment that most managers shy away from and instead compromise on quality or just ditch the idea. Writing shallow articles for a while will be demotivating, boring and not worthwhile in the long run.
I really respect companies that have well-written engineering blogs that go in-depth into their technical problems - Figma comes to mind here, for example.
For a small team/company, what are some good tips or resources on how to start an engineering blog? We've worked on many interesting challenges and I know the team would have a lot of insights to share, but it can be difficult to find and justify the time that writing a good article takes, and it's not something that everyone is necessarily interested in doing either.
I'm curious about the mention of Cloudflare's culture of "internal blogging". That seems to me like it could be a first step in that direction.
We use Confluence for all sorts of stuff and there's a blog category. It's full of stuff. Some of it would make a great public blog (in fact, one cool investigation is getting turned into a public blog right now). Some of it is so internal and full of details that it wouldn't do well publicly but is good for others inside the company to read (and a good way of having a memory of how we did something).
At a previous company (30-40 employees) the main thing was having a blog setup somewhere that engineers could post to - clearly distinguished from the main product blog. Actually getting engineers to write up blog posts was a separate problem. Besides me there were only a handful, even when it was made clear that it could be about a very small topic. A few hundred words is plenty.
Not CF, but my employer has a list for emails like that, where people might report on things they did, things that didn't work, ... Which sometimes is only of internal relevance, sometimes about things we can't share publicly, but sometimes also prompts "this could be a blog post interesting to other people"
My experience at Pivotal (now VMware) echoes Dan Luu's point: the less friction to publish, the more posts on the engineering blog [0].
Our current set-up is simple: clone a repo, create a blog post (in Markdown) from a template, and when you're ready to publish, commit & push to the master branch. We put a lot of effort into making the process simple for engineers.
However, before that process was put in place, it was much more burdensome. I remember in 2014 I had written a blog post and it needed to go through Marketing: Branding was important, and formatting was a challenge. Also, I encountered feedback unrelated to engineering content: "You need a call to action," said the person in charge. I was baffled: "If they've found my post, it's because they're trying to fix a particular problem--they've already had their call to action." The process was discouraging, and I didn't write a blog post for a long time afterwards.
To be honest, I don't think giving away information about your strategic edge matters that much. What does matter is the culture of a company. If you're hustling, you'll create extra new edges big and small all the time. If it's a big edge, the general outline will be good enough to tip off your competitor without you talking about it. As the saying goes, execution matters a lot more than ideas.
You can share your knowledge, which quickly turns you in a gathering point for interesting knowledge. This makes interesting stuff, good employees and new customers come to you begging for attention, which is a much bigger strategic edge.
On the other hand, imagine Dan Luu's example company that takes a year to approve a blog post. If your culture is that bad, even discussing if accepting a mountain of money laying on the street no strings attached is acceptable will take a few months. Show them your edge, and assuming they see it as actually valuable instead of extra work, it will still take a year of bureacratics before they start implementing it.
See also Rudyard Kipling:
They copied all they could follow but they couldn't copy my mind
so I left them sweating and stealing a year and a half behind.
> There is a non-trivial overlap between "look at this cutting edge cool stuff we're doing" and the company's strategic edge over competitors.
I don't really agree. I think the more you write about what you are doing the more you attract really good people and that's the strategic edge on competitors.
I think the bigger risk is you write a blog about some "cool stuff" you are doing and it's actually not cool, it's dumb and obsolete and people who might have been thinking about working at your company go apply to Microsoft instead. There's abundant examples of "How we handled a billion queries per year with only 1000 servers" out there. It's the risk that you don't know how you really compare to your peers.
Personally, the only "technical blog" I want to see from a company is papers accepted by OSDI, ISCA, VDLB, etc.
Sometimes you can drill into things that wont give anyone an edge but will help out many people due to lack of documentation. There's so many solutions I find for web stuff after googling around and reading through code after code only to come up with my own unique variation.
I think there are a lot of things people can post about that are not core to the business value. Of course any IP or trade secrets should be kept off the blog, which is, I assume, why the CTO typically reviews posts at the "good blogging" companies Dan mentioned.
There is also liability as a risk. At least for big companies. There is no money in sueing a startup, but big companies get constantly trialed. Especially, if they work in security/safety/mission-critical field.
Fast path is essential for corp blog posts. Reduce friction. Don’t even think about using your standard corporate release approval process, it’s unsuitable. As for design, I’m a minimalist. This is an engineering blog so it should be like sitting in an engineering meeting. The chairs and mugs are corporate colours but the diagrams can be _very basic_ while still being clear. It’s a balance.
> my blog helps me with job searching and it helps companies hire. But I only need one job, so more exposure, at best, gets me a slightly better job
I feel the same way about open source in my case. I already have, say, 6+ repos with quite a few stars, high quality and lots of installs. I keep doing OSS because I like publishing the tools I make and other people using them, but it's definitely past the point where there is a ROI with hiring.
Recently I got `react-test` and I'm building it, but I decided to ask for help from beginner programmers. I think it can get to a very nice place within the OSS community, and I don't mind sharing the credit with other contributors. We even published a bunch of detailed issues asking for help but I haven't found many people who are interested yet: https://dev.to/fpresencia/contributing-to-js-react-open-sour...
The irony of the linked blog having no justified text, larger headlines--instead of just using bold regular text--nor reasonable margins is staggering. I find it very annoying to read.
This reads as if "blog" is a metaphor for "product". I'm guessing that blog process is a pretty good indicator of development strategy. Stale bland blogs predict stale bland engineering.
It's not just about the content, but the typography, the style, illustrations...
I don't know why but I'm more and more sensitive with the general reading experience.
I wanted to try it, but their RSS/ATOM feed support is broken. The feed[1] currently 404's with a single emoji[2]. No feed support is a non-starter for me.
Question for you since you presumably read their blog: Do you follow a bunch of blogs/news sources? If so, how do you do it without using feeds?
I explored the business idea of "engineering blog in a box" and talked to a couple of companies about it. The idea was that, just like a drip campaign for customers has value, so does a drip campaign for engineers. You provide good content, an easy way to subscribe, and periodic calls to action (around a role) and you'll get conversions (aka hires).
Didn't go anywhere, but it seems that engineering blogs are an unoptimized recruiting channel. If anyone here wants to chat more about this idea, my email is in my profile.
>One person at a company with a compelling blog noted that a downside of having only one approver and/or one primary approver is that if that person is busy, it can takes weeks to get posts approved.
One way around this would be to have 14 stakeholders arranged so that any individual can approve the post. That would do as much to speed it up as a 14-person unanimous/veto system would do to slow it down.
One thing the company I currently work for has done is to use our "corporate blog" as a directory for technical employee's personal blogs. Many of our tech team members write blog posts on their own time about technical problems they're particularly interested in. Having our corporate blog (https://codeshare.getfreebird.com/) redirect to their personal blog allows our company to highlight our team's ability and provide interesting content, while the authors get a signal boost from having their content referenced from the company's technical blog.
We're a small technical team so I'm not sure how well this scales, but it's worked out well for us so far.
Well, they can actually be helpful. I've found a lot of good info on company blogs from engineers about embedded programming, electronics, and other topics.
You can also think of it as marketing for engineer types who are usually immune to formal forms of marketing. Managers don't care about details, they want to see $ numbers. Engineer types want gory details. So your engineering blog can help market your products to engineers. Just look at intels documentation pages vs their actual intel.com site. intel.com is marketing 101 eyesore.
An example would be a blog from a semiconductor company making analog circuits. Think Bob Pease types. They'll talk about a specific problem or circuit, go into the bloody details, math, schematics, charts, graphs, etc. Then toss you a product from their portfolio that can solve the problem.
[+] [-] drob|6 years ago|reply
Heap CTO here. I'm pretty sure this quote is about me! Or if it's not, it would be equally true about me. This is why we rolled out the "buddy" system described in this post. That way 90% of the iteration can be between the engineer writing the post and someone else who will be a lot more available than I am. This matters a lot if a post requires three or four round trips to really get it right. Plus, in a lot of cases, that other person is better at technical storytelling than I am to begin with.
I'd also note that this post and HN discussion focus a lot on reducing friction, as if having a really good blog is the state of nature. In my experience, this has not been true. A good blog won't just happen if you get out of the way.
Someone senior at the company needs to actively prioritize the engineering blog. You also need eng leadership that respects that writing posts is real work and is willing to have engineers spend time on-the-job working on them. At Heap, we do this down to the level of taking this into account in sprint planning. Also, a lot of the good ideas for posts come from working with engineers to find the kernel of a story in something they're working on. This is an active process, not something spontaneous that you just have to permit to happen.
We also benefit from having a lot of legitimately interesting technical work to talk about. This is more true at some companies than others, and is a big multiplier on how compelling you can make your blog. The success of a blog post is pretty non-linear – either it gets wide readership or not much at all. Having something interesting to talk about is pretty important, and is hard to manufacture.
[+] [-] craigkerstiens|6 years ago|reply
And echo everything your said. In terms of getting something out the door as soon as you do that you've diminished the impact of the post. It's similar to quality engineering you ship it when it is ready, not because you said it'd take a week and you spent a week on it. Most engineers hate artificial marketing deadlines, being able to work on a post to get it into a good state can be equally as unclear in terms of timing as engineering.
I've found that a dedicated mentoring process, similar to your buddy system can work well. As you're growing the people that are able to review/drive content having them follow along as I review posts and provide feedback helps for them to internalize some of the steps. In my experience after shadowing for about 5 posts they're able to start guide someone else with still some need for support and final reviews.
A final note, as someone that has written a lot of content I can crank out a post in anywhere from a day to an hour. For someone that has an interest in a topic you shouldn't expect the same output (time wise) as someone that does this more frequently, a quality blog post for someone not used to the process can spend multiple days up to a week in total on it. This comes down over time and with practice, so you shouldn't assume it's always that high, but it does take repetition.
Finally, everyone has interesting technical things to talk about. Anytime an internal email is sent to engineering@ about some interesting tip, how some problem was solved, or a guide to how to accomplish something it's a great candidate for a post.
[+] [-] swyx|6 years ago|reply
true, but if you get in the way, you have a lifeless/corporate-feeling blog, which is (subjectively) worse.
as someone who has worked in the blogging trenches, i can say that overzealous/overconservative processes can really stifle blogging flow and the primary alternative you're competing against is the engineer writing for their personal blog, which they know has long term career value as well. usually not all participants in the review chain are equally bought in to growing the blog and you eventually get your best writers self selecting out if you aren't careful
i do like the buddy system you propose, that seems like a nice solve!
what are your thoughts on having dedicated content writers - like technical writers or developer advocates - working on/owning the blog, vs "all engineers are explicitly encouraged to blog"?
[+] [-] gowld|6 years ago|reply
You have 200 employees and only one person you trust to publish communications to the public? Why not put a little trust in your teammates?
[+] [-] pulkitsh1234|6 years ago|reply
Even if there are no direct instructions to follow the design principles/themes of the company, it kind of makes sense that there are some underlying design principles that all the tech blogs are adhering to (in terms of videos, animations, illustrations, code snippets).
I know about tools like [1] but they are fairly basic (afaik) in terms of visuals.
For instance, look at the amount of work in creating illustrations for [2], it seems they had someone assigned from the design team to help with these. Another example is in the blog post [3] linked in the original post.
[1]: https://www.websequencediagrams.com/, https://mermaid-js.github.io/mermaid/#/ [2]: https://www.toptal.com/ruby-on-rails/decoupling-rails-compon... [3]: https://blog.cloudflare.com/content/images/2019/06/leak2-2.p...
[+] [-] jgrahamc|6 years ago|reply
Could of years ago I wrote a blog post explaining Spectre and Meltdown (aimed at the relative layperson): https://blog.cloudflare.com/meltdown-spectre-non-technical/ She did the illustrations based on a really vague explanation by me of what was needed. I think they really made the piece.
More recently, she helped me with state machine images in this piece: https://blog.cloudflare.com/details-of-the-cloudflare-outage... Here she did them in the style of an old CS paper.
[+] [-] craigkerstiens|6 years ago|reply
Yes, there are places that have designers and they're a great resource, but don't let that be a blocker. If a company has a designer that can be dedicated and support such awesome. If not just try something and see what works, then keep using it.
Edit: An example of very crude/napkin style drawing - http://www.craigkerstiens.com/2011/11/07/how-heroku-works-ma...
[+] [-] samsolomon|6 years ago|reply
https://harvardlawreview.org/
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] austincheney|6 years ago|reply
If you are writing a blog where corporate branding is associated then commandeer a graphic designer from your employer. They are going to be more in tune with the company’s legally approved branding guide and likely to produce better quality visual products in less time.
[+] [-] j1elo|6 years ago|reply
[+] [-] thundergolfer|6 years ago|reply
Besides picking the next company, great blog posts can be a real help in sanity checking the work that's happening in our team. I've noticed even senior engineers treating good blog posts from big companies as "See, we're not crazy".
Right now I'm operating in the data science platform space at my company, and have been reading a lot more company blogs than usual. Wayfair is a company I now know of after an engineer I really respect shared on Twitter "Bayesian Product Ranking at Wayfair"[1].
Lyft, on the other hand, disappointed me with "How Lyft Designs the Machine Learning Software Engineering Interview"[2]. That post sounds like it could have been victim to what Dan notes as:
> Approval/editing process mainly de-risks posts, removes references to specifics, makes posts vaguer and less interesting to engineers
1. https://tech.wayfair.com/data-science/2020/01/bayesian-produ...
2. https://eng.lyft.com/how-lyft-designs-the-machine-learning-s...
[+] [-] stuxnet79|6 years ago|reply
I would read through their engineering blogs with a critical eye.
[+] [-] bndw|6 years ago|reply
Lyft has put out some fantastic blog posts around their work on Envoy. Check out the posts by Matt Klein: https://medium.com/@mattklein123
[+] [-] ryan_lane|6 years ago|reply
We aim our posts towards a number of audiences. Our posts related to our interview process are to let candidates know what to expect when they're coming in for specific interview types. We actually get very high traffic to those posts, and we've gotten strongly positive feedback from candidates about those posts, so we've written them for a number of positions.
We also have posts oriented towards working with non-engineering teams, mentoring, engineering processes (like writing tech specs), and other things that aren't only technical deep-dives, because we believe in diversity of content.
[+] [-] VonGuard|6 years ago|reply
[+] [-] alxlaz|6 years ago|reply
In a former life, back when printed magazines were still a thing, I used to do some (pretty bad) tech journalism, so every time $crt_employer wanted to run, or expand their blog, I ended up going to meetings (I now do that professionally as well, actually -- it helps keep those programming-related brain cells sane). The vast majority of posts (and blogs) that I've seen were awful not because of a tortuous approval process or lack of high-level support. They were awful because communicating substantial, serious engineering information was not the main point. Or one of the main points. Or a point at all, really. It was usually just an excuse to push out some marketing and "establish a presence", and management felt that involving technical people writing on technical subject would lend that effort the kind of credibility that ads don't have.
This had repercussions over the whole publishing chain, and these efforts were doomed from the beginning. Topic selection was inadequate (topics were selected primarily so that they'd have the right "ring" to product/marketing/business development managers, rather than so that they'd be interesting for a technical audience). Editing was done with the wrong objectives and targeted the wrong metrics, and was often based solely on input from non-technical people who didn't understand what a technical audience wanted. Then this article -- on a topic that wasn't really interesting for a technical audience, and not really written for a technical audience -- was promoted mostly for a technical audience. Since the people who were doing the promotion were, inherently, in non-technical position, and they mostly consisted of a boring tech article with a mini sales pitch attached at the end, everyone ended up seeing them as marketing fluff.
It doesn't help that our industry is still stuck in this world where "technical" and "non-technical" is a very strict dichotomy, where technical people are basically like a 2020 Mr. Spock and non-technical people can barely type on a computer. That hasn't been then case in more than ten years. A lot of people who are seen as "non-technical" -- people in sales, marketing, or in management positions -- have grown up with computers. Lots of people in decision-making positions used to hold a technical position at one point. The kind of depth that a non-technical, but not tech-illiterate audience appreciates can be very surprising.
[+] [-] andrewzah|6 years ago|reply
This doesn't mean anything. Have you watched some 15-22 year olds interact with computers lately? (I'm 23, for reference). They don't hunt and peck on the keyboard in stereotypical fashion but they're just as clueless for anything besides basic interactions. They -are- essentially tech illiterate once they step outside of google sheets, etc, or the web browser in general.
I'm tired of hearing people say "digital native" like it means anything with regards to tech literacy. We're going to have another generation come in and take power that has zero idea of how computers function. At least we understood this and factored this in about the last generation- now we just assume the new generation knows things because they grew up using apps.
If anything, the new generation is more illiterate on average, but with better mechanical facilities and understanding of typical modern UX for apps.
[+] [-] rkangel|6 years ago|reply
If you leave it to the marketing people you'll get buzzword fluff that provides no value or interest to anyone.
If you leave it to the engineers to write about interesting things, and get the approval process out of the way then you might put up something of interest to engineers.
[+] [-] Goladus|6 years ago|reply
It can still feel that way, though, especially if you have any intersection of cutting-edge software or hardcore engineering with corporate bureaucracy. It's really a question of roles-in-context not holistic identity. If you have corporate managers and project people spending a lot of time in meetings talking about the "ABC initiative" to each other without a single one of them even having taken the time to walk through a basic "Hello World" tutorial for the ABC itself, you are dealing with "non-technical" people.
[+] [-] CM30|6 years ago|reply
For a successful corporate blog (engineering or otherwise), writing blog articles needs to be a foundational part of the company culture, the different teams must work together to create the best/most useful content possible, and there must be a schedule beyond 'whenever we feel like it'.
[+] [-] heligate229|6 years ago|reply
[+] [-] rv-de|6 years ago|reply
[+] [-] sciyoshi|6 years ago|reply
For a small team/company, what are some good tips or resources on how to start an engineering blog? We've worked on many interesting challenges and I know the team would have a lot of insights to share, but it can be difficult to find and justify the time that writing a good article takes, and it's not something that everyone is necessarily interested in doing either.
I'm curious about the mention of Cloudflare's culture of "internal blogging". That seems to me like it could be a first step in that direction.
[+] [-] jgrahamc|6 years ago|reply
[+] [-] bbrazil|6 years ago|reply
[+] [-] detaro|6 years ago|reply
[+] [-] brian_cunnie|6 years ago|reply
Our current set-up is simple: clone a repo, create a blog post (in Markdown) from a template, and when you're ready to publish, commit & push to the master branch. We put a lot of effort into making the process simple for engineers.
However, before that process was put in place, it was much more burdensome. I remember in 2014 I had written a blog post and it needed to go through Marketing: Branding was important, and formatting was a challenge. Also, I encountered feedback unrelated to engineering content: "You need a call to action," said the person in charge. I was baffled: "If they've found my post, it's because they're trying to fix a particular problem--they've already had their call to action." The process was discouraging, and I didn't write a blog post for a long time afterwards.
[0] http://engineering.pivotal.io/
[+] [-] Havoc|6 years ago|reply
There is a non-trivial overlap between "look at this cutting edge cool stuff we're doing" and the company's strategic edge over competitors.
These types of posts get dissected by the competition & a small slip up can give away a lot of clues.
[+] [-] hyperman1|6 years ago|reply
You can share your knowledge, which quickly turns you in a gathering point for interesting knowledge. This makes interesting stuff, good employees and new customers come to you begging for attention, which is a much bigger strategic edge.
See for example the story of Tom Wilson's videocard at Mike Abrash's https://www.phatcode.net/res/224/files/html/ch64/64-01.html - a minimal hint which turned out to be wrong was enough inspiration for a better product.
On the other hand, imagine Dan Luu's example company that takes a year to approve a blog post. If your culture is that bad, even discussing if accepting a mountain of money laying on the street no strings attached is acceptable will take a few months. Show them your edge, and assuming they see it as actually valuable instead of extra work, it will still take a year of bureacratics before they start implementing it.
See also Rudyard Kipling:
They copied all they could follow but they couldn't copy my mind so I left them sweating and stealing a year and a half behind.
[+] [-] jgrahamc|6 years ago|reply
I don't really agree. I think the more you write about what you are doing the more you attract really good people and that's the strategic edge on competitors.
[+] [-] thedance|6 years ago|reply
Personally, the only "technical blog" I want to see from a company is papers accepted by OSDI, ISCA, VDLB, etc.
[+] [-] giancarlostoro|6 years ago|reply
[+] [-] mooreds|6 years ago|reply
[+] [-] qznc|6 years ago|reply
[+] [-] papito|6 years ago|reply
Almost inevitably you will get comments about how your approach is bad or simply invalid.
[+] [-] nickdothutton|6 years ago|reply
[+] [-] franciscop|6 years ago|reply
I feel the same way about open source in my case. I already have, say, 6+ repos with quite a few stars, high quality and lots of installs. I keep doing OSS because I like publishing the tools I make and other people using them, but it's definitely past the point where there is a ROI with hiring.
Recently I got `react-test` and I'm building it, but I decided to ask for help from beginner programmers. I think it can get to a very nice place within the OSS community, and I don't mind sharing the credit with other contributors. We even published a bunch of detailed issues asking for help but I haven't found many people who are interested yet: https://dev.to/fpresencia/contributing-to-js-react-open-sour...
[+] [-] Funes-|6 years ago|reply
[+] [-] a1pulley|6 years ago|reply
[+] [-] reboog711|6 years ago|reply
[+] [-] NPMaxwell|6 years ago|reply
[+] [-] ksahin|6 years ago|reply
It's not just about the content, but the typography, the style, illustrations... I don't know why but I'm more and more sensitive with the general reading experience.
[+] [-] pR0Ps|6 years ago|reply
Question for you since you presumably read their blog: Do you follow a bunch of blogs/news sources? If so, how do you do it without using feeds?
[1]: https://segment.com/blog/atom.xml
[2]: https://emojipedia.org/police-car-light/
[+] [-] mooreds|6 years ago|reply
Didn't go anywhere, but it seems that engineering blogs are an unoptimized recruiting channel. If anyone here wants to chat more about this idea, my email is in my profile.
[+] [-] whatshisface|6 years ago|reply
One way around this would be to have 14 stakeholders arranged so that any individual can approve the post. That would do as much to speed it up as a 14-person unanimous/veto system would do to slow it down.
[+] [-] kevinmannix|6 years ago|reply
We're a small technical team so I'm not sure how well this scales, but it's worked out well for us so far.
[+] [-] throwaway13000|6 years ago|reply
[+] [-] MisterTea|6 years ago|reply
You can also think of it as marketing for engineer types who are usually immune to formal forms of marketing. Managers don't care about details, they want to see $ numbers. Engineer types want gory details. So your engineering blog can help market your products to engineers. Just look at intels documentation pages vs their actual intel.com site. intel.com is marketing 101 eyesore.
An example would be a blog from a semiconductor company making analog circuits. Think Bob Pease types. They'll talk about a specific problem or circuit, go into the bloody details, math, schematics, charts, graphs, etc. Then toss you a product from their portfolio that can solve the problem.
[+] [-] zffr|6 years ago|reply