/etc

I get a lot of questions about my transition from a career as a lawyer to being a software developer, so I thought I'd collect that story here and answer a few of the related questions.

My story

I graduated from college with a philosophy degree in 2009. Like a typical philosophy major, I gave very little thought to my future career or need to feed myself after college until pretty shortly before graduation. I learned that philosophy was a classic track to law, and figured I would start looking into what it was like to actually practice law.

After I graduated, I got a job as a paralegal in a small litigation law firm, and was delighted and encouraged to find that I was really good at law! Philosophy had trained me to think and write carefully, and I saw that those skills translated very well to a legitimate career in which I could be successful.

After a year of working as a paralegal, I started going to law school in the evenings while continuing to work days in the law firm. After 4 years of this, I graduated law school and made a pretty easy transition from a paralegal role to an associate attorney role at the firm I had worked at for a couple years already.

It didn't take too many years as a lawyer to realize that while I could be really good at practicing law, I really didn't want to. And while the day-to-day work was fine, I had good work-life-balance, and loved my coworkers, the thought of spending 30 more years at this was pretty soul-crushing.

I had taken some computer science classes in high school, and had kept up dabbling in software as a hobby for many years. I was surprised to learn, at some point, how open the software industry is to anyone, regardless of their degree, who can demonstrate adequate skills.

So I spent about a year of pretty disciplined nights and weekends taking some online courses and building a portfolio to try to change careers into software.

Then in March 2020, after 5 years of practicing law, and 10 years in the legal industry, I got a job as a junior full stack web developer, and loved it!

What was so bad about law?

The practice of law is a good and noble profession, and some people are very well suited to it. But, at least anecdotally, many of the lawyers that I met during my career were very smart people who couldn't think of anything better to do. So they got into law, something they could excel in, and mostly take pleasure, not in the work itself, but the satisfaction of a job well done. That just wasn't enough for me. I wanted to enjoy my work in its own right, and I could not imagine doing that in the practice of law.

Many leave the practice of law because of miserable working conditions, and that was not my case at all. I pretty much worked 40-hour weeks, I worked with really smart people who I genuinely liked, and my boss was extremely accommodating to my personal and family life. He was and remains a good friend and mentor to me.

I think the biggest thing that frustrated me about the law was the experiential futility of it. I could spend months, or years, working on a case, only for it to settle on terms that it was obvious it should settle on in the first place. It was also very common to spend months working on a legal brief, and have it be very clear that a judge did not understand (and maybe didn't even read) my brief. It is extremely frustrating to do great work, and have the right of a legal or factual argument, and still lose.

The adversarial nature of law also really took a toll on me. Living and working in a mindset where someone is always out to get me was incredibly wearing. It wasn’t so much the fighting itself - I enjoy a good argument, but the cognitive and emotional load of always being ready for a fight, and having to make sure everything you do and say is defensible. There are much easier and kinder ways to make a living than in an industry where opposing counsel routinely imputed ill motives and poor character to me on the public record.

Why software?

Magic. It's always just been so fun to take a problem, design a solution and have the tools and skills to make it work. It’s not all sunshine and roses, for sure, there are frustrations and disappointments in developing software, but day-to-day, there are problems that can be concretely fixed, and if something doesn’t work, there’s a reason (other than caprice) and a path to fixing it.

Speed. Even on an ecosystem level, when there are problems with software tooling, or patterns, there’s a path to fixing it in weeks or months. If the laws are wrong, or a judge makes a bad decision, the path to fixing it takes years (or decades). It’s just intrinsically more satisfying to work on something that is getting better at a measurable rate than explaining to people again and again how the system is broken and that all we can do is hope it gets fixed someday (I’m looking at you, patents).

Lifestyle. Although this varies widely with areas of practice in law, the schedule of a litigator, especially a junior one, to take meaningful vacation. The courts’ calendars dictate your life, and any sort of extended vacation takes month or years of planning. And there are always emergencies and client needs - I’m sure many software professionals deal with this as well, but at least in my recent roles, the odds of me waking up to 10 the-house-is-on-fire emails are pretty slim.

How, practically, did you make the transition?

I had a pretty solid foundation in the fundamentals of programming from (c++ and java) classes I took in high school. I had picked up javascript along the way when I discovered web development and how easy and fast it was to make user interfaces that solved the problems that interested me.

When I realized that I needed to get out of law, and that software was a field that was accessible to me, I spent a little over a year working on my skills and networking to get a new job.

I only took two full “courses” that I think were helpful in gaining understanding of some of the fundamentals that I either didn’t learn in high school or had forgotten.

I then worked on building up a portfolio of projects that I found interesting. I learned the technologies I needed along the way and learned them well enough to get the job done.

I networked with software developers I knew, I went to meetups, I chatted with people in slack, I just tried to get my portfolio out there enough to get some interest. It was awkward and nerve-wrecking at times, but I learned a lot through the interview process as well.

How did it go?

Great.

Working as a software developer has pretty much zero hard-skill overlap with being a lawyer, but a huge amount of soft-skill overlap. Many software jobs have relatively few very difficult engineering problems. The vast majority of what you do is communicate, plan, and organize: all skills that I developed pretty well in the practice of law. Lawyers and engineers both do a lot of talking to people to understand problems, use their specialized knowledge to design a solution to the problem, and then break that solution down into manageable sub-problems, and then work through those sub-problems, and communicate with stakeholders when problems arise.

What advice do you have for someone who wants to become a software developer as a second career?

Getting into software is a low-risk affair. It’s easy (and free) to jump in and try out. If you don’t like it, you’ve gained some valuable exposure to technologies that touch many industries, if you do, you can gain an interesting career that allows a lot of flexibility in working conditions and great compensation.

1. Learn Programming Fundamentals

A basic amount of classroom learning is pretty much a necessary prerequisite to doing anything useful. FreeCodeCamp has some really great accessible beginner resources that will give a solid foundation to build on yourself. I recommend the Responsive Web Design and Javascript Algorithms and Data Structures classes to start.

2. Build a Portfolio

Once you have some basic skills and tools at your disposal, your learning can really begin. Pick an ambitious project that is (a) useful, and (b) interesting to you. Building toy to-do list applications is neither interesting to you nor impressive to employers. Think of something you want to create, and figure out how to do it along the way. Build it once badly, then rebuild it better as you learn more. A github profile full of projects from courses is decidedly unimpressive, a portfolio of original, interesting (even funny!) projects that say something about you and your interests is far more likely to catch someone’s eye.

Maybe along the way you’ll realize that you need a database: don’t try to learn everything about databases, you will get lost and stall out. Learn enough about databases to get your application to do what you want. You’ll realize you have some complex logic that is tedious to manually test, and you’ll learn about unit testing. Don’t learn everything there is to know about test-driven-development, just learn enough about testing to be able to test that your code works as expected.

Keep building and rebuilding until you have a portfolio of 3-4 projects that you are proud of. It is unlikely that prospective employers will be impressed by the quality of the code, but a good organization looking at junior developers will be able to recognize and ability to learn and grow and figure things out. That’s what’s most important.

3. Network.

Like any job, work your network. Tap developers you know, ask them to look at your portfolio and ask them how it can be improved. Ask them to share it with their networks. I got my first job by sharing my portfolio on a local slack group full of tech professionals in the area.

4. Be Flexible

Keep in mind that the world of software is huge, that you cannot learn it all, and your greatest asset is your ability and willingness to keep learning. Good employers hiring entry-level developers know this and are not looking for people who know everything. They are looking for people who can demonstrate enough skills to be minimally useful, and an aptitude for growing and learning more.

Be flexible about the technologies you are learning. I highly recommend getting started with javascript simply because it is the most widely used programming language, and there are lots of resources to learn it, and jobs that use it. But don’t think of yourself simply as a “javascript developer,” and think that is all you can do. If companies that interest you are using php or python or ruby, go and learn something about those technologies. Most entry-level software positions will let you demonstrate your competency in any language, and are willing to train you on their specific technology stack.