A real full-stack software engineer spends >50% on automated testing
This article is one of the “IT Terminology Clarified” series.
Both my daughter and I love the “Silicon Valley” TV show. In one episode (S03E03), after Gilfoyle is free for hire, job agents keep sending him presents.
The reason: he is a ‘full-stack’ engineer which is in high demand. The term ‘Full Stack Engineer’, like as many job titles in a software team nowadays, such as ‘DevOps Engineers’ or ‘Solution Architect’, is abstract. Mediocre IT engineers like to call themselves fancy titles. Soon, these job titles will be less meaningful.
Today, I saw the term “Full-Stack” twice in my LinkedIn feeds.
- A former ‘Principal Software Engineer’’ I met before changed a new job with the title “Full-Stack Engineer”.
This principal software engineer cost the company millions and embarrassment with a very bad test automation attempt (Java with Concordion, a Gherkin syntax; two wrong choices: language and syntax framework).
- a LinkedIn connection request from a “Full Stack QA Engineer”. Full Stack QA?
What does the ‘Full Stack Software Engineer’ really mean? I tried to find a definition to explain it to my daughter. According to this Wikipedia page, a full-stack developer may specialize in both client-side applications (front-end) and server-side applications (back-end). This seems to be the most common definition. However, it does not sound correct as my daughter pointed out that, Gilfoyle, the character in the “Silicon Valley” show, does a lot of work on setting up the infrastructure.
Another common definition is “A full-stack developer is an engineer who can handle all the work of databases, servers, systems engineering, and clients.” Does this sound “full”? No, it isn’t. It misses an important skillset: Testing, in particular, Automated Testing. Before I clarify this, let me share a story about how I became a ‘full-stack engineer’ in 2004. My experience might help readers understand how the full-stack term comes out.
My Story: became a ‘full-stack engineer’ in 2004
In 2003, I joined a J2EE project as a senior Java Programmer (Contract). I was given the task to work on the client-side development as I owned a ‘Sun Certified Web Component Developer certification. There were 4 other developers who worked on the back-end with the job title “EJB Developer”. Nowadays, developers might find that strange as there should be more effort on the client-side work. However, EJB was complex (unnecessarily), and the client-side pages are relative static (no AJAX, javascript was commonly used to show/hide elements).
Several months later, the manager believed that I handled the client-side development well, he ‘promoted’ me to do some back-end work as well. I became the only developer who did both the front-end and back-end development. One day, I found a term full-stack on the Web that described a similar situation. Then I started calling myself ‘full-stack engineer’ unofficially. At that time, it did not mean cool or anything, just simply meant I could, and more importantly, was willing to work on both. Some EJB developers still thought ‘doing pure back-end’ is on the ‘higher’ rank. They prefer not touching the front-end.
A few years later, more and more development efforts were towards the front-side, and the boundary of front-end and back-end was getting less clear. Those back-end engineers have to work on HTML and JavaScript too, but they probably don’t want to be called ‘web developers’ (which they may have looked down on). Dropping ‘back-end’ to be a just ‘developer’ is meaningless. So the compromise is to use a new sounds-cool name: “Full-Stack”.
A real Full-Stack Engineer’s >50% work is test automation
Some will disagree instantly, and question on what basis my opinion was. I consider myself a real full-stack software engineer, as I single-handily developed TestWise, BuildWise, ClinicWise and SiteWise CMS. I transformed my daughter’s high-school work into a commercial online service booking app: WhenWise. It is fair to say that I am full-stack as it can be.
A full-stack engineer should work both the front-end and back-end development based on any version of the definitions. In other words, he/she completes a user story end-to-end. What the real engineers shall do after they think that they have gotten a task implemented? They would design a stable and repeatable process to verify that work. Sadly, this classic concept of engineering has been largely lost in software engineering.
Some developers might object loudly, “No, No, we are developers, we are not doing testing”. Oh well, let’s hear the culture at Facebook.
“It is really important at Facebook I will never, as a developer, write code and toss over the fence and for someone else to write test for it. It is my job as a developer at Facebook to write tests for my code, and my reviewers make sure I do”. – “Continuous Integration at Facebook” talk at F8 conference, 2015
The real reason is that most developers are very poor at test automation. Below are three types of automated tests a Facebook engineer needs to work with.
The more valuable and difficult one is on the top: End-to-End (UI) tests using WebDriver (Selenium for web or Appium for mobile apps)
Some might acknowledge, “Fine, I will do automated testing. but surely won’t be 50% of my whole work”. As a matter of fact, 50% is a conservative figure. I have been tracking my time spent on developing my apps, the figure is 70% — 80%. This is due to the nature of software development: one single line code change might affect other features elsewhere.
The more efficient a programmer becomes, the more frequent changes he/she makes, therefore, the more regression testing he/she needs to perform. Many mediocre programmers don’t realize this because the regression testing feedback, usually via manual testing, is very long. As the result, tech debts accumulate.
Compared to maintaining a large automated test suite, writing the code of a typical enterprise web app is a minor effort.
For web development, programmers usually follow a well-defined framework such Ruby on Rails, Angular.js, and React. In other words, the design is largely done.
Developing a system software (compared to web apps), like TestWise IDE and BuildWise Server (and agent), do require considerable more effort than web/mobile apps.
In summary, a software engineer, who does not follow a repeated process to ensure the quality of his/her work, hardly qualifies for an engineer, let alone a full-stack engineer.
—
The original article on my Medium blog, 2022-02-21