As I’m finishing up my final job placement course at the Tech Academy this week, I’ve had to step back and rethink how I write my materials for tech v. law jobs. Over the years, my resume has gone through countless revisions to forge a particular identity from my prior careers as a lawyer and diversity professional. But now that I’ve made the leap to a new industry, I’m trying to find that sweet spot between the two extremes of completely abandoning my past experience and completely overselling it to companies. And that, quite frankly, feels really sucky sometimes.
I worry whether I come off as full of BS or totally unfocused just because I still include my non-tech experience in my resume. But I really do believe that the type of work that I’ve done outside of tech strongly parallel the type of work that I eventually will do as a software engineer. But of course, the proof is in the pudding. So what are some of the similarities I’ve observed between my non-tech and tech skills? I’ve highlighted three particular ones below.
- Using a technical language to instruct an entity how to operate. I spent a lot of time as a lawyer drafting settlement agreements, trust amendments, and other kinds of contracts. Exciting stuff, I know. But if you peel back the layers of legalese, writing contracts is basically like coding a program (including the constant struggles we lawyers face with how “strongly-typed” our legal code is within a contract). Some examples:
- In software, you create a program that instructs a computer to perform particular tasks. In law, you create a contract that instructs one or more persons or entities to perform particular tasks.
- In software, you create classes and objects that have specific properties within the context of a program. In law, you create definitions that have specific meaning within the context of a contract.
- In software, you can define a function and reuse it by calling the function name, rather than copying and pasting the same code elsewhere. In law, you can draft a term and reuse it by citing the term’s location in the contract, rather than copying and pasting the same term elsewhere.
- In software, you rely on preexisting code libraries to provide essential functionality to your program without reinventing the wheel. In law, you rely on preexisting boilerplate language to provide essential functionality to your contract without reinventing the wheel.
- Client-focused design and work product. Like tech, law is a customer-service industry, whether in the form of providing discrete products (drafting contracts, corporate documents, pleadings, etc.) or ongoing services (advising clients of the legal and practical consequences of their actions). A successful programmer or lawyer is ultimately designing something useful to a client that meets their stated (and unstated) needs. That means communicating what technical work you’ve done to a form that a layperson can understand and appreciate, making and understanding the trade-offs in choosing one way to implement a solution to a problem, and proactively working with the client to identify new or emerging needs that they may not have considered when they initially retained your company.
- Understanding life cycles and hard and soft deadlines. No, I’m not going to tell you that lawyers use Agile or Scrum, or that a law firm can reboot your litigation strategy in the middle of a trial, but law and tech do share a common appreciation of deadlines. In tech, missing a deadline can mean missed opportunity cost. In law, missing a deadline can mean you’ve lost your case and exposed yourself to malpractice liability. It’s useful to think of the final product release in tech or the resolution of a case in law as the end of a marathon. Within that larger race are the numerous deadlines for smaller, incremental deliverables that are still necessary to get you to that final finish line. In tech, that may be building an additional feature of a product. In law, it could be successfully defending a motion for summary judgment. Some of the deadlines for these deliverables can be extended or pushed out of necessity, while others are “drop-dead” dates, with no exceptions. Being a successful programmer or a successful lawyer, especially in a team environment, therefore requires you to understand the importance of deadlines both in the instance sense and as part of the big picture. In other words, keep mind of the proverbial trees and the forest.
I can think of more parallels between law and tech (as well as some interesting differences!), but I feel that it’s particularly important to convey the similarities in these three areas when applying to companies here in Portland. I hope that potential employers will feel the same!