Questions We've Answered at Our First Public Workshop

If you are a newbie to software development, starting as a professional or still learning as a student, you might find this domain kind of exhausting. There is so much to learn, so many things to do and it might be hard to know where to start. It can also be hard to know what skills are needed for each step of the way.

But there is nothing to worry about! This is the message we sent to participants at our very first open workshop with young professionals. Together with our experts, we narrowed down some of the basic things that you need to know and learn in order to be ready for your first job or internship as well as help you develop during your first experience in the field.

First of all, together with Igor Marta we talked about what to expect from a typical day of a software developer.

When you’re a software developer, your days tend to be pretty well-structured. Each day starts with checking and responding to emails. Then, you’ll have a couple of meetings, one with people on your team and another with people in different departments.

The rest of the day is spent coding, which can be as monotonous or as exciting as it sounds. It all depends on what kind of project you’re working on! Some days it can get really frustrating when things don’t work out, but other days are so exciting that time flies by without you realising it.

Remember! Engineers are the gatekeepers of excellence in the development phase of a product. They ensure that all software issues are resolved before a product hits the market. Issues uncovered during testing can include integration problems, bugs, feature overloads, broken codes, communication inadequacies, security issues and/or deviations from a client’s specifications. An effective engineer on your team will resolve them before they ever become a problem for the clients.

Another hint from Igor was about the quality of code. Good programmers write code that humans can understand. Great ones write code that humans can understand and computers can run.

Like a painting or sculpture, writing code is like a form of art. Anyone can take a block of clay and smash it into the shape of a human, but true artists can use those same pieces of clay to sculpt something that is not only beautiful but speaks to the soul.

Anyone can write code that even a computer can understand. But what matters more are the humans: the ones who read your code, learn from it, build on it, and find ways to make it better.

Writing code that only computers can read is like crafting a message to an alien race in another galaxy: you might have figured out how to communicate with them, but will they ever actually be able to understand you?

Sergiu Ivanesi, however, challenged us with another question: Is developer superior to QA/tester?

To answer that, Sergiu told us the story of his developer background. 20 years ago he started at the bottom, taking any job to build skills and get comfortable in an industry he knew nothing about.

Now he can say confidently that he had learned more from QA than any other aspect of his career.

Spending time writing code that seems like it should work, only to have it fail when we put it into production can be frustrating and demoralising if you don’t have someone there who knows how to point out your mistakes.
That’s where QA comes in. They’re the ones who test your work against every scenario they can think of and tell you what’s not working.

As QA testers, we have a responsibility to our developers. We need to be able to provide them with meaningful feedback on how their code is performing—and what improvements could optimise it.

But guess what? It goes both ways. Developers need to respect the role QA testers play in the success of the product, too. They need to know that we’re working to improve the code and make it as clean as possible before it reaches production.

It’s true that building in quality from the beginning is a team effort: we need one another to succeed. And when everyone plays their part well, everyone benefits from reduced bugs, improved efficiency, and a better product overall.

Forget the myths: QA is more than just regression testing and entering defect reports. And it should be.

If you want to be an effective QA, you have to be willing to stretch the standard definition of what QA is—and that means being willing to learn.

Being a QA means looking in every direction: upwards, downwards, sideways, and inwards. It means taking part in design by testing first, and developing documentation through writing test cases. It’s not enough to just follow the same old path that you followed yesterday. You need to be asking yourself constantly:

Is there something else I could be doing? Is there somewhere else I could be looking?

Our common conclusion at the end of the workshop was that the day you decide to take your first steps as a software developer is the moment where all of your days become an adventure.

Every day, as a software engineer, you’re faced with new challenges—and new opportunities. From learning a new language to landing a new contract, there’s always something exciting happening in the world of code, and you’ll never stop growing as a professional.

And the best part? You’ll never hit a wall. A lot of careers have dead ends—but not this one. When you’re tired of what you’re doing, it’s easy to try something new. At the end of the day, all that matters is that you feel confident in what you’re doing—and when you can’t feel that way any more, it’s just so simple to move on to something new.

We’ve been blown away by how smart and engaged everyone was at the event. It was a great chance for us to answer questions about programming languages, what professional pathways are available after you learn how to code, and how to get more skills. We learned as much from our attendees as they did from us!