igurari's comments

For those interested in understanding the underlying case law that AB5 codifies (a decision called Dynamex Operations West, Inc. v. Superior Court), my company, Judicata, published a visual (and tech-enabled) explanation of the decision when it was first published: https://blog.judicata.com/understanding-dynamex-the-californ...

Whether or not Uber drivers are employees or contractors under Dynamex and the ABC test is an open question, but the Uber explanation of the bill's impact is more or less correct.

Although I have no experience in immigration law, as a former lawyer and software engineer (and the CEO and co-founder of a legal tech startup), I'd caution against moving into law (or at least taking a long hard look and talking to people who have made the transition).

I left a PhD program in CS to go to law school based on ideals around having a positive impact through the legal system. Ultimately, the law is a slow, difficult, and painful system to work through and with. The work is mostly tedious (relative to software development) and most of the time you're not really having a significant or positive impact. It's generally not very rewarding.

I'd be happy to chat if you're interested in hearing more about my take. (itai [at] judicata [.com])

A lot of the errors you'll see in lawyer work product is not just from being overworked, but also comes from poor quality control mechanisms and insufficient use of technology in law firms.

On the litigation side we regularly see significant typos, misquotes, and even misspellings of the judge's name - and those are just the more basic types of errors we see.

By building the technology they're using Atrium will be able to not just drive efficiency but also improvements in the quality of the legal work product they sell.

It's a very exciting company.

> Software developers build abstractions, write tests, refactor and simplify older code, yet no such trend seems to be occurring for law. Why not?

Actually, the Common Law[1] (which the US, England, Canada, and other English-speaking countries) very much have a legal system that includes building abstractions, refactoring, and simplifying (though there are no tests). Judicial decisions are precedential and over time rules and tests are discarded or re-written to be easier to use and more applicable.

I think the parent comment is discussing legislation (which politicians enact), but the process by which judge made law develops and improves is very similar to how code evolves and improves.

[1] https://en.wikipedia.org/wiki/Common_law

That is also not true (except that it is an up-hill battle -- I agree with that). A "Tameny Claim" is an exception to at-will employment, and the rules around discrimination, harassment, retaliation, and discharges in violation of public policy are different. California follows the "McDonnell Douglas" burden shifting process at the summary judgment stage for identifying where the presumption is, and who has to show/prove what.[1][2]

Ultimately, at trial the burden of proof is on the employee, but the standard of proof is low -- more likely than not, which is basically 50.1%. If the employee survives summary judgment, their chances of winning (or settling favorably) are probably pretty good.

[1] See, e.g., https://scholar.google.com/scholar_case?q=Diego+v.+Pilgrim+U...

[2] The burden shifting process is:

"When a plaintiff alleges retaliatory employment termination ... as a claim for wrongful employment termination in violation of public policy, and the defendant seeks summary judgment, California follows the burden shifting analysis of McDonnell Douglas Corp. v. Green (1973) 411 U.S. 792 [36 L.Ed.2d 668, 93 S.Ct. 1817] to determine whether there are triable issues of fact for resolution by a jury. [Citation.] In the first stage, the `plaintiff must show (1) he or she engaged in a "protected activity," (2) the employer subjected the employee to an adverse employment action, and (3) a causal link existed between the protected activity and the employer's action.' [Citation.] If the employee successfully establishes these elements and thereby shows a prima facie case exists, the burden shifts to the employer to provide evidence that there was a legitimate, nonretaliatory reason for the adverse employment action. [Citation.] If the employer produces evidence showing a legitimate reason for the adverse employment action, `the presumption of retaliation "`"drops out of the picture,"'"' [citation], and the burden shifts back to the employee to provide `substantial responsive evidence' that the employer's proffered reasons were untrue or pretextual."

That is simply not true (in California). If the underlying lawsuit is based on employment Discrimination or Harassment under the California Fair Employment and Housing Act, firing the employee because they filed the lawsuit itself subjects the company to liability. It's called a "Tameny Claim" -- a "Discharge in Violation of Public Policy." [1]

Of course, proving that the reason for the firing was Retaliation isn't easy, but that doesn't make your statement true.

[1] https://scholar.google.com/scholar_case?q=tameny+v+atlantic+...

Datanyze (https://www.datanyze.com/) has built a nice business doing this. You can learn a lot from understanding what software a company is using on their website. It's especially useful for generating sales leads.

Getting free or low cost access to a plain text searchable database is no longer a problem for lawyers. It was 8-10 years ago, but since the entry of Google Scholar (and Casetext, Ravel, and a half dozen or so other providers) getting access to the law is no longer difficult. To echo the original post, the law today is in a place like the "deep, dark, early days of the Web, using search engines like Lycos and Alta Vista". We do need a "Google for the law," but Google isn't good enough to be that. It's a very hard problem to create a good search engine for the law, but legal search engines will eventually get there.

The premise of this blog post is a little off base. (Though I think Open Law Library is doing good work.) The difficulty in building a high quality legal search engine is not in parsing the links between the documents. High quality links matter, but they only get you about 25% of the way there. The more important thing is to have a highly accurate and structured understanding of the law. (Think of Google's Knowledge Graph, or the maps they use for their driverless cars.)

Disclaimer: I worked on Google Scholar and am the CEO of Judicata.

A recent evaluation of various legal search engines [1] found: "The oldest database providers, Westlaw and Lexis, had the highest percentages of relevant results, at 67% and 57%, respectively. The newer legal database providers, Fastcase, Google Scholar, Casetext, and Ravel, were also clustered together at a lower relevance rate, returning approximately 40% relevant results."

Westlaw, Lexis and Google Scholar all have high quality citation parsing (i.e., links). And Scholar relies very heavily on PageRank (as [1] demonstrates). But it is Westlaw and Lexis that are the better search engines. That's because they have invested more into going beyond just links; they've invested a lot into understanding what it is happening with the law.

At Judicata our own findings are that the average legal search query is significantly more complex than the average Google query -- having more terms and more concepts. Moreover, whereas only 15% of Google queries are unique, the inverse is true in legal research: more than 85% of queries are unique. What that means is that in order to return a good result, you need to understand a lot more about the query and the documents you've indexed. You can't rely on links between documents and past searches and clicks to power a quality search engine (the way that Google.com can).

As has been mentioned in other comments here, the real challenge for legal research is extracting structure out of the law (Shepardization, Procedural Postures, Causes of Actions, Dispositions, Legal Principles, Arguments, Facts, etc.). That is what will get legal search engines closer to where Google really shines -- results that are powered by the Google Knowledge Graph.

[1] https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2859720

Ben doesn't share that backstory, but it's irrelevant to his point. He is suggesting that he might have gone to jail by association with her and having done something illegal at his own company. Hence his statement:

"Since we had the same head of finance, we almost certainly would have been investigated.... The whole thing was a case of the old saying: “When the paddy wagon pulls up to the house of ill repute, it doesn’t matter what you are doing. Everybody goes to jail.” Once the SEC decided that most technology company stock option procedures were not as desired, the jail sentences were handed out arbitrarily."

So even if she did much worse things at her old company, the SEC could have decided that he broke the law too (even if in a less major way), and should go to jail too.

One possibility is that this is because you're working/programming late at night, basically up until the time you're going to bed (or within an hour or two of it).

I've found over the last 10 years that if I'm programming late (and really only programming, other types of work don't do this to me), and don't give myself 2-3 hours of down time before bed, my sleep is exactly as you described. My brain is running on work, it takes me a long time to fall asleep, and my night is spent drifting in and out of light sleep and work related thinking. It's pretty bad and can screw me up for days and weeks at a time.

Usually this happens because my focus is very high with late night programming (to keep me going longer), and I don't give my brain the time it needs to finish working through problems after I'm done coding. (You may be able to relate to thinking up a solution to a problem after closing your laptop, or waking up realizing there is a bug in your code. It's this type of thinking that your brain needs to finish.)

I'd suggest that if you are programming late at night, stopping 2-3 hours before you usually go to bed and do some reading or watch a movie. A few nights of that is all that it takes for my sleep to get back to normal.

Judicata - Software Engineer - San Francisco

Judicata is building the most advanced legal research, analytics and artificial intelligence tools in the world. Ours is a highly collaborative environment that fuses engineering, law, product and design. Building an ontology of the law requires a deep understanding of natural and legal language.

Requirements:

We’re looking for software engineers with 2+ years of experience, including significant backend development, and a passion for organizing one of the most complex logical systems in the world. Having a B.S./B.A. in Computer Science or a related field is required, along with strong communication skills for collaborating, not just within our engineering team but with our legal team as well.

Candidates should be excited about transitioning between applying NLP and graph theory techniques to writing frontend code and optimizing database queries.

Our stack includes Python, Django, JavaScript, Java, PostgreSQL, AWS, git and gerrit. Experience in each of these is a plus but not required.

That's certainly a reasonable perspective, and one I take very seriously. (And to be clear, I didn't mean to suggest that services should be based on a la carte pricing instead of subscriptions.)

From a long-term industry perspective, though, I think there are several reasons not to try to milk money out of search (and I think any company that is serious about dislodging Wexis should think hard about these): # In the short term it's a competitive advantage. Free is better than absurdly expensive or even relatively cheap. That competitive advantage may be enough to get very significant traction. Also, Google Scholar is already free, so paid offerings need to be substantially better than that. # Search is a gateway, and its a sticky one at that. For many (most?) people, Google is how they enter the internet. Google has built internet dominance out of search. Having people on your site multiple times a day provides a great opportunity to earn trust and layer on additional services. # Search is ultimately a low yield service. Once finding information gets easy (and everyone will be reasonably good at it in the legal space in 5-10 years), evaluating which is the best bit of information will become the main problem. For example, it's not hard to get a listing of all the restaurants in an area; but figuring out which one I'd like best is far trickier and something I'd pay for. Network effects will help with that, so getting large numbers of users is important. # The future of legal research (5-10 years out) is in analytics and AI, not search. So the race will be won by whoever produces high quality products in those areas first. # Web based services tend to be dominated by a single winner that achieves network effects (e.g., Google, Amazon, Facebook) and I expect legal research will be the same. So second place probably still means that you fail.

Your quoted comment came from me (I'm the author of the above comment as well), the CEO of Judicata.

> So I’m now seeing that NLP (Natural Language Processing) as confirmed by Quora, is hard, meaning that Westlaw and Lexis Nexis is actually pretty decent?!

NLP and search are hard to get right in a nuanced and high-accuracy-requiring field like law. And Westlaw and LexisNexis have done a pretty good job with those. It's not easy (or rather, it's not cheap -- think tens of millions of dollars) to build what they have built. Even Google hasn't with Scholar -- though to be fair, Google hasn't tried very hard to get legal search to that level.

Ultimately, in the future legal search is not going to be a money maker, and Westlaw and LexisNexis will take a big hit when free happens.

As I see it (i.e., from the vantage point of Judicata), search will ultimately be free, just as Google search is free. And just as Google has been able to make boatloads of money on "ancillaries" to the results (ads), the ancillaries will be the big money makers here -- but in the forms of extremely precise analytics and AI. Want to see cases Shepardized on an individual point of law, and other on-point or conflicting cases? Here it is, for a price. Given a set of facts and a procedural context, want to know the best argument to make to a particular judge? Here it is, again for a price. Given a legal brief presenting your opponent’s argument, want to see a line by line teardown? Here it is, and once again, for a price. Want your own legal brief automatically outlined? You’ve got it, and again, it costs money.

Of course, getting there is not easy (it’s a long road that requires going over every single case out there with a fine toothed technological comb), and so while I'd say that Westlaw's and LexisNexis's days are numbered -- that number is well over a thousand.

Nope, alive and doing well.

Judicata is very much alive. We're tackling a hard problem, with little margin for error, and focused on doing it right. It's a very different model than most startups, but then again, law is a very different beast.

Depends on which meaning of "Just" you use:

1. guided by truth, reason, justice, and fairness: We hope to be just in our understanding of such difficult situations.

2. exactly or precisely: This is just what I mean.

Most lawyers understand the concept of a regex, so I'd agree that its a good place to start. Law students are taught how to search for caselaw using Terms and Connectors, which is a simplified form of regex: http://lscontent.westlaw.com/images/content/WLNT&CSearching....

So they already have a lot of familiarity with the topic, and this just makes it easy for them to understand that coding is not so foreign as they might otherwise believe.

A different style, but wonderful to read and illustrative of the often craziness of law, is Margaret Hagen's work:

Law Flow Charts: http://www.margarethagan.com/drawings/illustrated-law-flow-c...

Law Cases: http://www.margarethagan.com/drawings/drawn-law-cases/