Should I be a Programmer or a Tester or a Test Automator or an SDET or......I
mean,
that's a question that we're going to consider in this episode of the Evil
Tester Show. Hello, my name is Alan Richardson. Welcome to the show.
You can find all the show notes on the webpage evil tester.com/show.
So, I get asked this question a lot - what should I be?
Should I be a programmer? A Tester? Test Automator? SDET? Performance Tester?
Security Tester? Analyst? Project Manager? You name it, right?
It comes through. I get this on direct messages, emails, YouTube comments.
I'm going to try and explain how I think about this, in a second.
I just want to start with a warning, right?
Because the warning is that we should not have to think like this.
I understand why we do think like this.
Job markets emphasise specialism,
but software development requires harnessing all the skills,
right? That programming software, design development, automating,
testing, requirements elicitation, front end design,
accessibility. All of this - negotiation,
management - all of this.
Software development is a broad discipline.
That's why we have teams that have multiple rules on it - multiple skills.
Because what we're trying to do is make sure that we have,
from all the people there,
combinations of skills such that we have at least one person that has each one
of those roles.
It is rare to find people who can do programming,
testing, design analysis. As you get more experienced,
hopefully you're building a broader range of skills.
So you more fill that notion of what a software developer is.
But it takes time.
And we really don't want to let our role definitions define us or limit us in
any way. So,
I really want us to think that we want to be Software Developers,
rather than roles. But having said that, we need to get a job.
And in order to get a job, we need to specialise.
Most recruiters and job adverts only really focus on,
the last one or if you're lucky, the last two roles. So,
to recruiters, it almost doesn't matter what you want.
It matters what you have done. It matters - do you fit to their profile?
So keep that in mind because, if you want to be a Programmer,
but haven't programmed commercially or you didn't programme in your last role,
then you're going to need to figure out how to overcome those objections from
the recruiter. You might be able to do that through side projects.
You might be able to do that by putting stuff on GitHub, by having a blog,
but it's a sales process where you're trying to overcome objections,
to convince them that with their narrow view of the market you can fit into that
role.
And you also have the issue that sometimes it can be perceived as a massive
shift. If you're moving from being a Tester and wanting to be a Programmer.
Then you have to emphasise the aspects of your current role which map on to your
ideal or next role. So if you're a Tester, you want to move into programming,
emphasise the programming that you did, the languages you use, the IDEs,
the pairing with Programmers, the automated execution code you create.
All the stuff that maps on to the role.
And unfortunately if you're experienced in one role and you switch,
then you're likely to be much more junior in your next role.
I guess one of the benefits in software development is that we very often don't
view experienced as twenty, thirty, forty years.
We view experienced as two years in a technology, three years in a technology.
So even when you start, junior might not take that long to build up.
But shifting can be hard because recruitment is essentially lazy.
Because there's so many people competing for work that they can be very
selective. So the job adverts allow them to be selective and say,
you must have two years in this.
It's not because they necessarily want two years in that,
it's just an easy filter so they have fewer CVs to review and fewer people to
interview. But getting a job is different from - should I be?
Now, I know it is possible to change because I started as a Programmer,
I moved into testing and I've done management,
I do consultancy, I've done design, I've built websites,
I've built backend applications. I've programmed a lot things.
I've got a hundred projects on GitHub.
But it's also because when you shift, you don't really shift.
You've just emphasise a new part of the software development process and develop
the skills in there. But getting a job is different from - should I be?
Should I be?..
is more related to what you love doing - what you're,
what you're drawn to. So,
if there's one thing that you love above all else that you are drawn to that you
would do this all day. Whether you got paid for not - don't even question it.
That is what you look for. If you love writing code,
creating a stuff in code that does stuff on its own,
like writing applications or tools. You like TDD, you like writing unit tests,
you like looking at the code architecture of systems and working out how to
organise the classes better to represent the domain or to be more efficient.
If you love supporting applications in production at three in the morning,
then pick programming. Testing might be a good fit,
if, when you're using applications,
you stumble across issues more than other people and you spot things,
and go - that doesn't look right. And you can't help yourself,
you have to investigate it.
If you like the clarity of communication and take care to communicate as
precisely as possible.
If you're interested in technology but you also identify risks of
implementation. When you're thinking about driverless cars,
you're not just thinking about - how cool is that?
You're also thinking how risky is that? Where are the risks?
How is it going to handle this scenario?
If you see systems and risks everywhere.
You see government policies and you're thinking,
well how are people going to abuse that?
If you're more interested in the system and its impact,
than the coding and building of the system, then testing might be a good fit.
And if you do one of these in your spare time more than others, then do that.
If you like designing websites, if you look at websites and critique them,
then you might be more interested in design and front end design and
development.
Trying to find the niche that is most attractive is useful,
because that will carry you forward and if you like testing and programming then
automating might be a good fit.
The question - what should I be? might also mean different things.
It might be - what is better for me long term?
What is a better fit for me personally? (Which is what we've just looked at).
What will get me more money? What will guarantee me a job for life?
What will guarantee me a job for life?
Probably nothing will guarantee you a job for life.
I think you decide what your motivation is. Which one of those motivates you?
Is it money? Is it being interested? Is it career progression?
If it's getting out of the situation that you're in,
then you're pretty much going - I will take whichever one comes first and then
build on that, right? As long as you start,
you keep building and moving forward. Unfortunately
if you want more money, then go into programming.
We have a very tunnel visioned industry and more companies value programming
than they do testing or automating. So,
you may have an easier time finding work as a Programmer.
You may not. Maybe there's more competition for that.
It really depends on your environment, where you are, which country you are in,
what skill level, what you've done as a degree.
Getting the job is the hard part.
But it doesn't mean that programming is easier to do.
But if you're good at programming and good at automating and good at testing and
loved them all, then programming is an easy choice, because,
particularly if you're focused on money.
But it doesn't mean you'll be working on interesting things.
A lot of programming work can be very boring.
That's why libraries and frameworks exist - to remove drudgery.
And that's also why companies get in a mess because programmers want to use more
up to date technology because the actual domain is very boring. So,
they bring new stuff in,
that isn't really required for the technical implementation or to meet the
requirements. That's also where testing comes in, because we identify risk.
A lot of programming work is also actually not about writing code.
It's about infrastructure, build processes, environments, support.
And a cynic might suggest that some companies use the phrase,
DevOps to try and make all that more glamorous.
And there are things that don't actually matter.
There are things that can be taught. They might matter in job specs.
In reality you can learn them, right?
You can be taught to code, to unit test, to learn design patterns,
to use design patterns, to identify and spot design patterns, refactoring,
automating. You can be taught how to test. You can be taught how to use tools,
right? All of this stuff you can be taught.
But what you can't be taught is to be interested in the subject.
And if you aren't interested,
then you'll probably end up going down a fairly superficial path.
It can get you good jobs and good money,
but ultimately it will just be about the job and the money.
If you can identify the aspects that you are interested in and map those onto a
role, then that's the role to try and aim for.
But remember,
the software development world might not value testing or automating or
programming the same. Take a long-term view.
You have, if you get into this industry, 30 or 40 years possibly,
in computing. So continue to develop your skills over that time.
Aim to be a software developer, a problem solver, a solution developer,
right? These roles that we're talking about - programming,
testing - are not the defining characteristic of our ability.
They are simply the main way that we market ourselves at any particular point in
time.
Software development is the overarching concept that they all sit within.
If you want to be a good software developer,
then you need to learn programming and testing and automating and designing and
et cetera, et cetera, et cetera.
All the roles that form part of the software development process,
all the things that we've mentioned.
And you don't have to build them all at once, right?
Don't forget about them,
but try to find something interesting in them so that you learn from them all.
You start small with one rule, but branch out into software development.
And that kind of seems like a brush off to the question, what should I be?
But the answer is - what you want to be is where you aim.
But you start wherever you can get an "in". Thanks for tuning in.
I put this podcast together as a video and audio broadcast to try and get this
out to as many people as possible so that I can try and offer a different
perspective on software development and testing, based on experience.
I do use this forum and the podcast to answer questions.
So if you have any then pop over to eviltester.com/contact
and you can ask a question in confidence. I might email you back.
They might form basis for a podcast and if you do find this content useful,
then consider subscribing in whichever podcasts you're using or YouTube,
if you're watching this on YouTube.
And you can support the show by signing up to patreon.com/eviltester where I
release a lot of exclusive content.
Or have a look my books and courses on eviltester.com.
My name's Alan Richardson.
Thanks for tuning in and hopefully I'll see you in the next episode of the Evil
Tester Show.