🫨 Should an SDET move over to SDE?

Created by microsoft copilot using DALL.E 3

This question often crosses the mind of people working as an SDET one or more times during their careers. In this blog, I offer a personal story from my own career and hopefully give you a mental model around thinking about this.

Let me start with a personal story

Back story

In 2018, I joined Gojek as a Product Engineer QA with around 7 years of experience. I joined as the 3rd full-time QA engineer amidst a large consultant team.

During my initial month, I met another bright engineer with around 4-5 years of experience who was super passionate about Ruby programming.

In Gojek, we had a Java-based mobile and API testing framework used by teams already, he wanted to build his own version in Ruby. That seemed like an audacious goal that surely would not be able to land well without some solid technical justification, leadership, and influence

Oddly, I had just come from a Python background and was head over heels in love with the language, and wanted to use Python to rewrite our framework into something more simpler.

Ah, the naivety and simpler times.

We debated over which language was better and drew and architecture but could not come to terms with language choice among other things, and that eventually led to this idea not really materializing after a couple of weeks of effort and we both went to focus on our own teams

After couple of months into my new role, I heard that person is switching over to being a backend engineer.

🧑‍💻Should I switch to dev?

I wondered curiously if switching to a developer role makes sense.

At the time, I had personally not come across a lot of examples of people who had made this transition

I also did not feel strongly about making the move myself.

Why?

It was quite simple for me

I loved software testing ❤️

I also loved coding ❤️

I felt I was good at both

This love for the craft of software testing did not come originally but I developed it organically as I grew in my career as a tester

I started to appreciate learning its nuances. I loved peeling one more layer of the onion at a time, every new project or challenge helped me become better by adding another tool or approach to my toolset. I was a journeyman on the way to explore different depths of testing.

I also felt that there were lots of things that I had not yet explored yet

I did some personal reflection at the time and tried to imagine how my role would be different if I was to transition to a developer role

I would have to get trained on one specialization like backend, mobile, web, or data and self-learn most of it myself or on the job.

I would write a lot of code and get better at it

Probably take care of on-calls and any production incidents and earn my keep as a mid-level developer

But, It would probably mean not getting enough time to test and I would mostly be in one vertical to have any reasonable chance of being any good at it.

I might switch teams and domains but the core skill would remain this at least for sometime

I did not like the notion of being with one technical domain.

I wanted to be able to switch between web, mobile, backend, performance, accessibility, tooling, etc, and see how I could bring my testing mindset to add value in these diverse domains

Each of these areas appeared super interesting to me and I liked that as a tester and programmer in general I could learn and switch in these domains in service of testing

At the time, I also personally felt that the experience I’ve accumulated to this point in testing would go wasted. That thought was probably not true. I’ve come to realize that solid testing skills are transferable and super valuable in the life of a developer as well

Heck, I would not be far off to presume that software testing is more than 50% of the job of any decent developer anyway.

If it’s well tested, its not really developed is it?

💰Hey, what about the money?

Would I make more money as a developer?

Probably!

that was certainly attractive to consider.

However, my 1st hike at Gojek proved this wrong as I was paid on par with developers with similar experience and levels. I also personally did not index a lot on pay but more on learning and developing myself as a professional.

I was lucky that I was in a company with solid leaders who took care of compensation without me having to worry about it.

So in the end it was an easy decision for me.

I decided to stay in testing

Within 3 years, I grew from an individual contributor (IC) as a Product engineer QA to a Lead SDET in a couple of years and then on to an Engineering manager SDET within another year managing a team of leaders and ICs

It was fantastic growth. I worked with a diverse team of engineers, some into exploratory testing, and some deep into coding and building frameworks and tools. I enjoyed building a backend community with other SDETs and also forayed into public speaking at conferences, writing a blog, etc.

I met talented, humble people who were all passionate about the craft of software testing and doing it well to ensure our company can succeed in its mission on providing a quality experience to our customers.

It was a ton of fun

🤷 Who is an SDET anyway?

I also realised that as a Test engineer turned into SDET

I am not really a tester, nor a developer, and not a product manager

I’m someone in between who oddly can empathize with each function and possess some of the skills each people in above roles have

I have my legs in multiple worlds.

I’m a developer who thinks, breathes, and eats testing for breakfast and loves it

I obsess over coverage, over getting fast and reliable testing signals so that teams can make decisions to ship or not

I love building scalable tooling, frameworks, and infrastructure to help everyone test better

I also love understanding how the actual applications or systems work under the hood not just functionally or non-functionally but what they mean to an end user.

I can think in user flows and journey touch points and also step into the details of the code and also zoom out at a user level

This is a pretty amazing and very challenging role if you think about it.

I wrote about all the things an SDET is expected to do in this blog, Who the heck is an SDET? Feel free to give it a read to form a better intuition.

SDET vs SDE?

In my view, we are both programmers at heart

The difference lies in that we as software engineers are just focused on different things, working together to bring customer value sooner and safer

But really, who is an SDE?

An SDE has lots of things on their plate

They are very much focused on taking requirements from products, and businesses and using their knowledge and experience of the systems, to translate it into changes in the application.

They may write new APIs, make changes to existing ones, write a new app screen, or sometimes build a completely new one from scratch. They may sometimes work on general tooling as well at CI/CD, deployment level

SDE also focus on testing, they write unit tests and integration tests with mocks and may do some manual testing or occasionally write an E2E test as well.

I have personally seen many SDEs who are very good testing minds as well and such individuals experience high growth in their careers since they are usually appreciated by their leaders for shipping services or apps with high-quality

They also fix any bugs in the system either self-discovered or by someone other than them

SDEs are experts in their own systems and sometimes get tunnel vision by focusing too much on their code where they are not able to zoom out and see the feature as a whole.

It’s not really by choice, the amount of work and pace is often demanding enough and when put under the burner to deliver faster, a dev may opt for doing just good enough testing leading to missing bugs which are a factor of simulating different conditions

SDE’s also take care of deployments and ensure production systems are running smoothly, occasionally resolving any production outages

They focus on elegant software architectures and learn about many different technologies based on their domain.

What about an SDET?

You should read the above blog to get the full description, but let me give a short summary

An SDET is a developer who focuses on testing problems.

This person can write application code (APIs, apps, tools, etc) if required but spends the majority of their time building frameworks, tools, and testing infrastructure to enable everyone on the team to do better efficient testing.

The line is really quite thin between the two roles with a lot of overlapping skills

This also means that an SDET is expected to develop generalist software engineering skills based on the domain or team they serve.

If they are in a backend platform team, they should understand the backend architecture, tooling, programming language, and CI setup so that they can reason about how to test them better

If they work on a mobile team, they should understand the app codebase, what testing frameworks and solutions exist, and be able to work with and enhance them

In some teams they may author automated tests at unit, integration and E2E level, in some, they may not

An SDET could work on different problems depending on their company size, stage, and setup

Some examples of problems they usually solve:

• Build code coverage tooling
• Build test observability tools and solutions
• Bring tooling to do better testing at unit test levels like mutation, pairwise,
• Build distributed systems testing solutions around reliability, resilience
• Test boundaries of a system at scaled load
• Work on testing mobile, web, and backend systems: Each has its own set of nuances and challenges
• Tooling for security
• Work on efficient CI/CD systems

I could go on and on and on … it’s a really long list

It is also hard for one person to be knowledgeable in all of these and usually requires a whole career and lots of bandwidth to develop breath as well as depth in a few

Also, SDET != QA?

A slight tangent

Calling an SDET a QA engineer is very confusing, and honestly changes the narrative about what they are expected to do.

The testing industry has come with many different titles to describe different activities that people do and for the benefit of colleagues in general, we roll up everything to QA, more on this topic in Testers identity crisis - QA/QE/AE/SDET/SET/TA? and The problem with titles for testers

QA (Quality assurance) is not a dirty word

It has been bashed and confused a lot

Often managers hear QA and they would be quick to dumb down and reduce people with this title as simple button pushers which is not true to reality.

Some people find a hack to rename it to QE (Quality engineering) but that is also quite ambiguous

I would just prefer if people call it what it is

Test engineering

We are focussing on efficient testing at scale, nothing more, nothing less.

So, should you switch?

I can’t and won’t make that decision for you.

It’s personal.

You have to decide for yourself as you know your own context the best

Hopefully, this blog gives you some sense of what are the differences between SDE and SDET so that you can make an educated guess about what role would you prefer

Also if you decide to move to a dev role, it is not a one-way door.

I would rather think of it as a two-way door and if you don’t like what you see, you can always switch back as an SDET or to some other vertical.

Software engineering is a wide enough field to support multiple lateral transitions and we should not see our careers as being rigid or sticking to one thing only

Go on, explore. Try out different roles and see what you really fancy. It’s a whole wide world out there.

Why don’t you take a leap of faith?

| Thanks for the time you spent reading this 🙌. If you found this post helpful, please subscribe to the substack newsletter and follow my YouTube channel ( @automationhacks ) for more such insights in Software Testing and Automation. Until next time 👋, Happy Testing 🕵🏻 and Learning! 🌱 | Newsletter | YouTube | Blog | LinkedIn | Twitter. |