I was a corporate lawyer for 12 years. I never thought I'd be working at Google as a software engineer, but that's what I have been doing for the past year. I'm working remotely until COVID subsides and we can move to San Francisco.
In this article I'm going to share with you ten important lessons I learned during this career transition.
I finished law school in Bangalore, India, a year before Google listed on the Nasdaq. That was a long time ago. The world was very different. I think Facebook was still “thefacebook”.
I started my career as a litigator in the courts in India. Two years later I switched to corporate law, and then ended up moving to Australia to join one of the world’s largest law firms, in their Melbourne office.
Several years later, after surviving the Global Financial Crisis of 2008, I became an Australian citizen and moved “in-house” – the term for when lawyers move from working at a law firm to working internally at one specific company.
I loved being a lawyer, because it was filled with smart, ambitious people and it paid well. But there was always a part of me that longed to code, to create, and to contribute to the internet’s repository of useful tools.
To me, programming a computer is such a magical act. To write text, and have machines follow your commands – there is something so powerful, so limitless about that. It fired my imagination.
But I really did not view myself as “mathematical” or “nerdy” or a “brainiac”. Every bit of social messaging around hackers, coders, programmers, and technical founders (which by 2012 was a status symbol!) reinforced the myth that programming was the domain of “wickedly smart” math wizards.
I unwittingly reinforced that myth to myself – I tried to teach myself to code THREE times. In 2014, in 2015 and in 2017. And all three times I quit because I tried to jump too high, set myself up for failure, and then assumed I was not smart enough (when actually, I had just tried to run before I’d learned to walk).
Programming felt beyond my reach. Just. Too. Hard. I had no clarity on where to begin, what bits to learn, and most frustratingly, what bits to ignore.
Instead, I started a tech company and hired a team of coders. One of them became my technical co-founder. He quit a year into it, and I was left with partnerships and contracts with local governments that I had to honour.
Faced with the choice of being defeated or learning to code, I chose to try again – to learn to code.
I was 37. In 2020 COVID hit, and just as it was getting very serious, I signed my contract to be an an engineer at Google. I had just turned 39.
It felt odd to be “starting” over. But it also feels incredibly fun to be a beginner again. In fact, I can actually truly relate to what Steve Jobs said at his famous 2005 Stanford Commencement Address:
“The heaviness of being successful was replaced by the lightness of being a beginner again, less sure about everything. It freed me to enter into one of the most creative periods of my life.”
I had left a successful legal career and then a less than successful startup journey to be a beginner again. As a coder and coach, I am being more creative than I’ve ever had the privilege of being.
This is not about Google or any other fabled tech company. This is about you. It doesn’t matter what your goal is. I want you to know that transformations are not “special” or “miraculous” – they just feel that way.
The people I coach have gained an understanding of how I “found” my roadmap to becoming a coder, in a world where there is way too much information and consequently way too little clarity. But there isn’t enough time here to go into that.
Today I want to help you by whittling down my 10 most important principles for people wanting to transform their lives and achieve their goals.
You’ll see that this is true of coding, or anything else. But since I am now a self-taught engineer, working at Google, it is particularly relevant to others who are coders or aspiring coders.
At the end of this piece, I’ve put down some ways to reach out to me if you have any questions.
5 Things NOT to Do When Changing Careers
I am starting with the “don’ts” because it’s easier to identify things we do that hold us back, than to develop new habits. Tackling the don’ts first will give you quick wins that will build your confidence – and from there you can build up to the “Dos”.
DON'T Look at the Mountain Top
For a long time, you’re going to be climbing a steep mountain. It’s going to feel long in the moment, but it’s a short period in the context of Life.
The mountaintop will not get closer no matter how often you look at it. But the more often you look at it, the more you’ll get discouraged because somewhere, we are all in a hurry. Things take time. And as Jeff Bezos says, you can’t skip steps.
If you lose your optimism you lose confidence, and then you lose energy and momentum.
Instead, just focus on the process of learning. No matter how much code you write, you are always learning new tools, techniques, practices, languages, frameworks and so on. And if you rush yourself into feeling “competent” you will disappoint yourself, because at first you’re going to get suck.
That’s normal. You can’t skip the novice stage when you’re learning, and if you try to skip it, you will get frustrated and lose your passion.
The process of learning is to do a little bit consistently, rather than a ton of stuff in an inspired burst. 60 minutes every day for 3 months is far more effective than blitzing it for 20 hours on a weekend and then not doing anything for a month.
So don’t focus on “becoming a good engineer” or “getting that job”. Instead, focus on learning and getting your repetitions up until things start to feel comfortable.
DON’T Mistake Doubts for Evidence
You’re going to have doubt and fear with you every step of the way. If you think of it as a shadow, you may stop paying so much attention to it.
Doubts have a way of convincing us they’re real. They spotlight our weaknesses and over-emphasise our failures. And then, without realising it, we take them as evidence of our ability.
This one takes practice. And since you’re never going to be doubt-free no matter how much of an expert you are, you should practice making space for your doubts while not paying too much attention to them.
No matter what your doubts tell you, there is only one thing you know for certain: if your doubt is right, it is right only right now. Tomorrow it could be wrong. If not tomorrow, the day after that.
Your doubts don’t prove anything about tomorrow. Chances are your doubts are not right at all – they’re just insecurities and exhaustion.
Rather than fight doubt, it’s better to do some vigorous 10 minute exercise or take a nap. If doubts disappear (and you’ve experienced that!) then they can’t be all that real.
DON’T Measure Reality Against your Secret Wishes
All of us have secret hopes and fantasies. We hope we will be recognised as brilliant and our boss will promote us without us having done much, or that we can get super-fit bodies with 2 months of going to the gym, or that our first 3 blogs will get a bazillion comments and shares on social media. We secretly wish for success, without too much effort, and very quickly.
Maybe. Statistically, some people will get that lucky, just as a dead clock will tell you the right time twice a day.
But if you’re not aware of this secret wish and its power over your mind, you will feel disappointment. And you will not find the energy and discipline to keep going.
The truth is pretty much any goal that is beyond your current skills takes a lot of time, energy, focus, and discipline. And it requires you to maintain those practices well past the point you were secretly hoping for instant gratification. In fact you could go for months without much positive reinforcement from the world around you.
So measuring your results against your secret wishes is a recipe for giving up. Instead measure your results against your previous results.
I use a simple technique for this – my personal motto is to be 1% better every day. As long as you’re getting a little bit better each day (maybe you just read a blog, or did some deliberate practice for 30 minutes), then you would have improved yourself. These micro-improvement don’t stack – they compound.
Measure yourself against your past results, not your secret fantasies and you will feel tremendous motivation to keep going.
DON’T Take Big Decisions on Bad Days
You’re going to have a lot of bad days. Don’t negotiate with that – accept it and don’t put too much emotional weight on it. Even when you’re the best at what you do, you’re going to have bad days.
So you must expect a lot more of them, a lot more frequently, when you’re learning complex new skills. You must fully expect that you will have such bad days that the only rational-feeling thing to do is to quit.
You will have such bad days that you cannot see how things can get better. You will have such horrible days that you will assume the way you feel right then is how you’re going to feel forever unless you give yourself the relief of quitting.
I went through this so many times. Not just in coding – but in every single job I’ve ever had. This is why people respond so well to having a coach. A coach is “an external mind” that can see more clearly than you when you’re lost, struggling, confused, or discouraged.
The threat of quitting on a bad day is so high that I developed a technique to get around this. Rather than constantly arguing and negotiating with myself in my head, and confusing myself to exhaustion, I simply follow one rule: is this a bad day? Oh yes. Ok, no decisions today.
Rather than quit, take a break. When I was learning to code, I would sometimes stop studying and coding for a week if I was dangerously close to giving up. I figured I’d rather lose 1 week of progress than quit altogether. Most often, in 2-3 days my internal “state” would change and I’d be back at it, harder than ever.
In fact I found a rule from an olympic gymnast that I adopted for myself. I even wrote about it when I found it, as a way to ensure I followed her advice.
You can give up any time you like….as long as you’re having a good day. But you cannot give up when you’re having a bad day.
DON’T Assume Your Results Reflect Your Ability
It is easy to assume that your results reflect your ability. In a sense, that is true – they either reflect your effort or they reflect your current ability. And that’s the most important distinction to make.
If it’s not a failure of effort, then it is a shortcoming in your current skills. And that’s great, because skills can always be improved. It’s just hard because we secretly wish it would be faster, easier, and more glamorous to get to success!
Most importantly, it is critical not to let your internal dialogue switch from “I don’t know how to do X” to “I cannot do X”.
We often unwittingly confuse lack of knowledge or skill with lack of ability or potential. This is particularly easy to do when we’re surrounded by people who are a whole lot better than we are.
I felt this so many times. As a junior lawyer and then 15 years later as a junior engineer. I assumed other people were talented or gifted and I was not. As I grew in experience, other “juniors” viewed me as talented or gifted. It was just experience and learning.
There is a line from T. Harv Ecker that I really found to be true in my various careers:
“If you’re not doing as well as you’d like, all that means is there’s something you don’t know.”
Also, as a close cousin to this principle, follow John Wooden’s advice:
"Never let what you cannot do get in the way of what you can. "
There will be many weeks when you’re grappling with something that you simply don’t know how to do. It won’t come easy. It won’t come quick. And you may feel very stuck.
But there will always be something – maybe it’s something small – that you can do to take one step forward. By always moving forward, even if it's a tiny step, you will keep your momentum. And usually those small steps are the small learnings you need to stack up to solve the bigger problem that has you so badly stuck.
5 Things to DEFINITELY Do When Changing Careers
DO Work on Your Growth Mindset
If you practice the top 5 Don’ts, you will automatically start building a growth mindset. At first you may not have a growth mindset – it’s more likely to be that you will gradually remove the unproductive “fixed mindset” habits that we all have.
If you aren’t familiar with the concept of the growth mindset, take a look at this TED talk by Carol Dweck. She has even published her research in a bestselling book. This is a foundational worldview that will help in everything you do.
Note that I say “work” on your growth mindset. This is not a weekend hack. It is a lifestyle. It requires constant practice and self-awareness.
In my experience, the most powerful impact of practicing a growth mindset is that I asked radically different questions when I was failing or struggling.
For example, instead of asking myself “why can’t I figure this out?” I trained myself to ask “how can I find someone or something to help me figure this out”.
I remember when I was learning JavaScript promises, and I was really struggling to get the concept. At first I sank into depression because I read a few blogs and I just couldn’t grasp some of the intricacies and mental models. I felt drained and frightened, overwhelmed and very alone.
I watched this TED talk and I immediately asked myself – do I know any JavaScript developers? I went to LinkedIn and searched my contacts (I was too shy to ask total strangers on Twitter – a sign of my fixed mindset!).
I found a guy I’d met at a startup event, who was self taught and had built a JavaScript webapp. I reached out to him and it turned out his office was 15 minutes from my house. Two days later he spent his lunch break showing me how to use promises. It felt easy after that.
Carol Dweck was right – it wasn’t that I didn’t know JavaScript promises, it was that I didn’t know them...yet.
DO Make Friends with the Impostor Syndrome
Impostor Syndrome is when you secretly think that you’re not good enough to do what you’re doing and that you will get found out and exposed as a fraud, or an impostor. I wouldn’t say it’s common. I’d say it’s almost universal.
When onboarding at Google, I heard this topic come up so many times. There are tons of blogs, resources, and internal guidance on how to deal with it. Engineers feel it everywhere. Heck, the co-founder of Atlassian did a TED talk on it.
So, it’s a form of doubt, and we already covered how to deal with doubt in the DON’Ts section.
Impostor Syndrome has some added layers to it, because it typically arises in professional settings. That’s why it gets special treatment here in the DOs section.
Professional contexts produce more fear of embarrassment because we have all this baggage about performance, and promotions, and being reviewed by bosses. All that extra baggage gives it more power over us.
As you start to get successful in your coding journey, make friends with Impostor Syndrome and joke about it – it will oddly make your mindset more growth oriented, because by owning that you don’t know something, you open yourself to learning it.
If you hide it, you spend a lot of energy on soothing yourself that you could otherwise use to learn the thing you don’t know yet.
DO Practice Reframing Failure and Setbacks as Moments of Learning
We all hate the feeling of failing. We also can’t avoid it. What do you do when you can’t avoid something you dislike intensely?
You attach a different meaning to it.
If you classify setbacks and disappointments as failures, then you will emotionally respond to them as failures. If you classify setbacks and disappointments as information about what you need to learn, then you respond to them as lessons.
Let me be clear – this is not easy to do! Like everything else I’m writing about here, this takes practice. Just like coding.
As clichéd as it is, the emotional impact of the glass is half full versus the glass is half empty debate is very real. In fact marketers know this. They don’t tell you your fruity yoghurt is 20% fat. They tell you it’s 80% fat-free.
You’re absolutely going to fail, and if you learn from it then you have to ask yourself – did I fail or did I just learn something?
Put all your attention on understanding what you learned from that failure, analyse, deconstruct, and internalise it. That way, you won’t notice failing so much.
DO Hold Yourself Accountable by Making Fewer Decisions
As a lawyer, I can tell you that our minds are experts at arguing for both sides, depending on what suits it. If you ask your mind why it’s OK to skip a run today, it will tell you. If you ask your mind why running is important, it will tell you that too.
How do we get anything done with a mind that changes with the wind?
We don’t ask the mind. We simply commit to one action. If we ever discuss this action with our mind, then we will get sucked into a negotiation with, or rather against, ourselves. This wastes a lot of energy.
Have you ever gone around in circles in your head wondering whether you really need to do the assignment now, or whether you can finish watching the movie on Netflix and then find time for it later? We all have.
It’s much easier if we say, from 8 to 10pm I do nothing but X. Until I do X I will not do Y. But once I do X I will reward myself with Y, and not get distracted by Z.
If it sounds like a lot of effort, I can promise you that it’s way less effort than having the same internal debate every few days and then beating yourself up for it later.
Commit once and save yourself the headache of constantly negotiating with yourself. This is the best way I’ve found to keep myself accountable, because I don’t need to keep checking in. I just check against one rule that is not up to my mind to decide.
DO Focus on the Insight Rather than the Implementation
This one is important for coders and is a little less meta than the other points.
Ultimately, most people reading this are looking to code professionally or for economic gain of some sort. It is easy to be in a hurry when progress has taken longer than you secretly wished, or planned for.
As a result, we tend to try and learn “tricks” and “shortcuts”. These are tactically useful as they will help us make some progress. But they also come at a cost – those shortcuts may not help us apply the principles to unfamiliar contexts.
For example, if you’re learning how to use recursion, it’s tempting to memorise the approach rather than build your mental intuition around it. But if you can’t see how the same technique can be used to solve other problems or a “class” of problems, then you’re missing out on the real power of the tool.
This can then catch up with you in interviews or at the workplace. In interviews, you may fail to recognise the underlying “class” of problems.
For example, when I was first teaching myself data structures I once failed to recognise a problem about HR reporting structures as a tree/graph traversal problem. That actually happened during a mock interview! I had practiced graph traversals and memorised implementations but hadn’t fully internalised the concept.
Similarly, without understanding concepts you cannot communicate effectively with team members or people who come to you to learn. This will set you back at the workplace because effective engineers need to communicate abstract concepts well.
At a more general level, adopting this “DO” means that you won’t fake it. It will force you to be patient and persistent in developing your understanding, rather than a hack around true comprehension.
No matter what skill you’re learning in life, having clarity of concepts is much more scalable than knowing just one implementation of the concept.
Conclusion
On a departing note – these are my top 5 Dos and Don’ts. If you make them yours I can guarantee that you will make progress, and come up with your own - that is extremely important as your own framework can only emerge from confidence and practice.
But having your own framework will make you a real weapon, because it’s reusable across any learning context.
I really hope that these lessons are of value to you. I truly believe that if one person can do it, I can too, and if you believe that, you will be able to do it, too.
Post Script
If you would like to learn more about my journey from lawyer to software engineer, check out episode 53 of the freeCodeCamp podcast and also Episode 207 of "Lessons from a Quitter". These provide the blueprint for my career change.
If you are interested in teaching yourself to code, changing careers and becoming a professional coder, or becoming your own technical co-founder, please reach out here. You can also check out my free webinar on Career Change to Code if that is what you're dreaming of.