I say this because the bulk of work for many types of legal practice is information filtering/search/organization/and presentation, both in wrangling evidence and in exploring the law itself. Basic programming knowledge can do great magic in terms of making these processes more efficient, such as by programmatically manipulating the hundreds or millions of files that can be produced in legal cases.
In terms of more in-depth knowledge of programming, there is a definite place for it in the law (it has worked to my benefit), but I think that role is specialized/limited. I think improved software tools will, generally, fill the profession's need rather than every attorney attempting to specialize in another field enough to roll their own apps.
I would argue that this is true of nearly everyone. A small amount of knowledge can go a long way in helping to build simple tools that save a lot of labour.
For anyone else who is thinking about switching careers, this is how I started: At some point during my career as a lawyer I started collecting ideas for a better, more effective way to work as a lawyer. Software could help a lot while doing many administrative tasks and would allow a lawyer to focus on what creates value - giving legal advice, thinking through tough legal problems, negotiating a great outcome for the client... Yet a lot of enterprise software is too hard to grasp, and many lawyers just stick with the old way, doing most things manually (by themselves or have it done by their assistants).
So I started building one MVP, pivoted and now am building a "GitHub for Word". Steep learning curve as a startup founder and well worth giving it a try. If you are interested, check out my project Jules: https://julesdocs.com
What about as a partner?
Worse yet, lawyers have to keep working to continue to receive equity compensation in the overwhelming majority of cases. So you can't retire and continue to make money from your equity stake. You can't even really cut back on the crazy hours. This answer covers it pretty thoroughly: https://www.quora.com/Do-partners-in-law-firms-keep-a-share-...
Can you give a few examples of practical uses of those tools ?
I wrote a short blurb about my experience a little while ago: http://www.cachestocaches.com/2016/2/how-we-teach-programmin...
You have a $VeryExpensive accident.
There are $LargeNumber companies which have some partial liability.
That they are liable is extremely easy to prove, but the extent of the liability is extremely difficult and can be extremely costly on a per company bases.
You also have a database which holds most of the contributions of each of these companies, allowing you to build up a case for why each company has a certain percent of liability. While there is a team of lawyers and a team of programmers working on this case, the ability of lawyers to pull up simple enough data reduces the dependency of involving the programmers, and the lawyers having a basic understanding of SQL helps them both communicating with the programming team and when they have to explain things in front of the judge. Being able to query the data allows for the lawyers to better grasp which cases are the most worthwhile to pursue.
And for macros, sometimes you don't have a simple database, but you do have very standardized forms that are easy to scrape data off of.
If anyone there had even the slightest sense of how easy that would be to automate, they'd have saved hundreds of thousands of dollars by paying some random kid $200 to write them a bash script.
That's just a simple example, but I ran into issues like that on a daily basis. Databases full of evidence that were discarded because no one knew how to access them or run queries on them. Whole inboxes of emails in ost files thrown away because no one knew how to open them. Hundreds of hours spent manually reviewing documents when OCR and a decent text search tool could have gotten the same result in minutes. It was just never ending.
Also, there are discovery production management tools that incorporate indexing, OCR, searches, and what not.
For more complicated stuff you can use vendors.
It sounds like your old firm liked to bill clients for all of that extra staff time -- keep the revenue up.
You have a set of documents you prepare regularly. Could be a Power of Attorney, a diversion agreement, whatever. You can highlight the frequently changed part and substitute information by hand... or you can set up a macro with a form to enter the information and have it automatically generate.
Attorneys are knowledge workers burdened with a lot of administrative nonsense. There is a lot of low hanging fruit for automation.
Law firms have been using software to do this for 2 decades. Rather than using macros, they have dedicated document-management systems that can generate templates/documents based on the type of filing, client, etc. that get further customized by lawyers as needed.
Another example, though a bit more general, would be an attorney trying to find documents in a case that were created around a certain date. An attorney without basic skills is, again, going to end up in a manual or semi-manual (with a basic tool) process. An attorney with basic programming skills is likely able to directly craft a query that produces the documents.
It doesn't make much sense for a $400/hr attorney to play around with scripts and such or otherwise do much of anything with document production (that is what staff is for).
If an attorney knows coding from a previous career, it can be helpful in a few cases, but for a non-technical attorney to try to pick up enough coding to do anything useful is a stretch.
A shell script to achieve your ends could be endlessly helpful here.
It is one thing to teach a non-techie lawyer how to "hello world" But getting them to understand file system attributes, permission schemes, file I/O, regular expressions, and so on, is where "learn to code" falls apart in this context.
Just getting a non-technical person to learn how to navigate in Powershell is a near impossibility.
This is not true at all. Salaries for starting lawyers at "BigLaw" firms are generally fixed...but only by firm and by location. So Firm A in NYC pays $XXXk but their LA office only pays $YYYk. Firm B probably pays close to $XXXk in NYC but might pay $ZZZk. And if you go down to the smaller firms, they could pay anywhere from $40k to $XXXk based on location, type of law, etc.
After the first year, very few firms are lockstep with regards to raises...in the past few years, I think only 1 or 2 major firms is still on the lockstep model. Raises after 2nd year are almost universally based on performance, which depends heavily on technical skill (technical meaning legal, not programming, skills).
It seems -to-edit many more than one or two of this hundred https://www.vault.com/best-companies-to-work-for/law/top-100... are still paying lockstep.
Cravath still lists lockstep raises for years 1-7. Skadden years 1-8. Latham 1-9. Davis Polk 1-6. Etc. Are the firms reporting one thing but actually doing something else?
They rest don't do lockstep anymore. On paper they start with lockstep, but actual raises are based on performance, location, legal group, etc. I have enough friends at Skadden and Latham in different offices to confirm that.
Though, an exception would be patent attorneys. Patent attorneys with CS/EE degrees are usually in high demand.
If legal documents have to be parsed and understood almost like source code, could we also have a testing framework?
So I could stipulate things I want to happen as tests (user stories) and then run it against the contract / legal document and confirm that it does actually allow what I want to happen?
You'd be restricted to a subset of legal language - and possibly you'd have to actually write documents in some kind of meta-language (probaby lisp...) and then turn it into English or whatever as an output format in the end...
But would this work?
The problem is reconciling those requirements with reality. If contracts become functions, we don't make anything more neutral or unbiased. Same as today, the person who supplies the arguments to the function gets to control the output.
For example, earlier this year there was an interesting lawsuit . An insurance contract excluded "acts of war." There was no dispute that that was a requirement.
The dispute was on whether or not a given action was an "act of war." Mondelez claimed that the NotPetya cyber attack was an act of war as the US government said it was the work of the Russian military. Zurich disagreed.
We recently had a disagreement between an NPS officer and another visitor about what constitutes an occupied campsite. Apparently having paid for it, having a receipt on hand and another receipt with your name on the board by the entrance with the site number next to it doesn’t mean it’s occupied, you also have to leave a personal item. When you look at the rules it does mention leaving a personal item, but it’s in the “How to pay” section indicating to me that it’s a precaution to prevent two people trying to pay for the same site at the same time. Alas, the ranger disagreed and we almost lost our site and it turned into a whole ordeal all because the author of the rules didn’t spell it out and it was up to everyone’s interpretation.
Writing rules in the form of code has the chance of taking out a lot of that interpretation. Like you said, people can still disagree about what’s “an act of war”, but even that can be more precisely defined in a way that agrees with the common sense in the majority of the cases while still being unambiguous in the exceptional ones.
There is a fundamental tradeoff between specificity and generality, where the more specific a law is, the longer and more complex it must become to accommodate the nearly infinite number of situations that can occur.
Take a look at the bill of rights. The thing is about as vague as the English language allows and is less than 500 words.
When is a search "unreasonable?" What constitutes "due process?" Where is the line between a "peaceful" and non-peaceful "assembly?" How long of a wait before a trial is no longer "speedy?" When is bail "excessive?"
Is it even possible to enumerate all of the possible situations and amounts when bail is considered excessive? There are countless crimes and countless mitigating circumstances. How could anyone foresee all the possible situations that can ever happen?
Despite these questions, most Americans have some idea of what the amendments mean and they can be easily taught to high school students in a US history or civics class.
Compare with a highly specific law, the Affordable Care Act (not picking it, just an example), which is 350k words long. At most, people are likely to have read a summary of a few specific points, but the law is basically only knowable to career lawyers with significant domain knowledge.
So even if it is possible to be very specific in laws, doing so basically makes the laws so immense and complex that they become unknowable. And since laws govern human behavior, humans need to be able to know the laws.
You basically just run into Bonini's paradox. A set of laws that was sufficiently specific to have absolutely no ambiguity would be as complex as the universe itself. https://en.wikipedia.org/wiki/Bonini%27s_paradox
Let’s take the tax code as an example. I’d argue that it already is a form of a program (maybe that’s why they call it code), but instead of something that I can run on my computer and explore and play with inputs to achieve a more beneficial result for myself, I have to instead pay a tax professional to do it. I think having the tax code executable would actually make it more accessible to people that are governed by it, not the other way around.
Of course there is still a ton ambiguity in answering the questions on the form. That has nothing to do with the format of the laws and everything to do with the inherit nature of translating reality into simple booleans and integers. If you wanted to remove all ambiguity, the form would need to be complex as reality.
in theory, theory is the same as practice. In practice, they are different.
You cannot pass from the informal to the formal by formal means.
Believing so is a common misconception amongst engineers, but depending on it as such is likely to lead to disappointment, frustration, anger, needless bickering, extended conflict, and vexatiously long, hard to read, and mostly unenforceable contracts.
This is true, but I'd think the opposite point is more important.
Much of the grunge work I see the lawyers around me do really is about parsing out and semantically evaluating some clear-cut-but-complicated bit of text. As a result lawyers genuinely value producing (and succeed at) producing logically coherent, unambiguous text.
By contrast, most programmers are as sloppy as their compiler will allow them to be. This is bad enough in code, but it is much worse when we talk to each-other in English. Not only documentation, but internal design discussions etc, are usually some combination vague, meaningless and wrong.
Due to the requirement of legal language to be consistent and explicit (e.g. defining most terms in an annex), it's actually a very easy workload for NLP techniques, and the software is in production and widely used. Don't know if there's a version specifically trained for wills, but it would probably not be very hard to put together.
How about running a bunch of documents through ML and teach it what contentious contracts look like?
Canadian engineers have to take a short closed book 3-hr Professional Practice Examination (PPE) covering "ethics, professional practice, engineering law and professional liability" as part of the licensing process.
The reference is from Professional Engineers of Ontario as Canada's engineers are regulated at the provincial level, but thankfully is also generally similar across the provinces. I'd imagine the American version (PE) is somewhat similar.
While engineering law (typically torte) is a very small slice of The Law (TM), at least it's a start in the right direction.
Note that this would only apply to a subset of coders who actively seek out a professional "Engineer" title designation. Most computer engineering or electrical engineering graduates (probably the most likely population) don't need to, and don't actually end up, becoming professionally designated.
I would also imagine that they make up the overwhelming minority of software engineers. I don't know about Canada, but in the US the licensing authority did away with the software engineering PE entirely for lack of interest a few years ago.
If an engineer wants to answer a question like “The IRS and HMRC consider these stock options to have a specific tax status if an employee exercised them within 90 days of leaving a company. What defines the date of purchase of a stock? The date the payment is received or the date the stock certificates are delivered?”, what can they do (besides ‘ask a solicitor’) to learn an answer they can be sure of?
In your case, the exercise date is the date of issue
(I'm exaggerating, they probably have bespoke software which they can use for auto-generating their spreadsheets).
The lawyer only needs to learn a novel skill (Python), and then, said skill in hand, they can read through a few cookbook solutions to their problem on e.g. StackOverflow, and come away with an answer that is guaranteed to work—for at least their particular use-case—because they can test and iterate on it until it does work.
The programmer, on the other hand, would need to learn vast swathes of a body of knowledge in order to have the requisite context to understand the "subtext" (i.e. case law) governing any particular "cookbook" solution they find.
Or, to put that another way: as programmers, in the decades we've been practicing the craft so far, we've seemingly held as one of our "guiding principles" that implicit context (e.g. DSL/macro "magic") is generally bad: the more you have to know to start working on a new project, the worse a situation you're in. Programmers actively try to lower the "barrier to contribution", by 1. favoring larger libraries and fat language stdlibs over small atomized libraries, as large libraries can be shared as a lingua-franca/Schelling point; and then 2. avoiding abstractions that aren't built into the language itself, instead choosing a language for its built-in abstractions, as then programmers who "know language X" can be guaranteed to be ready to parse those abstractions.
Law has no such principle. The "law community" has in no way ever sought to make it easier to maintain or update existing legal text, and therefore, has never really developed an equivalent to the concept of "write-only code." They might make it easier to get started writing the write-only code (with templates) or might discourage writing more law than there needs to be (red-tape reduction) but there's nothing disincentivizing any particular legal document from being as impenetrable—and reliant on knowledge "from the environment"—as possible.
Or, to reformulate in a more productive way: if the whole body of law of a country were maintained in a reified form as some downloadable expert system knowledge-base, then anyone could learn the "pure skill" of legal analysis, which would be the skill of properly querying said knowledge-base (and, only if the answer isn't clear-cut, asking someone who has experience in predicting the way legal battles over such an issue would go.)
That's sort of the way medicine seems to be trending—doctors are more and more becoming people who practice the "pure skill of diagnosis" and less-and-less people who have a particular knowledge-base loaded into their heads. But law hasn't even begun to chart its way down this path.
For coders wanting to learn law it's much less available and significantly more costly. A lot of online legal learning resources are very oldschool, incorrect or incomplete, which is a real shame.
And if you're willing to look beyond online sources, legal treatises for laymen are available for most subjects for under $40. Many of those treatises (like the E&E law series) are so good that they're used as law school textbooks.
Meanwhile, for lawyers wanting to learn to code, a lot of online programming resources are very old school, incorrect, or incomplete. A lot of them refer to languages (or versions of languages) which no one uses anymore, features which have long been deprecated, or promote the use of code with poor security or programming practice, which is a real shame.
In that context of fragmentation, it's hard to imagine what an legal 'codecademy' would look like. You can't properly teach theory without a strong writing component, and the professors to review it would put you back into the cost structure of a full university (don't think a neural net would cut it, at least within the next decade). For a bunch of multiple choice on practical law, you would need to restrict your coverage to a specific geography, not to mention a specific field, limiting the market for such a service.
I guess you could start with the uniform criminal code + uniform civil code in the USA. Maybe common law principles too.
While it's generally great for people to learn to code as a hobby or for personal projects, I can't think of viable personal projects within law -- just as you wouldn't want to encourage personal experimentation in medicine. Likely the audience would be people trying to better understand their own problems with the law, which incentivizes Dunning-Kruger or law students, who are already in / will be law school. Unlike coding, law school degrees are absolutely required for the vast majority of legal careers.
I think the success of online legal resource providers like Clerky or LegalZoom is that they help non-lawyers navigate the law (outcome-oriented), rather than being a general educational resource.
Coding resources have come on a thousand fold, even in the last 5 - 10 years with top level teaching available for free / freemium via Coursera codeacademy, freecodecamp, udemy, udacity etc. Also all well supported by active user communities alongside stackoverflow and the massive open source community supporting the most popular languages and libraries.
There isn't an equivalent for legal knowledge in that sense, so far as we are aware.
Likewise you can't easily have personal projects with law or medicine - to do so is almost certainly illegal in most jurisdictions.
I think there should be a basic legal literacy, such that if someone comes along and asks for a feature or someone in the hiring pipeline asks a question that is likely trouble you know enough to consult legal.
Years ago I was working on an ATS system, specifically related to pre-hire applicant testing. Boss wants to be hip and with it, tells me we only need social login, e.g. Facebook, Twitter, LinkedIn. Almost immediately thought "adverse impact on a protected class," that class being "over 40." Few months ago an HN article about this very problem came up.
Had another one, team lead is assessing candidates with Hacker Rank. He starts giving random time extensions to various candidates, which opens us up to allegations of discrimination. Why did "Candidate X" get an hour longer than "Candidate Y."
And business law
And contract law
Has helped me immensely in understanding the world, and avoiding being manipulated by legal tactics.
I am not a coder nor a lawyer.
1) Contract law - if you're building software, make sure you understand how to licence it and not give away too much IP
2) Related to (1), understand Intellectual Property (IP) law - again, helps you understand what you own and what others own re the software or systems built
3) Tied to (1) and (2) increasingly, anything re data ownership and data privacy (incl. GDPR, an EU regulation re data privacy). Super important for anyone building tech that touches data, whether analytics, machine learning, deep learning, or any simple database backed product (i.e. most things).
Perhaps as an aside, relevant advertising / marketing restrictions to make sure a product doesn't fall foul of any laws re what can / can't be claimed about a product.
Naturally the laws are different in different countries / states, so make sure you anything you read relates to where you're doing business.
A good tip is to google for law firm client alerts re these topics - law firms often produce free one or two pager guides summarising "all you need to know" basic info to encourage their services. These can be a good starting point.
My recommendations might be a little bland from right here on the treadmill; but pick up introductory college textbooks on the three subjects. They will go into the overall topics and important legal principles. Also read case law as the books suggest, some are really kind of funny. At least to me.
I actually found law surprisingly useful and enjoyed those courses at uni. Maybe because I studied so little of it, or maybe because I should have gone all the way into that profession.
Protip: As an individual, drop a few legal paragraphs into a well written complaint when you've been wronged, and in my experience 9 times out of 10 the business will relent, instead of going further into legal matters.
1. They have a specialized skill set, and they can offload a lot of this to other people in the firm. Billing someone several hundred dollars an hour so that you can spend time fiddling with SQL is kinda unethical. This could be considered gray, but it's akin to charging someone the full billing rate to use a copier. Maybe this will ultimately end up billing less and saving the client money, but then maybe not. It all depends on the person.
2. The more important reason in my opinion is that programming is a specialized skill. You have to learn and really understand how it all works. It's easy to say "Well, just learn some Bash, and SQL" and you'll totally be able to get information faster. The question of whether or not it runs is an easy one to answer. Did it return information, yes or no? The real question and where it is tricky, is was it actually correct? Did you search all the files, etc.? Hiring a professional developer to aggregate information and have the knowledge to understand edge cases is why developers make the money they do.
Think about the flip side. Should all programmers become lawyers, because after you are one it's easier to understand the legal system. No, that's silly. Should programmers learn something about law? Of course, everyone should, but that doesn't mean that everyone should practice it. Now you could be saying, "Well, but going to law school takes years. That's a ridiculous statement to begin with." How long do you think it takes to be a really competent programmer?
Yes I could have delegated that work to do manually by a junior lawyer ($300/hr) or had the dev work done by an IT analyst ($800/day) but in both cases I'd have then had the check the output very carefully (junior lawyer) or gone through the cost and delay of onboarding a dev.
Doing it myself was the best overall value for the client.
There is an ethical issue if the lawyer is not properly qualified to do dev work. You can get into hot water that way. I avoid it by working closely with my client's IT teams, so they can vouch for what I've done.
I'm not in law, but I do work with physicians and health care researchers who often need elaborate data analysis. I've found that there are some types of work that benefit immensely from having both coding and medical knowledge in the same brain, so to speak. This is usually when data is complicated and messy, and when the question a researcher asking isn't fully formed yet. The ability do complicated SQL, natural language processing, data formatting and cleanup, and so forth can end up shaping the question that gets asked. The process isn't always straightforward - researcher thinks of the question, asks the programmer to do the coding, programmer gets the answer back to the researcher.Yes, sometimes it works to describe what you want from a dataset to a programmer, but this often isn't the case for very interactive investigation of data sets. For this reason, I actually would highly recommend learning to code for some health professionals and researchers.
Now, there's a limit to what one person can learn to do, and there comes a point where it's not reasonable to ask people to be expert in multiple fields. Even when a researcher is pretty skilled at programming for data analysis, the moment will eventually arrive where the medical researcher needs to work closely with a programmer (who has very advanced data analysis coding skills). But even then, I've found that researcher often wouldn't have conceptualized the question that gets asked without possessing at least intermediate level data analysis skills (including SQL, Unix, Python or R like languages). I've also noticed that researchers who possess these intermediate+ level skills are far more effective at working with programming specialists whose main skill set is processing data.
I'm not sure if this comes up as often in law, but I wouldn't be surprised if poring through very large data sets for discovery might be one scenario where this happens.
I even made a small app to autodownload train info from an API and tell me which route is faster two years ago. But that took me 40 times longer than it would take someone who does software engineering for a living.
So I leave the programming to the professionals in my legal practice.
Ironically, I'm one of the few attorneys who actually do look at honest to goodness code since source code review is common in patent litigation. But its a niche field within the law. And I don't even really need to know how to do it, just understand it at a high level.
The primary other way that "learn to code!" come up is idea/assertion that programming is like literacy. Now, I like the idea that programming is like literacy but we have to consider that programming has so far not shown itself to be like literacy at all. So far, programming has been much more like law or medicine, a specialized skill set. The amateur client who knows a little bit of law, medicine or programming, from the Internet or elsewhere, just makes things harder for the professional (whereas a literate client is better for a lawyer or any professional and literacy gives many non-professionals are skill to develop throughout their life).
Which is to say we should recognize programming as a professional activity but keep working on things that might, in the future, open the door to a programming as literacy.
I.e. it will not replace lawyers, but will enable 10x productivity, which means that you will need 1/10 less lawyers.
Lawyers are countable, so “fewer”, or, even better “1/10 as many”.
But the argument is flawed other than grammatically, as the quantity of legal services demanded isn't fixed, and if they are ten times more productive that means they become viable for tasks where they wouldn't have been worth employing before...and the total quantity of legal services consumed goes up.
I dunno, public defenders’ work is in a way the most basic of legal services, and from everything I've seen their time is rationed pretty heavily because there simply aren't enough resources. There’s a lot of room to translate more productivity into more getting done rather than fewer people doing the same level of work. (OTOH, I'm not all that optimistic about AI short of AGI helping that much in the aspects needed in that role, because I think the limiting factors there are the harder to automate aspects of lawyering, not the more mechanical ones.)
The problem is that in order to deploy AI you need a lot of very costly talent (costing as much as the lawyer itself). This will be solved first by AutoML / Auto deploy.
I.e. once automl is working, and each professional can create and deploy models, than will see the productivity gains.
Another effect of deploying AI, is that once a model learn something, ALL the other models become better - this does not occur in nature. I.e. once a human doctor fix a mistake other doctor can repeat this mistake.
However, once an AI doctor fix a mistake, all the other AI doctors learn from this mistake.
With a 2,000 page bill, it would make it easier to keep up with the changes, even if you don't yet know what is in every page at the start.
In College, I did spend some time wondering if a good Robert's Rules meeting running software might be a generally useful project, after being in a few society meetings where branches got long and twisty (amendment to an amendment to a proposal type things). Never did build anything more than a prototype though.
Seek out Thomas Jefferson's Manual for those clubs you'd like to see thrive. It promotes fraternity.
It would be an interesting project. Particularly if you could also wrap up the git in an interface that's accessible to non-programmers.
As far as the US goes, the Federal Register is a good place to start to see things as they happen.
What I think is missing is a concept of document: commits (laws) just accumulate on top of each other without producing named, organized documents (files, in proper source control systems) with clear responsibilities, that can be easily referred to from other documents, and of which the latest version is the only one that counts.
Instead, when you want to read a computer program, you don't look at individual commits to the code base, you look at its files. Commits are more or less irrelevant, what counts is the most recent version of a set of documents, and each commit might create, modify or delete more than one document.
It seems only a change in perspective, the end result is the same; but reasoning in terms of documents with well-organised names and responsibilities, describing processes and data and designed for reusability, is much easier and more compact.
It's still full of references to bills and such, but it is the consolidated text of the law.
has lots of intersting proposals and attempts
I guess the main blocker for this would probably be the formatting used to produce the documents. It would have to be a human readable markup language of some kind. Does anyone know what the standards are for, for instance, contract generation, in the legal industry? Are markup languages etc used or is it mostly just MS Word -> pdf?
On the flip side, DMS have far better tools for file preview, search, tagging, etc., and better integration with Microsoft Word and Outlook. These features are very important to lawyers.
Word and Outlook are defacto business tools for sharing legal documentation but oftentimes they are blunt instruments. I see mistakes or delays due to poor tooling all the time. E.g. the wrong versions are emailed, or each party's attorney makes their changes into a different copy of the document, the document becomes corrupted and needs to be copy-typed (I've never gotten to the bottom of what corrupts a document, other than to note it seems to be related to heavy commenting and track changes), or even just unproductive time needing to make simple updates across tens of files.
A github equivalent for lawyers would be fantastic. In fact I think it could be a killer app for the legal industry if it were possible to convince a quorum of big firms to move to it. Think: issue logging per substantive issue; pull requests for changes linked to each issue; full history of each lawyer's changes etc. Roll in some IDE for contact drafting with syntax highlighting, hinting, automated refractoring etc. All these technologies would be just as useful for lawyers as they are for developers.
If a small team of developers were to build a simple web app the way lawyers draft legal documents, it would look like this:
1. Developer 1 writes up the initial JS, CSS, and HTML files and emails them as an attachment to Developer 2.
2. Developer 2 prints out the files, edits them via hand markups, sends the printouts to his secretary to mark up electronically, and then emails the files to Developer 3.
3. Developer 3 repeats step 2 but emails the files back to Developer 1.
4. During this whole process, while one developer is working on the app, the other developers are waiting idly - even if they could be working on a separate part of the app with no risk of conflict.
This is a simplified explanation and lawyers will have some degree of version control internally through software like i-manage, but I find it hard to believe this process couldn't be improved significantly. I’ve been seriously considering starting a company in this space.
Often it becomes unclear who has edited what and when, and its exacerbated by the fact that many lawyers still prefer to mark-up documents with pen and paper and have them updated later by their secretary (while in the meantime the document will have gone through another round of markups from other lawyers in the team).
I don’t know if an automatic merge is the right solution either, but I can absolutely see the value in software that helps manage this mess. I realise it might be different in litigation, because in this case we’re not trying to draft a coherent legal argument but tick off a series of regulatory checkboxes that are semi-independent from each other.
A specialist contract markup language with a nice lawyer-friendly IDE would be ideal, but would need serious marketing $$$ and lots of patience to achieve broad adoption.
Unfortunately, since most law offices rely on Word, et al., just using git isn't to helpful.
For example: redrafting a contract is a lot like refactoring code. (Make sure that terms are only defined in one place; consider and account for edge cases; be aware of how changes in one area affect dependencies elsewhere, etc.).
If, like me, you’re allergic to repetitive, time-consuming tasks, coding is a way to potentially make your lawyering job go faster. I know lawyers who’ve used a combination of Python scripts and Zapier steps to fully automate client intake, for example.
HOWEVER! I’m pretty confident that coding will never become a core legal competency. Coding and lawyering are different roles, with different outputs, serving different stakeholders. Instead what’s more likely to happen is that coding will gradually eliminate a whole swath of tasks that we once assumed only lawyers could do — until we realized that those tasks were just algorithms in disguise, and therefore automate-able.
Like most other knowledge workers, lawyers are going to be responsible for managing — and applying wisdom and discernment — to the outputs that algorithms/software generates. And that’s a good thing! It’ll mean that lawyers are doing more of what they do best.
1.Many of these lawyers probably don't actually specialise in open source. Especially if they work for companies as project or product lawyers. They've probably been allocated it as part of their remit, along with issues like contract and data privacy.
2. Open source is a niche within a niche (IP law). It requires a nuanced understanding of copyright and patent law but also requires strong understanding of software development practices. Concepts like GPL linking are really tricky to grok even if you are a knowledgeable IP lawyer.
3. Several popular open source licenses weren't written by lawyers and so can be a little ambiguous when read against the relevant jurisprudence. Most are not well tested in court and so it's hard to give definitive advice on how they work.
Scroll jacking is unintentional - not sure what you mean in regards to the article specifically. Be great to understand this better and fix? Is it the lazy loading of the images? If so, that's an attempt to boost the page loading speed.
At the beginning of this year, after trying to explore what I wanted to do for the next stage in my life, I decided to get back into the profession as a solo practitioner and transition away from software development. I'm officially back to practice, and I'm surprisingly happy with my professional life - something I never thought would really be possible.
If you're a practicing lawyer who wants to give yourself an edge as a lawyer, I think it's more important to understand the concepts and principles as opposed inventing or finding the barely existent job of coder/lawyer for a firm - I don't know the name of the role, and I've seen it touted by legal tech folks - but these are elusive. Understanding what's possible, I believe, is by far way more important. For example, I've worked with countless non-coding project/product managers, and they've been great contributors to the process in software development.
My recommendation for lawyers? Do the Python track on Codecademy over a summer and read Code: The Hidden Language of Computer Hardware and Software.
I also wanted to move away from working for corporations to working for/with people instead.
If you have an itch, I say go for it unless you're on a track you absolutely don't want off of ever.
Coding is clearly really useful for repetitive stuff and to deal with lots of data, but from my own 10 years of experience practicing law I honestly do not see anything in particular that would make a lawyer benefit more than other professions from coding.
Looking back at my time, maybe having an app that had contract clauses and allowed me to quickly set up a base one from the templates would be helpful and save some time. Nothing huge.
Managing lawsuits is a great candidate, but there are already dozens of "spreadsheet apps" that do that, as are there apps to keep track of contracts (expiry, increases, thresholds and so on).
A lot of research is already taken care by Google and other apps (consider Brazilian law practice here, which is based on Civil Law so a little different than Common Law in US, UK, Canada).
In summary, learning to code is not really that huge of a deal for a lawyer. It is still helpful like it is for most professions, but I honestly do not see a lawyer that codes having that great advantage over one that doesn't.
* MS VB Macros for automating how my documents look and what they do
* Basic sync scripts that sync folders locally > server and vice versa
* An app to keep track of the my frequently used rules: trial rules dot com
* A website to keep track of various developments in my area law [internal to my firm]
* A PDF app that automates basic tasks [batestamping, adding exhibit stickers, etc]
Edit for spelling/formatting.
That's worth the 200E per hour I paid. I really don't need someone to do coding for 200E per hour (my own wage is more like E18) and I certainly don't need another 'me' to represent me.
I went to LS after several years of programming at various startups that failed. I wouldn't go now since LS tuition has almost doubled since then.
I do use "programmer skills" in my law practice, but I was a SW developer for 15 years before going to law school. I use emacs for initial editing and I have made some crude "lint" tools that help me proof my documents.
1) Workflow Creation - Obviously, much of the legalities start from a boilerplate template that are expanded upon. However, this skill is not exclusive to CS and so there are other domains where a lawyer could learn this (from, say, business)
2) Natural Language Processing - This is more a CS concept and where some coding may be necessary, but not really. The more focused work would be from argumentation mining  and properly building strong arguments. The link I include is to my PhD lab's project on "Augmented Graph Grammars", that look to quantify the aspects of argumentation into a graph structure. While CS researchers could mine the graph structures to report better arguments, using a process such as this for lawyers would be beneficial.
What's a good way for an consultant engineer to pick up a law firm as a client? What kind of open source community is there for legal software?
Though, if you are interested in law tech, law firms are not the place to be. Seek out law-tech companies that are building tools that enterprises may use to manage their contracts or licenses. Also, compliance management (SOX2, etc.) is a growing field.
Source: Sister was studying the Canadian LSAT.
It affects how you structure your thoughts, think through scenarios, gives you perspectives. There's so many perks, and kids would able to pick it up easily. You just need basic math and English skills to start.
I taught myself in the 6th grade or so. I believe it made a large impact early on in my life, and it makes programming very natural to me. I know the 10x developer term is controversial, but I believe that's one way to become one.
Well.. just like math
We teach math. We teach wood/metalshop and arts and crafts. Programming is right in there.
The value-add of knowing how to program is quite high, but a lot of that (IMHO) comes from the fact that we as developers have failed to make basic automation (such as what you get with shell "one-liners") more accessible to less technical users.
As a though exercise, could actual law (or, more specifically, Penal Law, Contract Laws, etc) be formalized in an analogous manner? I know contracts are not law per se, but the comparisons are easy to spot.
 In the case of laws, external events could be the judge's opinion, for example
This does not match my experience. I have worked in law for 20 years and hired (and fired) many lawyers for top tier companies. I saw some variant of an IQ tests for every one of them. As general rule they were not impressive and significantly below the scores we saw for programmers. The verbal comprehension was generally solid or better, the others not so much.
- Engineers make fucking excellent lawyers. Statutes construed alongside caselaw is sort of like data sheets alongside a schematic and code. You'll blow past everyone else in school and research will be a snap. When you get out to the real world don't spend too much on electronic research. Two services are there to service white shoe firms. You can't afford them if you're not one of the people I reference in the YMMV, infra
- Good engineer attys are efficient and effective and don't hold back the truth. Your clients will come back to you and trust you. You will be a rainmaker on merit. But schmoozing, man, learn it if you don't do it. I can't: It hurt. YMMV if you practice for a large firm and are expected to book 8K billable hours per year. At that point you're doing something exceptional (not a judgment)
- US judges are a mixed bag, elected or appointees. I preferred elected judges but wound up practicing 90% of the time before Federal appointees. Until early noughts the appointees were great. The statutes and binding caselaw in front of them may not make a difference. Unfortunately they're not like compilers or circuitry. You became an atty/engrnr because you're brilliant. But you need to schmooze or latch on to a partner to bring clients in and take the schmoozing bit on for you. Seek them out in law school and hang up your shingle with them. Don't go solo if you neither schmooze nor practice well. Don't go into law if you lie, please. If you don't schmooze, and if you forget to suppress your brilliance in arguments your client will get fucked. You'll get fucked if you have a temper and cross the contempt line (but that's really hard to do if you're sane enough to get through law school without a thorazine drip)
Bottom line: Go for it. My 2.5 years at law school were the most fun I had in my life. My 10 years practicing were stressful and not worth doing (I didn't have the schmoozer partner) but the education and my law license carries me forward in my engineering career, hopefully will get me into a corner office when geeking tires me. And it breaks the ice with my geeky colleagues who always need advice.
Copyedits for slightly improved readability. AMA here or by email if you wanna dig deeper
Patent law is no longer a good career track. There are so many patent agents today (post-recession) that it's very difficult to find non-contract jobs. Patent litigation is still a lucrative career path and doesn't require a US science/engineering degree, but it is significantly harder and more stressful. Patent litigation is also more about the litigation than the patent, so quite often the best patent litigators have no engineering or science background at all!
Engineers make fucking excellent lawyers. Statutes construed alongside caselaw is sort of like data sheets alongside a schematic and code. You'll blow past everyone else in school and research will be a snap.
Did not find that to be true at all. The engineers were the worst law students because they kept expecting black-and-white or determinable outcomes when the law is frequently incapable of any of that sort. The engineers who shed their engineering backgrounds did great though, largely because of their background in studying rather than anything related to being an engineer.
Good engineer attys are efficient and effective and don't hold back the truth. Your clients will come back to you and trust you. You will be a rainmaker on merit. But schmoozing, man, learn it if you don't do it. I can't: It hurt. YMMV if you practice for a large firm and are expected to book 8K billable hours per year.
Good lawyers are efficient and effective and don't hold back the truth. Their pre-lawyer background is generally irrelevant and engineers aren't any better at this than non-engineers. This is also unrelated to being a rainmaker--generally, for that sort of business development, it's about connections and schmoozing, where the truth rarely if ever is relevant.
Also, no firm requires a lawyer to bill 8000 hours a year. That's 22 billable hours/day, 365 days a year. I assume you meant 2000 hours/year, which is the normal standard for BigLaw firms in the US.
Now I find this out? And I loved litigation. So to add to my list of not to-dos: Don't boutique or solo right out of law school and if you don't like the answer you hear, be like that client who keeps asking the same question in slightly different ways hoping for a different answer until you get that different answer, and it's correct, and you've found the way into the area of the law you'd prefer to be in.
Some of the best lawyers we know in transactional law, IP and, in some cases litigation, come from STEM backgrounds, either academically and / or via prior experience in a STEM sector.
That's an amazing achievement to have paid your way through law school via software royalties. Kudos!
As you say, there are lots of overlaps between the two disciplines. We're trying to write up a continuing series of articles snapshotting these overlaps to help bridge between the techies wanting to work with lawyers and the lawyers wanting to work with techies. This was our first experiment with such content: https://lawtomated.com/law-coding-variables-and-defined-term...
I'm questioning whether you have actually worked for a firm because your expectations for firm billing are wildly inaccurate as is your understanding of how billing works in a firm.
1st year lawyers bill time which generally doesn't get charged to client, because clients are unwilling to pay for training brand new lawyers.
Associates after their first year generally bill between 1600 and 2400 hours/year, depending on the firm. All of those hours are actual hours worked because a lawyer who lies about that is committing fraud and can be disbarred for that (in addition to facing criminal sanctions). Clients do verify the hours billed--which is why lawyers are required to provide very detailed descriptions of hours worked, in some cases down to 6-minute intervals (i.e., tenths of an hour).
Partners bill in addition to those associate hours. The only partners that get to avoid doing billable work are the rainmakers, because they do the tough work of actually acquiring paying clients. 5th-7th year associates generate the most profits for law firms because they have the highest ratio of gross billings (= hourly rate x hours billed) to salary, though partners usually generate the most revenue for their firms.
Let me end your speculation: All of my time was in 1 and 2 person law firms. The inflated billables are anecdata from my classmates. You may rightly call those out as anecdata. As for myself and the firms I worked in no attorney ever exceeded 1K billables in a year.
You are only allowed to bill a unit of time to 1 client unless the work actually involved multiple clients. Thus, if you bill a client for 1 hour, you cannot bill a separate client for that same hour. You can, however, divide up that hour and equally bill clients for a portion of the hour.
If you bill on an hourly basis but switch between clients during that hour, generally you need to track your time down to portions of an hour and bill out at the end of the billing period accordingly. Thus, if you bill hourly but worked on client X for 0.56 hours 8 times, you would bill them for 4 or 5 hours at the end of the period, not 8.
How does that actually work?
Were there other startups you had in mind, or could link me to?
DoNotPay evolving ..? https://www.technologyreview.com/s/609418/this-chatbot-will-...
Here are some reviews of Stanford's FutureLaw 2019:
It's produced by one of the major legaltech meet-up / events groups, legalgeek, in conjunction with Thomson Reuters, who are also a major legaltech provider.
We need something like the AMA for software engineers. Or get rid of of these arbitrary cartel blocks that prevent an ordinary joe from taking an online course to become a lawyer.
Do you have a licence to practice software engineering? No well then you need to go to jail like doctors and lawyers who also practice without a licence.
1. Do you feel software or law is harder / more stressful?
2. Do you feel that devs or lawyers are "smarter" on average? Specifically at same pay scales - so partner vs architect / senior dev vs senior associate, etc.
3. Do you feel significant culture differences?
Any other notable positives and negatives that are significantly different between the two?
Also, some people seemed to have a lot of trouble analyzing fact patterns from different points of view. Where it may be easy for some to argue vigorously in support of an issue they agree with but difficult to form arguments for the other side.
Profs would listen to students argue from their preferred position (often the good guy position) and then ask them to argue why the other side is right. Some people just couldn't do it (future prosecutors?).
I found LS fascinating -- it was like learning a new kind of physics. One that described how society works rather the describing how nature works. And, like real physics, "legal physics" works whether you understand what is going on or not. E.g., previously I had a small business and entered into many contracts even though LS taught me that I had no idea how a contract really worked.
On the other hand, in my experience, the practice of law is much harder -- taking far more concentration and mental energy than SW development. Good lawyers are as nerdy and as smart good devs.
2. No opinion
3. Yes but I don't know how to express them, they're so subjective. Lawyering is like boxing coupled with research and writing. Tech work is engineering. Interpersonal skills, stamina, a go for the jugular instinct are far more important to successful lawyering than to tech work after you've established yourself as a developer and become sought after. For lawyering, selling yourself, reading people, keeping a poker face, negotiations, all of these skills yes you still need these for the every endeavor's business side but they'll be tapped constantly both the biz aspect and the job throughout your legal career, and you have to be in top form. Also when you start out if you don't come from a name school your employment options are nearly as bad as if you had no graduate degree. You may not have much choice in what kind of work you do if you generalize: Whatever walks in the door is your next task.
Law positives: I did mostly consumer collections defense and I loved it. The people I helped really needed help. It wasn't financially rewarding but it was immensely satisfying to help people out of situations usually not totally of their own making. The matters almost always have a definite ending point so there's not much worrying after its done and the relevant time periods run. I had no problems going to sleep every night. I kept 9-5 hours and had Federal holidays (unpaid though). The ageism in software is inverted in law.
Software positives: The money. Geographical flexibility if you don't need to be in SV. Being in demand all the time. Performing at the top of your field without having to schmooze with scumbags you'd avoid if you could (on the net excepted). Taking a concept from idea to market, and being recognized for it. Ageism. Working for The Man if you're not into roll of the dice contracting. Did I mention the money?
I do, however, think the two disciplines are very similar in that software development requires the same innate focus and problem solving. Though the two can differ in culture a fair bit as software – and high-technology in general – can be more laid back and friendly. On the other hand, defending and serving justice is a very straight practice with a distinct level of professionalism and ethics attached to the discipline – though, that’s not to tech lacks either.
Not mine but definitely an interesting resource for lawyers/coders.
For me the key goal is flexibility and uncertainty management. Lawyers have traditionally been extreme generalists across non-law domains (consider the fact that lawyers think of themselves as qualified to question expert witnesses from all kinds of hard sciences in a courtroom) who have exercised a consistent social function in the face of all kinds of social, political, economic, and technological changes, and the lawyers who have been best able to insert themselves at the joints of those changes are the ones who have succeeded. Having some understanding of the ontology of the various systems that are likely to be important in the domains where the law operates is pretty much a general good. And right now, code plays such a huge role in the economy that lawyers who have some clue what's going on are better positioned to adapt to changes in the economy as their careers move forward. (It's for similar reasons, I think that Harvard Law School recommends students take a class in accounting, or at least used to do so back in my day.)
With a minimum base of skill in slinging around code, it expands my students possible options. They might never use it again, relying on legal tech/document management/whatever vendors for any of the things noted elsewhere in this discussion. Or they might see a need and builds something that becomes one of these legal tech/document management/whatever companies. Or they might win a client a decade down the road by being the only lawyer in the vicinity who speaks their language. Or they might be working for a nonprofit who doesn't have the resources to buy solutions, and build something in-house that increases their capacity for service delivery to people who really need it.
TL;DR: lawyers have their hands in a lot of stuff by the very nature of the profession; it behooves them on general principles to become conversant with anything that occupies a large amount of territory in said stuff.
 version 0.1 of the course: https://sociologicalgobbledygook.com
Does anyone have a preferred method for generating Word documents that is better than mailmerge?
OpenXML or OpenDocument is the more robust way to go.