What is a recommended accelerated developer program like hackbright but for everyone(not just women)?
The Disruption Institute has a mobile development program http://www.disruptioninstitute.com
From Lawyer to Programmer
31–40 of 44 posts
Re: From Lawyer to Programmer
#32The article states "law is perhaps the only field where being a pessimist is actually an advantage", but I actually find this is an attribute that programmers and lawyers share. In developing code, one is always trying to think of all the possible inputs and outputs includes the unintended corner cases in order to write robust code. I would say the two professions are more alike than credit is given, and working as a…
I think programming is a bit more rewarding in this special case as you can preempt the outcome with unit tests ;)
Unit tests are merely approximations of what challenges you can imagine your application will need to face. An analogy can be drawn to the body of precedent in case law.
Re: From Lawyer to Programmer
#33"I had considered only my ambition and values, without stopping to think in an honest, meaningful way about what would make me happy on a day-to-day basis"
Sad thing is, most people don't think about what makes them happy. They simply try to live up to societal norms & expectations.
Here's one of my favorite quotes from John Lennon:
"When I was 5 years old, my mother always told me that happiness was the key to life. When I went to school, they asked me what I wanted to be when I grew up. I wrote down ‘happy’. They told me I didn’t understand the assignment, and I told them they didn’t understand life."
Re: From Lawyer to Programmer
#34Earlier quoted context omitted.
The thinking process behind both are very similar indeed. At the core of both is true problem solving. You are given a set of constraints and facts, and you have to apply some set of rules (man made laws, or algorithms) in order to take the input and create a result that you want. I think it is for this reason that many on HN enjoy discussing the law (of course it does have many other practical consequences as well).…
"You are given a set of constraints and facts, and you have to apply some set of rules (man made laws, or algorithms) in order to take the input and create a result that you want." I'm a programmer and I have a law degree, but I don't quite agree with your assessment. Practicing law (as opposed to the study of it) isn't usually about applying the law to facts; most of the time, it's representing the facts in a way th…
See, I found Orin Kerr's piece to be incredibly uninformed (as to the specifics of the case) because he literally wrote it by taking the complaint at full face value - this was despite the entire controversy being about whether there were facts to support allegations that Aaron was trespassing, broke and entered, stole property, etc...
but that's another topic, it was as you said at least more informed than the average person (but disappointing for a law professor and former CAFA prosecutor/defender).
and just to add to this conversation, I will have my law degree in a month and I'm just now starting to learn programming. I plan to use it in conjunction with things like Latex for building better briefs, building a robust issue bank, etc... - things that will enable me to be a better lawyer in practice.
Re: From Lawyer to Programmer
#35The "Law School changes how you think" line seems to be a popular one, but I'm not sure I buy the premise that it's inherently different. Anyone know of studies done to compare neurological effects between fields of study? I wonder if she'll feel the same about coding after finishing hackbright.
> The "Law School changes how you think" line seems to be a popular one, but I'm not sure I buy the premise that it's inherently different. I've done both. Law teaches how to bring rigour to fuzziness. In software we can set boundaries and push the fuzziness back into the problem domain. Lawyers can't do that, they must address the world as it is. Let me explain what I mean. Suppose you use constants with values for…
Very well and succinctly put.
At the top of the list I'd put "the learned ability to do that with buckets of documents, quickly, and then having to draft reasonably straightforward briefs or case notes."
One's goggles in going through the rooms of buckets of documents are tuned to those "fuzzy sets" of legal issues. An ancient lawyer once said that lawyering is the art of finding the relevant.
Or as Edmund Burke put it: "Law sharpens the mind, by narrowing it."
Re: From Lawyer to Programmer
#36Earlier quoted context omitted.
"You are given a set of constraints and facts, and you have to apply some set of rules (man made laws, or algorithms) in order to take the input and create a result that you want." I'm a programmer and I have a law degree, but I don't quite agree with your assessment. Practicing law (as opposed to the study of it) isn't usually about applying the law to facts; most of the time, it's representing the facts in a way th…
See, I found Orin Kerr's piece to be incredibly uninformed (as to the specifics of the case) because he literally wrote it by taking the complaint at full face value - this was despite the entire controversy being about whether there were facts to support allegations that Aaron was trespassing, broke and entered, stole property, etc... but that's another topic, it was as you said at least more informed than the avera…
Latex for briefs? Ah, the idealism of youth. (I was going to revolutionize legal research through artificial intelligence) Most lawyers don't have the time, and almost every court I practiced in had rules specifying a utilitarian uniformity that made fancy formatting superfluous.
Re: From Lawyer to Programmer
#37I quit teaching very recently (I have a Masters in English) to pursue programming as well. In all careers you make a lot of mistakes, but with teaching, you only get another crack at the problem once a year. If you create a terrible lesson, you agonize about it, and you might not get it right the second time either.
Add to that the fact that schools are always really slow to change, requiring you to fight for anything remotely progressive (the school I was teaching in graded multiple choice entrance exams by hand); it's really easy to get sucked into the traditional educational model even if you don't believe in it; and teaching doesn't allow for the creativity I want in my life.
I suddenly realized that I wanted to be creating not evaluating — to be always learning and building on what I know. Programming does seem to offer that.
Re: From Lawyer to Programmer
#38Earlier quoted context omitted.
The thinking process behind both are very similar indeed. At the core of both is true problem solving. You are given a set of constraints and facts, and you have to apply some set of rules (man made laws, or algorithms) in order to take the input and create a result that you want. I think it is for this reason that many on HN enjoy discussing the law (of course it does have many other practical consequences as well).…
"You are given a set of constraints and facts, and you have to apply some set of rules (man made laws, or algorithms) in order to take the input and create a result that you want." I'm a programmer and I have a law degree, but I don't quite agree with your assessment. Practicing law (as opposed to the study of it) isn't usually about applying the law to facts; most of the time, it's representing the facts in a way th…
What little similarity I found between the disciplines in law school evaporated in practice. I was at a middle of the pack Biglaw firm (not exactly chasing ambulances) and very few partners could form a logical argument. Not that they needed to - threats, leverage, and obfuscation were plenty effective with emotional clients, overworked/underqualified(domain knowledge) judges, and dumb opposing counsel.
Re: From Lawyer to Programmer
#39Earlier quoted context omitted.
I think programming is a bit more rewarding in this special case as you can preempt the outcome with unit tests ;)
Unit tests are merely approximations of what challenges you can imagine your application will need to face. An analogy can be drawn to the body of precedent in case law.
Precedent only deals with regression, which is also useful to document in code, but should not be your only source of documentation.
The purpose of testing, though oft missed due to the name we have given it, is to document your code. The tests explain intent, usage, etc. that can often not be conveyed by the code alone. Verification that the documentation does what it claims comes as an added bonus, of course, and is why we recommend testing over writing comments. Though comments can also be useful in certain situations – right tool for the job and all that.
I feel like law could benefit greatly from something that mirrors TDD, not only to help convey intent of the law, which is information often lost as years pass, but also to help third-parties better understand what the law says. The exact same reasons why we write tests for code. Starting to write that documentation after the code is already in production, so to speak, seems too late.
Re: From Lawyer to Programmer
#40The "Law School changes how you think" line seems to be a popular one, but I'm not sure I buy the premise that it's inherently different. Anyone know of studies done to compare neurological effects between fields of study? I wonder if she'll feel the same about coding after finishing hackbright.
> The "Law School changes how you think" line seems to be a popular one, but I'm not sure I buy the premise that it's inherently different. I've done both. Law teaches how to bring rigour to fuzziness. In software we can set boundaries and push the fuzziness back into the problem domain. Lawyers can't do that, they must address the world as it is. Let me explain what I mean. Suppose you use constants with values for…
I apologize in advance for what will be at least a partially incorrect comment.
But don't lawyers deal with this fuzziness to some extent by putting the question to a jury? For instance, suppose we were writing a software application to decide when to shut down a machine because it got "too hot". We could go ahead and assign a specific temperature, or perhaps set up an equation with a few different readings.
Now suppose there was some litigation because a tennis player collapsed during a tournament that was "too hot". Would the lawyer define "too hot", or would the jury? You could have a situation where all parties agree on the law, and that it turns on whether it was "too hot", and the legal system would treat the jury's definition almost as definitively as a temperature reading input into an algorithm, right?