I've never been the most confident person. I shied away from way too many challenges that could have pushed me to be better.
I never felt comfortable with failure.
What's worse is that I passed on opportunities other people would find astounding. All because I wasn't up for the challenge.
I've been stuck in a bit of a programming rut and wondered if I could break this habit with a challenge that was of my choosing?
I Googled for some examples of coding challenges, searched on YouTube for different challenge formats I could potentially use.
I came up with two coding challenges I could take that would really push me but in areas of development I was already comfortable with. Providing just enough challenge to make it engaging but not so much that I would quit or not attempt it at all out of fear.
I recently wrote about what I learned from doing two 5 hour long coding challenges in my newsletter.
I really struggled learning React at first. There were so many new concepts I had to wrap my head around on top of learning Typescript at the same time. It was rough.
It got worse because I was learning this on the job making all sorts of mistakes and taking more time then I would normally to get something finished.
Learning on the go is hard enough but trying to tackle a huge project in tandem is nearly impossible.
I wondered how other developers managed to pick up React so quickly so I researched what some of the thought leaders in the space had done.
This research led me to a discovery that's affected the way I learn anything new including new frameworks etc.
Progressive projects!
I only started to get a proper grasp on things when I took the time to start from the beginning and commit to small projects.
Tackling React in a project based approach was the key to my progress but what helped even more was incrementally increasing the size of the projects I was doing.
I recently wrote about the best React projects for beginners in my newsletter.
I used to bash my head against the wall endlessly when trying to debug a problem in the codebase I was working in.
I would just stare at the problem and try everything I could imagine and when I ran out of ideas I would just fume.
It got worse because I was being called out for not raising the issue early enough when I was stuck to get the help I needed.
It wasn't until one of my guys I worked with showed me this simple technique that I was able to break this bad habit of forceful will to be able to solve a lot of my own problems with minimal friction.
It saved me so much time and helped me really understand what was really happening in the code that I was clearly overlooking and not understanding.
The solution? Rubber duck debugging.
Simple, effective, slightly embarrassing but rarely fails.
I was a front end developer who wasn't working with React. I was stuck in legacy hell.
It got worse because I didn't think much of it until I began applying for new roles at different companies and realised how out of date my skill set was.
I stopped exploring new technologies and the things that made me excited about being a developer/engineer in the first place. And I was punished for that.
I started to dabble with the new things that developers were using and having fun again with a fresh experience.
I then started to look ahead at what might happen in the following years and exploring what could potentially blow up in the next year.
The solution to becoming stagnant and outdated? Playing.
I made some predictions based on my past experience and started to adapt before other developers were even thinking about it.
I recently wrote about my predictions for programming in 2025 in my newsletter.
I've never been a good negotiator but I at least thought I understand how to negotiate. You make the case, show the data, you put in the effort.
It never paid off.
Time passes and things weren't getting any better!
I constantly had to face the sad realisation that I sucked at negotiating. I was ready to give up. To just settle for what I had and stop trying so hard.
I contemplated and brewed for about a week until I finally snapped out of it.
"NO!" This can't be it.
I knew that negotiation was a skill, I'd seen better negotiators walk away with much more than I ever could.
I could learn.
I began my search online like anyone else. Found some articles, books and videos but they were all the same.
I knew all of this already and it didn't work.
Was the conventional wisdom wrong?
And sure enough, it was.
I read Never Split the Difference by Chris Voss and found out how wrong it all was.
I recently wrote about my experience reading the book and applying the concepts to my own life as a software engineer.
I've been working as a developer for over 12 years. I've made so many mistakes during that time.
If gets worse because a lot of that time wasted could have been avoidable knowing what I know now.
What if you could steal someone else's 10,000 hours of experience, successes and failures?
Well the lucky thing is, you can! You just have to find the right person who's walked the path you want to take, have a conversation with them and hear their stories.
Today I'm going to be sharing all the tips, tricks and truths I've discovered along my programming journey.
I had been denied or pushed back on promotion to senior software engineer for about 3-4 years.
It got worse when I realised I was essentially trapped in this "mid-level" prison. I had been in there quite a while but didn't understand why.
I didn't blame anyone else except myself. So I began analyse why this was happening and really analysing the feedback I'd been given. I realised it was all preventable.
I'd read a book called Extreme Ownership by Jocko Willink which opened my eyes to the truth. It was my fault AND my responsibility to get out of this prison.
The solution was... ownership! Not just technical ownership at work but ownership for taking control of the progression of my career.
It then only took one year to finally get promoted.
If you're currently struggling to break out then I believe you can learn from my mistakes and escape a lot sooner.
"I'm average, I am definitely a part of the 99% of software engineers."
That's me, that's my mind in 2020. I wasn't a great software engineer and I knew it. I wasn't even sure if I even average!
It got worse because I didn't believe I could become great.
My thoughts started to become my reality as I stayed in my comfort zone and rarely stepped out into the unknown.
I was stagnating and starting to lose the energy and passion I once had.
In 2024 I still don't think I'm great, I'm still not sure where I fall on the scale but there's one difference between now and 2020.
I believe I can become great.
I know I am not as good as I want to be, but I am where I am now. I accept that but commit myself to the process of improving everyday.
I step out of my comfort zone, I take on the challenge, I accept the failures, learn and adapt.
I changed the perception of myself and the repositioned the frame.
I might never be great, and understand that greatness is a factor for other to determine.
But... I will never let myself believe I can't be, that I give myself the excuse to relax and not give it everything I have.
I've been lucky enough to work with some great software engineers over the last 12 years. I wrote about some of the keys things they do that others don't in my newsletter.
Liam Walsh
Liam Walsh
I've never been the most confident person. I shied away from way too many challenges that could have pushed me to be better.
I never felt comfortable with failure.
What's worse is that I passed on opportunities other people would find astounding. All because I wasn't up for the challenge.
I've been stuck in a bit of a programming rut and wondered if I could break this habit with a challenge that was of my choosing?
I Googled for some examples of coding challenges, searched on YouTube for different challenge formats I could potentially use.
I came up with two coding challenges I could take that would really push me but in areas of development I was already comfortable with. Providing just enough challenge to make it engaging but not so much that I would quit or not attempt it at all out of fear.
I recently wrote about what I learned from doing two 5 hour long coding challenges in my newsletter.
You can read it for free here 👇
www.liamwalsh.tech/newsletter/lessons-learned-from…
8 months ago | [YT] | 0
View 0 replies
Liam Walsh
I really struggled learning React at first. There were so many new concepts I had to wrap my head around on top of learning Typescript at the same time. It was rough.
It got worse because I was learning this on the job making all sorts of mistakes and taking more time then I would normally to get something finished.
Learning on the go is hard enough but trying to tackle a huge project in tandem is nearly impossible.
I wondered how other developers managed to pick up React so quickly so I researched what some of the thought leaders in the space had done.
This research led me to a discovery that's affected the way I learn anything new including new frameworks etc.
Progressive projects!
I only started to get a proper grasp on things when I took the time to start from the beginning and commit to small projects.
Tackling React in a project based approach was the key to my progress but what helped even more was incrementally increasing the size of the projects I was doing.
I recently wrote about the best React projects for beginners in my newsletter.
You can read it for free here 👇
www.liamwalsh.tech/newsletter/best-beginner-react-…
8 months ago | [YT] | 3
View 0 replies
Liam Walsh
I used to be the prime example of stubbornness.
I used to bash my head against the wall endlessly when trying to debug a problem in the codebase I was working in.
I would just stare at the problem and try everything I could imagine and when I ran out of ideas I would just fume.
It got worse because I was being called out for not raising the issue early enough when I was stuck to get the help I needed.
It wasn't until one of my guys I worked with showed me this simple technique that I was able to break this bad habit of forceful will to be able to solve a lot of my own problems with minimal friction.
It saved me so much time and helped me really understand what was really happening in the code that I was clearly overlooking and not understanding.
The solution? Rubber duck debugging.
Simple, effective, slightly embarrassing but rarely fails.
Check out the full story below.
www.liamwalsh.tech/newsletter/rubber-duck-debuggin…
8 months ago | [YT] | 0
View 0 replies
Liam Walsh
Have you ever spent 30 plus hours on a software project only to have it scrapped because "it wasn't important".
Well I have. And you know what's worse? They were right.
I spent a lot of hours on a project that simply didn't need to exist.
I failed to see that the project, had I completed it, would have had no real value at all. Apart from simply completing it and scratching my itch.
Things only started to improve when I came across a particular principle.
A principle so innate it's almost a law of nature.
I started to see where the real value was hiding and how I could uncover it.
The answer was the 80/20 rule also known as Pareto's Principle.
I recently wrote about the Pareto Principle and how it relates to software engineering in my newsletter.
You can read it for free here 👇
www.liamwalsh.tech/newsletter/the-80-20-rule-for-d…
8 months ago | [YT] | 0
View 0 replies
Liam Walsh
I was caught off guard in 2018.
I was a front end developer who wasn't working with React. I was stuck in legacy hell.
It got worse because I didn't think much of it until I began applying for new roles at different companies and realised how out of date my skill set was.
I stopped exploring new technologies and the things that made me excited about being a developer/engineer in the first place. And I was punished for that.
I started to dabble with the new things that developers were using and having fun again with a fresh experience.
I then started to look ahead at what might happen in the following years and exploring what could potentially blow up in the next year.
The solution to becoming stagnant and outdated? Playing.
I made some predictions based on my past experience and started to adapt before other developers were even thinking about it.
I recently wrote about my predictions for programming in 2025 in my newsletter.
You can read it for free here 👇
www.liamwalsh.tech/newsletter/programming-predicti…
9 months ago | [YT] | 1
View 0 replies
Liam Walsh
Never getting what you want is super annoying.
I've never been a good negotiator but I at least thought I understand how to negotiate. You make the case, show the data, you put in the effort.
It never paid off.
Time passes and things weren't getting any better!
I constantly had to face the sad realisation that I sucked at negotiating. I was ready to give up. To just settle for what I had and stop trying so hard.
I contemplated and brewed for about a week until I finally snapped out of it.
"NO!" This can't be it.
I knew that negotiation was a skill, I'd seen better negotiators walk away with much more than I ever could.
I could learn.
I began my search online like anyone else. Found some articles, books and videos but they were all the same.
I knew all of this already and it didn't work.
Was the conventional wisdom wrong?
And sure enough, it was.
I read Never Split the Difference by Chris Voss and found out how wrong it all was.
I recently wrote about my experience reading the book and applying the concepts to my own life as a software engineer.
You can read it for free here 👇
www.liamwalsh.tech/newsletter/the-one-book-softwar…
9 months ago | [YT] | 0
View 0 replies
Liam Walsh
I've been working as a developer for over 12 years. I've made so many mistakes during that time.
If gets worse because a lot of that time wasted could have been avoidable knowing what I know now.
What if you could steal someone else's 10,000 hours of experience, successes and failures?
Well the lucky thing is, you can! You just have to find the right person who's walked the path you want to take, have a conversation with them and hear their stories.
Today I'm going to be sharing all the tips, tricks and truths I've discovered along my programming journey.
You can read all about it in this newsletter 👇 the great thing is it only takes 5-10 minutes. Time saved 👍
www.liamwalsh.tech/newsletter/30-programming-tips/
9 months ago | [YT] | 0
View 3 replies
Liam Walsh
I had been denied or pushed back on promotion to senior software engineer for about 3-4 years.
It got worse when I realised I was essentially trapped in this "mid-level" prison. I had been in there quite a while but didn't understand why.
I didn't blame anyone else except myself. So I began analyse why this was happening and really analysing the feedback I'd been given. I realised it was all preventable.
I'd read a book called Extreme Ownership by Jocko Willink which opened my eyes to the truth. It was my fault AND my responsibility to get out of this prison.
The solution was... ownership! Not just technical ownership at work but ownership for taking control of the progression of my career.
It then only took one year to finally get promoted.
If you're currently struggling to break out then I believe you can learn from my mistakes and escape a lot sooner.
Get the full details of my breakout in my latest newsletter below ⬇️
www.liamwalsh.tech/newsletter/escaping-the-mid-lev…
9 months ago | [YT] | 0
View 0 replies
Liam Walsh
"I'm average, I am definitely a part of the 99% of software engineers."
That's me, that's my mind in 2020. I wasn't a great software engineer and I knew it. I wasn't even sure if I even average!
It got worse because I didn't believe I could become great.
My thoughts started to become my reality as I stayed in my comfort zone and rarely stepped out into the unknown.
I was stagnating and starting to lose the energy and passion I once had.
In 2024 I still don't think I'm great, I'm still not sure where I fall on the scale but there's one difference between now and 2020.
I believe I can become great.
I know I am not as good as I want to be, but I am where I am now. I accept that but commit myself to the process of improving everyday.
I step out of my comfort zone, I take on the challenge, I accept the failures, learn and adapt.
I changed the perception of myself and the repositioned the frame.
I might never be great, and understand that greatness is a factor for other to determine.
But... I will never let myself believe I can't be, that I give myself the excuse to relax and not give it everything I have.
I've been lucky enough to work with some great software engineers over the last 12 years. I wrote about some of the keys things they do that others don't in my newsletter.
If you missed it then grab it below 👇
www.liamwalsh.tech/newsletter/get-ahead-of-the-99-…
10 months ago | [YT] | 1
View 0 replies
Liam Walsh
I've always been afraid.
It's a hard thing to admit but I've always been a bit of a coward.
If I hadn't grown as a person in the last few years I would have caved into the "programming is dead", "software engineers are done" narrative.
Even worse I would have swapped career paths or crawled into a theoretical cave seeking safety.
Buried my head in the sand to avoid seeing what was coming.
I would have ruined my future prospects.
But I'm not as cowardly as I sued to be. I've grown.
I listen to the fear mongers and I face them, question them, challenge them.
I started to think critically and form my own perspectives rather than relying on somebody else's judgement.
If they're out to scare you then they don't care about you.
Nobody who cares about you tries to frighten you.
They warn you but they don't go out of their way to make huge statements with little evidence.
The solution for me?
I stopped listening to them and instead started doing for myself. Testing what's real, creating for myself.
Not letting emotion steer the ship.
I recently posted a video about hope for software engineers in 2025.
You can watch it for free here 👇
10 months ago | [YT] | 0
View 0 replies
Load more