Building a Text Editor for a Digital-First Newsroom | Hacker News Reader

Building a Text Editor for a Digital-First Newsroom

open.nytimes.com

486 pointsaaronbrethorst168 comments

One of the most truly fascinating things I learned from my father was how early 1980s word processors were designed for the magazine he worked for. The different ways to handle fonts, screen placement, and how to include data from a local database.

It was truly an awakening to the hidden wonders of the world.

RE the flat paragraph structure - did they just reimplement Emacs in the browser?

https://www.gnu.org/software/emacs/manual/html_node/elisp/Te...

(Also I think - from occasional messing with XML in .docx files - but can't be sure that Word flattens styling like that as well.)

Any sufficiently complicated editor contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of emacs?

I prefer vim though..

Vim ain't sufficiently complicated (that can arguably be seen as a good thing). That's why it's been mostly reimplemented in Emacs.

Vim has vimscript (ugh) with a lua and python gaining popularity so emacs sort of got it right IMO anyways.

Neovim's main goal seems to be replacing vimscript with lua in a backwards-compatible way.

Any editor is simply a graphical frontend to ed, even vim.

I'm surprised she didn't mention Marijn in the "thank yous" at the end - without him giving away his time building ProseMirror they would have nothing to build upon.

I've invested in Mobiledoc (mostly because it was for two ember apps) and it's mostly been fine, but is there any reason why I shouldn't be moving to ProseMirror? Seems to be a lot more powerful and have things like collaborative editing and track changes as well.

Just my experience: I had a rough time with ProseMirror trying to use it before it was released. It didn't use modern JS modules for a long time, the source code was a mess as far as I could tell, and JavaScript variable errors would surface with every version.

Maybe the author has overcome these issues, but I'd be inclined to go with a different editor. Also, ProseMirror's architecture is extremely close to DraftJS, which I've had much fewer issues with.

Yeah thanks for dropping some deeply outdated impressions in here. (Also not even fair—the code was never a mess and at the time it wasn't clear how ES modules would be used so using CommonJS was a completely reasonable choice.)

Impressions matter, no matter how outdated they are.

I also don't think the concept of fairness applies since I'm accounting the details of my personal experience and the conclusions I personally drew from it. Some of those are subjective (code quality) while others are purely objective (I got a lot of errors). What I infer from that may be entirely different from what you do, but that does not make your characterization of things more fair than mine.

Does a review of Windows 3.1 give you any idea at all of how applicable Windows 10 would be to solving a given problem? At best, you’ve stated a bunch of nonsense for people to filter out once they eventually realise you’re talking about a version which bears little similarity to the current state of things.

It's more important to appear smart and to spread your opinion than to contribute anything of value!

I have also used the newest version of prosemirror recently, and it caused me and my team so much pain we had to rip it out of our codebase.

The documentation is still no good. The underlying tech looks super promising, but the plugin system makes no sense.

If all they did was update their documentation so you can clearly see how to use it, perhaps it would be great.

Hey there,

Just wanted to offer some feedback. Prosemirror's docs are woefully incomplete. The way controls are added is extremely confusing. Why do we need some node module called "prose-mirror-example-setup" ?

I know I'd personally prefer being able to add all the markup and style for the editor, and then just use prosemirror underneath the hood for state management.

Another thing that I found quite difficult, was programmatically inserting images at the cursor.

Finally, storing state as markdown has turned out to be a nightmare. Not really your fault, but perhaps something you should be aware of.

I agree the docs are obtuse, and implementing features is hard, but document state is not saved as markdown. The whole point of PM is to separate content from prsentation.

We used ProseMirror in the past few months to build a rich text collaborative editor. We were able to get started and get a collaborative editor up and running in ~1 hour. This was a big deal for us, we'd tried to implement a good collab editing experience multiple times and each time we felt like the editor was the sticking point in creating a good experience. ProseMirror treats collab editing as a first class use case and makes it really easy.

We then spent 2-3 weeks getting all of the formatting, tooltips and key mappings to handle some basic formatting (bold, italics, underline, bullet lists, numbers). Eventually, once there are more examples on the web of more complex formatting for the community I think it will become much easier to use.

It's the first editor I've used that felt like it made sense at a conceptual level but implementing "simple features" can feel very hard at times. I don't think that's a knock on the library though. There's a lot to learn and understand and it just took us a lot of time to get it all.

This was my experience as well, quick to pick up but harder to master with more complex specs and commands even if seemingly simple. Understanding the concepts and the design patterns used in the examples goes a long way, it is a powerful framework.

ProseMirror requires a certain willingness to work with strict data flow and immutable data structures, and to cobble together a loose set of small modules before you have something user-friendly, but if you can handle that I think it's a safe bet at this point. (Disclaimer: I wrote it, and am heavily biased.)

Cool, but it's yet another case of re-engineering the same thing. (edit: its not entirely new).

Splitting editors into an abstracted structure for finer control over data and presentation is something that's been done for a decade now in various text editors. Medium and Basecamp started similar projects and there's Mobiledoc which is trying to standardize the format. It'd be nice if all this effort focused on a single project so we could all just get a decent editor instead of different versions with various states of functionality.

FYI, my running list of editors: https://gist.github.com/manigandham/65543a0bc2bf7006a487

Considering that they have built it on top of ProseMirror makes it seem pretty reasonable approach in terms of "reinventing the wheel"

This is discussing one that you already had on your list; ProseMirror. In fact, you've had it on the list since 2015: https://gist.github.com/manigandham/65543a0bc2bf7006a487/429...

This is talking about using ProseMirror to build some more features into their CMS, but it sounds like more of just a use of ProseMirror rather than a new editor entirely.

It might be helpful to update your list with some feature comparisons. For example:

Quill vs (CKEditor and TinyMCE, Draft, ProseMirror, Trix): https://quilljs.com/guides/comparison-with-other-rich-text-e...

Slate vs (Draft, ProseMirror, Quill): https://github.com/ianstormtaylor/slate#why

I personally went with Slate because I needed first-class React support but not as low level as Draft.

I really like Slate....but the ability to do collaborative editing is relatively new.

Have you done anything with collaborative editing with Slate? If so, how are you finding it?

Collaboration isn't a requirement for me. I would definitely go with quill instead if it were. They put a lot of thought into making the delta format natural for operational transforms: https://quilljs.com/docs/delta/

Your document state is always represented by a list of deltas. Two people trying to change the same document would just have their individual list of ops "rebased" together using OT before being concatenated into the existing list of ops, forming a new document that is still just a list of ops.

I second using quill. It's really modular and the code itself is so clean.

Quill has a great API, it seems like they really thought things through and designed it (what's a good word for the opposite of ad-hoc?). Even the lower-level bits are available with a clean API if you should ever need them (e.g. it's super simple to use the underlying OT and diff/merge functions on whatever text you want)

> Splitting editors into an abstracted structure for finer control over data and presentation is something that's been done for a decade now in various text editors.

Sounds like Latex which has been around much longer.

Is there a web-based WYSIWYG editor?

Overleaf and Sharelatex have WYSIWYG Editors for latex, yes.

Going with your own format has some advantages, but using a well known popular format also has advantages. I did look into ProseMirrors and other editors but due to the formatting I ended up making my own. Where I've gone the painful route of having HTML nodes instead of a JSON tree. My reasoning is that I always want to end up with HTML anyway, and this also allows switching back and forth between editing HTML and WYSIWYG-mode. And use existing source control (Git/Mercurial) for versioning. The biggest pain is that browsers like to mess with the white space, and different browsers want to format the HTML in their own way. The next step would be to implement my own html/CSS renderer/wysiwyg-editor using the canvas. When researching I found some proprietary tools that did that. I wish the contentEditable would get more love from the browser vendors, because that's what most web editors use.

If you're looking for a traditional editor then Froala is worth every penny. It has 10x the features of all these more modern versions and still outputs solid HTML.

There Is also Slatejs. We use it at work and it's really great.

https://github.com/ianstormtaylor/slate

Mobiledoc document format, while abstracted, is heavily based on html. ProseMirror completely abstracts content from prsentation.

Anyone know if Oak is (or will be) released as Open Source?

ProseMirror, the underlying editor they are using, is: https://prosemirror.net/

Yep. That was clear from the article.

Not Oak, but you might interest in Grid.

https://github.com/the-grid/ed

Built on top of Prosemirror.

Last commit over year ago.

I'm choosing an editor for my project right now. Can someone compare ProseMirror to Slate and Quill? What is the difference, which one is better? What do I need to know to choose one?

If you just need a WYSIWYG editor on a web page, and it's a single one, I've used tinyMCE.

On projects where I've had to load up multiple instances, I've had to move away form it as it kept reloading stylesheets and js files for each editor on the page.

Now I usually use quilljs, which works really well for some basic markup.

Prosemirror and Slate both great projects but lack of community interest. They are basically framework for creating WYSIWYG, until they release full featured editor built on it, i dont think it will become popular.

Personally tried both, working with Slate feels much smoother, plugin system easier than prosemirror in my opinion.

And, there is ckeditor5-beta. You might wanna check out.

And couldn't find any info on the backend requirement. Do they require nodeJS or can any backend framework be used ?

I've used a lot of quill in the past couple of years. It has some tricky bits, but seems similar in a lot of ways to ProseMirror - separate internal representation of data that gets rendered into HTML, delta-based state changes, etc. At this point, I use quill out of momentum - it was the only game in town when I started working with rich text, and now I know how it works. I also like it enough that I've never felt the need to go find something else; it's always done what I want.

I think to fully experience all three of those editors, you should build the following: something that generates a rich text input using the editor, updates a data store (can be just in-memory if you want), and then re-presents the rich text in a read-only format.

With Quill in particular, there's two ways to approach the second part - you could dump the data into another instance of the quill editor, but one flagged as read-only, and let quill handle rendering out all the elements. I don't do that, myself, as it's a bit heavy and relies on the DOM to be present to create the end result (meaning rendering rich text into emails on the server side can be tricky). Instead I use a library (that I wrote) that converts the quill representation into an HTML string that can be later injected into whatever place it needs to go.

In general, I think that's where the one of the important pain points is for any major modern text editor exist - converting the internal data representation into a canonicalized HTML string. This gets further complicated by your framework - it's easy enough to inject an HTML string, and angular 1 lets you even compile that so you can have custom elements there, but angular 2 has no such facility (compiling; you can still inject). So rendering custom elements into angular 2 is feasible but quite tricky.

You'll need to figure out how to handle custom elements too, like at-mentions and so on; those are really domain-specific. How I handle at-mentions in quill (with a pop-up autocomplete) depends on the structure of the overall system as well as the framework I'm in - angular 1, 2 and react all suggest different approaches for this.

Anyway, this is all a long response that means "it depends". Each editor has its own strengths and weaknesses that are exposed by the specific data and presentation needs of your project and the other frameworks in play. But building an atmention or other custom element and converting from the internal data structure to HTML is a good test of functions for all of those.

Is Oak going to be opensourced? Looks very interesting.

I've been watching this product for a while: https://www.nuclino.com/ it seems they too have built something really impressive on top of ProseMirror (it's a lot like Quip/Paper but more interesting). ProseMirror really feels like the only editor on top of which you can build an entire user experience and app.

So, we had this product (or the larger one anyway) demoed for my work and our takeaway was that only really large organisations could possibly use it. It needs to many human hands between writing an article and getting it published. We want to move to something more automated, and this system would have been a serious setback.

Oak was the codename of Java IIRC... May confuse some old people like me

This isn't even a test editor. It's closer to a web publishing tool. The article also didn't talk about the normal text editor challenges like the way the text is stored in memory and modified.

Agreed.

I carry the personal view that when someone says "text editor" they are implicitly implying plain text. As such the leading paragraph of the article makes me twinge a little when "text editor" is used rather than "word processor".

The article then continues on to describe the editor which sounds very much like a WYSIWYG editor. Indeed ProseMirror[1] homepage says the following.

    ProseMirror tries to bridge the gap between Markdown text editing and
    classical WYSIWYG editors.
    
    It does this by implementing a WYSIWYG-style editing interface for
    documents more constrained and structured than plain HTML

So whilst I've made a point of it reading oddly (and I would have thought this would also be the view of most others on HN) I am not trying to disparage the authors use of the term "text editor". But rather I am curious as to why such nomenclature happened to be used here as I seldom see it outside of descriptions of things such as Vim and Emacs.

[1] http://prosemirror.net/

What would you call Adobe Indesign?

It's a digital publishing system.

Not sure why you're getting downvoted. This appears to be an evolution of WYSIWYG tools to me, which I wouldn't categorize as a text editor either — more like a word processor.

FWIW ProseMirror does not bill itself as a text editor:

> An ideal content editor ... bridg[ing] the gap between Markdown text editing and classical WYSIWYG editors.

> It does this by implementing a WYSIWYG-style editing interface for documents more constrained and structured than plain HTML...

from https://prosemirror.net

Every comment that remotely questions this article is getting downvoted, rather than discussed. Lame.

Agreed. It feels odd to read an article from a developer who doesn't know the terminology. Vim is a text editor because it edits strictly text content and not other media or presentation. Oak is a 'desktop' publishing app if not a CMS; it's purpose is to handle multimedia and presentation, as well as document review.

(At least that's how I understand text editors; maybe I'm the ignorant one.)

You sure this is only for web? I got the impression that a story authored with Oak could just as easily be vectored to the web, newsprint, or magazine. Clearly video and audio content don't apply to the latter two but I can see where Oak-authored content is sucked into the print layout app(s) and more metadata (fonts? formatting?) applied that are only relevant for the dead-tree versions.

That seems a bit too pedantic of an argument for this article. The very first paragraph implicitly states its definition of text editor:

    If you’re like most people in America, you use a text editor nearly every day. Whether it’s your basic Apple Notes, or something more advanced like Google Docs, Microsoft Word or Medium, our text editors allow us to record and render our important thoughts and information, enabling us to tell stories in the most engaging ways.

Also, it could be argued that all word processors are also text editors but with added features. The fact that they allow the presentation to be edited does not mean that they stop allowing text to be edited.

Data Warning: 100 MB.

Viewing the header illustration for more than a few seconds crashes my iPad Safari tab. Scrolling until it is off the viewport prevents this.

EDIT: Dev Tools reports 74.8 MB transferred with an ad blocker. The illustration is a single 69.2 MB gif.

EDIT: 101 MB in total when you scroll to the bottom. Three more gifs: 18.1 MB, 7.1 MB, 4.7 MB.

Unbelievable

Why are they gifs instead of mp4s? Yikes. Also, since they are screenshots without a lot of movement, they really should compress better than that even as gifs.

Maybe because they're using Medium, and Medium doesn't have that option.

Why the biggest newspaper in America can't run their own hosted blog is a bigger question.

I'm sure they could run a hosted blog, it's probably a deliberate decision by their tech team to seem cool and hip by posting on Medium, because that's the in thing right now for developer blogs.

(Note: I'm not dissing them, I know a very talented developer who works there and says he has a great team)

> because that's the in thing right now for developer blogs.

Which is bizarre. The comments section of tech blogs are a great place to discuss and ask questions, and the support for comments on Medium is abismal, looks like they deliberately made it suck.

I think Hacker News does a better job of this, and so here we are.

On some cases, agreed. But most content posted on Medium doesn't end up here.

Or it is but never gets upvoted enough for most people to see it.

Maybe it was a decision to not have to run and maintain unnecessary shit when they have enough to deal with with their primary products when third parties have already invented that wheel.

And then they end up with a 70 mb GIF because the platform has deliberately poor features.

>While it may seem strange for us, a publisher, to post on Medium rather than our own platform, we are here for a simple reason: the community. Medium is where so many of our people are, so much of the product, design and development community, so we wanted to be here too.

https://open.nytimes.com/introducing-the-new-open-blog-23eba...

Organizations use Medium instead of their own platforms to try to create a sort of social signalling--like, "this is not the usual old-school BS you'd expect from us--this is cool design or tech content."

Whether that actually works is up for debate...

Medium has already turned around to just be uncool and pushing stupid bars and buttons in front of the text. So they are late to the party.

https://daringfireball.net/linked/2011/03/06/dickbar

I've had this vague sense all year that someone gave it a term and wrote a post on it and I read it, but it never reached the level of consciousness where I'd actually look it up. Thanks for pointing the way.

On iOS, the app Unobstruct is a lifesaver for these.

https://itunes.apple.com/us/app/unobstruct/id1255281426?mt=8

> Maybe because they're using Medium, and Medium doesn't have that option.

> Why the biggest newspaper in America can't run their own hosted blog is a bigger question.

Kind of ironic given that the post is about building their custom web-based text editor... I wonder if they use it to draft their posts for Medium too.

69 MB gif - isn't that called a video? I thought we had different formats for that.

What I find amazing is that it's that large despite only being two bits of color depth, and it's extremely short and low framerate. Where the hell did all that filesize come from?

Screen-grabber?

Crypto currency mining!

/joke

Looks like they cut the size down some. I am seeing 10.7 MB for the GIF.

There are several reasons for why the GIF is so large that all contribute to the size. The GIF's resolution is quite large for a GIF, at 1004px by 788px, this is larger then they display it on the page. And the GIF is pretty long at 336 frames.

Since GIFs on like just about every video format except MJPEG has no interframe compression. So each frame only has to average 32 KB to make up that 10 MB (336 * 32.6KB = 10.7 MB).

This is an example of how extremely good our modern video codecs are.

[0] - https://ezgif.com/split/ezgif-4-240b758f26.gif

Instapaper Text view reduces it to a slightly more reasonable 41 MB.

https://www.instapaper.com/text?u=https%3A%2F%2Fopen.nytimes...

(This may require a free Instapaper account to view.)

UBlock brings it down to 204KB because the images are on a CDN. Being on a CDN is probably why the author is oblivious to the file sizes.

There's something wrong with your iPad or safari itself. My 2 year old phone has no problems keeping up. It is incredibly stupid to have a 69 MB gif though.

That's kind of outrageous. Esp since the nytimes webdev team has generally done such a bang-up job w/ compelling UX.

I'd love to work for this engineering team. Their tech blog and github is full of interesting projects.

the BBC sounds like it has a really good tech team too. wonder what it is about newspapers that leads to this sort of tech culture.

I'd say it's desperation. The traditional business model of newspapers has been upended, and the ad driven model isn't really working out that well either. So instead of doubling down and riding it to the ground, some outlets are actually innovating and making cool stuff and throwing it against the wall to see what happens.

While I agree, I wouldn't think BBC would be dealing with those same pressures, being primarily (I think?) state-funded.

The BBC is state funded, through the TV Licence, for use within the United Kingdom, elsewhere it is funded on a commercial basis. The web site differs between domestic (no adverts) and international (adverts).

BBC Studios is the commercial arm of the BBC for licencing and distributing media outside of the United Kingdom.

https://www.bbcstudios.com/about/about-us/

An excellent profiler for perl, NYTProf [0], came out of New York Times. It's still actively developed and still kicks ass - outputs easy to grok flame graphs that you can click around on to zero into any statement. More than just finding bottlenecks, I find it useful to understand workings of new codebases...

[0] https://metacpan.org/pod/Devel::NYTProf

A desire to stay relevant. Print publishers often get criticized for being behind the curve, but a few like NYT and BBC have invested heavily in the technology of their business. Not sure how much it's paid off, but my impression is they aren't struggling as much as some.

I hope they manage to find the right combination to stay around, I loathe the dystopian future where Buzzfeed and Breitbart are the only news outlets.

Buzzfeed isn’t comparable to Breitbart at all. Buzzfeed does real journalism these days.

Their news coverage is pretty strongly slanted to the left. Just because I tend to agree with them doesn't mean I think they are really that much better than Breitbart in terms of providing objective reporting.

In any event, what I meant was that I don't want a future where we only have sources of "news" that serve to reinforce our pre-existing beliefs, with everybody siloed into their own particular little bubbles.

The NYT fortunately seems to be transitioning moderately well to digital at this point. They seem to have the wind at their back now. There was a period of time, spanning a decade or so, where it was very questionable if they'd make it or could survive on digital.

Their stock is at an 11 year high. Sales are growing again. Profitability looks set to surpass where they were several years ago. If it weren't for some stray costs & adjustments in Q4, they might have hit $100m+ in profit in 2017, the highest since 2010. Their balance sheet is solid, long-term debt is modest ($250m), and they have plenty of cash ($490m). Overall, it should be a good decade coming up for the NYT.

The BBC publish magazines but I wouldn't describe them as a print publisher.

They're a broadcaster.

True, I was thinking news in general.

Thanks. That's kind of you to say. We're also hiring. https://careerssearch.bbc.co.uk/jobs/search

It's a good melting pot for people who are passionate about writing, design, and ideas.

Kind of like how all of the best programmers have some kind of log or blog that they post in. While this could very well be some form of survivor bias, I think that just having to put effort into articulating your thoughts in a coherent way now and then improves other parts of your thinking.

Come hell or high water, the paper has to be on the newsstands the next morning. It is the very definition of mission-critical computing.

I worked on the Graun’s website/publishing backend in the late 90’s. Lots of Tcl/Tk.

We're hiring! You should apply! https://nytimes.wd5.myworkdayjobs.com/Tech/job/New-York-NY/S...

Any backend openings? I've been looking to move into frontend work more but don't think my experience is there yet.

There are! We're hiring for lots of open technology jobs here https://nytimes.wd5.myworkdayjobs.com/en-US/Tech

For backend specifically, on the CMS team there's this job https://nytimes.wd5.myworkdayjobs.com/en-US/Tech/job/New-Yor... or a fun one with the cooking team https://nytimes.wd5.myworkdayjobs.com/en-US/Tech/job/New-Yor...

If you're looking for a backend role, we're also hiring in New York Times Data Engineering--application engineers, data engineers, and database reliability engineers:

https://nytimes.wd5.myworkdayjobs.com/en-US/Tech/job/New-Yor...

I'm an engineer on our CMS team and as Albert mentioned we're currently seeking both back-end and front-end team members. We're not opposed to hiring skilled developers that don't have deep experience the specific language or frameworks we use. There's also always the option of joining the back-end and transitioning over time to a more front-end role. If you're interested, I'm happy to answer any questions or connect you to the hiring manager.

A CMS team? Christ, no wonder NYTimes is losing money.

As someone who has worked on the integration of off the shelf CMS and as well as built in house ones, I question this statement.

There’s a lot of value in building tools that fit the domain and workflow perfectly well. It’s expensive in the short term but in the long term saves a lot of time and money.

Sure. But it doesn't take a "team" to build up a CMS. This is why media "tech teams" are viewed as a joke in the tech industry.

WTF?

It takes a 'team' to provide any sort of professional level of support for an organization of their size. If the one-person "CMS/tech wizard" decides to stop working, or die, or get sick, or take an extra 4 hours to be with their family, the entirety of the NYT operations should just say "oh well, we'll just wait around for a while until we find our next one person to be our tech saviour"?

It is not constructive for me to engage with this level of cinicism.

Could you please not post unsubstantive comments to HN?

https://news.ycombinator.com/newsguidelines.html

NYT seems remote friendly, but is NYT remote non-US friendly? Front-end/Full-stack engineer from The Netherlands here.

We do have news employees in bureaus around the world but I'm not sure what the the exact policy is for tech employees. I'll see if I can find someone with the answer for you

Any openings that need Python folks?

A word of unsolicited advice: Someone who thinks "I am a Python developer" is generally less useful to a team than someone who thinks "I am a developer who is good at Python."

It depends on whether you're taking the perspective "if someone offered me this job, would I take it?" or "if I applied to this job, would they hire me?".

In most hiring settings this isn't true though. Language-specific skills actually do matter, for all but entry-level positions at massive tech companies. It's not like my 3 years of experience in Ruby is immediately translatable to Java/Python/whatever. Could I get up to speed in those languages in due time? Sure. But if you were on a hiring committee, hiring for a team that works mostly with Java (or whatever) would you rather hire me or the version of me that's had the same amount of experience but with Java?

Language-specific skills actually do matter, for all but entry-level positions at massive tech companies.

Absolutely, which is why I didn't stop at "I am a developer". That "who is good at Python" bit is definitely important.

However, seeing yourself as a "Python developer" rather than "a developer who is good at Python" makes it look like you see every problem as something you'll solve using Python. That's bad. That will put a lot of companies off hiring you (companies that believe in a 'best tool for the job' approach anyway, and those are the ones you probably want to work for).

>However, seeing yourself as a "Python developer" rather than "a developer who is good at Python" makes it look like you see every problem as something you'll solve using Python. That's bad.

If a company didn't hire me because they idiotically interpreted "I am a python developer" to mean "I would try to build a rendering engine in python" then I'd say that's probably a bullet dodged.

I'd interpret it as "I don't build rendering engines but I build other stuff for which python is a good fit", but maybe that's just me being weird.

The trope about great programmers being people who reverse binary trees in their sleep and being able to swap ecosystems at the drop of a hat needs to die. Great programmers specialise.

Being able to interpret around your words does not make your words inherently better.

You aren't honestly trying to sift out clueless prospective employers out by their ability to parse a title, are you?

The advice here is to put focus on ability to write software, and experience using python as a tool to do so, rather than implying that your ability is limited to python.

> It's not like my 3 years of experience in Ruby is immediately translatable to Java/Python/whatever.

It should be.

Picking up language X is very easy for most values of X (more esoteric ones excluded). After you know a few (and the more diverse the set, the less new concepts you'll see), picking up a new one is quick. If it is something like Go, it's a weekend's worth.

Using the language in idiomatic ways and knowing the most useful libraries and frameworks does take more significant ramp-up time. If you are a solo developer, or if the entire team is ramping up at the same time, then it is bad.

But a new, experienced team member, with zero knowledge in the most used language in the team? Sure, why not? They may even bring new skills to an otherwise homogeneous group.

I always let the interviewee pick the language during my interviews. Usually it is something like Javascript or Python. Sometimes it is Bash. I keep waiting for the day someone will offer to do it in Scheme, Haskell, Elixir, Prolog, D, Rust, even Ada. Pseudocode is actually fine too, unless I have a reason to think the individual lacks programming experience.

Whatever you do, DO NOT brand yourself as a X developer, if X is a programming language. I can understand specializations like machine learning. But languages? It's a mere tool, and you need more than one in your toolbox.

> Picking up language X is very easy for most values of X

I disagree. If you know Y and you're learning X, it depends much more on the value of Y. If Y is Lisp you will be quite successful at learning any X. If Y is something like C or assembly language, then you will not (it's always easy to spot the C guy who just started using Python etc.)

In my experience it is like learning a spoken language. If you know a language in the same family then learning the new language is relatively easier (e.g, Java -> Scala, Lisp -> F#). I also think the ease of learning a language is proportional to the ratio of expressiveness of the language you are coming from to the expressiveness of the language you are going to (e.g., Lisp to F# might have a much easier time than F# to Lisp).

>Using the language in idiomatic ways and knowing the most useful libraries and frameworks does take more significant ramp-up time.

Yeah. As in years. This stuff also changes all the time so requires perpetual learning.

>But languages? It's a mere tool, and you need more than one in your toolbox.

It's not a mere tool and languages are more than just trivially learned syntax. They are the umbrella under which a panoply of tools, approaches, ideas, priorities and culture aggregate.

Sure, you specialization isn't necessarily always the optimal approach and sure there are benefits to the cross fertilization of ideas across community lines. However, being a jack of all programming languages, master of none probably means you'll suck more than a specialist at a lot of stuff.

Moreover, some ecosystems plain suck and avoidance is the sign of a good programmer. Statistically, you're probably a worse programmer if you've used a lot of PHP and better if you've learned rust/F#.

> But a new, experienced team member, with zero knowledge in the most used language in the team? Sure, why not?

It really depends on how much time you have to wait for a new hire to ramp up before they are useful. If you need immediate help, then hiring someone who doesn't even have experience with your programming language is a complete non-starter. If, on the other hand, you are hiring for the long term and can afford to pay a ~3-month tax for a good engineer for (hopefully) several years, then you are correct and the ramp-up cost becomes pretty insignificant. But don't make the mistake of thinking that this is an exception to the rule—what languages you know absolutely does matter to any company needing to get work done now.

That is true.

What parent was trying to explain is that an individual is not defined by a specific subset of his/her experience.

Just as fluency in Spanish does not make me Hispanic, experience in python does not make me a "python developer". That title puts focus in the wrong place.

Not all languages are created equal. While yes a developer with years of experience in python may have lots of transferable skills to other languages, my team arent going to hire someone for a mid level/senior position without a good knowledge of c++

C++ is somewhat of an outlier due to the sheer size of the spec(and getting bigger all the time). Not everyone will use the same subset of features either, which complicates things.

That said, aren't you using C++ as a proxy for other needed skills though? Many Python programmers are not exposed to concepts like vtables, or they do not know how a linker works(or why it is even needed). Heck, many won't have done manual memory allocation or manipulated pointers.

Even though most people won’t use everything, all c++ programmers will need to understand RAII, manual memory management, lifetimes, effects of inheritance and some* undefined behaviour. We’d probably take people with C experience, and maybe Some D or Rust, but really for a mid level C++ job we wouldn’t accept much less than C.

Funny that you mention linkers, as they’re a bit of a minefield. Lots of the behaviour of linkers is platform (and implementation) dependent, I.e. are you building a shared library or an exe on windows or linux, and there are different gotchas for all of them. We wouldn’t expect people to know al of those things, but it definitely helps when it comes up, and you don’t have the same problem (ODR violations come to mibd) in many other languages...

I like your way of putting it, but I think those concepts (RAII etc) are fairly easily learned by a competent developer in any language. Most languages have analogous concepts if you use them long enough.

A shop that says it requires years of experience in a particular language is probably making their own hiring situation more difficult than they need to.

C++ for example is definitely a sharp language that takes some time to adjust to, and experience in C will help.

However: I think any competent programmer with a few years of experience would be able to gain basic proficiency in a month or two and probably daily-level-mastery in 6-12 months.

I say this as someone who had 10+ years in Java and only passive experience in C. I've managed to become mostly proficient in C++14 in about a month of full-time learning. After 10+ years of programming, I can pretty quickly adapt to the C++ way of thinking about things. I don't think I'm alone in this style of learning a language, and many hiring teams seem to agree.

May I ask, what's the company (and the particular team)?

Sorry, it was more of a hypothetical. I'm not involved in hiring for my current company and definitely don't speak on behalf of them.

I work in games on gameplay and engine code.

> Not all languages are created equal

No language is inherently "better" than another. They are each useful for specific cases, and understanding more languages means understanding their contextual strengths and weaknesses.

Apologies, I didn't mean to imply that C++ was better (or worse) than any language, just that it's not the same as others.

Don't suppose you'd consider remote candidates?

NYT is remote friendly, but most engineers are based in NYC. Wirecutter (https://thewirecutter.com/) is owned by The New York Times and is fully remote: https://nytimes.wd5.myworkdayjobs.com/Wirecutter

Thanks :D! I love Wirecutter, didn't know they were fully remote.

> If you’re like most people in America, you use a text editor nearly every day.

Filter bubble detected.

The author does not say "work in a text editor", only "use". Considering she's including text editors on mobile devices, which the majority of America will utilize today, that's not a particularly bold statement.

I suppose when I send a text I am using a text editor of sorts

Disagree. Paragraph context and examples made it clear she is discussing a dedicated text editor, not something embedded in e.g. your SMS app.

Can't imagine why parent is getting downvotes - it's an important point, and doesn't seek to invalidate the whole piece.

I'm speechless.

XML

"We’re planning to begin work soon on a collaborative editing feature that would allow more than one user to edit an article at the same time"

You mean like Google Docs or Quip?

> this new story editor needs to combine the advanced features of Google Docs with the intuitive design focus of Medium

This part made me sad. Imagine how much more powerful our tools could be if we didn't insist on jamming them all into web browsers!

But at least they run everywhere.

Where everywhere is some subset of browsers in the wild and often not that consistently anywhere.

I mean the web is awesome but it’s far from perfect from a programming point of view but that of course doesn’t matter for other reasons.

> Where everywhere is some subset of browsers in the wild and often not that consistently anywhere.

Yes, but it's easier to download a version of the browser that works. The alternative is for the developer to build native apps for each OS they want to support. In my experience, it's easier to build cross-browser than it is to build cross-platform.

If you have professional writers why not just teach them markdown and git?

Instead of spending engineering $$$ building, maintaining and operating a complicated editor?

Because professional writers are not professional coders. Markdown covers the basic text markups but does not define how to format all these embedded media a modern newspaper has. Just to give an example: Inspect the syntax of wikipedia, which is the MediaWiki wikitext (https://www.mediawiki.org/wiki/Wikitext) language. It is simple and therefore Wikipedia pages are rather simple. I expect the NYtimes to have higher aims in markup.

  >> why not just teach them markdown and git?

I myself am surprised they don't just use markdown. Git is another story.

  > writers are not professional coders.

But I have heard of writers clinging to old versions of WordPerfect, which were not WYSIWYG. They preferred the keyboard shortcuts to clicking around with the mouse.

Furthermore if you're just writing the text of the article, you don't even need markdown, just a textarea. They used to do these on typewriters after all. Newspaper articles traditionally lacked anything but plain text. No bold, italics, or subheadings.

  > Markdown covers the basic text markups
  > but does not define how to format all these embedded media
  > a modern newspaper has

Traditionally the jobs were separate --- and I assume they still are. There are the reporters, who research and write the text of the article. Then there is the layout team who lay it out, decorate it, etc. I can see how markdown would be no good for them. They would want a graphical user interface.

> Traditionally the jobs were separate --- and I assume they still are.

Is this really a good assumption? Journalists are making complex documents with central interactive features and lots of data visualization. It seems a lot like classic waterfall thinking to assume that reporters could perfectly envision that and toss it over the wall for a separate team.

Well yes, I think so, for these reasons:

1. Most articles have simple layouts, like this one, https://www.nytimes.com/2018/04/12/us/politics/trump-trans-p...

2. Most reporters were journalism majors, which teaches research, interviewing, and writing. Graphic design is a separate discipline. It is possible for one person to be good at both, but rare.

3. Companies tend to cut up work, especially big companies, like the New York Times.

4. Complex articles like this one, https://www.washingtonpost.com/graphics/2018/entertainment/v..., aren't tossed over the wall. But that doesn't mean that one person did it all either. I'm sure there was back and forth between the writer and designers, and likely an editor oversaw it all.

git isn't great for quickly writing and editing text. In response to breaking news, it isn't unusual to have two people making changes to the same paragraph at the same time. That's a recipe for messy merge conflict in git.

On the graphics desk we know how to use git— we use it for js/css—but still write words in google docs.

Whew, what a gross way to over-engineer a text editor. If the NYTimes structured themselves like a dev team, they could use common sense tools to get much better results.

Why is the journalist responsible for how it's presented? Wouldn't it make more sense to have some kind of product manager or designer handle this? And why is the journalist responsible for programming the look and feel of the their article? Why not have a front end dev do that?

Business choices, perhaps, aimed at reducing costs by reducing editors and moving more responsibility to reporters. See https://www.nytimes.com/2017/06/29/business/media/new-york-t...

Journalism is in the toilet, so journalists end up being one-man bands. Local Gannett paper had everyone using CRTs--in 2014!!!

Not true. Presenting is part of writing. It's not separate.

A lot of tech people don't get this. You see this in web design, where they think HTML and CSS are separate domains. They think CSS is just pretty effects.

Style can convey as much information as text.

Not true that journalism is in the toilet?

My wife was, and all of her friends still are, journalists. They constantly worry and complain about all of the tasks that were once the domain of trained professionals--photographers, editors, designers--being put on the journalist due to budgetary constraints.

I don't think the distinction is as artificial as all that. It wasn't even possible for writers to decide on presentation until DTP came onto the scene. They just typed up their articles and then the person doing paste-up created the presentation.

The journalist doesn't only write an article, he also structures and plans how the story is going to be presented because that's also part of the job. Hiring another person in-between the article and the journalist is like hiring an extra person to only hammer a nail when there is a construction worker to do that job already.

They develop the underlying technology to let journalists do what they want without needing to hire more employees.

In industries that still make money--even ones with better software-chops than the New York Times--writing/researching an article, and presenting it, are still separate jobs--and for good reason! They require orthogonal skillsets and a decent amount of time and hands-on experience if you want a professional result.

No one is "only" hammering a nail here.

Reply on news.ycombinator.com