3 Career Lessons I Learnt From “Hidden Figures”

Reading time: 5 mins

hf-poster

I went to see “Hidden Figures” last week and I absolutely blown away! The hype is real! The film is based on the lives of Katherine Johnson, Dorothy Vaughn and Mary Jackson, black female mathematicians, engineers and computer scientists that worked for NASA in the early 1960’s under the racist Jim Crow and Segregation Laws. Not only did these helped put Man on The Moon but helped advance the fields of Science, Mathematics and Technology and some of this was before US segregation even ended!

At first, I was going to do a straight-up movie review, but a) that would be too easy and b) that’s why Rotten Tomatoes was created… So I decided to write about 3 career gems that I learnt while watching this great film!


***MAJOR SPOILER WARNING*** This post will be discussing major plot points of the film, so it you haven’t seen it yet and don’t want it to be spoiled, stop here, watch the film and make your way back here. You have been warned…


1) Be So Good That They Can’t Ignore You

Hidden Figures Day 41

In the film, our three heroines were known as ‘computers’, human beings who could work out long and complex calculations with speed and accuracy. Because of the Segregation Laws, whites and ‘coloured’ people had to be separate which meant that coloured had to put up with inferior utilities, services and be treated as second class citizens. The black computers were segregated in the ‘West Area’ while the white ones in the ‘East Area’. In the movie, the ‘East Area’ needed more talented computers and Katherine Goble (before she got married and changed to Katherine Johnson) was selected as the first black female to cross the barrier and found herself working closely with the Director of the Space Task Group, Al Harrison.



hf-running


However it wasn’t smooth for our dear Katherine. Katherine was treated with suspicion, had much lower pay and her line manager left out key parts of the calculations which meant that she could not do her work accurately. To add further humiliation, in the East Area, there were no coloured toilets, which meant that Katherine had to run to walk 20 minutes to the West Area just to relieve herself. When Al Harrison publicly rebuked her for being away from her desk for long periods of time, she emotionally explained that all the difficulties that she faced being a coloured woman in NASA. Very shortly after Harrison, abolished the toilet segregation rules and Katherine found herself being treated as more as an equal and playing a more pivotal role in the Project.


Although this was heartwarming, there is a very clear fact that emerges: Katherine was brilliant and she was so good at what she did that towards the end of the film, John Glenn refused to fly unless Katherine personally checked the launch calculations. There is an old Bible saying that says that “A man who is good at his work will serve before Kings and not mere men.” Cal Newport in his great book “So Good That They Can’t Ignore You” stated that those who work on critical skills that serve the marketplace can basically write their own life ticket. Work on your skills and they will work for you!


2) If You Are Not Learning, You’re Dying

hf-dorothy-ibm


Dorothy Vaughn, the unofficial supervisor of the West Area, learns that NASA is going to install the IBM 7090 mainframe – a massive room-wide computer that could do thousands of calculations per minute – making the human computers obsolete. Rather than defeated, Dorothy quickly figured out that, although they maybe able to do the calculations, they will need someone to program the machine with correct ones.


hf-dorothy-fortran


Dorothy, after taking a FORTRAN book from the public library, started to teach herself computer programming and also taught her colleagues ready to configure the supercomputer. When the IBM 7090 was fully installed rather than lay off the entire West Area, NASA promoted Dorothy as the supervisor of the Analysis and Computation Division, saving her colleagues’ livelihoods and helping usher in the new Technological Age in Space Travel.



hf-west-area-walking


I love this part of the film! Dorothy created a new opportunity for herself and her peers by leveraging technology rather than being crushed by it and she did this by improving herself. Continuous learning is an absolute must if you want to survive in the Information Age. And this does not apply only to programmer either – with the increasing technological, social and economical changes in our world, your willingness to adapt quickly and evolve your skillsets will be vital to your life success. To adapt 50 Cents famous album cover we now must “Get Skills Or Die Trying.”


3) Nothing You Learn Is Ever Wasted

hf-kath-chalk
In a key part of the film, the Americans were behind in the Space Race – The Soviet Union managed to send a man to Outer Space and complete a full orbit of the planet. They needed to better and fast.


The Americans started the Mercury Program to go beyond and even the odds. The human computers were tasked with coming up with the Math that will allow an astronaut to go into space, stay in circle the planet a coupe of times, then break orbit and return to Earth. The problem was that this hadn’t been done and they needed a new set of Maths to calculate the capsule’s flight – and they have 2 weeks to do this before the launch.


After many long nights, Katherine recalled “Euller’s Formula” an almost 300 year old set of equations to help solve the problem. After a couple of hours adapting the formula, they finally solved the problem and the Astronaut, John Glenn, managed to do 3 orbits around the Earth becoming the first American to do so.


What’s so great about this example is that Katherine’s line manager at NASA described the formula as “ancient.” But this didn’t stop Katherine from using it to get the job done. Before I started to learn coding. I would many jobs from a retail sales assistant, an inventory planner, a music performer/producer and my latest career, a teacher. And as the years go by, I have managed to use most of my skills in my teaching practice. I was intimidated because I didn’t have a Computer Science degree but I soon realised that virtually all my skills in sales, writing, negotiation and organisation have helped me become a better coder.


Take stock of all the jobs and courses that you have studied over the years and see what skills that you use today: you will be very surprised on how these skills give you a unique advantage in your job and can help you get the next one!


I hope you enjoyed this blog! Please go and watch “Hidden Figures”- it’s a very inspirational film. Have you watched “Hidden Figures?” What do you think? Leave your comments below or @karlwebdev.


As always, see you next Thursday


Karlwebdev


The Number #1 Skill You Need To Be Great At Coding

Reading time: 5 mins

sherlock-vision

This man knows how to do this well…

Houston… We Have A Problem

Since starting to learn to code over a year ago and now 6 months into my Techdegree, I am in a very weird place in my journey. On one hand, when it comes to Javascript, I can just about get my head around the concepts and ace all the little code exercises that are part of the learning program.

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…

Problem Solving

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.

4 Steps To Solve Problems

In my search for the answer, one book to my rescue. “How To Think Like A Programmer: Problem Solving For The Bewildered” by Paul Vickers was written for people like me: folks who just wanted to learn not just how to code but when to use it and build stuff. Vickers felt that a lot of coding books and online resources would teach you ‘how’ to code but would not tell you ‘why’ you would use a method and ‘when’ you would need to apply it. Vickers felt that the actual language i.e JavaScript or Ruby shouldn’t be the main focus but the problem that you are trying to fix.

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!

1) Understand The Problem

apollo-13

You know the catchphrase… I said it already!

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!

2) Devise The Steps

ironman-rocketboot

As they say the Iron Man suit wasn’t built in one day…

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.

3) Execute The Solution

wright-brothers

The Wright Brothers had the right idea…

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’.

4) Reflect Upon The Solution/What Did You Learn?

obama-thinking

This fella will have a lot of time to reflect now…

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:

  • What could I have done better that would make the program faster/more responsive/less bug prone?
  • What did I do well?
  • If I had time, what could I add/take away that will make the program better for the client/user?

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.

Conclusion

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

Karlwebdev