Hacker News Reader

Comment by yodon | Hacker News Reader

If you're leaning towards stripping all your writing down to list form, you may want to read Tufte's analysis on the role PowerPoint (aka writing everything in the form of bulleted lists) played in the Space Shuttle Challenger disaster [0]. I used to write exclusively in bulleted list/outline format until spending time with Tufte's analysis. Now I get that the connective tissue of the document is vitally important to the reader even if it's not important to the writer. If you don't put in the connective tissue, your reader has to do it for you and they'll probably do it incorrectly (leading to, for example, the failure to prevent the Challenger disaster).

[0]https://www.inf.ed.ac.uk/teaching/courses/pi/2016_2017/phil/...

View on HN

There is one important difference between written lists and PowerPoint presented lists. IIRC Tufte emphasises this difference too.

A written list can be read in any order. You can go back and re-read previous items, and then go into the future and see what the conclusions from the current items are, and so on. This free-form temporal flow of any writing (including lists) is a very powerful tool of reasoning. Arguably, this property of writing is what leads to an intellectual explosion once a people learns how to write.

In a PowerPoint presentation, the temporal order is fixed. And humans have a tendency to infer causality based on order. So with a PowerPoint presentation, you can (more easily) convince someone of invalid conclusions of logic because you control the post hoc ergo propter hoc.

So, I guess, all of this to say: writing lists good. PowerPointing lists bad.

Hmm. Tufte does note that one of PPs specific ailments is the linear nature of the presentation, but he also goes directly for bulleted lists. He pretty clearly takes down deeply indented bulleted lists as the internal structure of "The Software Bureaucracy" leaking out through the software.

I think the salient argument is his argument that the CONTENT should drive the presentation style. Lists are good for some stuff, but not everything.

Order matters, and will create bias or cognitive prioritization, regardless of whether something is a bullet point.

Take the famous Napoleanic map - top left Carrie’s similar weight as the first bullet item. It may not be linear (1d) since it’s 2D, but the same problems exist: the first items we are exposed to will create a stronger reaction due to an artifact of arrangement rather than importance.

A bulleted list, particularly in a slide presentation, is all headings, no content.

Sometimes the presenter talks about each item, giving meaningful detail while the structure is there on the screen. But it means that someone reading the slides alone misses the detail. Someone not listening carefully misses it too.

In written work, the headings are just headings. The paragraphs under the headings are the content. You can write transitions, too.

While this is a valid concern, I think its importance is over stated.

Much like some people tune out the speaker and just read the bullet points, I have known people who read just the headings or just the first sentence of paragraphs and then take action based on what they perceived of the document.

There is an argument still, of course, that the PowerPoint situation is worse because (if presented badly) the reading competes with the listening. I would still be hesitant to judge a medium based on bad execution, no matter how widespread. I'm willing to admit that might be unpragmatic of me.

In journalism there is the concept of the inverted pyramid. An article's structure should be in order of importance. This way readers can assess the incremental gains of persisting with the article against their interest in the subject.

Arguably that (and I think it might be Columbia you're thinking of) represents a misuse of lists though, because in my mind all the things on a list are supposed to be of roughly the same importance or size or magnitude. I would say that's part of the "contract," as this author puts it, that a list represents. (Although he doesn't mention that specifically.) On the PowerPoint slide in question, there are a bunch of good-news points and then the bad news is at the bottom in a smaller font. It's either incompetent or deliberately deceptive to set it up that way, and actually come to think of it, under those circumstances I kind of doubt the incompetent or deceptive author would've done a good job with paragraphs either.

Anyway here's where this battle is really raging right now: on my resume. For years I've been distilling things down to action-oriented bullet points with dots, because I heard the Deputy likes dots.[0] Then I got an eyeful of someone else's resume that instead had articulate paragraphs intended to be read by, you know, a calm human being with some dignity and self-respect, and immediately felt like that was way better. But I dunno.....

[0] https://www.youtube.com/watch?v=YUYuGNpOk5U

The typical screener in the hiring process spends 8 seconds or less making a decision to discard or advance a resume to the next stage.

In the GP comment I advocated reading Tufte's critique of bulleted lists, but resumes are definitely a place where they significantly increase the odds the initial screeners can spot the things they want to see to advance your resume. A well structured list written using parallel construction (similar grammatical structure from one bullet to the next) is far far faster for a reader to parse. Once you've been told they want to interview you, you're generally free to submit an "updated" resume if you want to, which can be in prose format if you think that's best (but again not all interviewers will look at your resume more than a few seconds before they jump into the zoom session with you).

> The typical screener in the hiring process spends 8 seconds or less making a decision to discard or advance a resume to the next stage.

I’ve been involved in hiring several people and this has never been the case. So I’m curious as to where you got those 8 seconds.

Hell, it usually takes the damn HR onboarding systems more than 8 seconds to load each page.

I’m curious about how you do it. Could you share your process?

(I’m currently looking, so knowing about concrete examples might help me)

I’m Danish so that may have an impact, but basically every company I’ve been with has had some sort of HR onboarding system where applicants submit their cv and letter of application to.

A typical process is that you or your manager sets down a group to hire. This group fills out a HR form of what sort of responsibilities, challenges and opportunities the applicant will meet as well as the requirements and wanted level of experience. Then HR puts up the position in various places and people apply online.

Once the period closes (sometimes while it’s running) the hiring group logs in and rates all applicants 1-5/7/10 (depending on the system) and then the system automatically moves the best x to the final group.

How people handle the first step variates and this is probably where the person I was replying to got the 8 seconds. But around here, people read the letter and look over the CV and often spend the most time on this step because it’s where you “grade” everyone.

The next step is group discussion about the top x where the people we want to talk to are selected. Then come the interviews and possible HR personality tests like DISC profiling and the occasional technical interview/test if there is doubt as to the applicants ability.

Here in Denmark the most important part of getting an interview is the letter you write. If it’s generic people will grade you lower. Your CV is sort of important, but only in the sense that “I know this skill, and these people recommend me” - LinkedIn style. In fact, people with good LinkedIn profiles might as well be submitting those as their CV as far as I am concerned (but still make a pretty one yourself because not everyone agrees with me).

Unless you’ve done some extraordinary work that actually sees real world use, nobody is going to look at your GitHub. Even if you have, write about it and how it makes you a good applicant instead of linking to it, because 99% or the time nobody is going to look at your stuff. This isn’t because hiring groups aren’t interested, it’s because it takes a lot of time and the process is already resource demanding.

Once people get to the interview, here in Denmark, it’s 95% about finding the person you think will fit into your team the best. Sometimes people will fall through because they’ve “hacked” their way and aren’t as capable technically as we thought, but that’s not often.

There are no rights and wrongs here, but I personally like applicants who seem to be “grading” us. As though they’re figuring out whether or not the job we’re selling is something, they, will want. Even if it’s a junior straight out of an education I like this, even when everyone knows they will kill for the opportunity it’s good to see people actually be curious.

It’s obviously a situation where the power dimension is insanely tipped to one side, but it’s important to remember that good teams are shopping as much as you are. We want the right match, because the most expensive mistake any manager or hiring group (at our level) will ever make is hiring the wrong person.

So be honest, be yourself and hope you’re seen as a good fit. And train your interviewing skills by applying for jobs that aren’t “as” important to you so that you’re not a completely nervous wreck when you apply to that one dream job. (This isn’t advice for new people), I recommend everyone doing a few interviews every 2-3 years.

I've read that number many places and more importantly heard it from many folks who do front line resume screening. If you've ever had a stack of 50 new resumes hitting your inbox every day and the task of finding the 3-5 people people to interview for the role among the hundreds that are submitted, you'll realize what a radically different experience that is from being one of the folks tasked with interviewing the 3-5 who made it through that sieve (and yes the HR software for reading through large numbers of resumes is surprisingly horrible)

I've been in the unfortunate situation of sifting through those resumes before. That 10 second look isn't for me to determine whether or not you're in the interview category, it's literally "person has applied for programming job, have they degree/experience/projects" or do they just want a job and have no relevant experience.

Terrifyingly when I was doing this that filtered out about 75% of the candidates (applying for senior/lead roles with only office admin experience was _really_ common). Once you get past that point you're probably going to get 5 minutes to see what's what.

So if I'm reading your resume, I am personally trying to get a quick scan of you as a person before I meet you. Do you have an education? Or are you self-taught? Neither one is bad. Do you have an education in a completely different field, and is it interesting to me, could we bond over it? How long have you been in the industry for, was it at one place or a bunch of places, was that place dedicated to tech or was it a small tech team adjoined to a larger company doing other stuff. If I am diving into those it is because I want to know more about the level of responsibility you took on at that job. I wouldn't put it into bullet points because it shouldn't be long enough that you need bullet points, I need to know were you leading the team, mentoring others (more dev experience vs more leadership qualities--neither is bad), or were you a solid engineer, or were you transitioning from say security work to development. Just give me one or two sentences about who you were at that job.

Basically, reading is much faster than listening, so I would like to not waste your time in the interview getting to know things that you already told me through a faster, asynchronous medium.

BUT. But. A bunch of places that I have worked at also have a process by which a non-technical person pre-processes your resume before handing it to me. They are looking to see whether you have checked the boxes. IDK what boxes, it depends on what those folks are taking out of the posting. It probably helps if you have a section of buzzwords so that they can say “they say they have React experience, I can check the React box!” For me most of those criteria are fungible, but you have to put something for the HR folks to screen out half the applications.

Now, the interview is where it gets a bit trickier. I used to have a great approach to this, when I worked at smaller companies and had more say in the hiring process. That was just, “your resume is a claim that you are a certain sort of person, my interview just tests whether you are who you say you are, are you faking it or are you selling yourself short?” In other words if you say you managed your coworkers I want to devote 15 minutes to see what sort of manager you are, even for a non-management role.

But, now I work at a Big Tech company and I don't really have that freedom... Now when I am interviewing you, I have usually been asked to either assess culture fit or technical chops... If technical chops, I am usually not tailoring my questions too closely to your resume, but to the forms that I have to fill out after the interview. The actual programming exercise will usually be amorphous, the actual work will be simple but the scope will be unbounded relative to the interview length—and so I am not expecting you to complete it so much as to parcel it up into smaller workable chunks and execute on one or two of those. Based on how you do this I can usually give decent feedback on my forms without feeling like I have fed you a trick question.

Belated thanks for the thoughtful reply. I do have a "skills" section that was designed specifically to satisfy the box-checkers. So maybe that means I can get away with replacing bullets with paragraphs in the experience part? And yeah when I say paragraphs I'm not talking long ones, just 1-2 sentences that sum up the experience skillfully. I think "ability to write a sentence" is another thing that can set you apart as a candidate (sadly), so I'm still definitely considering this kind of rewrite. Cheers!

The thing is, this article doesn't really advocate for stripping everything down to bullet points.

All of the examples are clearly written in paragraph form, but there are nice, big section headers that would clearly delineate the subtopics within the example.

In other words, the title is misleading. A more accurate title might be: "I learned to stop worrying and give all my essays clear sub-headings".

What does worrying have to do with writing structures?

To further improve the title: "The advantages of list structure on most writings".

However, if you are a person struggling to get into a habit of writing, it is okay if you do not yet have aerospace-grade writing. You can stop worrying and structure all your writing as lists.

You don't need to weigh yourself down with the responsibility to prevent a catastrophic misunderstanding among rocket scientists.

That it caused a catastrophe and the participants were rocket scientists doesn't mean the problem was anything more than poor communication. The information on the slide in question wasn't hard to understand; it was arranged in a way that distorted its meaning.

I agree that this is likely not appropriate to a context where you've got lives and millions of dollars on the line. That's not my point. My points are that:

1. The audience for the article is not program managers at NASA but instead random people thinking about how to learn to write.

2. If someone is starting their learning journey then it is unhelpful to catastrophize the consequences of imperfect effort.

I'll also add to this. From my experience in the military, there were often times when the PowerPoint presentations fell victim to over-simplification as individuals omitted important details that were difficult to break down — instead leaning on the talking points that were easier to list.

My personal experience was as comms flows up a military org, the summarization process at every level is to mechanically convert each slide into a single bullet in the more senior deck. Everything became diluted, and there was no way for a key point to survive from the tactical level up to the flag level.

But that is inherent in cognition.

We see an incredibly detailed universe, and we simplify it into objects and personalities.

Then we make it more abstract and talk about personalities doing things to objects, and so on up the chain, until we get to “army 1 did this to army 2”.

And add a satellite to any on the ground architecture.

Found this account recently emphasizing how bonkers military PowerPoint slides can be

https://twitter.com/DefenseCharts

Thanks, I hate it

My dad was at the Skunk Works and then at Northrop Grumman. I’ve seen wicked PowerPoint slides that animate like a Pixar film. Poor guy was so engrained in the way that he used to send me screenshots via .ppt file (print screen, paste).

What an insighftul analysis. I haven't noticed how vague my writing was until I started writing my book. Editors had to constantly correct me on missing information in my sentences which I didn't notice beforehand even once. They were always right. The whole writing experience has been truly eye-opening for me about how teaching is an entirely different skill set than writing.

This is why it’s valuable to proof read your work. After you write it, come back the next day and see if you still like it or it makes sense.

Not just proof read it, but read every word out loud. You'll pick up mistakes, awkward sentence structure, poor word choices that you never would by reading it silently. Reading alound means you don't skim.

Yes for superficial structure, I might skip things reading silently. However I struggle to think about the meaning of what I read when I read aloud, different focuses maybe. So that's complimentary.

Precision and brevity are my guides for code comments after a careful ux analysis of comment encounters in code.

Anything that makes me pause while reading code or a comment is something I’ll strive in a timeboxed manner to simplify.

It’s not always possible, but my code doesn’t get a lot of style comments or comments about readability anymore so seems to be working.

The difference may be that you are not getting feedback on the quality of your teaching.

> you may want to read Tufte's analysis on the role PowerPoint (aka writing everything in the form of bulleted lists) played in the Space Shuttle Challenger disaster [0].

Nit: PowerPoint didn't even exist when Challenger exploded (o-ring failure), you must be referring to Columbia (heat-shield failure).

From the link:

> Richard Feynman had also experienced the bullet-outline format style of NASA in his service on the commission that investigated the first shuttle accident, the Challenger in 1986. Feynman wrote:

>> Then we learned about "bullets"—little black circles in front of phrases that were supposed to summarize things. There was one after another of these little goddamn bullets in our briefing books and on slides.

but Columbia is discussed in much more depth.

And to be clear, re lists/bullets, Tufte's complaint was about 4+ levels of nested bullets:

> At the same time, lower-level NASA engineers were writing about the possible danger to the Columbia in several hundred e-mails (with the Boeing reports in PP format sometimes attached). The text of 90% of these e-mails simply used paragraphs and sentences; 10% used bullet lists with 2 or 3 levels. That is, the engineers were able to reason about the issues without employing the multi-level hierarchical outlines of the original PP pitches.

So much of my career's low points have been due to this engineers unable to convey information to management for various reasons issue. When you add too many layers of managment it becomes a Sisyphean task almost. If anyone has any tips we all could probably use them.

Bad presentations are eternal

Harvard Graphics Forever

Ha - i used that, both v2 and v3 IIRC ;-) Nice to be reminded about that product ;-)

I think the connective tissue in such a list-article (I hesitate to use “listicle” because it sounds so trivial) is in the introduction and conclusion. The intro is the classic “tell them what you’re going to tell them,” the list itself is the “tell them,” and the conclusion is the “tell them what you told them.” And items within the list can refer to other items, still letting the reader start anywhere while potentially guiding the reader to earlier points and tying the overall piece together.

In the Challenger case, the bad information has been deliberately hidden within the structure. They could just as well have pulled it up in the structure.

It's like saying variable font sizes are inherently bad because due to them, contracts can have small print sections.

That's a good argument against one-sentence lists, but the author seems to be arguing in favor of numbered headlines (with paragraphs in between).

Literally every scientific paper has sections and subsections. Aka Lists.

The problem is not the existence of structure or lists. The problem is the presentation of complex material as hierarchical short bullet points.

You can see some of Tufte’s recommendations for formatting lists here https://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=...

I don't understand what's being explained. Should people use lists alongside paragraphs?

Tufte's article probably answers your question better than a once sentence answer here can.

Has. Not "is entirely".

If you're a NASA manager and send people to their death because you can't be assed to properly read all the words on the screen, you should be tried for murder. There's no way the management was unaware, they just wanted to save money and hope for the best and not lose face, same as last disaster.

Reply on news.ycombinator.com