Answers to FAQ about being a Software Engineer in Picus

As one of Turkey’s leading startup companies, Picus’ awareness is increasing day by day. While writing this article, I wanted to talk about the engineering culture inside as a software engineer who has been working at Picus for about 2 years.

One of the most common question that we get is “How much cyber security knowledge is expected from a software engineer in Picus.” To answer this question I would like to introduce the Picuslabs. Picus has very strong labs teams that handle the heavy lifting in terms of research for the problems that we want to offer solutions to our customers. While making research they try to answer if we as Picus can offer a valuable solution in an elegant way, if yes what are the pros and cons of each alternative.

As well as doing research before adding new functionality to the product, they also handle producing all the threat and detection content.

If we get back to the question, no cyber security knowledge is expected from the software engineers, at least at the beginning. Of course it is important to understand the basics to comprehend the big picture of the product. However, that knowledge is easily gained within the first few months with the help of the onboarding process and ready to help team members.

Another question that we frequently get is “How do the engineering teams operate?”

There is a roadmap that is managed and constantly updated by the Product Management team. As I mentioned above, the research that needs to be done in order to achieve the medium and long-term goals in this roadmap are carried out by the labs teams, while the UX team analyzes the short-term goals in detail from the user experience perspective and prepares the necessary designs.

That way, the development teams focus on the items below:

• The delivery of the features in the current scope & fixing the existing problems
• Working on the next scope by analyzing the items in the roadmap from the technical perspective
• Designing and preparing the infrastructure for the items that will be developed in near future.
• Managing the technical debts
• Clear & maintainable code base

Delivering the features of the current scope, fixing the existing bugs, working on the next scope and preparing the necessary infrastructure for it are pretty obvious things for almost all software development teams. So, I’m skipping them because I want to talk more about how we approach technical debts and code base maintainability.

Technical debts & refactoring

There are so many features we want to add to our product and we are trying to add them quickly. Speed brings faults, bad practices & low performance, wrong design decisions, and even mistakes in analysis. When these errors accumulate, it can be very laborious and costly to return. We are aware of it and that’s why we pay attention to our mistakes, and want to return from them as early as possible. We constantly approach the decisions we make and the code we write with a critical eye, we generate technical debts for ourselves and manage them explicitly in our development board.

Paying off the technical debts often means refactoring. For us, refactoring is not a separate activity to be handled from time to time, we see it as a part of the software development cycle instead and include it our plans.

If you want to read more about refactoring, here is my personal thoughts about it.

Automated Tests

Another thing that we see as part of the software development process is automated testing (especially unit and integration tests). Before you can write a test, the code you want to test must be testable. In order to write a testable code, you inevitably have to apply the basic software principles which as a result helps you write more modular and more manageable code. Another benefit of writing tests is that they are the protectors of the code base from unexpected side effects.

Automated testing is part of the CI/CD pipeline for us, as in many software companies. If all tests are not passed, the relevant piece of code cannot go to the main development branch and therefore cannot go live.

But we realised that noticing the failing tests after the CI/CD pipeline fails is a little bit late. For that reason, we wrote a git pre-push hook that is automatically triggered with the git push but before the code is actually pushed to the origin. That hook automatically regenerates the mocks, runs the tests in the local environment, and fails the push command execution if there are test failures.

Code Review

The code review phase is one of our strengths. The review activity is a prerequisite for a piece of code to go to the main development branch. While doing code review, we warn each other about our mistakes, discuss more effective versions of the proposed solutions, check if the basic software principles are applied, and most importantly we learn from each other. This helps all the software developers in the team meet on the same page over time.

One final question that I want to talk about is “Working remotely is nice but also hard. How Picus handle it?”

Picus has managed to say “health first” by removing the obligation to come to the office from the beginning of the pandemic process, and even turned remote working into an advantage. Many companies worry about switching to remote work because they are afraid of a decrease in productivity. I can clearly say that productivity in Picus, on the contrary, has increased. Yes, it is not easy to achieve this, but it is quite possible when the necessary environment is provided. Trust, autonomy, and communication are the keys here.

With remote work, the importance of intra-team and inter-team communication increases even more. As software teams, we are aware of it, and we always keep in touch, support each other, do pair programming when necessary and solve problems together. We move forward as a team.

One challenge that comes with working remotely is emotional disconnection. It is very difficult to develop ties in relationships where we do not work side by side and communicate only in digital environments. Although we think that professionalism is a necessity in the business world and act accordingly, we believe that developing close ties within and between the teams has a very important role in success. That’s why it is important for us to get together occasionally and spend time together.

In this article, I talked about both the distribution of the responsibilities within Picus Security and what we care about as engineering teams. Of course, the way we work and the points we care about are not limited to what I wrote here. For example, we pay attention to constantly improving ourselves and sharing what we learn. We attach importance to following the right software development practices. We constantly criticize not only the code, but also our processes, and strive to improve the way we work. In each cycle, we set our sprint goals as a team and try to comply as a team.

There are many other points like these that can be listed but I tried to talk about more interesting topics and tried to answer the most common questions about being a software engineer in Picus Security. I hope I was able to paint a picture in your mind for those who are wondering.