Skip to main content

Bloggers Club: Managing and Achieving Goals

In this blog post, I will focus primarily on the struggles I've faced in managing and achieving my goals, as well as what I've learned from it.


Less is better

When it comes to managing and achieving goals, I've found that less is better.

I used to have many goals (which I used to share on my blog in the Skills Development List page) but then found that I felt like I was being pulled into too many different directions. By having too many goals that I was simultaneously working towards, it meant that I often didn't get things done - things were often constantly ongoing. This was rather tiring.

Once I decided to focus on fewer goals at a time, then I could actually start celebrating that I had achieved some goals.


Frame it differently

One of my personal goals used to be to lose weight. The thing is, I found that (as a horribly impatient person), there was too much of a delay between action and result. As someone who loved good (bad for you) food, hopping on the scale a week after being "good" and seeing a disappointing number in the scale would really get to me. 

However, since I had my daughter, my focus hasn't been on losing weight but on my waist line and my progress pictures. I realised that weight is just a number on a scale (Proof of this is that recently I lost about a kg in a month but also lost 8cm from my waist and the progress pictures clearly show a difference after 4 weeks). 

Another way I have decided to frame it differently is to focus on my daily and weekly water, food and exercise goals to live a healthier lifestyle - which then ultimately feeds into reducing my waist line and helping me see progress in my progress pictures. 


Remind myself of the 'why' constantly

For the longer term goals, I would sometimes forget why I set them in the first place. It felt like a "past Nicola" had set something for me that was no longer relevant, and if it was actually no longer relevant or important to me, then I would stop working towards that goal. But often I just needed a little reminder of the 'why'.

When times get tough (e.g. lack of time or I hit a speed bump), I remind myself of why I am working towards that goal. When I initially set goals, I tell myself why it is important to me, and why I want to achieve it - but I've found that reminding myself of the 'why' helps me get back on track and gives me the push I need to keep going. 




Comments

Popular posts from this blog

Getting started on a testing project

I started on a new project a few weeks ago and thought it would be a good idea to share a checklist for what new testers on a project need and some good starting questions when you, as a tester, are new on a project Checklist for what new testers on a project need (Note, your project may not include all of the below) Note to check if user credentials are needed for any of the below

My Most Used Test Heuristics (with examples)

First, what is a heuristic? A heuristic is a guideline ,  it is fallible.  Therefore, it will give you a good idea of what behaviour you should see BUT it isn't definitely what should happen - it's up to you to confirm that the behaviour you are seeing is correct.  In a previous blog post I shared a step by step guide on  how to test without requirements/little requirements.    But I figured it's good to share my most used test heuristics that I use for testing without requirements. They are: Consistency with History Consistency with User Expectations Consistency within Product Let's take a look at each of them along with some examples to illustrate the concept. 1. Consistency with History  The feature's or function's current behaviour should be consistent with its past behaviour, assuming there is no good reason for it to change. This heuristic is especially useful when testing a new version of an existing program. (Source: developsense) Example: Whitcoulls, a

Bloggers Club: The Importance of Exploratory Testing

 Before we dive into the importance of Exploratory Testing, I would like to clear three things up. Firstly, I align with this definition of Exploratory Testing, by Cem Kamer, it is an approach to software testing that consists of simultaneous learning, test design and test execution. Secondly, I don't think Exploratory Testing has to be a substitute for test cases, it can complement test cases. (It's up to you, how or if you choose to combine both Exploratory Testing and Test cases when you test a feature) Lastly, exploratory testing is not adhoc testing - adhoc testing is random, unstructured testing, exploratory testing forced you to think critically about the application under test. (For more about the difference go here .) Job Interview Analogy To illustrate the importance of Exploratory Testing, I'd like to first use the analogy of a job interview. (I wrote about this in a previous blog post but will expand on this further) The Test Cases in this analogy In a job inte