How employers foster impostor syndrome and what to do with it

Impostor syndrome is one of the psychological phenomena where a person is unable to attribute their achievements to their personal qualities. In other words, in all achievements "the chance" is to blame, not the efforts made by you. I can agree the chance plays a big role in our lives but to attribute everything to it...

So, what does the employer do to seed this?

1️⃣ Companies hide the salary range when hiring. We've already gotten used to this, but it directly affects us. To combat this, we need to be aware of the salaries in the market (this will require talking to many colleagues, including those from other companies). Without this information, there is a high probability of undervaluing yourself during the hiring process. Of course, the business will be happy with such an outcome, but what about the employee?

2️⃣ Company promotion processes. Yes, this process is the main one for forming our professional self-estimation because we start negotiations about salaries from a losing position. If you've been through this once, remember how you collected metrics and achievements for self-presentation. The business shifts onto your shoulders the responsibility to prove that you are a worthy candidate for promotion. As a result, the process may be prolonged (which is also beneficial for the employer, as they save money), and you remain with the cool skills, solving complex tasks for the old salary, and still have to find time for self-development, although the quality of your work has improved over the past year. Recall all the management concepts as an example: an Agile team where everyone knows everything, T-shape, etc

3️⃣ The presence of bonuses. Often their availability depends on the financial situation in the company. I rarely encountered projects where the bonus was tied to KPIs (the sample is not representative, it's just my experience). The problem with bonuses is that they can be easily canceled, and the employee is left only to blame themselves for not working hard enough

4️⃣ Grade divisions. Usually, the competence matrix contains the tasks and skills that are beneficial for the business in general. As a developer, you may be able to solve other types of tasks just as effectively, but you won't move to the next grade because "this skill is missing." As a result, a psychologically uncomfortable situation is created for the employee, which makes them think that they "can't keep up"

5️⃣ Incident analysis. Sometimes this metric is paid attention to during salary negotiations. But we are human, we make mistakes, and we can do it quite often. So why does the problem in processes reflect on the developer's salary? I don't quite understand this point. It's good to see that there is a tendency to cancel this metric

In conclusion
I'm not a metrics enemy. They help us understand how good we are in the world of development. But they should be analyzed wisely, remembering the motives for their appearance. If there are clear signs that a particular metric is being used for management and cost-saving purposes, it's worth thinking about how it evaluates your professional qualities and, perhaps, not taking it into account

A few thoughts about impostor syndrome from an impostor ?

Write in the comments if you have impostor syndrome and how you deal with it

? 30-Year-Old Bug

This story began in 1985 when Lotus Software released the spreadsheet editor "Lotus-1-2-3." The editor was fantastic, but it had one small bug - for some reason, the year 1900 was considered a leap year. Users complained about the issue, but the company decided not to fix it, arguing that rewriting the entire code of the program would be necessary, otherwise working with data would be impossible.

In 1995, Microsoft Excel started gaining momentum, and they "borrowed" this bug to avoid breaking compatibility when importing files. According to their claims, fixing the bug would affect all dates, not just this one, and the disadvantages of rewriting the code outweighed the potential benefits of the fix.

Some sources claim that the error was fixed in 2007. However, in my fresh version of Excel, it still exists ?
To check it, enter February 29, 1900, and February 29, 1901. One of the cells will be formatted to the right, indicating that Microsoft Excel considers it a valid date.

So this bug has been living for 30 years already and seems to live on for much longer, although in Google Spreadsheets, this error is no longer reproduced.

Yesterday, one of my mentees expressed an interesting thought that seemed obvious to me. He brought up with a code of a test and a "non-test" according to him. Here is an example of a test code:

@Test void testGetExact() { given().baseUri("http://localhost:8080/public/v2") .header("Authorization", String.format("Bearer %s", ...)) .pathParam("id", 2436) .when().get("/users/{id}") .then().log().all() .statusCode(200); }

The same code, which is refactored (requests are extracted to the controllers layer), is no longer a test ?

@Test void testGet() { users.getExactUser(2436) .statusIsOk(); }

The argument was that we are calling methods now, not checking anything...

Of course, this is not true. The test purpose is not only to explicitly show what is happening inside (log requests), but also to be readable and understandable for the developer, as well as be easily maintainable. That's why the second example of a refactored test is a test still, but also a significantly more convenient test in all the aspects.

? if you want to know how to step by step go from the first example to the second

🧪 Testing Philosophy
Hey, folks! 👋 Check out one of my favorite articles on programming and unit testing. There's a ton to unpack, but let's dive into my absolute favorite concept today:

Good tests fail
Wait, what? Why are we celebrating failed tests? Well, the answer is pretty straightforward. If I've crafted an impeccable test, following all the best practices in the world (yes, even on a real project, believe it or not), it should be susceptible to breaking with code changes.
Let me break it down. Tests should seamlessly integrate into the code, whether they're E2E (API or UI). Why? Because we want to validate every tweak we make to our codebase. So, when our test fails on a new branch – jackpot! It means we've caught a bug early or discovered a broken old behavior that was not meant to be broken, exposing a design flaw.

But what about those "always green" tests? Can we fully rely on them? Or are they just giving us a false positive sense?
Might be. It's worth to dig into to get the exact answer.

Here's a checklist to ensure your test is rock-solid and will show the problems while new updates is coming:
- Independence: All test data is tailored for the specific test; execution order is irrelevant.
- Atomicity: Each test validates one business requirement, including negative scenarios.
- Mutation Sensitivity: Tweaking your test or assertion should trigger a resounding "failed."
- Stability: A non-flaky test; it passes consistently, unaffected by factors like a slow internet connection.

Let's build robust tests that don't just pass but shout when there's trouble. 🚨
Happy testing, everyone! 🧑‍💻

#testing_philosophy #best_practices

? Every day I find more and more reasons to use Playwright instead of Selenium. Today, we won't talk about the speed or simplicity of using Playwright but about a feature that I recently discovered and that greatly helps to save time when writing new tests – test code generation.

? Let me demonstrate how it works:
- Install Playwright first as a global npm package
- In the command line enter the command npx playwright codegen <website URL>, for example, npx playwright codegen https://bookcart.azurewebsites.net
- Manually perform the scenario you want to automate
- Obtain the code generated by Playwright. Choose the language you want to convert your sequence of actions into: Java, C#, JS, or Python

❗️Here is an example of the generated code

```
import { test, expect } from '@playwright/test';

test('test', async ({ page }) => {
await page.goto('https://bookcart.azurewebsites.net/');
await page.locator('mat-card-content').filter({ hasText: 'HP3₹213.00shopping_cart Add to Cart' }).getByRole('button', { name: 'Add to Cart' }).click();
await page.getByRole('button').filter({ hasText: 'shopping_cart1' }).click();
});
```

Of course, this is not the final version of the test since we are using Page Objects, scenarios, etc. However, it will significantly speed up the process of writing new tests.

*? Feel free to use it and a great Monday to everyone!*

❓Every day I come to work with the same question: "Am I doing everything right?"
It turns out I can't always answer it positively. However, today we'll talk about why this question arises.

Most people are accustomed to use what they know well and that's normal. When you go to a certain place you choose a familiar route; when you write code you choose familiar operators; and when faced with a choice of which tool to use, you choose the one you've worked with before.

? Here are a couple of recent examples I encountered:

1️⃣ On a new project, we launched a framework based on Playwright. Within a week after it is deployed, someone suggested integrating it with BDD, which, in my opinion, makes no sense when using Playwright (we'll talk about this separately). He justified it by saying that BDD is more convenient for business even though Playwright contains the same tools as Cucumber.

2️⃣ The promotion of Selenium. At the moment, there are technologies that significantly surpass to the other ones technically. Nevertheless, many people and courses continue to push it as the only possible automation testing tool.

⛈ There's one problem - in the world of development, things are constantly changing: new tools emerge, old tools lose their effectiveness, and new approaches replace previous ones. For example, if knowing and understanding Page Objects pattern used to be enough to be considered a skilled automation testing specialist before, now it's no longer sufficient. This knowledge has become the foundation that every automation specialist must know. More attention is now paid to code architecture and structure.

? So, what actions help me answer the question of whether I'm doing everything right?

☝️Read the documentation. Reading the documentation can provide incredible insights into using the tool and its capabilities. This is a valuable source of information that should not be disregarded

☝️Analyze the current solution I'm working on. In development, there are many factors that influence the quality of the final product. Going back to the question of the applicability of the current approach to the task, you can find new factors that could potentially change the course of events

☝️Reject authoritative opinions. The facts that someone presents as an evidence for their point of view may turn out to be false. Many different opinions often unsupported by anything other than emotions in our days. At first glance, the evidence often seems logical but can lead us down a false path.

Wish you a good rest of the week and be mindful of cognitive traps so that I don't feel embarrassed for you ?

? Testing Chronicles: Lesson Learned
Today, I had an interesting experience: a developer handed over a task for testing, and during the process, new requirements emerged that were not discussed or considered when estimating testing efforts. Do you know why this happened?

? Unclear Acceptance Criteria
The acceptanсe criteria were not clearly defined during the grooming session. Although the task was created, described, and taken into work, apparently, each developer interpreted it differently. As a result, it was completed as planned, but additional changes were needed that were not documented anywhere.

? How we found it?
When the task came for testing, it was checked according to the initially described criteria. However, no one from QA side was aware of the new features that had to be introduced during the task implementation. This only became apparent during the standup, meaning we had already lost a day (it could have been done earlier if everything was perfectly described). Fortunately, the changes were not critical, and we quickly adapted to the new requirements. Nevertheless, both the developer's and tester's time was spent in a meeting where we discussed testing techniques for the new functionality and the scope of work.

*? Avoiding Similar Situations in the Future*

1️⃣ Break tasks into very small ones that take no more than a day to complete. Remember that the larger the task is, the greater the error in planning (both estimation and implementation)
2️⃣ Provide detailed and specific acceptance criteria. The more questions we ask during grooming, the higher the probability that all team members understand the task in the same way and will only perform what is written in it. This approach also helps identify uncovered areas of functionality. If something is uncovered, either create a new task or modify an existing one by adding specific requirements.
3️⃣ Be prepared for such situations to occur constantly. Teams often make mistakes in planning, especially with large tasks. Even teams that have learned to plan well still make mistakes. Armed with this information, when estimating testing tasks, factor in some extra time for planning errors.

❓ And that's how my week started off on a lively note. How about yours?