Posted on

Probability teaser 1 – the Monty Hall problem

Introduction

I recently posted the following teaser on Twitter:

Self-doubt

This is known as the Monty Hall problem, named after the game show host.

When I first read this problem, my brain initially told me that my chances were 50/50, whether I stuck with my first door or switched to the only other closed door. Of course, I’m a bit of a natural sceptic and so I had this niggle in my head that said 50/50 was too obvious. So off I went to read up on the problem.

A number of people responded to my tweet. Most thought it was also a 50/50 chance even when I tried, in a limited stutter of 280 characters, to explain the real answer. One person said it would be higher than 50/50 but they couldn’t remember the maths and only one person gave the correct answer, so let’s see if we can get there together.

Breaking it down

Let’s begin with just three doors.

? ? ?

One door has a car behind it, the other two have goats. Your chances of picking the car is 1 in 3, 1/3, 33.3% to use various measures. I will use a probability measure of 0.33… which is on a scale of 0-1. If you add up all the probabilities of events that can happen, they will add up to one. You can only pick the car or a goat. There are no other options. Therefore, the chances of picking a goat are 2/3, or 0.66…. This can be calculated as 1-0.33….

(Note, for numbers that are recurring, I am using two decimal places with the … notation)

The doors can be setup before the game as below, G=goat, C=car:

GGC

GCG

CGG

Remember what happens when you pick your door? Monty will open all but one of the other doors to reveal a goat, so you end up with your chosen door and one unopened door. So one of two situations can happen here.

  1. You pick the car 1/3 of the time and the other door will always be a goat
  2. You pick a goat 2/3 of the time and the other door will always be the car

The teaser asks, what is your chance of winning the car if you switch doors. Therefore, 1/3 of the time when you switch, you lose (or win if you prefer goats) and 2/3 of the time when you switch, you will always get the car. So no 50/50 here.

It gets better

OK, the last section started with the basics using just 3 doors, but my question was with a game using 10 doors. Let’s use the same process but update the numbers accordingly.

? ? ? ? ? ? ? ? ? ?

One door has a car behind it, the other nine have goats. Your chances of picking the car is 1 in 10, 1/10, 10% to use various measures. I will use a probability measure of 0.1 which is on a scale of 0-1. If you add up all the probabilities of events that can happen, they will add up to one. You can only pick the car or a goat. There are no other options. Therefore, the chances of picking a goat are 9/10, or 0.9. This can be calculated as 1-0.1.

Remember what happens when you pick your door? Monty will open all but one of the other doors to reveal a goat, so you end up with your chosen door and one unopened door. So one of two situations can happen here.

  1. You pick the car 1/10 of the time and the other door will always be a goat
  2. You pick a goat 9/10 of the time and the other door will always be the car

The teaser asks, what is your chance of winning the car if you switch doors. Therefore, 1/10 of the time when you switch, you lose (or win if you prefer goats) and 9/10 of the time when you switch, you will always get the car.

So…always, always switch!

Still not convinced?

OK, sometimes people like to see this in action and so I’ve created a Python script here that simulates the game. Please don’t troll me too much for the lack of Pythonic code, although I welcome constructive feedback! Hopefully the code is commented well enough for you to see what it is doing.

Summary

I’ve always loved probability and statistical type problems because they are great examples of using pure mathematics to challenge people’s assumptions and biases. Hopefully, you found this example clear. If not, let me know so I can improve upon it.

Till the next time.

Posted on

The truth about Boolean values in Python

Introduction

George Boole was an English mathematician who is credited with having invented a branch of algebra in which an expression is evaluated to one of the truth values, true or false. Unsurprisingly, this became known as Boolean algebra (I’m hoping that Thompsonian snark will be a thing in the not too distant future).

This post looks at how all objects in Python can be tested for a truth value and what that means.

True dat

In Python, you can assign True or False to any variable.

That’s all well and good and is very useful if we want to have a binary type value to assign, rather than trying to use 0’s and 1’s,  ‘yes’ or ‘no’ etc., which could cause confusion with your code where you also use those values for other purposes e.g. it probably doesn’t make sense to have 5 -5 = False.

You can’t handle the truth

Additionally, in Python, any object can be tested to see if it is truthy or falsy. What does that actually mean? Take a look at the following code:

 

A nice and simple example but for beginners to Python, the second if statement might cause confusion. Initially, let’s confirm we understand the first if statement; if the foo variable refers to the value 5, that branch runs i.e. bar() is called, if not, that branch is skipped.

What about the second example. What is if foo: doing? This is where Python tests the truthiness or falseness of the foo variable. In short, that statement means if foo is truthy, run that branch, if it is falsy, skip that branch. So bar() will only be called if foo is truthy.

True or False

The truth will set you free

So what determines if something in Python is truthy or falsy? It depends on the type being evaluated. The table below lists the main types within Python. Remember that these are all objects in Python.  (Some other languages consider data types such as strings and tuples to be primitives.)

Type When is it truthy? When is it falsy?
str Not empty Empty, ”
list Not empty Empty, []
tuple Not empty Empty, ()
set Not empty Empty, set()
dict Not empty Empty, {}
int Not zero, 0 Zero, 0
float Not 0.0 0.0
bool True False
NoneType Never Always
Function Always Never
Class Always Never

Let’s go back to that second if statement.

There is a really handy built-in function we can use to tell us if something is truthy or falsy, the bool() function.

Summary

This post began discussing the True and False Boolean values you can assign in Python and then went on to discuss how all objects in Python can be tested for a truth value and what that means. I hope this has been useful.

Till the next time.

Posted on

We need more mentoring in IT

Introduction

In an earlier post on strengths and weaknesses, I briefly talked about a general lack of mentoring in IT. Having given this some further thought, I thought I’d tease out some more salient points on the topic.

I like the following definition of mentoring so will be basing my post on this:

Mentoring is to support and encourage people to manage their own learning in order that they may maximise their potential, develop their skills, improve their performance and become the person they want to be– Eric Parsloe, The Oxford School of Coaching & Mentoring

What is the problem?

The diagram below (FYI, produced in PowerPoint thanks to this great little video) broadly represents the distribution of knowledge in our wonderful field of technology.

Bell curve

Note the following observations:

  1. Nobody knows nothing
  2. Nobody knows everything
  3. There is a certain level of knowledge at which the numbers drop off steeply
  4. There is a clear grouping near the middle
  5. The graph also provides a reasonable model of the speed at which people acquire knowledge. The y-axis represents that speed

The first two points are worthy of further discussion:

Point 1 essentially means that everybody has something to teach somebody else.

Point 2 is the same as point 1 but flipped on its head. Everybody can learn something from somebody else.

Yet the theme of this post is that there is a lack of widespread mentoring going on in IT. By that, I simply mean that it is far from being the norm and would benefit from serious improvement.

How to address the issue

If you work somewhere that encourages people to mentor others (which is lovely!), it is likely that the people who sit towards the right of the graph above are mentoring people who fall further to the left. If you are less fortunate, you might find that it is longer serving people mentoring people who are less time-served, which isn’t always useful. Of course, who gets to mentor who might simply be decided by the length of one’s beard, which is wrong for a whole number of reasons, a key one being that some of the most knowledgeable people I’ve worked with are unsurprisingly incapable of growing a beard.

However, one can combine points 1 and 2 above under the following statement:

Anybody with knowledge should be able to mentor somebody without that knowledge– Vegaskid

As well as strengthening people and teams across your business, with all the benefits that brings (happier staff, increased productivity, personal and business growth, innovation, collaboration, etc.), a common business risk is also mitigated i.e. the risk of a ‘key master’ walking out of your organisation with unique knowledge that nobody else knows. I’ve seen this happen in a number of organisations and it puts unnecessary strain on those who stay and can stunt growth, both at the individual and organisation level, whilst the gaps are filled.

Building on the foundation

So, having read this far, are you ready to have a think about what you are knowledgeable about and offer to transfer some of that wisdom to somebody else? Or even just to offer support at any level? It needn’t be in a more formal format if that isn’t your style. It could be as simple as emailing snippets of information, or posting to your Intranet. Or writing a blog post to a wider audience. Or simply walking over to somebody’s desk and having a chat about what they are working on.

Businesses should enable and encourage this behaviour and make it part of their culture. Reward people who do it, at the very least by acknowledging it and giving them the time to do it. That is often all that is required.

Beyond our own organisations, I would love to see an industry wide movement to help foster a mentoring mindset. A combination of bottom up and top down approaches could really help across the board.

Summary

In this post, I’ve deliberately steered well clear of the reasons why people don’t mentor up to this point because in my experience, it usually has something to do with either the culture of the business or individuals having a fear of losing some level of perceived control or worth by sharing knowledge with others.

I think the best way to address starts somewhere in the middle i.e. businesses enabling and encouraging their people to share knowledge whenever they can. The rest is up to you.

Till the next time.

Posted on

Working with strength and weakness

Introduction

Do a search online for “people’s strengths and weaknesses” and you’ll get a deluge of advice that tends to throw more weight at dealing with weakness than fostering strength. This post briefly adds to the deluge, but turns that approach on its head.

Strength > weakness

As individuals, we often get hung up on weaknesses, both our own and of those around us. There seems to be an unrealistic expectation, especially in technology, that we should be experts at every level of the stack.

This expectation is not helped by less tech-savvy friends and family.

You work in IT, can you fix my house alarm?-Dad

It is also not helped by colleagues who are more knowledgeable than us, but don’t know how to mentor. And it is most certainly not helped by working environments that are clueless how to address weakness and end up creating teams of mediocre generalists.

Everybody has the potential to be great at something. It is quite heartbreaking to think that the vast majority of people who never find that thing or at best never really get to develop it to their full potential, fail because of an unproductive focus on their weaknesses rather than their strengths.

Weakness

Often, this is self-inflicted by people who beat themselves up for not being great at everything they put their mind to. It is also down to external factors not nurturing people’s strengths and rather than counter their weaknesses by balancing them across a team, choose to focus on them, again, an often unproductive path.

Teams > individuals

The key to dealing with weakness (and conversely strength) is to build teams that complement each other, based on a number of key factors:

  • Manager’s/leader’s ability
  • Company’s hiring process
  • Candidates honesty on CV/in interview as to what their strengths and weaknesses really are

The first two points refer to how good the workplace skills and processes are to firstly determine the existing strengths and weaknesses in the teams and what strengths would both complement them and the future strategy of the business.

The third point is something I’ve not heard discussed much due to a get the job at any cost attitude but as somebody who has been in a hiring manager role previously, I’ve seen CVs come across my desk which simply beggar belief. People claiming to be a mythical unicorn in terms of skills and experience and when they’ve come in for interview, they’ve not been able to back up the claims under a modicum of pressure.

If you land yourself a role by being overly economical with the truth regarding your skill set, it shouldn’t come as a surprise that at some point, you are going to be expected to carry out tasks which fall in to your “weakness zone”. You need to be prepared when that time comes, one way or the other.

Summary

As individuals, I think people would be far more productive if they focused more on their strengths than weaknesses. Sure, address those weaknesses that are holding you back in your chosen path, but if you work in the right team, in the right company, the balance of the team should allow you to flourish regardless.

Companies take note too. The best teams have members who have roles that play to their strengths, those combined strengths blending together to negate any key weaknesses across the team

Till the next time.

 

Posted on

To recertify or not

Introduction

I counted them up the other day and I’ve done over 30 exams since I’ve been working in IT. Mostly in Microsoft and Cisco, with a CompTIA Security+ thrown in to upgrade my MCSE 2003 along the way. Most of those certifications have expired, having either been upgraded along the way or left to die with a modicum of dignity. This post looks at some key reasons why you might want or not want to recertify/upgrade your certification when the time comes.

Why certify in the first place?

Whilst some people in IT go all in on the certification train, others never take an exam in their career. So what reasons do people have in each camp? There are probably as many reasons as there are people I’m talking about, but some possible answers might be:

The aye’s

  • Like to measure their knowledge against a known standard
  • For vendor partnership levels and incentives
  • For the kudos amongst colleagues and peers
  • To gain vendor best practice knowledge
  • To aid them in their day to day job
  • A requirement of their employment
  • Looks good on the CV

The no’s

  • They either know what they don’t know and pursue it in other ways or they don’t know and have no wish to find out
  • Not keen on the pressure or format of exams
  • Exam blueprint not relevant to their role
  • Got better things to do

In short, IT certifications are for some people, not for others and some just get forced to attain them.

Recertify

Why recertify?

However, the point of this post is around recertification. Once you’ve proved you have the knowledge to pass an exam, what drives people to recertify at some point in the future, sometimes three or more years later?

Again, a list of contenders would be:

  • To make sure you prove your knowledge with the new blueprint
  • Maintain that kudos
  • Maintain partnership levels and incentives
  • …in fact, the same reasons for getting the certification in the first place

Although, here is my issue with IT certifications:

  • The blueprint never matches my day to day job. It usually has a good 25-50%+ of content that I’ll probably never use
  • The whole IT certification business is a gravy train. Vendor A are selling me their product and then charging me on top to learn how to use it and more money still to show that I can prove I can use it? And we need how many ABCDs to get gold partnership? Too much hoop jumping. There is a fear that letting certifications expire means previous investment in knowledge is just lost
  • Once you’ve been in the business for a few years (let’s say 10+ for the sake of putting a number on it), I’d like to think that my previous experience and endorsements count for more than a transcript

Depend upon it there comes a time when for every addition of knowledge you forget something that you knew before. It is of the highest importance, therefore, not to have useless facts elbowing out the useful ones. – Sherlock Holmes

Summary

I did 75% of my 30+ exams in the first half of my career. As time has gone by (ok, and possibly as my brain has grown older), I’ve come to the conclusion that focused knowledge that can help me in the short to medium term is far more valuable than certification blueprint knowledge that might, in part, serve me for the next three years. Time is of the essence, I don’t want to be studying things I won’t use anymore.

I’ve taken this approach for the last three years and have no regrets about it at all. It has allowed me to learn many things that I would simply not have had time to if I had focused only on certifications that I needed. Don’t be afraid of jumping off the certification train.

Having said that, my CCNA (R&S and Security) was due to lapse next week and this was always my favourite exam, so I caved in and did the resit. The reason? See the list above 😉

Till the next time.

Posted on

Games for the family

Introduction

I know a lot of nerd types that like playing games. To be clear, I’m not talking about mind games or computer games here, but good old-fashioned family games that usually involve a board or pack of cards of some sort.

This post covers off some of the Thompson family favourites that we keep coming back to, to keep our minds sharp and gently take the mickey out of each other.

Family games

  • Uno. This card game was introduced to us by a family we met on summer holiday in 2014. We still play it now, and we still keep in touch with the family. In fact, we went on holiday to Spain with them in 2017 and played Uno every night whilst drinking the all-inclusive gin. You basically discard one of your cards when it’s your turn to match the colour or value of the card in the middle, with various special function cards such as change colour, skip a go, reverse direction, pick up two (for the next player). This game provides the perfect blend of luck and skill to allow all ages to play together.
  • Frustration. A board game, based on the older game Ludo. Instead of a handheld die, there is a clear dome ‘Popamatic’ in the middle that you push down to make a satisfying pop and spin the die (in newer versions, the outside of the board has a mini paddle for each player that flicks the underside of the dome for the same effect. Again, thanks to the random die factor, this makes for a great game for all ages.
  • Dobble. We only recently discovered this card game and it is as fun as it is frustrating. The pack comes with 55 cards and there are a number of alternative game options you get instructions for (you can probably make up your own too). The premise is that each card has a fixed number of symbols on it (tree, sun, igloo, etc.) and that any two cards only have a single symbol in common with each other. The common theme with the game types is being able to recognise the common symbol between the cards the fastest. This sounds simple enough, but the symbols appear at different sizes on cards and as symbols are matched by a , some of the cards are removed/replaced by others and so you get this manic panic going on (might just be me, evidence suggests otherwise!) where you are trying to spot the common symbol and somebody gets to it before you, then you have to start again. Great, fast paced mind game, again for all ages
  • Backgammon. Still trying to get my 10-year-old daughter in to this, but my wife and I love playing this ancient classic, especially with the doubling cube to add that extra level of skill

Less popular alternatives

There are many other games that we sometimes drift back to from time to time e.g.

  • Cluedo
  • Monopoly
  • Pie Face (doesn’t really have longevity, but good fun for larger family get-togethers)
  • Speak Out (in the same ilk as Pieface in terms of longevity
  • Bingo
  • Various quiz games inc. Trivial Pursuit

Summary

I’d love to hear from other people who spend a lot of time playing these type of family games. If you have other suggestions, or comments on mine, please do leave a comment below. We’re always looking for that next time-consuming game that lets us turn the telly off and put our electronics down.

Till the next time.

Posted on

Azure Stack – my take 01-18

Introduction

In the first few months after Azure Stack was announced, there was quite a bit of buzz around what it promised.

A true hybrid cloud experience, allowing workloads to move seamlessly between public Azure and your private Azure Stack data centre.

If anybody could deliver this, you’d think Microsoft could.

Later than expected, it has now been released under General Availability. This post takes a look at a couple of factors that I believe are key to the success of Azure Stack.

Scalability

Azure Stack is a fixed size hyper-converged platform. That is, the compute, storage and networking are tightly integrated with an overlaid software architecture. The fixed aspect refers to the fact that when you buy a Stack, you are buying a fixed number of nodes e.g. 4, 8 or 12.

I’m not a massive fan of hyper-converged infrastructure unless it’s dedicated to a well known workload that you can scale the nodes to. As soon as you put inconsistent or unpredictable workloads on there, you run the risk of, as an example, having to buy a new node (with all that compute, RAM and storage) just for the additional storage, even though your CPU and RAM utilisation might only be at 30% and 60% respectively. You can’t just buy more storage.

For me, one of the key definitions of cloud is scalability and flexibility. If you have an 8 node cluster, you don’t want to have those nodes sitting at 40% utilisation. You want them at near capacity, taking N+1 in to account.

I feel that the ‘pod’ approach that Azure Stack takes amplifies this problem even more. You can’t currently buy a 4 node pod and add another node when the cluster fills up. You need to buy another pod. That doesn’t come cheap.

I wonder, once the platform matures further, if Microsoft will allow single nodes to be added. It would mitigate the concern, but you are still limited to specific workloads if you aren’t going to be wasteful with your resources.

Feature parity

The big promise of hybrid cloud is running workloads in either your private data centre or the public cloud (Azure Stack and public Azure for the purpose of this post), migrate freely between the two, with a consistent experience regardless of where your workloads were.

That sounds like hybrid nirvana, but the current reality is less enticing. Stack was always going to deliver a subset of public Azure, but the feature gap today break’s the hybrid promise in their current state as far as I’m concerned.

The biggest difference is with the PaaS services. There are a number of hoops required to jump through to enable any level of PaaS services and requires licensing of additional VMs on the Stack to run some of those services, the latter point not really coming as a surprise though. For me however, PaaS is where the real benefits of migrating to cloud are reaped so this feels like a big bump in the road as it stands. A number of resource providers appear to be missing too. Again, I’m hopeful that as the platform matures, the capabilities gap will narrow considerably.

A great example of using a hybrid cloud setup is being able to DR your workloads from your private data center to the public cloud. You can currently do this with Azure Stack, but to fail the workloads back to your private Stack, you need to lift and shift them manually. This feels very much like a lock in to my sceptical mind. I can almost hear Admiral Ackbar shouting his warning out.

Microsoft are not offering any SLA on Azure Stack at the current time too.

Some of these shortcomings are likely to change over time but the key theme here for me is, what is the use case for purchasing Azure Stack? With no SLA, would you run your production on there? Would you use it for development on what is essentially a hobbled platform?

Summary

The idea of having a common interface to manage all your workloads, regardless of where they are hosted, is very appealing for obvious reasons. However, in its current incarnation, I can’t see a compelling reason to dive in to Azure Stack, although I have no doubt that over the next 1-3 years, it will mature to something that will genuinely be a game changer.

Have you deployed Azure Stack? If so and assuming you aren’t just talking about ASDK (the development kit that allows you to install Azure Stack on any tin), I’d love to hear what types of workloads you are running. How have you dealt with the shortcomings listed above? I’d love for you to reach out either on here or at my Twitter account to have a discussion.

Till the next time.

Posted on

2018 – predictions in tech

Introduction

First of all, best wishes to all my readers for the new year. Keep learning new things, aim to be the best you can be and find your happy place.

January seems to be the month of the predictions post. I’ve largely stayed away from these in the past, usually posting something relating to my own resolutions instead but am bucking the trend this year with a slightly tongue in cheek look at what 2018 might bring.

Predictions

  • Stuff is going to get owned. Most likely some of your details. It seems that there is no end to the ignorance, or perhaps arrogance of some organisations when it comes to protecting their customer’s data. As more data gets stored, more of it gets leaked so expect 2018 to be a depressing year of getting emails from Have I Been Pwned, especially when Patrick Gray from Risky Business is on his holidays.
  • SDx. It’s only a matter of time before coffee becomes software defined it seems. Whilst most of the nomenclature is industry spin, I do think that SDN will really come in to its own this year. SDWAN, a subset of SDN, has already made good progress in recent times. I expect to see an exciting level of innovation in other areas of SDN over the next 12 months
  • IPv6. Prediction here is that it will continue to grow at the completely unexciting rates that it has so far
  • Cryptocurrency. Have recently invested in this myself and am already seeing gains, but to be honest, I’ve not got a Scooby Doo what it’s about, but am getting up to speed. Doesn’t stop it being good fun though (disclaimer: as long as you are playing with money you can afford to lose!). I think we’re going to see a tonne of cryptocurrencies become relevant this year
  • Skillset. Whilst I don’t think this prediction is going to be explosive, I do believe more traditional IT engineers are going to realise that they need to up skill in order to remain relevant over the next 5-10 years. This discussion is already at least 5 years old but I see evidence of some die hard dinosaurs starting to get it. You don’t need to be a developer. You will benefit from learning some basic coding skills/knowledge
  • Hybrid cloud. Standby for an article on my take of Microsoft Azure, but I think more players will spring up this year, offering true hybrid cloud solutions

Summary

Let’s see how accurate these predictions end up being in 12 months time!

Till the next time.

Posted on

Writing good code 101

Introduction

A workmate of mine has recently been dusting off his coding skills and using PowerShell to access REST APIs to pull data and graph it in a dashboard. After falling down the never ending rabbit hole for a while, he tweeted the following question:


It’s not really a question that is best answered in a series of separate 140 character responses so I thought I’d write a brief post to try and distil my understanding of what good code is. A full time developer could probably tear this apart and flesh it out with all sorts of deep and meaningful computer science principles but I’m going to take the perspective of a coding hobbyist, with my target audience being the very same, looking for a quick answer.

Pictures are nice

Let’s keep this as simple as possible. Code can be functional and code can be readable. You want your code to be both at the same time. Let’s discuss those requirements a bit more.

Functional

Code that is functional, by my definition, is code that does what it is supposed to do and does it well. Bear in mind that I am talking about code that works well here. I am not talking about functional programming, which is a separate paradigm (you can melt your mind here). Some KPIs to bear in mind:

  • Works predictably. Expected results occur every time
  • As bug free as possible. Good run time error checking and code testing
  • Good validation of all user input. Don’t let humans screw up your hard work
  • Allows additional functionality to be added with relative ease. You don’t want to have to start from scratch every time

Readable

Code that is readable, by my definition, is code that another person who has a basic or even better, no understanding of your language of choice can browse through it and understand what the code does. It also means you can go back to your code in 6 months time and not ask ‘what the hell was I thinking?’. Some KPIs to bear in mind here:

  • Follows the language guidelines e.g. in Python, adheres fairly closely to PEP8, code is ‘Pythonic’
  • Is well documented. Good code is self-documenting i.e. the intention is clear in the code itself. Next best thing is well commented code
  • Not over documented. By this I mean focus on the guidelines and making your code clean. You shouldn’t need a comment for every single line of code. Try to make the intention speak for itself as much as possible
  • Does not have duplicate code, which can make understanding code more difficult as well as being generally inefficient. Learn about functions and classes to help with this

Bringing it all together

To write code that puts you on the right path to Venn diagram overlapage (pronounced o-ver-la-par-jay), you do need to put some effort in though. The key steps are:

  1. Learn some basic computer science skills. Not talking about getting a degree, but if you know some basic algorithms and understand what people are talking about when they reference loops, conditional branching, OOP, etc. you’ll be in a better place to answer the question ‘how can I write code to solve this problem?’
  2. Learn how the language of your choice implements those different features. Read the online documentation, buy a book, write some code!
  3. Collaborate. I’m a bit weak in this area myself as the coding I do is pretty much all specific to my workplace and besides, I have justified imposter syndrome. Work on other people’s code and ask for help on yours. This is a great way to gain experience and also improve productivity
  4. Set out to maintain functionality and readability before you write a single line of code. It’s better to incorporate both these requirements as you go, rather than trying to retrofit them later

Summary

In this post, I took a high level look at what makes good code. In answer to Craig’s initial question on Twitter, I would say code that isn’t functional and readable is not great code and could always be improved. Make functionality and readability requirements of all the code you write.

This post is aimed predominantly at beginners and hobbyist coders. Got any other advice? Post in the comments.

Till the next time.

Posted on

Getting started with coding – Part 7 – Next Steps

Introduction

In part 6, we looked at a number of training options to help take your knowledge and skills to another level.

In this final part of my Getting Started With Coding series, we will review what we’ve covered so far and then try to answer the question that will, at some point, inevitably crop up. “What do I do next?”. Continue reading “Getting started with coding – Part 7 – Next Steps”

Posted on

Getting started with coding – Part 5 – Version control

Introduction

In part 4, we discussed some additional tools to help your coding. In part 5, we look at version control, which is a way of tracking changes you make to your code (or in a wider sense, documents, information, etc.). As it is such an important topic, I think it warranted its own post, even though technically it is just another tool in your kit. Continue reading “Getting started with coding – Part 5 – Version control”

Posted on

Getting started with coding – Part 3 – Editors

Introduction

So you want to start following examples you’ve found online or in a book to learn more about your chosen language from part 2. Which editors should you consider to start knocking up some super useful scripts? Part 3 looks at three broad categories, giving some suggestions along the way. Continue reading “Getting started with coding – Part 3 – Editors”

Posted on

Getting started with coding – Part 2 – Languages

Introduction

In part 1 of this series, we addressed the key concerns people starting to code might have and also set out some key reasons why you should give it a go in spite of those, often unfounded, concerns. In part 2, we cover off how to go about picking one of the languages to learn to code in from the numerous choices. Continue reading “Getting started with coding – Part 2 – Languages”