3 ms·

Jane Street has been doing this since they were much smaller. I interned there when they had like 300 people, and they were actively cultivating a great brand a

Jane Street has been doing this since they were much smaller. I interned there when they had like 300 people, and they were actively cultivating a great brand as an employer back then too—and looks like they've really made it work over the last decade! My impression with them in general was that they were willing to do lots of things that did not "conventionally" make sense at their size, and those things paid off. The internship program, for example, was relatively large in comparison to the size of the company at the time (≈50 interns?) and had lots of structure (events/talks/classes/group projects/etc) like you would expect from a big tech company, not from a 300-person firm. They were also willing to build a lot of tools in-house like their own build system[1], their own code reviews system[2], etc. Most people would see this as wasteful NIH but I'm convinced it was a net benefit for them—they managed to be so productive in an absolute sense and especially on a per-engineer basis because they were willing to build so much themselves, not despite it. I'm sure the same thing applied to their recruiting efforts. The biggest thing I took away from my internship was how much conventional wisdom in the software world was not necessary or true. [1]: First Jenga, now Dune [2]: Here's a neat talk on how they do code review at Jane Street: https://www.janestreet.com/tech-talks/janestreet-code-review/ https://www.janestreet.com/tech-talks/janestreet-code-review...

thor24 2y ago
curious why did you end up leaving? Since the company is known to be this amazing.
physicles 2y ago
> how much conventional wisdom in the software world was not necessary or true. Do you remember any specifics? I’m also curious how their tooling made them so much more productive. Were the tools just really well designed, or did they integrate perfectly with each other?
peppertree 2y ago
I often dread when I see an employer using in-house systems for common tasks like project tracking and code review. I'm curious how does JS's internal tools stack up against systems out there, like Github or Jira.
- wyager 2y ago
  I prefer the JS thing to github, mostly because it makes it a lot easier to juggle lots of in-flight changes that depend on each other while simultaneously supporting code review.
hyperbovine 2y ago
> Most people would see this as wasteful NIH Because it is. What is the point of reinventing these wheels when gazillions of man hours have already been invested on open source tools that can do it better and cheaper?
- cess11 2y ago
  What do you mean, "reinventing these wheels"? Are you sure there are other tools that look and feel the same? Letting your development team control and build their own tools is a good idea, if they are able to. You probably don't want to do it in Java or C#, it'll take too much time, too many people, and be too unreliable.
- mgh95 2y ago
  This implies that open source tools that do more (i.e. serve more use cases, work with larger amounts of software) work better for the narrowly defined use of a single company, even one as large as Jane Street.
- tikhonj 2y ago
  1. You can do it better, with better taste. Existing tools are... not uniformly well-designed. 2. Building something for yourself is qualitatively different than building something for somebody else. (I've heard this described as "situated software"[1].) Both the results and the process are different. 3. Building something yourself lets you become an expert in the domain and the tool you're building, often faster and deeper than using somebody else's system. It's a way to build up tacit knowledge and institutional capital as much as (or even more than) software. 4. More often than people realize, building something yourself ends up simply faster than first learning and then wrestling an existing tool into the exact shape you need. I've seen a lot of teams waste way more time trying to get some existing thing working than they would have spent building their own thing. Obviously it isn't always true that building your own version of something makes sense, and nobody is going to be building everything from scratch... but it makes sense far more often than conventional wisdom dictates. [1]: Term originally coined by Clay Shirky, but I can't find the original essay online, but looks like Gwern hosts a copy: https://gwern.net/doc/technology/2004-03-30-shirky-situatedsoftware.html https://gwern.net/doc/technology/2004-03-30-shirky-situateds...
wyager 2y ago
I used to work there - the jane street code review software is awesome, kind of like graphite but it works reliably. You can write a big tree of PRs. PRs get reviewed separately and you can merge them in any order at your leisure, without worrying too much about rebase issues or clobbering review or whatever. I would love to have some open source thing like that that actually works nearly as well. It may exist, but I haven't seen it yet. And yeah, jane street is a pretty compelling demo that A) NIH syndrome is fine if you're good at writing software and B) it doesn't really matter that much if you use a mature language or some uncommon immature language
- HALtheWise 2y ago
  Revup does a good job of integrating tree-of-PRs workflows into GitHub, and is also designed so that one developer can use it in a way mostly transparent to reviewers or their colleagues. I _think_ that Revup + Reviewable.io would match much of the capabilities listed in the linked talk. https://github.com/Skydio/revup https://github.com/Skydio/revup
  - wyager 2y ago
    The issue I've run into with graphite, for example, is that it gets confused by things like squash merges. I think fundamentally a merge-based workflow, which git(hub) encourages, is kind of inimical to stacked PRs compared to rebase-based workflows.
jallmann 2y ago
> Most people would see this as wasteful NIH but I'm convinced it was a net benefit for them—they managed to be so productive in an absolute sense and especially on a per-engineer basis because they were willing to build so much themselves, not despite it. It paid off for them, but I would say it's a risky move in general - it is very easy to get sidetracked with failed projects that have nothing to do with the business. There are many examples - Uber's internal chat system, etc. Others tools were more a necessity, eg the OCaml build story was not great back then. Investing in OCaml itself was a calculated risk. Also I wonder how things would be different if they were starting today, where there are more mature tools in the space.

thor24 2y ago

curious why did you end up leaving? Since the company is known to be this amazing.

physicles 2y ago

> how much conventional wisdom in the software world was not necessary or true. Do you remember any specifics? I’m also curious how their tooling made them so much more productive. Were the tools just really well designed, or did they integrate perfectly with each other?

peppertree 2y ago

I often dread when I see an employer using in-house systems for common tasks like project tracking and code review. I'm curious how does JS's internal tools stack up against systems out there, like Github or Jira.

wyager 2y ago
I prefer the JS thing to github, mostly because it makes it a lot easier to juggle lots of in-flight changes that depend on each other while simultaneously supporting code review.

hyperbovine 2y ago

> Most people would see this as wasteful NIH Because it is. What is the point of reinventing these wheels when gazillions of man hours have already been invested on open source tools that can do it better and cheaper?

cess11 2y ago
What do you mean, "reinventing these wheels"? Are you sure there are other tools that look and feel the same? Letting your development team control and build their own tools is a good idea, if they are able to. You probably don't want to do it in Java or C#, it'll take too much time, too many people, and be too unreliable.
mgh95 2y ago
This implies that open source tools that do more (i.e. serve more use cases, work with larger amounts of software) work better for the narrowly defined use of a single company, even one as large as Jane Street.
tikhonj 2y ago
1. You can do it better, with better taste. Existing tools are... not uniformly well-designed. 2. Building something for yourself is qualitatively different than building something for somebody else. (I've heard this described as "situated software"[1].) Both the results and the process are different. 3. Building something yourself lets you become an expert in the domain and the tool you're building, often faster and deeper than using somebody else's system. It's a way to build up tacit knowledge and institutional capital as much as (or even more than) software. 4. More often than people realize, building something yourself ends up simply faster than first learning and then wrestling an existing tool into the exact shape you need. I've seen a lot of teams waste way more time trying to get some existing thing working than they would have spent building their own thing. Obviously it isn't always true that building your own version of something makes sense, and nobody is going to be building everything from scratch... but it makes sense far more often than conventional wisdom dictates. [1]: Term originally coined by Clay Shirky, but I can't find the original essay online, but looks like Gwern hosts a copy: https://gwern.net/doc/technology/2004-03-30-shirky-situatedsoftware.html https://gwern.net/doc/technology/2004-03-30-shirky-situateds...

wyager 2y ago

I used to work there - the jane street code review software is awesome, kind of like graphite but it works reliably. You can write a big tree of PRs. PRs get reviewed separately and you can merge them in any order at your leisure, without worrying too much about rebase issues or clobbering review or whatever. I would love to have some open source thing like that that actually works nearly as well. It may exist, but I haven't seen it yet. And yeah, jane street is a pretty compelling demo that A) NIH syndrome is fine if you're good at writing software and B) it doesn't really matter that much if you use a mature language or some uncommon immature language

HALtheWise 2y ago
Revup does a good job of integrating tree-of-PRs workflows into GitHub, and is also designed so that one developer can use it in a way mostly transparent to reviewers or their colleagues. I _think_ that Revup + Reviewable.io would match much of the capabilities listed in the linked talk. https://github.com/Skydio/revup https://github.com/Skydio/revup
- wyager 2y ago
  The issue I've run into with graphite, for example, is that it gets confused by things like squash merges. I think fundamentally a merge-based workflow, which git(hub) encourages, is kind of inimical to stacked PRs compared to rebase-based workflows.

jallmann 2y ago

> Most people would see this as wasteful NIH but I'm convinced it was a net benefit for them—they managed to be so productive in an absolute sense and especially on a per-engineer basis because they were willing to build so much themselves, not despite it. It paid off for them, but I would say it's a risky move in general - it is very easy to get sidetracked with failed projects that have nothing to do with the business. There are many examples - Uber's internal chat system, etc. Others tools were more a necessity, eg the OCaml build story was not great back then. Investing in OCaml itself was a calculated risk. Also I wonder how things would be different if they were starting today, where there are more mature tools in the space.