Reading time: 4 mins
The Magic Word
3 Reasons Why We Must Say No More
1) Stress and Overwhelm
2) Opportunity Cost
Reading time: 4 mins
I hope that you are well! As I am well over a year into my coding journey, I just thought that I would put together a couple of the resources that have really helped me progress on my path! It’s a collection of online courses, books and meetups (in the UK) that have been a great help! Hopefully they will help you too!
I can’t speak highly enough of these guys! Teamtreehouse.com is an online school that teaches a whole lot of courses to teach you to code and get you job ready at a reasonable price! They use a combination of video, code quizzes and have a great online community that will help you if you get stuck! I am currently taking the techdegree now and I have written some blogs about my progress! It’s definitely worth a look!
It’s a free online coding school that uses primarily text and code quizzes that teach you to code in a number of languages. What I have found great about CodeAcademy is that they walk you through a number of real-world projects so that you can gain experience. I use this alongside Treehouse and this has really reinforced my learning!
This book honestly has transformed my learning journey. Oakley’s book challenges the assumptions that maths and science is a GOD given talent and that these skills can be learnt. Oakley’s book is about Maths and Science in particular but about learning how to learn. I have taken many of the ideas in this book and applied it my own life with great results! Read my review here!
Codebar.io run free weekly workshops, regular events and try to create opportunities for our students making technology and coding more accessible to underrepresented groups. Now they have a number of branches in London and around the UK and branches in Berlin, Germany and Barcelona, Spain. These guys have been absolutely essential in my growth as a programmer and if you are in the UK or any of the other places, please look them up!
Thank you for reading! If there is any resources that you have found helpful in your path to learning to code, list them in the comments below or tweet me @karlwebdev!
As always, see you next Thursday!
Reading time: 5 mins
But when it comes to creating a new project from scratch or when I am given a more complex challenge, I become stuck. I have reached what Eric Trautman said in his brilliant blogpost “Why Learning To Code Is So Damn Hard” the ‘Desert of Despair’. After a couple of months of scratching my head, I slowly realised that I was missing a key tool to help me survive this desert, Indiana Jones style…
This I discovered was the million-euro answer. It’s problem solving. The Oxford Dictionary describes ‘problem-solving’ as the “process of finding solutions of difficult or complex issues”. Although good coders can write decent code and through some programs together, great coders use their code to solve problems. Like giving dogs and cats typewriters and expecting them to produce Shakespeare, was like my method of writing loads of code and hoping that answer would reveal itself – there had to be a better way.
Vicker’s book is extraordinary (book review coming soon) and he devised a 4 step framework that you could use to help you tackle most coding problems!
Vickers believes that most of the coding problems that we have is simply because we do not have a enough of a grasp of it to solve it. Humans are good at ‘abstraction’ which means that we can look at something i.e a thing, an idea and a person and understand what it is without going to very specific details. For example, if I asked you to ‘think of a dog’, in general you would think of a small animal with four legs, fur and a tail without having to think about whether it was a poodle or a rottweiler.
But in coding, the issue is that these ‘abstractions’ lead to assumptions that can actual hinder us in solving the problem. A great personal example of this was once when I was teaching a school class, I had a video clip that I wanted to show them but it was showing without any sound. After 10 minutes of unhooking the speakers, checking the software drivers were up to date and turning the machine on and off, I realised that the actual volume in the Media Player was turned off! It’s only when I went through it step-by-step, did I realise the error in my thinking.
If you are confronted with a large, complex problem, break it down it smaller, simpler chunks and solve those instead. Another tip I gained from the book is that if you become stuck, explain the problem to yourself as you would a small child: this will force you not to think less abstractively and take it step-by-step and this really works!
Once you think that you have understood the problem and broke it down to it’s core components, not you can start planning the steps that will give you the solution. This is not a static process: while planning the steps, you may find that there still maybe flaws in your thinking and you may have to go back to Step 1. Don’t worry, as the planning helps strengthen your understanding of the problem and lead you to new possibilities that you just would not of known in the planning stage.
Vickers suggests that you should display plans in more than one way i.e flowcharts and pictures so that it forces you to look at your plan from at least more than angle and this can help you get a different perspective on how it can be done.
Once you have done Steps 1 and 2, its now time to put the plan into action. So does that mean that as soon as you click ‘launch’, your job is done and you can sip your Tetley tea? Not on your life. To quote that great philosopher Mike Tyson, “everyone has a plan until they get punched in the face”. Remember as much as you plan, it’s not possible that you will perceive every possible outcome. Your code will have to go through a ‘testing phase’ where you will have to remove bugs and rearrange your code until everything runs smoothly.
At this point, it very easy to get discouraged when your program doesn’t work properly but remember this is normal when you ‘ship’ your solution. Good programmers understand this and don’t let the bugs and the failures hinder them and they keep on truckin’.
So you executed, everything works smoothly and you are ready to jump on your horse and ride into the sunset. Not so fast Clint. The best programmers will often look at their solutions and evaluate them to see what they could learn. Great programmers ask themselves questions like:
Good coders don’t work in isolation. They allow peers and other users to critique their work and make suggestions on how they can improve. Throughout this phase, Vickers believes that good coders write documentation not just for other users but themselves which helps consolidate everything that they have learnt.
Although this framework is incredibly simple (as it should be), it has been a real eye-opener for me as it gave me a plan of attack in which to help create better solutions.
Another aspect I liked about this framework was that made me feel that it was OK not to have the right answer straight away and we have to sometimes have to fail many times before we get the ideal solution. Of late, while learning to build more complex programs, I felt frustrated much of the time and dare I say it, part of me was questioning whether I really had ‘the chops’ to learn coding and was feeling a little lost. This framework has given me confidence that ‘failure is not final’ and in fact is the true path to successful and happy coding!
Thank you for reading! What did you think? As always, leave your comments below or tweet at me @karlwebdev.
See You next Thursday
I have a question: what does edgy comedian Chris Rock, animated movie powerhouse Pixar and Jeff Bezos, Founder of Amazon.com have in common? (I know that this sounds like the setup to a bad joke but just roll with me here!)
They all take “Little Bets”.
So what are they? “Little bets” are small, concrete low risk actions that are made to discover, develop and test ideas. Peter Sims believes that the most innovative, creative and successful artists, individuals and companies consistently use “little bets” to stay ahead of their fields and Sims provides the step-by-step playbook in which they make this happen.
When it comes to creativity and innovation, there are generally 2 assumptions:
1) The people who come up with the most creative and innovative ideas are just geniuses i.e Walt Disney, Prince or Steve Jobs
2) The great world changing ideas come to these people in a flash: fully formed, perfect and the superstar creative puts all his time, resources and energy (bets the farm) on this idea and becomes a gazillionaire.
Sims through extensive research and by doing in-depth interviews with 4-star generals, superstar entertainers and Silicon Valley pioneers disagrees. What Sims noticed is that although they operated in different fields, these pioneers used surprisingly similar approaches to coming up with great ideas and solutions using experimentation, being playful, looking at the project/problem from every angle and if something is not working, changing direction quickly or ‘pivoting’. Many chapters of the book cover one of these aspects in detail and at the end of each chapter, Sims provides concrete action steps that you can implement into your own projects.
For me this has been a great book. The number 1 take-away of this book has been what Sims calls “small wins”.
Sims explains that when most people want to start a new project or goal, they look at it from the wrong way around: they start off with this grand vision of what the end should look like i.e landing their first coding job or building a successful business and they plan all the steps that will get them there. But Sims believes that is a bad idea as with any detailed plan, things are likely to go wrong and there will be many external factors that will throw the plan off course. Most people at this point get frustrated and give up.
Sims argues that innovators instead of focusing on the ‘grand plan’ focus instead on “small wins” which are small , positive actionable steps that show them that they are going in the right direction. Sims used comedian Chris Rock as an example of this trait. Before Chris Rock embarks on a worldwide stadium tour or major hosting gig, Rock will many months before go to tiny, more intimate venues locally to test his material. Rock comes unannounced with has a rough outline of the subjects he wants to discuss on a legal pad: many of the jokes are half-baked and many “bomb” but when he does get a laugh, Rock watches intently, logging it down. After doing this dozens of times, Rock slowly builds and refines his act to the award-winning, box-office smashes that he’s known for.
The “small wins” concept has a lot in common with “The Slight Edge” where it focuses on small consistent actions rather than massive ones. At first when I signed up to the Teamtreehouse Tech Degree, I honestly believed that I would be able to become a proficient coder in 6 months – but things didn’t go to plan. I started to get frustrated and wondered whether coding was for me. But remembering this lesson, I started to focus on the “small wins” like understanding loops or functions rather than landing that coveted job. The “small wins” focus made my learning less frustrating and increased my confidence that I was improving and nearing my goal.
I loved this book but the only downside was that it could be a little wordy in places and towards the end it got a little repetitive – but don’t let that stop you! This is a must-buy!
Final score is 7.5 out of 10
Thank you for reading! As always let me know what you think by leaving your comments below or tweeting at me via @karlwebdev.
See you next Thursday!