What's in a title?: Difference between revisions
Jump to navigation
Jump to search
m
no edit summary
(Created page with "'''April 2024''' The job titles we have matter sometimes, but at other times not so much. A job title can limit the understanding of what we can do, but at the same time they...") |
mNo edit summary |
||
| Line 1: | Line 1: | ||
'''April 2024''' | '''April 2024''' | ||
The job titles we have matter sometimes, but at other times not so much. A job title can limit | The job titles we have matter sometimes, but at other times not so much. A job title can sometimes limit people's understanding of what we can do, but at the same time they can sometimes convey succinctly exactly what we do do. | ||
Over the years I've had many job titles and roles, including | Over the years I've had many job titles and roles, including | ||
{| | |||
|- | |||
| | |||
* Tester | * Tester | ||
* Software Test Analyst | * Software Test Analyst | ||
| Line 11: | Line 14: | ||
* Quality Coach | * Quality Coach | ||
* Quality Analyst | * Quality Analyst | ||
| | |||
* Support Engineer | * Support Engineer | ||
* Software Developer | * Software Developer | ||
* Logistics Manager | * Logistics Manager | ||
* Father | |||
* House dad | |||
* Chauffeur | |||
* Programmer | * Programmer | ||
| | |||
* Production Scheduler | * Production Scheduler | ||
* Operator/Scanner | * Operator/Scanner | ||
* Volunteer | |||
* Organiser | |||
* Chair | |||
* Treasurer | |||
* Tram Driver | |||
|} | |||
Some of these will have meaning for you, others may mean little without knowing more of the context. | Some of these will have meaning for you, others may mean little without knowing more of the context. | ||
| Line 22: | Line 36: | ||
---- | ---- | ||
Recently I've been thinking of what am | Recently I've been thinking of what I am, and I've landed on | ||
== I am a Software Quality Engineer == | == I am a Software Quality Engineer == | ||
Although, I do feel a little conflicted because '''quality''' is really an attribute ''of'' something, not some we can engineer by itself. However, the title seems to have gained traction over the recent years as meaning a broader engineering role focussed on software quality, which I can certainly sign up to. We build and engineer tools, systems, and processes to help us efficiently analyse and monitor the quality of software solutions. Testing is a wide and varied endeavour, but there is real value in being able to quickly get basic quality information about a code change through automation. The objective being to automate the boring and free up the tester to explore more and deeper. Automation of course, covers so much more than simply automating the product itself, but also in preparing the product to be ready for testing, the local development environment, the version control and branching strategy, the CI/CD pipelines, the creation of test environments and infrastructure, the preparation of test data in an environment, the capture and aggregation of (test) environment logging and monitoring data, and much more. All of these tasks may lend themselves to degrees of automation, and can each take a serious chunk of (boring) time to do without the automation. Creating the whole interconnected ecosystem necessary to efficiently determine the quality of a software solution I believe is a genuine engineering activity. | Although, I do feel a little conflicted because '''quality''' is really an attribute ''of'' something, not some we can engineer by itself. However, the title seems to have gained traction over the recent years as meaning a broader engineering role focussed on software quality, which I can certainly sign up to. We build and engineer tools, systems, and processes to help us efficiently analyse and monitor the quality of software solutions. Testing is a wide and varied endeavour, but there is real value in being able to quickly get basic quality information about a code change through automation. The objective being to automate the boring and free up the tester to explore more and deeper. Automation of course, covers so much more than simply automating the product itself, but also in preparing the product to be ready for testing, the local development environment, the version control and branching strategy, the CI/CD pipelines, the creation of test environments and infrastructure, the preparation of test data in an environment, the capture and aggregation of (test) environment logging and monitoring data, and much more. All of these tasks may lend themselves to degrees of automation, and can each take a serious chunk of (boring) time to do without the automation. Creating the whole interconnected ecosystem necessary to efficiently determine the quality of a software solution I believe is a genuine engineering activity. | ||
== My old intro | == My old (pre 2024) intro ... == | ||
In the blurb at the top of my CV I used to call myself a '''Full Stack Agile Quality Analyst''' ( | In the blurb at the top of my CV I used to call myself a '''Full Stack Agile Quality Analyst''' (original text below). However, I feel it no longer fully resonates with me, some of the words like "Full Stack" and "Agile" have had their day. We now generally expect people to adjust to the context they've been placed in, to simply get on and do the job as best they can with the resources available. To be able to recognise the things that need doing the most, to communicate concerns and ideas, and to have a shared commitment to achieve the most for our users, customers, team mates, and organisation. Full Stack seems to me to mean you're happy to google for (new) solutions to a problem on your plate, rather than simply handing it over to another person in the organisation. In addition, Agile seems to have become a de-facto industry norm. Of course Agile is hard to do properly, but saying you're into Agile development seems superfluous these days. | ||
{| class="wikitable" style="margin-left: 50px; margin-right: 50px; text-align:left" | {| class="wikitable" style="margin-left: 50px; margin-right: 50px; text-align:left" | ||