Hacker News new | past | comments | ask | show | jobs | submit login
Should lawyers learn to code? Arguments for and against (lawtomated.com)
115 points by lawtomated 76 days ago | hide | past | web | favorite | 206 comments



Speaking as a software engineer who became an attorney, I would say that most attorneys could benefit from basic programming knowledge (e.g., simple scripts, macros, and SQL).

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 say that most attorneys could benefit from basic programming knowledge (e.g., simple scripts, macros, and SQL).

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.


How was that career change? Worthwhile (from a financial, job security, level of responsibility etc sense)?


I went the opposite way. Big law to programming. I make about the same (maybe slightly less but not if you account for unreimbursed business expenses like buying suits and similar hidden costs of employment) but for less work and I'm way happier. Many, possibly most, lawyers are miserable and hate their work. It's long hours and high stress, both because the stakes are usually high and you are frequently dealing with open interpersonal conflict/adversarial relationships. Plus no chance for equity, so you're an hourly worker for life.


I went this way as well: Worked in big law, always enjoyed coding on the side, and went all in with coding to build an MVP for a document collaboration platform. It is an experience I wouldn't want to miss.

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


> no chance for equity

What about as a partner?


Law firms are usually organized as LLPs, LLCs, or PCs these days, but bottom line that means ownership shares can't be freely transferred. You can't sell your stake, so there's no opportunity for a major liquidity event like you might experience as an employee compensated in stock at a corporation when the stock increases in value dramatically and you sell.

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-...


I thought Big Law pays $200k+? Meaning that the typical programmer would be making considerably less, or is that not the case?


Someone with the drive and intelligence to make it in big law (i.e. a far above average lawyer) is probably not going to be making the salary of an average programmer.


Depends on the lawyer and the programmer. I was on the lower end of big law and I'm on the upper end of programming.


Biglaw pays 200k in high CoL areas where Big-N tech workers start out at 200k.


I work in tech in a high CoL area, and sure senior engineers and eng managers are making 200k+ total comp. SWEs with <5 years of experience are not starting out over 200k.


There is overlap in terms of required aptitude, but otherwise they’re completely different jobs, so it’s odd to ask whether the change is “worthwhile.” Do you like cooperation and building things? You probably won’t like being a lawyer. Do you like conflict and tactical maneuvering? You might enjoy being a lawyer. You can make a good living doing either.


I did it too. It has been successful for me but inherent conservatism of the legal profession can be wearing over time.


>> attorneys could benefit from basic programming knowledge (e.g., simple scripts, macros, and SQL).

Can you give a few examples of practical uses of those tools ?


I was a paralegal a number of years back and, due to my experience as a coder, I was able to automate a bunch of my responsibilities. Much of the job of a paralegal (and some of the responsibilities of a lawyer) are things like data entry and records keeping that are trivially automated. One of my most popular tasks was to take data from Doc X in format A and move it to Doc Y in format B. Some string parsing (with human oversight) massively accelerated my productivity.

I wrote a short blurb about my experience a little while ago: http://www.cachestocaches.com/2016/2/how-we-teach-programmin...


An example I was once involved in.

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.


My first day at my last job as an attorney, I was told to submit 3000 files to a team of paralegals to have them manually convert them to PDF and rename them using a standard exhibit convention (eg EX-2019-001). This activity consumed three FTEs annually. I wrote a script to automate it in ten minutes.

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.


There are cheap PDF tools that do all that -- many designed specifically for making and marking exhibits.

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.


This was years ago, and the commercial offerings weren't as well developed.


Higher echelon (DOJ, State AG's office, etc.) wants to make a case for a change in the law and needs statistics about how many cases over the past x years where certain factors are met. You can query your case management database... or you can send an RFI to every subordinate office and make them do it by hand when they already have crazy workloads.

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.


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.

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.


Some of them do this. Some of them don't. We used to have LexisNexis HotDocs. Now we don't. However, even if we still had a third-party macro and templating system that was better-suited to the task, it would still be useful for the lawyers to know how to program those macros.


One simple example would be where an attorney receives a thumb-drive with 100s of documents and files as a "production" in a case. An attorney without basic skills would (or would have staff) manually enter all of those files into a spreadsheet or a word document. An attorney with basic programming skills would write/run a short shell script that instantly pumps all of the metadata about those files into an Excel spreadsheet.

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.


Or you send it to a vendor who has written the code to do that.


This.

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.


It may be the case that some vendor somewhere can provide a tool to do this, but they will charge quite a bit more than $400 and it will take more than an hour to find them.

A shell script to achieve your ends could be endlessly helpful here.


Having the depth of knowledge to recognize when a simple shell script would be helpful is the harder part.

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.


That comes with long RTTs and delays. That's often how Big Law does things, but it's suboptimal in lots of cases.


My vendors are pretty responsive (hours for a small production). They're using the same automated scripts 'rudyfink is talking about--they're just already written, tested, and ready-to-go.


Would you say a lawyer can make more / be more employable than the average lawyer if they can take software-related cases?


That is more complicated than you might think. In a lot of ways the legal profession is only a semi-functioning market--at least compared to software. On one hand, there are fairly amazing and very longstanding restrictions on how attorneys can market their services. This makes it harder (or outright impossible) for an attorney to market, so that diminishes (but does not eliminate) comparative technical advantage. On the other hand, salaries for most starting attorneys (i.e, associates) are fixed nationwide and proceed, generally, in lockstep, so almost all firms will pay the same, regardless of technical skill. So, the attorney is likely more "employable," but the market signals are substantially muted.


On the other hand, salaries for most starting attorneys (i.e, associates) are fixed nationwide and proceed, generally, in lockstep, so almost all firms will pay the same, regardless of technical skill.

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).


Are you sure this is true?

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?


With respect to the BigLaw firms cited, yes, since Cravath is the only one that is actually doing lockstep.

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.


I've never heard of anyone who hit their billable minimums (e.g. 1900, 2k, etc) not get bumped to the next year. Although I guess there's a bit of a dance that happens years 5/7-9 for people who think they have a shot at partner.


Doesn't the lockstep go away after only a promotion or two when the attorneys get promoted beyond senior associate? I guess that's still the better part of a decade, though.


The promotions are based on business case, especially as you get senior. To make a business case for partnership practicing technology law at BigLaw you need to have a decade or more of doing that as an associate, where you get paid more or less the same as everyone else at your level. In fact it can be harder to meet your targets / make your bonuses because technology law tends to be faster moving than other areas so proportionally more time needs to be spent on professional developer, as against fee earning.


Interesting, thanks. I always wondered if there is carry over to law if you know say, finance or SE well.


No. While a lawyer can build a lucrative practice around software/tech clients, the legal issues are not really unique to software. Learning to recognize/handle legal issues common to tech companies does not require programming skills.

Though, an exception would be patent attorneys. Patent attorneys with CS/EE degrees are usually in high demand.


My grandmother passed away a few years ago, and some of her express wishes were not correctly stipulated in her will - so when things were being sorted out it got messy. Thankfully all the family were really chill and we could sort it out amicably - but I had the idea at the time:

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?


It wouldn't work because specifying requirements isn't the difficult part of law or really a problem now.

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 [1]. 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.

https://www.zdnet.com/article/notpetya-an-act-of-war-cyber-i...


Maybe it’s different for the contract law, but I definitely think that legislation could benefit from more formal language.

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.


Sounds like the campsite could improve their signage, but as a general principle, I very much disagree.

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


The Bonini’s paradox makes perfect sense, but I don’t think it applies to this case because the law is not trying to model anything, it stands on its own. It’s the same difference as trying to model the law and predict what is and what isn’t lawful based on some circumstances vs declaring that the model IS the law and it determines what’s legal or not.

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.


For the program you want regarding the tax code exists now. TurboTax, HR Block, free file etc...plug in numbers, see different totals is exactly how it works.

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.


Epistemology epigrams:

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.


No. Because the definition of every word in your meta-language is subject to interpretation by the involved parties. There will be disagreements and then an independent adjudicator will have to provide its own interpretation (hopefully taking the parties view into account) to resolve the issue. Just like we have now.


No. The law is not a virtual machine and legal documents are not programming.

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.


> No. The law is not a virtual machine and legal documents are not programming.

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.


There are companies already doing this for specific kinds of contracts, e.g. DealSumm [1] (https://www.dealsumm.com/). You give them a large corpus of lease agreements (e.g. for an apartment building you've just bought) and they give you a nice structured representation of the obligations, total revenue, all the upcoming deadlines, etc.

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.


Take a look at this: Formal Methods and the Law https://youtu.be/EshxZVMURt4


What a great idea. I feel like there are a dozen variations in this that might be effective.

How about running a bunch of documents through ML and teach it what contentious contracts look like?


I'm really waiting for the corollary. Should coders learn law? I'm of the opinion that engineers most certainly should.


>>Should coders learn law? I'm of the opinion that engineers most certainly should.

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.[1]

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)[2] 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.[3]

[1] http://www.peo.on.ca/index.php/ci_id/2060/index.php?ci_id=20...

[2] https://www.nspe.org/resources/licensure/how-get-licensed

[3] Anecdata


>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.[3]

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.


Yup. In BC, we basically have to read a law textbook covering contract law, professional liability, use of codes + standards, intellectual property, and other such topics and then pass an exam about it. Among many other requirements...


It's much the same for us Canadian accounting grads. Law classes are standard in any reputable accounting undergrad program, and mandatory for CPA accreditation (as it was in the CGA, CA, and CMA before the CPA merger). It's not so much about training accountants to be lawyers, but more about making sure that accountants understand when to seek legal advice, the consequences of failing to do so, and how to converse with a lawyer effectively.


The amount of study required to pass the law and ethics exam is perhaps an evening or two of reading. I did learn a few things in the process, but the level of knowledge it represents is on par with a learner's permit for a new driver.


Beyond lawcomic[1], what is a good resource for this? If a lawyer wants to learn enough python to create a script that joins PDFs together, they can pick up a copy of Automate the Boring Stuff with Python[2] of the law.

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?

[1] https://lawcomic.net/guide/?page_id=5

[2] https://automatetheboringstuff.com/


Tax law is a lot like coding, the answers are there if you know where to look. Generally, look to regulations for definitions, publications for working examples, and case law for ambiguities and ombudsman/case for unanswered questions.

In your case, the exercise date is the date of issue

https://www.irs.gov/publications/p525

https://taxpayeradvocate.irs.gov/


Yes. In fact the tax law as the authorities apply it probably is code in the sense that they probably shove some inputs into some Excel spreadsheet to calculate your tax return.

(I'm exaggerating, they probably have bespoke software which they can use for auto-generating their spreadsheets).


There's a fundamental difference between your two examples.

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.


We think it helps if coders need to work with lawyers, e.g. particularly so in the fintech, legaltech, regtech and insurtech biz space. That said, it's somewhat unequal in terms of availability of educative resources. For lawyers wanting to code they are spoilt for choice with free, freemium or premium courseware online or in person.

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.


Most legal codes are available freely online. Almost all US federal cases are freely available online going back to the first SCOTUS. Most state appellate court cases are also freely available online. Hundreds of lawyers and firms provide online articles or posts explaining the law, including detailed analyses of cases, regulations, issues, etc. Programmers wanting to learn the law are spoiled with choices for free online legal resources.

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.


I think the online educational resource availability follows from the field dynamics. Python is python no matter whether you're in India or Hawaii. Law is specific to geographies. Law schools generally either focus on their regional context or, at the very top, teach theory instead of practical law (e.g. Yale).

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.


Yes we were thinking of a legal and localized equivalent of codeacademy for law when we said there's simply not the same level of legal learning resources online as there is for coding.

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.


> Should coders learn law?

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."


International legal frameworks for business

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.


Any recommended reading?


We'd recommend anything you can find re:

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.


Besides the international frameworks, it depends on the legal system in your country.

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.


Not reading as such but at www.SCL.org we have a 12 module course for foundations of tech law. It includes many topics of relevance to coders. We are a registered charity promoting public knowledge of law and technology.


Law maybe not, ethics definitely. Although a cursory understanding of IP law is probably essential for wearing many hats at a job.


I'm not saying that lawyers shouldn't learn to code, but I don't think it would be wise of them to heavily rely on it in practice.

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?


I agree with most of this, but as a lawyer who has used SQL and PHP to automate work that I'd have otherwise been billing $600/hour to do manually I do find fault with your point on ethics.

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.


Interesting observation. Coding could be comparable to using the photocopier, or it could be comparable to very advanced electronic legal research.

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.


Yes you are correct - I've seen this in e-discovery exercises.


I misspoke. In your case, I totally understand. You sound like you know what you're doing, but I have met a number of legal people that try and cut corners. I get it, it's a business. Everyone has to make money. You keep expenses down, etc. You do have to admit, that there comes a point where billing at that 600 dollar rate so you don't hire someone that could have done it in 1/5th the time (and at a lower rate). That's pushing the boundaries a little.


I don't disagree. It is how the legal profession works, though. If clients demanded something more efficient then there would be incentive to change, but they almost never do.


Exactly. I'm an incompetent programmer. I took about 4 classes at university on CS and a lot of my EE courseload used some programming. So I've written smaller programs, I've made a simulator of an 8-bit processor.

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.


This, definitely. Many of the "X should learn to code" arguments really miss the key point that X is professional, specialized skill and clients pay for that skill.

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.


Programmer will probably should not become lawyers. But an AI will (after more advances in machine reading, and NLG).

I.e. it will not replace lawyers, but will enable 10x productivity, which means that you will need 1/10 less lawyers.


> I.e. it will not replace lawyers, but will enable 10x productivity, which means that you will need 10x 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.


Sure. My bad. Been coding for 12 hours... So introducing AI is not unlike the innovator dilemma, it will push human lawyers up and up. However, I think that even if the demand is not fixed, most of it is for basic legal services.


> However, I think that even if the demand is not fixed, most of it is for basic legal services.

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.)


I personally think that the problem with AI today is deployment and not research. You see a lot of very busy lawyers not because AI cannot help, but because it is not deployed. The same applies to health care. Even if we come up with super human models for cancer detection, they are not deployed.

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.



I am afraid that this does not apply to intellectual work since the marginal cost of new AI is 0. Hence, in theory, any new work given to lawyer, will be soon covered by more AI models.

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.


The context was (explicitly) not AGI that can fully replace lawyers, but AI technologies that make human lawyers more effective. In that setting, the Jevons paradox would still seem to apply (until we actually saturate demand for anything human lawyers can do).


Even if lawyers don't learn to code, I think they'd find source control to be a significant boon.


I wish our laws were in source control, even the bills that don't pass. I'd love to see who added the pork, who watered it down, etc.

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.


This article was pretty neat (How I Changed The Law With A GitHub pull request) https://arstechnica.com/tech-policy/2018/11/how-i-changed-th...


Something I find interesting is that Robert's Rules of Order encapsulate a simple, early version of source control. Amendment processes are early pull requests, built to peer review diffs to the most recent previous document. If done properly, the minutes for a meeting should represent almost a full commit log, including discarded branches.

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.


Tangentially, when counseling clubs and other non-profits clients seem to reach for Robert's Rules. Robert's Rules is very well marketed but IMO are just awful, clubs tear themselves apart following them, and invariably one or two members expertly wields procedural R'sRs to the detriment of minority opinions and good neighborliness and the club founders.

Seek out Thomas Jefferson's Manual for those clubs you'd like to see thrive. It promotes fraternity. https://en.wikipedia.org/wiki/Jefferson%27s_Manual


The amendments and such are generally public, right? Presumably someone could put that into Git.

It would be an interesting project. Particularly if you could also wrap up the git in an interface that's accessible to non-programmers.


Is there a regularly updated copy of the U.S. Code available for download? Or a feed of individual passed bills? This seems tractable but I'm somewhat worried that the "free" version is bound volumes in the Library of Congress and the digital version belongs to some quasi-private agency out there that might sue me for attempting to republish the laws.


All US Federal statutes and agency rules are online. The amendment and rule making process is transparent.

As far as the US goes, the Federal Register is a good place to start to see things as they happen.

https://www.federalregister.gov/


On the executive agency side, it's not uncommon to produce a "redline" version that's kind of like a manual, carefully drafted "Track Changes" version of a document. I produced one for the U.S. Marine Corps for the Temporary Early Retirement Authority.


Laws (at least in Italy, probably in other countries with similar systems) are actually commits to a source control system- in the sense that they contain both new content and modifications to previous content (additions, changes and deletions).

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.


US jurisdictions mostly produce the organized documents you speak of. For instance, the codified laws here:

https://www.loc.gov/law/help/statutes.php


This (from a quick reading, I might have misunderstood) seems to be a system for categorising laws, but not exactly what I was talking about: when you look for something, you're still referring to individual laws, by law number or popular name.

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.


Here's a better link, to the text of the United States Code:

https://uscode.house.gov/

It's still full of references to bills and such, but it is the consolidated text of the law.


This is one aspect of how LexisNexis and Westlaw make their money. Copies of legal instruments in their up-to-date 'as amended' form are often behind a paywall.


Same in the US. Most bills are structured as diffs to the United States Code.


https://www.google.com/search?q=git+for+laws

has lots of intersting proposals and attempts


Very true, actually thinking about it contracts and laws are perhaps the perfect usecase for source control - plaintext, can track who changed what and when, etc.

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?


When I was practicing law couple years ago people were just sending around Word documents with redlines for changes. I'm sure there are companies that make version-controlled, share-editing tools for contract markups but I don't think they really caught on.


They’re used universally at larger firms. Net Documents, FileSite, etc.


Shudder. A world of difference between these tools and source control.


Apples and oranges. Source control is better in some respects, such as tracking related changes in groups of files, or automatically merging changes by multiple authors into the same document. This is rarely useful in legal work, where there might be at most a couple of documents (and typically just one) touched to implement a logical change. Moreover, because of the need to maintain a consistent "voice" throughout the document, it's rarely useful (at least on the litigation side of the fence), to automatically merge multiple changes to the same document at the same time.

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.


I think there's space for a middle ground.

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.


For what it’s worth, I agree. I’m a junior lawyer at a big corporate law firm in NZ and it’s incredible that we don’t have anything resembling Github or meaningful source control.

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.


The premise that the other team members could be working in the documents at the same time is false. I’m a litigator, so that’s a bit different, but there’s almost never a situation where I want other people editing the document while I’m doing so, even if the technology permitted the changes to be integrated seamlessly.


Is this inherent to the way law works, or did practices develop this way to route around the messiness of simultaneous changes without git?


It’s inherent to the way writing prose works. Documents are sequential, not modular. You can’t have 10 people all working on a novel at the same time. Maybe there are a few logical sections you can split up, but even then everything needs to be in the same voice so someone needs to massage the pieces during integration. Automatic merging provides little benefit over copying and pasting a couple of individual sections together. There are also very few documents being written. (The ratio of documents read to documents written is probably 100:1 between cases, discovery documents, etc.) You’re never editing dozens of files at the same time. Maybe 3-4, and often just one.


Right now I’m working on a 100 page due diligence report. Even if I’m doing a simple task like proofreading, I have to mark up my changes by hand and wait for the document to become available to access because an associate is making edits to a single page of the report. To make things worse, once we finish our draft, we’ll send this document to our clients, the investment bankers, and the auditors to review and send us 3 different versions of markups. Meanwhile we’ll be continuously updating the document ourselves.

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.


Perhaps it's a contentious vs non-contentious thing but in the latter (my world) we edit drafts collaboratively all the time.


Word has Track Changes built in already,


The standard is Word, because Word allows for formatting and for version tracking and works well with DMS software.


Word is deeply frustrating, buggy and prone to formatting glitches, but has the network effect.

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.


We use source control (document management systems).


And syntax highlighting. Coders really only solve their own problems well. Everyone else gets "built to the spec".


Document management software usually provides versioning.

Unfortunately, since most law offices rely on Word, et al., just using git isn't to helpful.


I think everyone would benefit from learning a little bit of code and maybe databases. Not necessarily for practical purposes, but rather to expose them to it since so much of the modern world runs on software. The same way as we are thought the basics of chemistry, biology, physics, history, geography etc in school, I think kids should be thought the basics of software too. Give them some exposure, show them a little behind the curtains and.. then let them decide if they want to do more or not, same as the other sciences and subjects we teach kids and teens in school.


As a lawyer who codes (though I don’t currently work as either a lawyer or a coder) I thought this article does a great job of explaining where coding fits into law. At least in my experience, coding is a “legal-adjacent” skill: coding is neither necessary nor sufficient for good lawyering. But there are deep conceptual similarities between coding and lawyering, and knowing how to do one job well can certainly make some parts of the other job easier.

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.


Unrelated to the point of the article, but since we're discussing lawyers and their knowledge of coding in a Silicon Valley audience: has anyone else noticed that many of the lawyers who specialize in software licensing actually have a very shallow understanding of common open-source licenses? I think I've worked with at least 3 firms now at my current employer, a medium-size (>2000 person) software company. When I've had meetings with them about compliance with open-source licenses, they seem to be unaware of really basic aspects of the licenses. I've had one that thought the ASL 2.0 left you wide-open to patent trolls because you gave up all of your patent rights. I've had another that thought we could simply stop redistributing GPL software and have no further obligation to provide a way to get our modifications to the source. Especially for someone who went to law school, it seems as thought most of the lawyers I've worked with haven't read the license text, but simply heard this and that about the licenses. Is this common among Silicon Valley lawyers, or have I just had bad lawyers? I'm sure there's a lot more to law in Silicon Valley than this, but this is even with the person they refer me to for open source license questions.


Not excusing shoddy lawyering but here are some thoughts:

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.


The combination of headers, ripped images, scroll jacking, and that it is posted from the source give this article a very blog spammy feel, optimized for that exact google search.


Thanks for the feedback. Honestly not optimised for anything other than trying to attempt a complete answer to a question we often get asked and see asked time and time again in the press, albeit usually answered in hyperbolic terms, i.e. "lawyers should never code" or "all lawyers should code", neither of which we agree with.

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.


Scrolling is horrible when using a trackpad like on a Macbook


You could have cut that sentence down to the first three words and I still would have wholeheartedly agreed with you. There is no justification for that design choice, in any circumstance.


This is good to know. We use mac and PC, plus a bunch of different mobile devices. Will do some debugging and UX testing! Thanks


Holy crap, what is wrong with the scrolling on this site? It makes it super hard to read the article.


I'm guessing it's related to the hummingbird plugin they used.


Maybe it’s his code. :)


It depends on the situation. If one is a lawyer who wants new skill sets and perhaps even a career change, an absolute yes. I did this transition seven years ago and left law entirely. I've met a handful of other interesting ex-lawyers who have made the switch from law to software and have been satisfied with the choice.

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've thought about moving from law to software more than a few times. I like being a lawyer but software is an unscratched itch. I've noticed that many people who leave law eventually come back. What made you return?


It has a bit to do with the type of work arrangement I want for this phase in my life -- nearing 40 and splitting my time between two geographic locations where active computer time all the time becomes challenging.

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.


Interesting thanks. Sounds like we are at a similar stage and have similar circumstances. Being a lawyer is working for me too for the same reasons, so I'll ride this track for a little longer.


As a corporate lawyer that transitioned to software engineering, I'd say lawyers need to learn to code about just as much as everyone else.

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.


I'm a lawyer who can code. Here's how I have used that skill:

* 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.


Against: in my romantic view after watching way too much 'Suits', being a lawyer is mostly about convincing the other party to settle. By becoming a coder instead you may end up becoming nerdified and hence less capable of making the other side settle. The lawyer I used is a very bald old man who wears suits and is generally speaking a little bit intimidating. He knows a bit about law and a bit about humanity. He doesn't use computers other than to check his email and write documents in word. And he did his thing and convinced my boss that he'd better pay up if he wants to get rid of me.

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.


Software is full of almost lawyers who left law because they couldn't handle how irrational the law is.


A few of us lawyers left the tech-grind because they couldn't handle how irrational software development is.


NO. They should have a good mental model of computing and they probably should learn tools that would aid them in data analysis (Excel is phenomenal for that). Apart from that, there is little benefit in knowing how to program in C# or Java or Python.


I am thinking about doing JD after MBA (with CS & ML degrees already). The environment got really bad for developers, all kinds of fraudsters zeroed in as tech is making more money than finance these days and startups weaponize legal illiteracy against their own early employees. I woke up from the "all will be good" illusion and realized one has to be well-versed in legal matters these days in addition to be a top tech person. I guess it's going to be valuable for a JD to have some algorithmic skills as their own field is now changing and resembles early badly run algorithms in a need of bugfixes.


Do you enjoy history? Your first year classes will be like taking history lessons from caselaw. If it's remotely close to "yes I like it" and if you can do it without going into debt then go for it.


Yeah, I am aware of that :-/ OTOH it could be refreshing to focus on something completely different than hunting the latest Deep Learning papers and figuring out if they work on the problems I am trying to solve... I still hope there will be some accredited online JD program by the time I get to do that to save time and money.


There's nothing more remote from those papers than reading about the Rule in Shelley's Case and various archaic English Court opinions dealing with pirates, matey. You won't like years 1-2.5 if you don't like English history. OTOH if you're in the English speaking world you'll learn stuff you'll never use in a law practice that you'll never forget and cherish the rest of your life. Enjoy! But FFS do not I repeat do not go into debt for it. Marrying rich is an option for some.


Ditto on not going into debt for law school!

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.


Probably better to just get better at using office products.

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.

Learning a bit of javascript, perl, python, etc. isn't going to be much use for a neophyte coder in an office full of Word, PPT, PDF, or visio documents.


I disagree* to lawyers learning to code. With the asterisk because I think there are aspects of Computer Science they would benefit from.

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 [1] 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.

[1] https://research.csc.ncsu.edu/arglab/projects/augmented-grap...


Does anyone have any thoughts on heterodox ways to go the other direction? I'm a software engineer with an interest in the law and I always wondered what sorts of opportunities there were for someone like me.

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?


Some big firms have electronic discovery departments (and there are vendors in that space too).

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.


Real question: should they be trained in formal logic? Should everyone be trained in formal logic? (I think so, anyway)


Lawyers are generally trained in formal logic and in Canada is necessary knowledge for them to enter law school.

Source: Sister was studying the Canadian LSAT.


Unfortunately there is little use for formal logic in the practice of law.


Should anyone not learn to code?


It's probably a useful skill even at a relatively superficial level for a lot of people. But there are an awful lot of useful skills out there and people have differing interests, aptitudes, and needs. So I don't buy the idea that everyone should learn to code.


You learn a lot of mental skills from coding. I believe we should teach it really young, at least a simple scripting language. Sometime around Junior High, it can even be an elective, like band. I thought I didn't have any creative skills because I couldn't draw or play music, but I have the most creative skill of all, being able to build useful tools out of thin air.

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.


I think one would benefit from coding regardless what one perceive "coding" is. On one end of the spectrum, it can be treated as a vehicle for abstract thinking. On the other end as getting things done quickly.

Well.. just like math


Given the ubiquity of programmable machines in engineering, commerce and art, I think algorithms and basic (not BASIC) programming should be taught at all levels of public education.

We teach math. We teach wood/metalshop and arts and crafts. Programming is right in there.


If you had an infinite amount of time to learn, then there is pretty much no reason not to. But the time we can devote to learning something is finite, and you have to consider if learning coding is going to detract you from being better in your core competencies.

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.


When I was growing up the general assumption was that you'd have to program the computer in order to use it. Learning BASIC was touted as a new household skill like setting the time on the VCR. That never really happened because of advancements in usability and design.

Tl;dr no


In Composing Contracts[0], Peyton Jones, Eber and Seward describe a framework for "programming" financial contracts, even allowing for external events[1] to influence the result (for example, actual stock prices) of the contract.

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.

[0] https://www.cs.tufts.edu/~nr/cs257/archive/simon-peyton-jone...

[1] In the case of laws, external events could be the judge's opinion, for example


> General Intelligence > Lawyers are generally very bright. Law is a tough degree > and a tougher profession. It rewards intellectualism, > continual learning, and adaptability. These are all > traits necessary for learning to code.

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.


This is a good piece. I don't believe (I'm probably mistaken) it's a US take. But it's still good. I came through it from the other side and used software royalties to pay my way through law school. I didn't have a CS or engineering degree and that ruled out practicing before the Federal patent bar: Make sure you realize this if you start taking law school classes, you need the undergrad engrg or CS degree in the US to sit for that exam and practice before the bar in that specialty. My geekdom precedes most CS major offerings and all but a handful of computer engineering offerings.

Other observations- - 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


I'm a lawyer turned software engineer and I'm amazed at how much the two jobs have in common. Not the technical stuff, obviously, but in the mental tools that I use on the job - like understanding complex systems and its nuances and failure points, thinking through the cascading implications of changes, weighing tradeoffs, communicating complex topics to non-experts, writing clearly, etc.


Same. Five years as a federal patent litigator and I'm shocked how much of the soft skills, and thought processes apply in my new life as an engineer.


Make sure you realize this if you start taking law school classes, you need the undergrad engrg or CS degree in the US to sit for that exam and practice before the bar in that specialty.

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.


> 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!

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.


Patent law is still a good track. But you have to know your stuff. Emerging companies that require good IP still pay top dollar for patents.


Glad you enjoyed it! You're spot on: it's a UK take (the authors are based in the UK but work with lawyers from all over), but intended to generalise to most legal systems.

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...


For a first experiment I think you have a winner. It does a great job analogizing routine contract drafting to scripting. I'd give that article to a coder that's not sure about facing seemingly unfamiliar concepts in a different setting, for reassurance. Keep up the great work. I will look for your other submissions as you post them here.


Thanks for the feedback and that's a great idea! Will have to run it by some pure dev contacts.


8k billable hours per year = 153 hours per week. Not even Elon Musk works that much.


You are indeed correct. Nevertheless that's the way it is for new grads - 1st and 2nd yr fresh out of law school - at high end medium and large firms that are sort of like pyramid schemes. The associate newbies need to generate those billables (are those realtime hours? I never checked. Does the client check?). The partners get their cut from those billables. Periodically the herd is winnowed to make room for those with more energy.


You are indeed correct. Nevertheless that's the way it is for new grads - 1st and 2nd yr fresh out of law school - at high end medium and large firms that are sort of like pyramid schemes.

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.


> 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.

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.


If you work for 36 minutes and bill for an hour, you can bill five hours for every three hours of work. You just have to switch clients every 36 minutes.


That is billing fraud.

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.


it's easy if you eat/sleep 2.14 hours daily and work every other second of the day


> ...book 8K billable hours per year...

How does that actually work?


If you have some 100hrs of paperwork to do, you can get 25 associates/paralegals/whatever to work for four hours each and have it done by end of day. That's still 100 billable hours.


from what I’ve seen not every hour is 1:1. 15, and 30 minute tasks are billed at an hour. And projects handled that take special expertise can be billed with a multiplier. So reading and summarizing some document for 2.5 hours might turn in to being billed for 12


That is considered billing fraud. Lawyers are not allowed to apply "multipliers" to time billed to the client if they are billing hourly...unless they are using the multipliers to reduce the time billed. I.e., administrative work is billed at 0.25x of normal rates.


Any legaltech startups that you like?


One posted here on HN about to offer bankruptcy services. One of the problems with that besides them not having Florida counsel is that the consumer bankruptcy market's been in a race to the bottom after BAPCPA passed (something like 2007 or 8 I forget). Between petition prepares acting as pseudo attorneys and actual law firms bifurcating their services in what used to be an impermissible way (small amount pre-filing, more "optionally" on installments after filing but immediately before meeting of creditors) the only feasible bankruptcy practice is one that's willing to litigate creditors in bankruptcy court on non-bankruptcy matters, one that has the stick toitiveness to seek appointment by the court to recover exemplary damages for the estate - provided there's a cut for the client - and there aren't bankruptcy courts everywhere. The firm has to be < 15 minutes from the courthouse or the clerk will so screw up your schedule you'll never be able to attend creditor meetings, hearings, and meet with clients.

Were there other startups you had in mind, or could link me to?



This is a really good overview of the legaltech start-up ecosystem as it is today. Slightly European focus, but increasingly global: https://www.legalgeek.co/startup-map/

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.


I feel it's unfair that we have to jump through all kinds of cartel like processes to get accreditation to lawyer it up while lawyers only need google to learn how to code.

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.


Some other questions, and a purely subjective ones at that:

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?


Compared to getting an engineering degree, law school was easy (time consuming but otherwise untaxing). The hardest part for some people was learning to think like a lawyer.

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.


1. Law is far more stressful from a business standpoint. Because of the business pressures I'd only go back into practice as corporate counsel or now that I've learned about it, as a patent litigator, but I'm too late for that game maybe

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 would argue law is harder and much more stressful. The sheer amount of knowledge needed to critically think on your feet in an instant is paramount to a lawyers success. There’s an incredible amount of time put into research and formulating arguments on the fly with a huge requirement for all types of memory in all kinds of scenarios.

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.


Yes, so they can automate 90% of their function.


An old roommate of mine who has knowledge in both created https://free.law/ to help address the lack of availability of public court records for free (apparently the fees charged by the gov't may be illegal).

Not mine but definitely an interesting resource for lawyers/coders.


I'm a law professor who has taught some basic coding (along with stats) to law students[1], I have a slightly different perspective on the lawyers learning to code thing than a lot of what has been expressed here (though it's similar to the "Dr. Doolittle" idea in the post).

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.

[1] version 0.1 of the course: https://sociologicalgobbledygook.com


I feel like Software Eningeering and Contract Law have many parallels and similarities. What does a contract and a codebase have in common? 90% of the content is covering bizarre edge cases and eventualities.


This is probably the best place to ask with talk of macros for generating documents.

Does anyone have a preferred method for generating Word documents that is better than mailmerge?


Most legal doc generation tools spit out Word's mangled version of HTML, but with a .doc file extension.

OpenXML or OpenDocument is the more robust way to go.


Should they? Wouldn't they legalese the profession the same way that politicians would politicise it?


No, because none of their conditionals would be truthy.


Whatever happened to division of labour?


A lot of lawyers would quit being lawyers if they could code




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: