30 lessons I wish I could go back and tell my junior self

My biggest life-lessons from 20,000 hrs spent as a software engineer that can be the difference between a thriving skillset and career, and feeling stuck in a loop.

𝘐𝘮𝘢𝘨𝘦 𝘤𝘳𝘦𝘥𝘪𝘵: 𝘓𝘰-𝘍𝘪 𝘗𝘳𝘰𝘥𝘶𝘤𝘵𝘪𝘷𝘪𝘵𝘺 𝘰𝘯 𝘠𝘰𝘶𝘵𝘶𝘣𝘦

1. Consistency beats random hustling

I’ve always loved to hustle. But it’s only gotten me so far.

Hustling is great in little motivational spurts…

What it’s not great for is a longterm growth strategy. When our motivation fails, we fall back to our systems and our daily habits.

If you have no daily habits of learning and growth, you won’t make much progress.

Several years back I was stuck on endless tutorials and weekend hustling not making much progress.

Here’s what saved me and helped me massively level up and 2x my salary.

Go ahead and read it, and then read the other 30 tips 😅

2. Anyone can learn software engineering

I'm an Average Person who became a senior software engineer. You can be too.

Am I decently techy? Yes. 

Have I ever spent 1000 hrs on leetcode? Nope. 

• Have I built my own computer?

• Built my own compiler?

• Built my own app?

Nope. Nope. And Nope. 

Have I built projects in two weeks that resulted in $70,000 in additional revenue for my company?

Have I built an email campaigns tool that’s now scaled to 750,000,000 emails sent?

Have I grown from graphic designer, to wordpress sites, to fullstack engineer, to tech lead? 

Yes. Yes. And Yes. 

For me it’s all been about:

• a drive to own my own growth

• prioritizing learning and growth

• finding engineers and mentors I can learn with/from

Your growth will compound if you keep showing up.

Be patient, and believe in yourself. You can do this!

3. Join a team where others are smarter, but still willing to help you level up. 

I’ve always heard you are the average of the 5 closest people you hang out with. 

That’s usually quoted as a negative, but you can totally use it to your advantage. 

Surround yourself with people who are growing. 

It’s amazing how much you can grow by just being around other people who are growing and eager to learn together. 

This has been true for me the past 3 yrs. 

I joined a startup that was filled with all the 10% kids. 

Yeah, you know. The ones in college on the group assignment that did all the work? I went from being the smartest person in the room to being the dumbest. 

But it was the best thing ever for my career and skills. 

For a while there, every day was a struggle. It almost felt like I was starting over. 

It was almost embarrassing seeing what everyone else was cranking out while I onboarded and took 6 weeks on a 2 pt task they assigned to me.

But they stuck with me. I was with a team that let me ask stupid questions. They let me pair with experienced engineers and take on challenging projects.

Every day I learned and grew so much just by rubbing shoulders and working with other smart engineers.

4. Take on challenging projects to stretch yourself

Looking back over my career, it’s been the times I volunteered for or was just assigned a difficult project that I grew the most. 

• Figuring out how to process and save thousands of webhooks / second 

• Exceeding the data binding limit in Angular and building a scroll offloader

• Optimizing complex database queries so they ran in 300ms instead of timing out 

• Building and scaling an email campaigns tool that’s now sent 800,000,000+ emails

None of those projects were easy. 

Some of them I had a freak out moment when I started. Some of them I got stuck on for a while. 

But I did it! I figured them out and grew in my skills! 🚀

Now anytime I’m working on something particularly difficult, I get excited because it means I’m really going to grow. 💪

5. Freelancing is a business, you have to be good at coding and running a business

When I first started my journey as a software engineer I decided to run my own freelancing business. I figured it would be a good way to step my toes into coding.

It was much harder than I expected.

I thought I would be able to sit around coding up really cool websites and apps, just working for myself and really fun companies.

The reality: freelancing requires you to run a business.

I actually had to learn sales, marketing, finances, contracts, retainers, cash flow, charging what you are worth… and on and on.

I definitely learned a ton and wouldn’t trade the experience, but I didn’t realize how much “businessy” things I’d be doing, vs. just learning coding like I hoped.

tldr;

You can definitely learn a lot doing it, but just go in with your eyes wide open.

It’s a business, not just a heads down coding shop.

6. Drive the screen while screen sharing

When I was learning fullstack development early on I had a mentor engineer who was a wizard.

You know the ones, the kind that build compliers for fun on the weekend.

Whenever we paired it was easy for me to let him screen share and walk me through things where I was stuck or needed a deeper dive.

However, doing so actually slowed down my learning.

I left many of those calls nodding along, and then later one I’d have to ping him again with another 20 questions because I hadn’t actually done the work.

Driving the screen can be scary, messy, and nerve-wracking…

But wow, does it help you learn and level up quickly. 🚀

7. Git is a lifesaver, “git” good at it

Do I really need to be good at git? 🤪

This question was pretty popular in a freeCodeCamp forum. Here’s what I would say:

Git is useful even for solo projects, and is a must have skill for any engineer working on a team.

It essentially allows you to have infinite file versioning history. To break up your work into little “commits” of work.

• Got something working? – commit it

• Want to try something crazy? – start a new branch

• Messed up something? – roll git back to the last working point

I loved what one engineer shared in response to that question:

“Git is extremely useful.. because of its “oh--I-**-my-code-up-big-time” rollback ability. ...Working it into your habits will save you loads of hours in case things go wrong later down the line.“

I totally agree! It’s something I use every single day.

8. Learn how to learn, it will help you grow quicker

Software engineering often changes quickly.

There have been many times in my career that I felt like I was falling behind. I needed to quickly learn a new technology at a job I just landed, or I was working on a new project that required a new library I hadn’t used yet.

It’s been times like these where I’ve been helped by a proven learning framework.

A dude named Richard Feynman once dubbed: “the smartest human in the world,” came up with a proven approach to learn new things.

I’ve adapted it a bit to apply more to software engineering.

1. Read the official docs, grab a book, etc.

2. Try it out

3. Do more reading / research

4. Get it working

5. Refactor

6. Summarize and document

7. Share what you’ve learned

Anyone can learn software engineering – even the most complex things like microservices, kubernetes, kafka, idempotency, etc.

If we put in consistent effort, and apply the learning systems that work, we will successfully grow in our skills.

Don’t take it from me though – here’s what the smartest man in the world had to say:

There are no miracle people. It just happens they got interested in this thing and they learned all this stuff. There’s just people.

– Richard Feynman

I believe in you – you’ve got this.

9. Don’t be afraid to make mistakes

Making mistakes is part of the job. We all suck when we start something new.

It’s part of how we learn and grow as humans.

When I think back to my now 1st grader as a toddler learning to walk, he stumbled and fumbled quite a bit. But we were elated he was moving and learning and trying!

It’s the same thing with making mistakes as an engineer (in a good company culture).

You learn, you grow, you figure out how to do it better next time.

Soon you’ll have people coming to you asking you for advice.

It’s that 1% better everyday that matters and adds up.

10. Develop a bias for action, just try things

This is one of the traits of top performing software engineers.
Amazon even lists this as one of their core principles.

It’s often heard in our industry as: “move fast and break sh!t.”

But what does that mean?
Does it mean being impulsive?
Does it mean build first, plan later?

Having a bias for action means you will:

Take calculated risks with the best info you have, and try things to find the best solution quickly.

If you find yourself asking: “should I do something about this?” 
The answer is probably yes. ✅

Make a plan, and start acting. 
If it fails, regroup, and start again.

Try. Fail. Learn. Fail. Grow. Fail. Succeed.

11. There are no stupid questions, ask more

One of the best ways to learn is to ask questions.

I used to be afraid to ask questions for fear of what others would think of me.

However, instead of just looking dumb for 5 mins while asking the question, oftentimes I’ve gone 5 months without knowing the really learning something.

Now I see that asking questions is a way to supercharge my growth.

This applies to so many things:

• learning a new skill on the job

• landing a new job and learning all the things

• interviewing and researching a company

• learning about the business to make better engineering decisions

Pro-tip: after you get an answer, document it for yourself and others to level up!

12. Spend 15-30 extra mins to understand the larger system when you work on bugs

One of the ways I really leveled up in my systems design understanding was working on bugs.

Oftentimes when we fix a bug it’s deep inside a code flow or system and just needs a one line fix.

It’s really easy to find the error and push up a fix without understanding the whole picture and exactly how it broke and what all it affected.

What I started doing was taking an extra 15-30 minutes on a bug to understand the surrounding system I was working in.

I would ask myself questions like:

• What APIs call this code path?

• How would users experience this bug?

• What could we do to prevent a similar bug in the future?

• Is there a poor architecture pattern in use that allowed this bug to slip in?

Asking questions and digging in for an extra 15-30 mins helped me massively level up in my understanding of our systems.

Do this for 6 months, and soon you’ll become the engineer everyone goes to with questions.

13. Clean coding design patterns really help reduce spaghetti code

Ah yes, good ol’ spaghetti code. Easy to hate on, difficult to work in it.

But how does spaghetti code even get there in the first place?

From what I’ve seen, it’s over prioritizing new features, rather than maintenance, flexibility, extensibility, simplicity, etc.

Over time one more function param is added, one more unit tested is omitted, one more rushed deadline is thrown at the team…

Until one day you end up with a mess of code that one one wants to touch.

To combat this, I like to follow the boy/girl scout rule:

“Always leave things better than you found them.”

• Add that missing unit test

• Rename a variable to be more clear

• Break out a massive function into little ones that do one thing

Make your code better over time, not worse.

If everyone does this, little by little your codebase will improve and soon become a joy to work in again.

Not to mention be cheaper to maintain, easier to extend, and faster to build in.

14. Read one or two books a year

Reading one or two really good books will often help you round out your skills more than just reading a bunch of random blog posts.

However, what you don’t want to do is see lists of 50 top engineering books, try to read them all tomorrow and then get overwhelmed.

My advice: pick 1-2 books and read them over the next 6-12 months.

You’ll probably finish way more and retain a lot more than if you try to crush through all of them and only finish a few.

Here are a few of my favorites:

• Clean Code

• It doesn’t have to be crazy at work

• Practical Object Oriented Design

• Designing Data Intensive Applications

15. Take some basic design training, you’ll need it some day

So often as fullstack or backend engineers we focus on getting something to work and then we’ll “make it pretty” later on.

However, a lot of times that “we’ll come back” never happens.

Poor design minimizes the value of the user’s experience to an afterthought.

We preach about test driven development.

We should do the same with good design + user experience.

For me, taking some basic design training, as well as getting good at HTML/CSS really helped me be confident creating new components and UIs that look great, and work really well for our users.

16. Build yourself a support system

Community has been huge for me.

Not only for support, and mentorship, but also opportunities, and career growth.

A few years ago I was working in a toxic job environment.

One thing that really helped me recover from that time is a group of engineers I call my “coders support group.”

We have a group chat going where we:

• Share what we are stuck on and could use ideas for

• Laugh at random things we find funny

• Support each other during hard times at work

When I was in that really stressful job, it was amazing to have their support.

I healed by being able to share stories, have their empathy and support, and hear them tell me my workplace wasn’t normal or ok at all.

I’m in a much healthier environment now, but the support group is still something I really value.

We are made for community. To do life with others and share the highs / lows with them.

Here’s a few ideas on how to find people for a group:

• Connecting on social media (twitter/linkedin/youtube)

• Meeting at a co-working space

• Striking up a conversation at your favorite coffee shop

• Happy hour at work with coworkers

17. Find a mentor who really cares about you

Finding a mentor who cares about you and your personal and professional growth is huge.

It’s like having a cheat code for the test.

You can learn from others and their experiences without necessarily having to go through the same mistakes yourself.

If you find someone willing to be your friend and mentor you – even if they are just one step ahead, hold on to them. They are worth their weight in gold.

18. Take breaks and acknowledge your humanity

I love to work hard. I love fast-paced work environments.

But I also really believe in work-life balance. 60 hr forced work weeks are not for me.

However, what I haven’t been great at is actually taking long breaks. This year I haven’t taken any vacation… and I’m not really proud of that.

It’s been one crazy project after another we had to get out.

Then recently I stepped into management for the first time and I’ve been trying to protect my team from some of the craziness of bugs, organizational shifting, and crazy clients.

However, what message is that sending to my team? I want them to feel freedom to take their vacation, to rest and recover.

I want to celebrate breaks just as much as we do working hard.

So this week I’m on the beach with my little fam, off social media, unplugging, resting up, refreshing my mind and body.

Deep breath – man, it feels good.

(fyi: I wrote this article last week and scheduled the send time so I could fully unplug)

19. Imposter syndrome is a sign you are in a season of 🚀 growth

I used to look forward to becoming a Senior Software Engineer so I could build anything, and all my imposter syndrome would go away. 

I’m here now. Did it work?

Nope. At least not all the way. 

Yes, I know more, I can build more things, but I’m also working on harder problems…

I still struggle with imposter syndrome, but now I see it for what is.

A sign I’m in an uncomfortable 🚀- season of growth.

I’m leveling up in new, exciting, and challenging ways. And that’s truly something I can get really excited about. 

20. Never say that’s not my job

One of the things I’ve learned after working at several startups is that sometimes you just need to roll up your sleeves and do the dirty work.

The thing that’s not really your job, but also isn’t really anyone else’s.

• Writing up that ticket with better acceptance criteria

• Pitching the business value of a refactor to leadership

• Working with a designer to work through differences in the styleguide to code

• Pulling a .csv report so that one customer feels confident in your system

• Estimating the cost of scaling that db on your busiest service

A lot of those things are “devopsy” or “designy” or “businessy”, but sometimes you’ll just need to do them.

I’m not advocating for doing a bunch of invisible work and saving the team from defining roles and responsibility and processes.

What I am saying is be flexible, pitch in to help out the team, and just be a kind human.

Other folks will want to work with you, and opportunities will find you.

21. Soft skills are the hard skills

One of the things I see often in our industry is that “soft skills” are undervalued.

Most of our tutorials, books, youtubes, courses all focus on getting better at coding.

Reality: our jobs as engineers have a lot of things that aren’t coding.

• We have to learn how to disagree respectfully and move forward with others who’s opinions are different than us

• We need to learn how to write project status updates in a way business leaders can understand

• We prepare presentations, and write technical specs

• We mentor others and help each other grow

There are a lot of “leadership” and “relationship” skills in our day-to-day.

Focusing on growing in them with the same rigor as I have to grow in my coding skills has led to promotions and opportunities I never would have had.

22. Be a kind and genuine human

I’d loved this bit that Ryan Peterman shared recently that really lined up with something I’ve learned and am passionate about.

So much of our work is actually just about being a kind/helpful/thoughtful human.

Being a great engineer doesn't mean it's okay to be a jerk. Building software is collaborative. The better teammate you are, the more effective you will be.

Empathy in a strong engineer is a superpower; having high EQ will do more for your career than writing perfect code.

–Ryan Peterman, Staff Engineer | Instagram, author ofThe Developing Dev

If anything, as leaders, we should be the most enjoyable to work with.
With great power comes great responsibility.

Be a thoughtful, genuine, kind, caring human. 💙

23. We are problem solvers first, not coders

As software engineers, we are brilliant thinkers, creative problem solvers, and excellent tradeoff analyzers!

Our main job is actually not just writing code…

It’s creating value and solving problems. At the end of the day we are writing software that humans or computers will use to help humans.

Sometimes the best way to solve a problem is without code.

Focus on learning how to solve problems, not just on learning how to code.

It’s a subtle difference but it will really help you focus and create huge value for the companies and users you work for.

24. Communication skills are huge

One of the best non-coding engineering skills you can develop is clear, concise, and thoughtful communication.

The type of communication that speaks to all interested stakeholders – not just technically minded people.

Wait, but hold up… don’t software engineers just write code for 10 hrs a day?

That couldn’t be further from the truth. Here are just a few of the ways we spend our time communicating besides just writing code.

• Writing 5 pager technical specs

• Creating documentation for new app features

• Writing out tickets and bug reports

• Sharing standup updates

• Giving project status updates to business leaders

Work on your communication skills, both written and verbal.

It will pay huge dividends. 📈

25. Learning about the business will help you be a better engineer

One of the things I loved about the hyper-growth startup I worked at in 2020 was the way I got to learn about the business, sales, product, customer support and more.

Our founder always encouraged anyone – even lowly engineers – to ask about business plans, about upcoming sales, or new projects.

He even welcomed us to challenge their growth plans or new product ideas in an all hands meeting or via private DM with the C-suite team. 🤯

I learned so much from that experience.

It made me a better dev.

Because I understood more about our products, services, and clients, I was able to pour that into how I built features, and solved problems for our users.

I don’t hear many people talking about this – but I think it’s a really underrated area as a developer that can make you standout – especially if you want to work at a startup.

26. Some company cultures are just toxic, it’s ok to leave

There’s a time to stay and affect change by speaking up – and there’s a time to affect change by leaving and choosing health for yourself.

A toxic job can take years to recover from (speaking from experience).

If you see these and other unhealthy signs repeatedly, you advocate for change, and nothing improves – run.

• Working weekends and evenings is part of being a “team player.”

• Leaders bad-mouth other leads to their reports developing an us vs. them culture.

• There is no diversity in thought, opinion, culture, representation, or ideas. eg. “we just need people to do their jobs, we don’t have time for that diversity stuff.”

• Project estimates are not respected: “I know you said 4 wks for this project, but can’t you just hack it up in 2 wks somehow?”

• Everything is engineered at google scale. There are no MVPs. Complex systems built for simple problems happens again and again.

There are healthy company cultures and teams out there, you deserve to work at one.

27. Don’t hold yourself back from applying for that stretch dream job

Something I’ve learned is that companies are going to ask for the world.

Mid-level engineer position job post:

• 8+ yrs experience in faang tech companies

• Expert in Java, Ruby, Php, Typescript, Elm, React, Serverless, DBs, Kafka

• Crushed 1000+ hrs in leetcode with a top 1% rating

It’s so easy to see unrealistic posts like this and undervalue your skills.

In reality, if you find a healthy company and can show you know how to solve problems, are excited about their vision, and eager to learn and build, they will probably be interested in you.

Good companies know that the best engineers can pick up new languages.

It’s not so much that you know everything on the job post, but that you know how to learn, and have the experience to solve the kinds of problems they have.

Don’t hold yourself back. Apply for that job!

If you don’t make it, keep working on your skills, and try again in 3-6 months.

Rinse and repeat.

28. Keep a brag doc for encouragement and resume building

A brag doc is something you update bi-weekly with everything you’re working towards and accomplished.

Every couple months review your bi-weekly notes and summarize them.

Summarize the value or business outcomes of your successes. 

Maybe you spearheaded a new product feature. Did sales land a new deal because of that feature? How much was that deal worth? 

Example: Built a feedback form tool for customers to leave dine-in reviews after a meal. As a result of successfully completing the engineering work for this feature ask, we pulled in $700,000 in additional sales this year. 

Or perhaps you onboarded and mentored three junior engineers. How much did your team productivity increase because of helping those engineers onboard successfully?

Their success are your successes in part, because without a good onboarding experience or mentoring they wouldn’t be contributing as successfully. 

A lot of times you’ll be sharing your accomplishments with business and hiring folks who aren’t in the day-to-day of the coding world.

Learning how to speak their language and show your wins in a clear way will really help you standout in our crowded engineering field.

Quantify. Quantify. Quantify.  ✍️

Brag docs are also an awesome reference doc for your LinkedIn, 1:1s, resume, yearly reviews, promotion conversations etc. 

29. Your skills are worth a lot

“The problem isn't that people are over paid. It's that so many are underpaid.”

For a long time in my career I didn’t realize I was so underpaid.

Yes, I had some areas I needed to grow in, but even then every time I asked for a raise I was told “ok, once you become a better developer we’ll consider it.” 

Problem was, there was no career ladder defined. It was just a way for the company to say no.

We all deserve better.

Eventually I did level way up and my boss said: “Woah, don’t learn too quickly we can’t afford to pay you that much.” What??

You realize you are underpaying me but don’t want to lose me but still want my skills here?

We all deserve better.

After researching growing companies with good compensation and a healthy engineering culture for three months.

I ended up landing a new job that 2x’d my salary. 🎉🤯

I didn’t realize how much of a boost of confidence that would be!

Now I see under paying workers lowers the self-esteem of your employees. 

Creating a vicious cycle of frustration of working for low pay, but also not feeling like you any other options.

We all deserve better than this. 💙

If you are in a situation like I was reach out, talk with friends and family, do research on other companies with similar positions and looks for companies that will treat you better and compensate you well!

You may just land a 2x pay increase like I did. 🙌🏼

30. Senior engineers, stop coding so much

Wait what?? Ok, Caleb, now you are off your rocker – that’s what helped me get to senior engineer level. 🧐

I know, same here!

What I’ve learned is there’s actually a point where too much heads down coding will hurt your skills/career growth.

What you should focus on instead is becoming a force-multipler:

• Encouraging others to lead 

• Coaching other engineers through technical speccing 

• Letting go of my opinion as the best way to solve something 

• Spending time to research where we need scaling or refactoring

• Mentoring others on their engineering skills, soft skills, and leadership skills

It’s starting to become more clear now… 

Senior+ engineering levels are not just about being the best coder.

It’s about how all our teams and systems work together, rather than just my project or tasks. 🤝

It’s more about supporting, cheerleading, and coaching others. 💙

Helping us all level up together 🚀

---

I hope those lessons were helpful! I’ve learned a lot over my last 10 years as a software engineer. And I know I still have a lot more to learn!

What lessons have you learned that you would you share with your junior self?

I’d love to hear from you in the comments 🙋‍♀️🙋‍♂️

Until next week 👇🏼

Catch me daily on LinkedIn where I talk about everything software engineering, startups, and growing in your engineering soft skills.

– Caleb

P.S. Don’t forget to like, comment, and share with others if you found this helpful!