Hacker News Reader

Comment by minimaxir | Hacker News Reader

This post is a good example of my current issues with modern data journalism as content marketing: you can say anything you want without evidence to back it up, but hey, there's a pretty chart, so it doesn't matter. (In this blog post, the data points don't correspond to actual data!)

This is also the primary reason I have switched to Jupyter/R Notebooks for my blog posts: if I make ridiculous claims, people can check my work as evidence. This post doesn't even provide any quantifiable metrics, just "we analyzed millions of commits."

View on HN

I just got done staring at some code written by a prolific upper quadrant coder, that I'm going to have to noodle on and figure out how to disentangle some bad design decisions. I might be able to do a fairly short commit to refactor and extend, in which case my metrics will be crap. I might wind up looking at all the outstanding issues with this codebase and rewrite every class in this directory (in which case my LoC metrics will improve dramatically). Right now I'm probably one of those "stuck" coders that need "help". Kinda? But most software developers hit problems like this and run away in terror, and looking around me IDK who can really help me that much, I'll run my ideas by some colleagues, but the other ones who work on problems this gnarly are also neck deep in their own issues...

Sounds like "Discovery" quadrant more than "Prolific" to me.

Mikado Method might offer you some clues, or at least confirm some of your existing habits.

Basically, start a top-down refactor. When you find the bottom you stop, revert your code, and refactor from the bottom up.

You probably won't find the actual bottom, but in my experience the moment when I was about to give up and call it quits was usually just before I reached the bottom. Taking a break, and starting over from the spot where I stopped, usually the solution became obvious, and far less invasive than I expected.

Do I understand this correctly:

You start refactoring at a high level -- essentially set out to rewrite the whole chunk of code in which your refactoring work lies. And focus on the most important until you get to the inner-most structure.

Then when you are to the "sum(a,b)" level you start over with the original code base and refactor bottom up. With the knowledge of how it works all the way up to the top? Re-creating your original refactorings?

It seems interesting. Like tackling a math problem or puzzle from two directions. Are there certain situations in which it is most effective? Architectures? Paradigms?

Most refactoring is from the bottom up. Make the change easy, then make the easy change. I said "start a top down refactor" but redesigning from the top or all at once isn't really refactoring. Some of the actions look similar but you get few of the benefits of refactoring.

When the architecture problem has gotten away from you, or only becomes apparent late in the project, it's hard to see the trees for the forest. The only way to decompose the problem is to start somewhere and see what happens. With a top down rewrite the number of bits in flux becomes overwhelming, which is the anxiety I picked up from the previous commenter.

Mikado is just an exploratory development trick to help you find a way to make the change with refactoring. You try rewriting pieces until the number of concerns starts to multiply, you keep going essentially until your brain starts telling you, "this is nuts, you should stop", and you take that detail that broke the camel's back and do just that part, and build up and out from there.

> you can say anything you want without evidence to back it up

Actually, you can say anything you want with evidence to back up the opposite of it ;)

I have a hate-love relationship with journalists. It's both incredibly surprising and incredibly frustrating to discover what they end up publishing after an interview.

http://www.smbc-comics.com/?id=1623

That is one of the reasons companies train people speaking to the press. Having a message and being articulate is often not enough.

The thing is, it doesn't matter what you say. They'll just write anything they want ^^

They could retitle this "In Defense of Cowboy Coding". Engineers that code this way become the owners of their codebase because nobody else wants to deal with their insane decisions.

Forget cowboy coding, this is cowboy data analysis. At best, it's misleading; at worst, it's dangerous.

This is embarrassing from a YC co.

They sell metrics, this blog post has us talking. This is a blog post, a PR piece, not a news paper story.

Source metrics are the new panopticon of Software is Eating the World.

Is this even journalism?

> Is this even journalism?

I wondered this also, when the popups in the lower right kept presenting a chat box with "Can we help you with something?"(from gitprime). Do they want to sell me something, or do they want me to read their publication?

Am I missing the sarcasm at some point in this thread, or something? It's very clear to me that this is not journalism, and shouldn't be read with the expectation that it conforms to journalistic standards, any more than some observation on distributed systems on a personal blog should be read with the expectation that it conforms to scientific standards.

It's a different type of content, which has a different kind of value. Are people trusting the claims the way they'd trust journalism from a known good media organization (or a paper from a known good research organization)?

If it looks like a duck and quacks like a duck, it should follow journalistic standards. The fact that it obviously isn't is irrelevant. If you're going to pretend to be a journalist, do it right or don't do it at all.

So, should I not post things about distributed systems to my blog without rigorous peer review, lest I get accused of pretending to be a scientist?

(I'm genuinely confused about how this person is pretending to be a journalist. It doesn't look like journalism at all to me, starting from the part where it's on some startup's blog. What am I missing?)

There's a difference, IMO, between a blog post from a person in their spare time and a blog post by a startup whose main purpose is to get people to sign up for it.

Less of a difference, IMO, than that between either of those blogs and a reputable journalistic outfit.

I wouldn't argue the journalism point, but it's very clear that the blog post is an attempt to (1) present solid statistics and (2) bolster their own credibility because "they have good statistics".

Except what we really have is a lack of data backing up the fancy non-informative charts (that clearly in no way shape or form correspond to the so-called millions of data points).

If you publish something, it's your responsibility to ensure what you write is true, to the extent reasonable within your skills and time available to you.

Doing less is harmful to your own reputation at best, but can be harmful to whoever believes in the things you got wrong.

Now that applies to mistakes. But for those who intentionally write and publish misinformation - I hope there's a special circle in hell waiting for them.

> skills and time available to you

Lots of plausible deniability, here.

It needs to be very clear from what and how you're presenting information the quality, source, and rigor of your data.

This blog post is pretending to be true.

I want to contrast it with this: another startup(ish) blog post about their own data

https://www.backblaze.com/blog/hard-drive-reliability-stats-...

That is a wonderful, useful, trustworthy source of interesting data.

The post source seems like made-up marketing fluff pretending to be real information. I'm looking at graphs I entirely believe were made up, I have nothing to support the conclusions, and I'm very concerned that a less wary reader would think it's true.

I wasn't being sarcastic, I was questioning the labeling of the use of charts and numbers as data journalism (This post is a good example of my current issues with modern data journalism as content marketing) in the comment I replied to.

If it had said something like tools of data journalism I wouldn't have been inclined to reply. A small difference, but enough for me.

When a page starts popping up unsolicited chat boxes, the only conclusion I tend to reach is that they want me to go away. I'm happy to oblige.

Would love to better expose our data set. It’s a bit tricky however: we’re specifically interested in enterprise software engineering (the patterns of which differ radically from the open source world).

In order to dig into enterprise data, we sort of need to have a ToS that only allows us to talking abstractly about aggregate data.

Any thoughts on how we might navigate that?

You don't have to expose the raw dataset explicitly, but you do need to describe your methodology (moreso than an arbitrary "impact" score; give a formula) and give actual numbers for the analysis, and not just argue a "strong correlation" with a highly arbitrary matrix of attributes.

It's a marketing article - trying to explain their product to potential customers, not a scientific publication.

I'm not saying that you are necessarily wrong but I do wonder if making an article like this more like a formal publication will actually make it better or worse at it's real goal which is presumably to sell more.

Yes, the standards of an marketing article are nonacademic, but you can't make a article containing a data driven argument and skimp on both the data and the argument.

I don't know if it's respectable to doll up a marketing article like journalism, let alone scientific research.

There is no downside to a legitimate marketing article to make the underlying data and analysis available to those who want to drill down. If it is valid, you stand a chance of persuading the skeptics.

More importantly, calling something a marketing article does not immunize it from critical analysis, and especially not on a forum such as HN.

They go into slightly more detail on factors that influence the impact rating in a linked post. It still doesn't explain what formula or weightings they use. https://blog.gitprime.com/impact-a-better-way-to-measure-cod...

How do you publish them? I had always heard that publishing notebooks was a pain in the ass.

GitHub can render Jupyter Notebooks natively.

For R Notebooks (which are HTML files), you can use GitHub Pages, which is super easy to set up nowadays, as the static files can now be located in the master branch.

Github pages can also work with exported org pages rather easily. (For an example, here is one of my blog posts: http://taeric.github.io/Sudoku.html)

It's also easy to convert R notebooks to PDF, which are easily viewable on GitHub, if you don't value the interactivity highly.

That's misleading though — GitHub can render pre-run Jupyter notebooks but does not allow you to actually run them. IMO that's only half the battle.

When would you want Jupyter notebooks that you'd want to run, rather than just pre-render?

You need a host that serves Jupyter notebooks to actually run them vs render a pre-run notebook, which is what GitHub, Gist, etc do.

A few hosts that currently support that are PythonAnywhere and as of this month, Azure [1].

[1]: https://notebooks.azure.com

They talk about 'small bites', but if their first chart means anything, its linearity shows that commits tend to be of the same size. As to whether those commits represent progress or repeated attempts to get it right, we have no idea.

As for their size measure, they are vague, but the comment about 'normal' commits raises the question of whether they have crafted a metric for which the linearity is built-in by definition.

Reply on news.ycombinator.com