The Scalac Factor

Every company has its own culture. So do we. We really love to work together as a team. Scalac started as a remote-friendly company without managers, and we continue with those values in mind. Remote work is only growing inside the company, and even though the flat structure isn’t that flat anymore you can still call our CEO by name, and we’ve got more roles rather than complicated structures. Startup atmosphere – as they call it – but we prefer to call it the Scalac’s atmosphere because we believe that the fact that we work hard, have fun, and do the right thing is something unique and great about our company. 

Growing company

Why things changed at all? Because now we have exactly 124 people in our team while only 3 years ago there were only 70. So obviously, we had to reorganize how things are done. 

We have a core team, whose members are responsible for different business areas. Of course, at the top of our team, we have a CEO, but we also have technical leaders for different teams: Development –  Backend (mostly Scala), Frontend, QA, UX/UI designers, Business Development, Project Management, Human Resources, Finance, and Marketing. 

As I’ve mentioned before, we are far away from a corporate structure, which we want to avoid as long as possible. This is crucial, but the most valuable thing about  Scalac is the people –  working as one big team of functional, passionate people to keep our quality bar very high. 

5 things to join Scalac

Are you wondering how it is to be a Scalacer or thought about applying to Scalac? Here’s a quick guide to prepare you for joining our crew and to briefly show you what the core values we cultivate are.

1. Be sure that your code is functional

If so – that’s the first strong sign that we want you in our team! 

Be ready to learn

If your code is not functional… yet – this section could be for you. Our candidates are often strong and experienced Java, PHP, Python, etc. developers, willing to switch to Scala. Their code in the technical task is well-structured, has all the goodies of OOP. However, the code isn’t very functional or reactive. In this scenario, we could call it “Java/PHP/Python in Scala”. Too many variables, as well as a lack of the proper usage of techniques available in Scala, such as Tail Recursion.

Don’t get us wrong. This doesn’t mean that we will reject great guys like this at the beginning. We encourage them to work hard and change the way they code by providing solid feedback and learning sources. 

How to learn?

We are always happy to send them Scala Tips, which were prepared by our developers, or a list of good sources to study to help start properly with Scala. We also try to share our developers’ thoughts and opinions about a candidate’s code, so if you want to consult them during the recruitment process about anything – don’t hesitate to let us know – we will be happy to help. 

A good and proven method that works best for learning functional code is to read the famous red book “Functional Programming in Scala” or complete the Martin Odersky Course. They have several exercises that force you and your brain to switch to a functional way. It might be a bit painful at first, but when you manage to break through the wall of pain, you will be enlightened and delighted. And in our experience, you probably won’t want to go back and return to nonfunctional code. But let’s see – we await your opinion! d

2. Be sure that you are close to our values

Scalac at its core is a flat organization. We love to cooperate. We have three strong values at the center of our culture:

  • Work hard
  • Have fun
  • Do the right thing

Work hard

We work hard on our projects and put our whole hearts into making them real and work properly. 

Have fun

But after all this hard work, we like to spend some time together during our online informal meetings, talking about random stuff. Or during our integration trips when we can be together, doing new activities like off-roading, paintball, kitesurfing, and do even more talking, dancing, and signing up to the morning hours ;) 

Do the right thing

Doing the right thing is just as important as the previous two. We want to believe that everything we do – we do with good intentions and for a good purpose. Often we get involved in charity campaigns to help those in need. We choose good and responsible sources for our gifts or swag if you prefer. For our employees, the most important areas for ‘doing the right thing’ are the environment, children, and animals – so we try to help them whenever we can. 

If you’re one of us – we trust you

It may sound like a cliche but when you think about it, you realize that the answer to most of your questions is you. You know what is “the right thing”. So just do it. If it doesn’t work – you can make mistakes, we all make them. That’s the way we learn. The main reason is that we strongly believe in another of our values: “People at Scalac are very smart and responsible”. When you are smart and responsible, you are able to make decisions about your own tasks, take ownership, and face up to the consequences. You do it because you know it’s needed. This goes back to our core value “Do the right thing”.

Everything around coding has to be done by someone and in most cases, you are the one who decides what to focus on.  

3. Be ready to be an integral part of Scalac

The Handbook

We use the Scalac Handbook to show new employees how we work, who is who, how all the processes work. We want to be transparent and open to discussion at all times. In our Handbook, we have an unwritten chapter, where everyone can add something his or herself to improve our way of working. 

Scalac Times and Meetings

In our internal communications, we try to be as transparent as possible. We have our Scalac Times newspaper, which comes out cyclically every month and contains the most important information about what has been happening in our projects, teams, events, etc during the last month. In this newspaper, every team has its own space and can give any information it wants. We have also set up cyclical meetings between the whole team and our CEO, at which we can ask about anything connected to our company.  


A really important part of the way we function is knowledge sharing. We love to share our knowledge everywhere, all around the world in fact. We want to be an integral part of the Scala community and develop it together at different conferences, in our branches, or via taking part in open source contributions. Scalac organizes its own events such as Functional Tricity meetups, Scala Wave conferences, Scalac Summer Camps, and Pizza meetings, where we can also share our expert knowledge with each other. 

4. Be open to working remotely

Scalac is a remote-friendly company. This means that apart from the values we have already outlined, remote work is another core aspect of our company. How do we work remotely? 

How to work remotely

Our employees have already written great articles on this subject, you can find them here: 

In these texts, our Scalacers list several challenges of remote working and share tips on how to handle them from different perspectives. Please read them and think for a moment if it’s really for you. Maybe you would prefer to mix remote working with working from the office in Gdańsk or in coworking spaces. This type of work is challenging and requires a lot of self-organization and perseverance. But if it suits you – it can be a great, valuable experience! 

Despite the remote character of our work, as we mentioned before, we love to spend time together. We pay a lot of attention to our relationships and nurturing them. After work, we can talk on our #cafe or #wine channels or meet during company retreats. 

Watch this video to have a little sneak peek on how it looks like.

These days, after the coronavirus lockdown, the world and ways of working are changing and market research shows that remote work has become more popular than even just one year ago. And we’re quite lucky to have 6 years of experience in this matter. 

According to the ‘Remote Managers 2020 Report’, 87% of remote managers believe that remote work really is the future. 

5. Be ready to choose your own direction

It’s important to know where you are heading. Of course, your plans may change a year from now but we like to work with people who know what they want to invest their time in. We know that it’s hard to be good in every field. 

There are cases when somebody is a full-stack developer but being good at both ends of the software requires a tremendous amount of hard work. We really appreciate it and support it as much as we can. 

Scala hAkkers 

We are experts in the field of Scala functional programming and we want to work with the best Scala hAkkers in the world. 

It’s important to know where you want to be in the future and we as a company can help you develop your career path in various directions: 

  • Consultant – focused on cooperation between technology and business, explaining technical issues to the clients, proposing solutions, and ways to implement projects.
  • Team player or mentor supporter – focused on teamwork, always willing to help, share your knowledge, caring for the development of both yourself and the team.
  • Typical hacker – focused on the hard, complicated programming tasks to bring projects to an end with good quality. 
  • Any other path which you have a vision for, or maybe you have an idea you want to develop, something you’re able to show us and convince us it’s a great idea.   If so, yes! Let’s do it together! 

We like to work with people who are well aware of their choices and are fully committed to achieving their goals. We help them to do this by sponsoring their trips to the best conferences around the world, providing books, holding both internal and external training.

Join Scalac

On our Careers page you might like to take a look at us, our teams, how we work, what is important to us, which positions are open, and a lot more information which we hope will convince you to join us. 

As I mentioned before we do not have only Scala team, but it is our core – especially in the context of functional programming, so it was only to highlight where we’re coming from. We’re constantly changing and building new teams. 

So, are you ready to join Scalac? Do you agree with our core values? Is there anything you would do differently? If so, we’re happy and open to talk to you about it! 

Originally written in 01.2016 by Maciej Greń, updated in 09.2020 by Katarzyna Królikowska

We compared hours and hourly rates and the outcome might surprise you

Automation testing or manual testing? That is the question! Which one is better? This is something that gives many in the tester community sleepless nights. Especially during a project when we have to determine the testing strategy, even at its later stages. This is also, unfortunately, a question with no clear answer. Why? Because the reality is that these two ways of testing are inseparably connected with each other.

If you’re still wondering which is more profitable, effective, or better suited to your or your client’s project, let’s dive right in. Here we’ll be revealing the true value of automation vs manual testing, based on one of our clients’ applications – CloudAdmin.

Why CloudAdmin?

Together with Pawel Gieniec (CEO & Founder CloudAdmin), we are creating and developing a web application – CloudAdmin. Cloud Admin is a cost-optimization platform, which helps save thousands of dollars by eliminating hidden cloud instance buying costs.

The project turned out to be perfect for introducing an automation architecture for modules that are always tested during regression testing (the process of running older tests to ensure that new updates to a piece of software haven’t introduced or re-introduced previously eradicated bugs). Our goal is to save time, which we will then be able to spend on manually testing new functionalities. The application is developing dynamically, so we’ll be needing more and more time to check all of the fresh new features.

One of the core functionalities is logging. Nothing surprising, this is probably the module most often automated.

We decided to use automated testing with Python and pytest. 

And this is how it went:

We based our login tests on these 7 test cases below.

The first video is from PyCharm (the Python IDE). It shows how long it takes to run and finish all of the tests for the login module. As you can see, all of them passed. This means all of the cases have been tested correctly and have achieved the expected results, i.e.  the functionality works properly. 

Automated tests – this process took 1:39.

Now take a look at the video below. It shows how long it takes to carry out manual testing for the same test cases as for the automated tests. 

Manual tests – this process took 1:57.

How test automation reduces the time

At first, you might think “Hmm, this is no big deal. There’s only an 18-second difference in favor of automation.”. Okay, you’re right, but let’s think more in the long-term and globally.

First of all, it’s not just an 18-second gain. It’s an almost 2-minute yield for one run! This will ultimately give us more time to spend on the project. How? 

If you decide to implement automation architecture for sections that always needs to be covered by manual regression testing, you will gain all of this time for doing other things (manual testing for new features, application development, automation architecture development).

The login module is just a drop in the ocean. But let’s take a look further. Let’s compare working times by adding the next 3 modules: AWS Ri Planner, AWS RI Management, AWS Spend.

As you can see, the automation tests give us a 35% time yield relative to the manual tests (9:16 min vs 14:14 min). And again, this is a 14:14-minute gain, we have saved on regression tests – for only 4 modules.

How test automation increases productivity

As mentioned before, by dint of test automation, the testing team gains more time they can spend on doing other tasks. But this is not the only thing they get. Regression testing can be tiring. Imagine how tedious it would be to repeat the same action over and over again. This might sound trivial, but the time involved in repetitive, manual testing is wasted, especially over a longer course of time. With this in mind, think about how much more productive testers could be if they were able to devote more time to performance testing, security testing, or testing of new features. 

Moreover, testers have to quickly and continuously execute a lot of time-consuming tests simultaneously, just to be sure an application is performing as expected at all times.

How long will setting up an automation architecture take?

It’s rare that everyone on your team has  automation experience, so when it comes to resources, you will really have to gauge how much time it will take for your tool to make an impact. You will either need to invest in expanding your team’s automation knowledge or hire automation specialists.

Let’s go back to our CloudAdmin tests. 

Considering the  4 sections previously mentioned (Login, RI Planner, RI Management, Spend), our QA Engineer (the automation tests were written by one person) devoted 80 hours to:

  • choosing and configurating tools  – 16 hours
  • writing automation tests for every test case – 16 hours per module / 64 hours per 4 modules

It might seem like this is a long period of time, but don’t be fooled. Automation architecture is reusable. We can use it limitlessly.  Maintenance and development of automated test cases is an ongoing process. Unfortunately, there’s no guarantee that  spending eighty hours automating a set of tests means you won’t have to deal with them again. But it will still take definitely less time in general. Take a look at the graph below:


The turnaround time for automatic testing is definitively longer than for manual. However, the benefits of automation outweigh the time benchmark in terms of:

  • Reduction in execution time 
  • Reduction in effort 

These two metrics will provide an incredible boost towards higher efficiency and a better rate of reaction to potential bugs.

What about costs?

Last but not least, is something most crucial when establishing a contract with a client – costs. Test automation might be a catchy slogan during negotiations but it’s worth checking the hidden costs. You don’t want the client to think this is just another fashionable balloon, ready to burst at any time.

If you intend to adopt an automated testing process to meet the rising demand for bug-free releases and faster delivery cycles, it’s vital to assess whether the return on investment (ROI) is worth the changes. Before executing, or even considering building an automation strategy, you will want to calculate the net gain you will achieve from transitioning. Divide this by the net investment needed to transition (i.e., the tools and resources you use), and you will see your ROI for automated testing.


The maintenance cost of test automation is not usually trivial but if you keep enhancing the test automation framework, improve the application testability and overall testing processes, a high ROI is very much achievable.

To get the total cost, you will also want to take into account the hourly cost of the number of team members executing the tests.

Based on the average earnings for an Automation QA Engineer and a Manual QA Engineer (I rely on data from Glassdoor), we can make a labor cost comparison simulation based on the CloudAdmin case study (hours needed to perform each type of tests for this application).

As I mentioned before, it took 80 hours for our QA Engineer to develop and execute the automated tests for the 4 CloudAdmin sections. How many times might we manually test the same part of the app at the same time? 337 times (for the record: manual testing time -> total time from the module times table). So what’s better: 

  • spending $2,100 on performing  the same set of regression, manual tests 337 times


  • spending $2,700 on building an automation architecture – which once created is reusable?

We’ll let you answer that question ;) 

Final battle: Manual Testing vs Automation Testing

To wrap up, is an automation testing a cure-all for time-consuming manual testing? Not really. Manual testing will always be important. There are scenarios that will always require manually executed test cases. This means you will still have to create, run, and maintain the tests. But there are still a lot of situations when you can successfully implement automation. This can be a cost-effective method for regression testing of software products that have a long maintenance life.

With a balanced approach to the testing process and a smart and effective amalgamation of both automation and manual testing, you can spend more time focusing on building new features to enhance your product quality – ultimately giving yourself the opportunity to stay ahead and be more competitive in the market.

Check out other testing-related articles

Check out other business-related articles