On a personal level I can absolutely empathize, but respectfully, I don't see why that should be the state's concern. The goal of IP law should be to promote the creation of good art, not to make sure artists' wishes are respected.
So, for example, theft should be illegal, because a world of unrestricted IP theft might be one in which we would get a lot less art. But allowing Tolkien to block adaptations of his bestseller 14 years after publication was probably not good for art.
Do bad adaptations prevent good adaptations? Lynch's Dune flopped but Villeneuve had a $165m budget.
We can't know the contrapositive but I don't see why giving the author a veto makes good outcomes more likely, especially decades after a book is published.
> 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"?
> 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"?
I like this, and I think a good developer relations person who is prolific, sufficiently technical, and can get the tone right can be very valuable for building up a company's visibility. It's a good way to take 80% of the work of writing a post off the relevant engineer's plate and also produce great posts, because the person writing them is a professional writer.
We're small enough right now that we can do well enough with some ad hoc stuff, e.g. periodic slack posts to shake the tree. But this is something we discuss every now and then and the timing will be right at some point, as we scale.
It's easier to justify the cost of a full-time employee if your buyers are also primarily engineers. For someone like Stripe or Twilio, an active eng blog doubles as marketing.
To be clear we're talking about the state of the world around two years ago. I'm not a bottleneck for this anymore. :)
Also, this is a bit of an uncharitable read. The calculus at the time wasn't about trust per se, and more about the fact that the relationship between quality of blog content and the content's reach is nonlinear. That means it's worth taking the time to get it right, even if the people best suited to make that happen aren't super available, because the difference between getting on the front page of HN vs not is multiple orders of magnitude. (But I think we get the best of both worlds now.)
Under this scheme, the only way to make more money as a law firm would be to increase your costs, so this creates an incentive to prosecute the case as expensively as possible.
The eventual endgame of this system would be that law firms’ costs should rise to eat as much of the settlement as possible, which leaves as little as possible for the actual victims.
A fixed percentage system creates an incentive to maximize the settlement (on behalf of the victims) and leaves the law firm to pay its own costs.
Great article. I had been hunting down a similar issue in Java 8 with maven dependencies. I was getting the same error, but confirmed that the dependent jars were correctly included on the classpath. I eventually gave up and decided to take a different programming approach that did not include these missing classes, but I think I will revisit it to see if a class loader is getting closed somehow.
Ooh, check it out and let me know what you find! It would make me really happy if this post helped someone debug something when they had previously hit a dead end.
I'm curious how do you guys operate the flink cluster, do you have a single huge shared flink cluster where people can submit any kind of jobs for various applications/streams.
Or do you have multiple smaller flink clusters for specific use cases?
Are they on Mesos/YARN/k8s, or just plain vms/baremetals?
We're running a single flink cluster. Engineers can run whatever jobs they need, but we aren't writing new flink jobs that often so the load is pretty predictable. We have a single digit number of jobs at the moment.
We are on 1.3.2 at the moment, running on EC2 vms.
Iirc Ivan (post author) spent a few days tracking this down. There were some other debugging dead ends that we omitted in this writeup. One red herring was that the issue appeared to happen during the US morning, so there was some time-of-day component, and we thought it might be a system load issue.
The fix turned out to be fairly involved too – on the order of a week I think.
Ivan works from Bulgaria so sadly he is asleep right now.
Isn't that a bit odd, your stack trace there in the article?
Usually the stack trace when a NoClassDefFoundError is thrown contains a "Cause" clearly showing the name of the class loader that was supposed to know about the class in question, and which then rather obviously failed to load it. If it actually isn't in the real trace, the exception/error logging is probably a bit wonky.
I have seen logging procedures that don't traverse/print the entire traceback chain, but only prints the message and the immediate stack. But this is unfortunately a rather terrible idea. Quite often it will exclude the actual cause from the printed trace while simulataneously retaining the error message, not rarely leading to liberal amounts of confusion. The pattern with exceptions being thrown with a cause is not uncommon in the JDK, so making sure to log causes are important.
In general, although it's probably obvious, I would like to mention that having code loaded by class loaders with different lifetimes interact is rife with "interesting" issues. Wherever possible I would recommend serializing messages over any boundaries where class loaders have different lifetimes, as it both prevents all of the strangest causes of errors, and can also lead to a cleaner design. An exception would be if prohibitively expensive from a performance perspective, of course.
> Chai-1 achieves a ligand RMSD success rate of 77%, which is comparable to the 76% achieved by AlphaFold3
[0] https://chaiassets.com/chai-1/paper/technical_report_v1.pdf