somewhat agree that it's a tough topic to start with, but regexes are one of the few things that can be immediately applied. a lot of the practice of law (esp. early in your career) is pretty mundane and repetitive stuff. couple that with attorneys love of OCR, you get a lot of copy/paste/hours of editing workflow that can easily be solved by a quick find and replace with a handful of regular expressions. (you could also argue that the root cause e.g., storage mechanism, should be changed, but often times that is a nonstarter or at least heavily resisted)
edit: also, a lot of services like westlaw/lexis have a very rudimentary type of regex searching capacity (i think just * and some connectors) so it's not 100% foreign to many lawyers
to be honest though, most attorneys need training in basic desktop publishing software to start with. i've seen things done in microsoft word that no man or woman should ever have to see.
I would actually vote version control as chapter 1 of Coding for Lawyers. Also not "coding" per se, but immensely important - anything to get past "importantdocument.version.13.3.barkingcat.doc" hell.
I sent a pull request with a chapter on diffs[1]. They're important in their own right, but also as a good precursor to the inevitable git/github/version control chapter[2].
The end note is just a legal in-joke which could be paraphrased as: 'because I say so, so there!', but he does give good reasons in the first paragraph (and the legal profession would not have to be persuaded of the usefulness of more powerful automated search).
Regex is not necessarily the best intro to coding, but for a lawyer, it will animate much of what follows by quickly delivering value. At least in my practice, we'll commonly encounter terabyte-sized productions of data during litigation, and the search tools are just awful. For folks in litigation, the power of regex, once past the learning curve, will quickly provide value and might motivate them to dig deeper.
If anything, this list of topics is not law-specific enough. I'd suggest a tutorial on the format of doc production of load files, tesseract, and pdf-manipulation tools for those dealing with doc productions. And a tutorial on relational databases would be very useful for those lawyers drafting discovery requests trying to extract "documents" from ERP systems.
Seeing DRY at the end there was amusing. I recently worked with a client who convinced me he was really interested in our web project's back-end. Normally I keep things really light, but this guy had a convincing air of tech-savvy about him.
Toward the end of the project, he wanted to do a lot of copy/paste-style "reuse" within the content management portion of the project, so I showed him how he could take advantage of the de-duplication features, and explained what DRY meant--just in terms of content management.
The next day I got an email about a bug he found, where a sidebar wasn't showing up properly or something like that.
His conclusion at the end of the email read:
"So this DRY thing doesn't seem to be working, can we please remove DRY?"
(I know, it's my fault for exposing the innocent client to such heavy terminology, blah blah blah...but I had a very pleasurable laugh about the whole thing)
That's an interesting story. I know a guy who's a senior developer - probably makes $190k a year. He just codes copy-paste. I think he makes a lot because he puts out products really fast, and clients are really impressed. But, he completely ignores any maintenance. He just hands off the code to some other poor souls who have to maintain it. And, then they look bad, because what used to take hours now takes weeks.
DRY is good when you care about maintenance or design, but to those who don't understand or care about maintenance, it just looks like added complexity.
Or, in other words, a lot more people would rather buy a junky watch with a fashionable aesthetics than a simple-looking watch with impeccable internals.
I'm not the author (but I know him and he doesn't have an HN account--I've also contributed a chapter currently awaiting as a PR). PRs are certainly welcome.
This project immediately won my heart by starting off with regular expressions. It amazes me how many coders flip out at the suggestion of teaching/advocating regexes to novices, as if the first thing a novice will attempt to do is parse HTML with regex or build a credit card validation application.
I've spent most of my life in the journalism world, and I imagine parts of it, especially the investigative projects time, share some characteristics with the law world...in that you're dealing with messy documents and data. You would not f--king believe how much time is wasted on manually reading lists of names/addresses, because the person has no idea how to split "Smith, Bob -- 1020 Broadway, NY" into a spreadsheet. Nevermind the countless hours spent hand fixing whitespace or other formatting errors, things that could take seconds with even just Sublime Text.
Regexes are amazing because they teach people how to think in patterns, and that manually defining the pattern for your specific domain can be a very powerful thing. I've greatly increased the speed that I can research things across large document sets...simply by grepping documents for patterns that fit proper nouns, or even large money values (for example, /(?:\d{3},){2,}/)...when dealing with messily OCR'ed documents, in which phrases/words will have common mistranslations, being able to grep in order to find a key name/number/noun is incredibly powerful.
IMO, regex is exactly the first thing you should be teaching people like lawyers and researchers. It's a very powerful programming concept, but besides that, it is immediately useful to anyone who can use a text editor. And it opens the door to programming in general (because find-and-replace with a text editor gets old, you'll soon find the need to run grep from the CLI)
This guys is a laywer, with a mechanical engineering degree, and does coding on the side.
He was also the guy who wrote the SCOTUS opinion tracking software that was all over HN a few months ago.
Seems like a cool guy, and unlike some posters I think regex are definitely something to start people off on.
Many people who are non-technical but have used a computer understand the concept of a wildcard operator, you just expand that knowledge a bit and they can do very powerful things if their jobs involves a large amount of text.
I had some realtors that I worked with, and after seeing me fly through some of the things they did, they were eager for me to teach a bit about regex (and gave them a simple simulator to give them instant matches, I think it was rubular at the time) and they wrote some simple rules to take like 10 hours of drudgery out of their jobs per week.
Most lawyers understand the concept of a regex, so I'd agree that its a good place to start. Law students are taught how to search for caselaw using Terms and Connectors, which is a simplified form of regex: http://lscontent.westlaw.com/images/content/WLNT&CSearching....
So they already have a lot of familiarity with the topic, and this just makes it easy for them to understand that coding is not so foreign as they might otherwise believe.
Having been to law school in the last 3 years (would have taken the bar 2 months ago had I finished), you are overestimating how many law students actually learn how to perform Westlaw/Lexis searches like that. You only really need to use them in a few select classes, and no one really attends anything more than the mandatory trainings (which cover things like how to log in).
So many coding lessons are so irrelevant to business / law people. No, business people don't need to really learn how to code. They want to learn how to parse / clean messy spreadsheet data.
REGEX + basic loops and conditional in VBA will do wonders to the productivity of business people.
On a separate note, I am surprized that there is still no good graphical way to build regexes
I like the idea of niching down for a use case, but I've never met a lawyer I thought had the time or energy to devote to learning programming. I'm also having trouble understanding how a lawyer might use their programming skill to improve their daily lives. It seems to me that other folks on a lawyer's staff would be more likely to be interested in this subject and use it to the firm's benefit.
Check out https://permafrast.herokuapp.com. OP built this as well, and it makes it really easy to read cases without signing into Lexis, Westlaw, or, well ... anything.
Just one of many examples of how lawyers can use tech to make their day jobs easier.
Programming is like cooking. You don't have to know it, but it comes in handy and you can impress your friends with it. Just don't thing you can open a restaurant just because you make a great risotto.
There are lots of things you can use code for as a lawyer, if you just think about it as "automating stuff." I wrote custom code all the time when I was at the law firm (and still do, but I'm in a more technical role now).
It was fun to take something where hordes of associates were being used as slightly smarter computers and automate it - there were several times when people were amazed that I turned out a properly formatted in-depth diligence report about multi-hundred-patent portfolios within a couple of days.
Lawyers don't necessarily need to code to improve their own lives - but they MUST learn to code to improve their relationships with their clients.
If there is any aspect of programming involved in any contract or lawsuit (which is becoming the norm), the lawyer absolutely must have at least a vague grasp of the tech to be effective.
Too many lawyers and judges are just utterly perplexed, and it leads to bad law that makes things more difficult for everyone down the road.
Even the most basic understanding of programming would be so so helpful, if only because it makes the world of computers slightly less alien to your average legal practitioner.
I'm negotiating a contract with a software subcontractor and I had to involve our legal department. The lawyer I'm dealing with quite clearly understands software (speaks knowledgeably about OSS, although I don't remember if he's actually a programmer), but I can't think of a single case where programming knowledge would have been useful. Instead, I'm the outsider, because everything that comes up for discussion is an issue of Contract Law and nothing specific to Software.
That's a good idea , but it could be greatly improved by offering lawyers(which are surely time strapped) , a tool like RegexMagic[1] , which really simplifies the learning needed and lets one easily understand complex regex's.
I don't think the point is to offer them a tool, the point is to offer them the option of some coding education designed specifically for their background. Agreed that the tool you mentioned is probably more useful to more lawyers, I just think this is targeting a segment looking to go beyond a tool that does the work for them
I'm intrigued by the parallels between software engineering (scripting, really) and legal work.
In a sense, a legal agreement seems like a cross-platform piece of software that is "executed" in the minds of the signing parties, their business associates, and occasionally the court system. Given that context, I'm a little surprised that lawyers and engineers tend to communicate and think so differently.
[0-9]{1,2} U\.S\.\C. § \d+(\w+)?( \([0-9]{4}\))?
Should probably be:
[0-9]{1,2} U\.S\.C\. § \d+(\w+)?( \([0-9]{4}\))?
\C. -> C\.
Great work! The line between computer user and computer programmer needs to be blurred. Many people who use computers would benefit from knowing a little programming. Just look at how useful Excel is.
I haven't gone through this yet, but I have a liberal arts degree and did a year of law school before dropping out to work on the internet. I'm competent in HTML/CSS, basically competent with Rails (have built very rudimentary web apps), but working full time in online marketing.
If this is actually an intro to coding for lawyers, it's an intro to programming for those with no technical background whatsoever. Which is really cool (not that those don't exist, but specifically designing this for a career path full of liberal arts types, not just for those with no experience, is interesting). I like that they start with regex and HTML/markdown, since, while they are not what anyone would call software development, they are a simple, quickly useful example of the basic concept of coding - expressing human instructions in a language designed to be understood by a machine. They also are some of the more quickly usable "coding" concepts, HTML & Markdown in the obvious cases, but regex familiarity makes Google Analytics much more powerful.
Looking forward to working through it and seeing what it's like. I sent it on to a few law school friends who had been somewhat interested in tech skills too.
46 comments
[ 4.8 ms ] story [ 105 ms ] thread/compiler geek
If the author is reading this:
WHY? out of all the horrors, why?
Maybe try reading a thing before breaking out the multi-punctuation and caps? ;)
edit: also, a lot of services like westlaw/lexis have a very rudimentary type of regex searching capacity (i think just * and some connectors) so it's not 100% foreign to many lawyers
to be honest though, most attorneys need training in basic desktop publishing software to start with. i've seen things done in microsoft word that no man or woman should ever have to see.
[1] (https://github.com/vzvenyach/codingforlawyers/pull/10) [2] https://github.com/vzvenyach/codingforlawyers/issues/5
He lost me at REGEX in the title... it gives me an allergic rash
If anything, this list of topics is not law-specific enough. I'd suggest a tutorial on the format of doc production of load files, tesseract, and pdf-manipulation tools for those dealing with doc productions. And a tutorial on relational databases would be very useful for those lawyers drafting discovery requests trying to extract "documents" from ERP systems.
Toward the end of the project, he wanted to do a lot of copy/paste-style "reuse" within the content management portion of the project, so I showed him how he could take advantage of the de-duplication features, and explained what DRY meant--just in terms of content management.
The next day I got an email about a bug he found, where a sidebar wasn't showing up properly or something like that.
His conclusion at the end of the email read:
"So this DRY thing doesn't seem to be working, can we please remove DRY?"
(I know, it's my fault for exposing the innocent client to such heavy terminology, blah blah blah...but I had a very pleasurable laugh about the whole thing)
DRY is good when you care about maintenance or design, but to those who don't understand or care about maintenance, it just looks like added complexity.
Or, in other words, a lot more people would rather buy a junky watch with a fashionable aesthetics than a simple-looking watch with impeccable internals.
Law Flow Charts: http://www.margarethagan.com/drawings/illustrated-law-flow-c...
Law Cases: http://www.margarethagan.com/drawings/drawn-law-cases/
From Chapter 3, Exhibit 6:
I've spent most of my life in the journalism world, and I imagine parts of it, especially the investigative projects time, share some characteristics with the law world...in that you're dealing with messy documents and data. You would not f--king believe how much time is wasted on manually reading lists of names/addresses, because the person has no idea how to split "Smith, Bob -- 1020 Broadway, NY" into a spreadsheet. Nevermind the countless hours spent hand fixing whitespace or other formatting errors, things that could take seconds with even just Sublime Text.
Regexes are amazing because they teach people how to think in patterns, and that manually defining the pattern for your specific domain can be a very powerful thing. I've greatly increased the speed that I can research things across large document sets...simply by grepping documents for patterns that fit proper nouns, or even large money values (for example, /(?:\d{3},){2,}/)...when dealing with messily OCR'ed documents, in which phrases/words will have common mistranslations, being able to grep in order to find a key name/number/noun is incredibly powerful.
IMO, regex is exactly the first thing you should be teaching people like lawyers and researchers. It's a very powerful programming concept, but besides that, it is immediately useful to anyone who can use a text editor. And it opens the door to programming in general (because find-and-replace with a text editor gets old, you'll soon find the need to run grep from the CLI)
He was also the guy who wrote the SCOTUS opinion tracking software that was all over HN a few months ago.
Seems like a cool guy, and unlike some posters I think regex are definitely something to start people off on.
Many people who are non-technical but have used a computer understand the concept of a wildcard operator, you just expand that knowledge a bit and they can do very powerful things if their jobs involves a large amount of text.
I had some realtors that I worked with, and after seeing me fly through some of the things they did, they were eager for me to teach a bit about regex (and gave them a simple simulator to give them instant matches, I think it was rubular at the time) and they wrote some simple rules to take like 10 hours of drudgery out of their jobs per week.
So they already have a lot of familiarity with the topic, and this just makes it easy for them to understand that coding is not so foreign as they might otherwise believe.
So many coding lessons are so irrelevant to business / law people. No, business people don't need to really learn how to code. They want to learn how to parse / clean messy spreadsheet data.
REGEX + basic loops and conditional in VBA will do wonders to the productivity of business people.
On a separate note, I am surprized that there is still no good graphical way to build regexes
Just one of many examples of how lawyers can use tech to make their day jobs easier.
It was fun to take something where hordes of associates were being used as slightly smarter computers and automate it - there were several times when people were amazed that I turned out a properly formatted in-depth diligence report about multi-hundred-patent portfolios within a couple of days.
In my spare time, I built a natural language processing + graph analysis tool to help look for patent prior art. I spoke about it at PyCon - see <http://pyvideo.org/video/425/pycon-2011--how-to-kill-a-paten....
Right now I use an internal Github instance to manage CCLAs at Rackspace, and its just a matter of time until I automate some more stuff here.
If there is any aspect of programming involved in any contract or lawsuit (which is becoming the norm), the lawyer absolutely must have at least a vague grasp of the tech to be effective. Too many lawyers and judges are just utterly perplexed, and it leads to bad law that makes things more difficult for everyone down the road.
Even the most basic understanding of programming would be so so helpful, if only because it makes the world of computers slightly less alien to your average legal practitioner.
I'm negotiating a contract with a software subcontractor and I had to involve our legal department. The lawyer I'm dealing with quite clearly understands software (speaks knowledgeably about OSS, although I don't remember if he's actually a programmer), but I can't think of a single case where programming knowledge would have been useful. Instead, I'm the outsider, because everything that comes up for discussion is an issue of Contract Law and nothing specific to Software.
[1]http://www.regexbuddy.com/
In a sense, a legal agreement seems like a cross-platform piece of software that is "executed" in the minds of the signing parties, their business associates, and occasionally the court system. Given that context, I'm a little surprised that lawyers and engineers tend to communicate and think so differently.
[0-9]{1,2} U\.S\.\C. § \d+(\w+)?( \([0-9]{4}\))? Should probably be:
[0-9]{1,2} U\.S\.C\. § \d+(\w+)?( \([0-9]{4}\))?
\C. -> C\.
Great work! The line between computer user and computer programmer needs to be blurred. Many people who use computers would benefit from knowing a little programming. Just look at how useful Excel is.
If this is actually an intro to coding for lawyers, it's an intro to programming for those with no technical background whatsoever. Which is really cool (not that those don't exist, but specifically designing this for a career path full of liberal arts types, not just for those with no experience, is interesting). I like that they start with regex and HTML/markdown, since, while they are not what anyone would call software development, they are a simple, quickly useful example of the basic concept of coding - expressing human instructions in a language designed to be understood by a machine. They also are some of the more quickly usable "coding" concepts, HTML & Markdown in the obvious cases, but regex familiarity makes Google Analytics much more powerful.
Looking forward to working through it and seeing what it's like. I sent it on to a few law school friends who had been somewhat interested in tech skills too.