“It was the best of times, it was the worst of times, it was the age of wisdom, it was the age of foolishness, it was the epoch of belief, it was the epoch of incredulity, it was the season of light, it was the season of darkness, it was the spring of hope, it was the winter of despair.” Dickens was obviously referring to the Covid pandemic.

So here we are, at the end of 2020’s sequel, and while it sometimes feels we’re stuck in limbo, OutSystemers had plenty of reasons to celebrate in 2021. Our team grew by leaps and bounds, we celebrated 20 years of this now grown-up company with a vibrant startup mindset, and we have exciting new projects ahead.

To keep the good vibes flowing into the new year, we asked eight OutSystemers about their best moments of 2021. Here’s what they had to say.

For me, 2021 was both challenging and rewarding. OutSystems is a place where no two days are the same. I can guarantee you will never get bored!

I’ve been at OutSystems for the last six months; it seems like it was ages ago. When looking at all the work I’ve done and the feedback I received, the satisfaction is priceless. I am really proud to be part of this team where I had the opportunity to learn from the best-you do learn every single day.

Things at Outsystems happen at a fast pace, but it gets easier when you have a team that is always available, willing to support you, believes in you, and aims for the best. It is so fulfilling when your opinion and work matter.

I met such amazing people, and some have become my second family, my friends!

2021 was a year full of the best moments and I can’t wait for 2022!

This is one of the happiest memories I will keep from this year:

I’ve been at OutSystems for more than a decade, and the ability this company has to adapt to every circumstance never ceases to amaze me. For most of us, 2021 was the year of the consolidation of remote work. We learned how to work as a group in a distributed way, and even expanded to new areas of the globe.

This year, my team implemented a solution to send Emails in Reactive Applications. It was a huge challenge from the start, as it was a highly requested feature in our community, and we had to redesign it from scratch. We just released it into general availability, and it’s already in use in hundreds of applications. Wow! It’s an absolutely fantastic feeling — I’m super proud of my team!

What was my biggest accomplishment? My beautiful daughter! Sofia was born in August, and she is amazing! The biggest challenge? Well, dealing with a newborn and a toddler with my arm in a cast. I do not recommend that! Please stay safe!

I joined OutSystems because I strongly believe in the impact that it will make on the market and world. We have a once-in-a-lifetime opportunity here.

The Security division is non-stop action, comparable to a “Mission Impossible” movie. We get to hunt down threats via Breeze and Wazuh, walk through cobblestone streets in Portugal, gain insights into what is running in the infrastructure that we have, and are starting to develop an actionable intelligence system to mitigate identified threats.

Sometimes, we even get to impersonate other individuals within the Individual and Account Management Teams. The company and division have a positive outlook and are performing with a sense of purpose. 2021 was a wild ride. We’re all looking forward to what we get to see and bring to the company in 2022.

After nine years at the OutSystems Customer Success team, in February 2021, I moved to OutSystems Engineering, where I found people full of drive, committed, with a true sense of pride over our Product and what it stands for, and a great leadership alignment!

I had the challenge of maturing the product ownership (PO) practice while growing the PO structure as the R&D Team expanded. After 10 months of tons of interviews to almost triple the PO structure in size, I’m very proud of what my team and I have achieved in 2021: a consolidated PO practice, product owners who are recognized as key in bridging strategy and execution, and playing a leading role in all key initiatives across the year, and a solid and collaborative structure that is well integrated into the Product groups.

It’s been one hell of a ride, and I’m looking forward to what 2022 will hold!

2021 was a strange year for everyone but, at the same time, a great year for the team. At Technical Knowledge, not only did we onboard several new colleagues throughout the year, but we also continued to deliver the best technical content to our users. In between, we were recognized by it, which is always nice.

In 2021, I would highlight two major accomplishments:

We created and delivered “Project Facelift,” in which we updated all the documentation and training visual assets to support the launch of Service Studio for macOS. That translated into roughly 4,500 updated visual assets, among images, screenshots, videos, etc. As part of this project, we also reviewed (literally) thousands of documentation articles and hundreds of videos to make sure the content was contextual and up to date with the new Service Studio. These were delivered on launch day, as we released Service Studio with a fully digital experience that takes macOS users to the right training and documentation.

Secondly, we’ve been delivering a fully updated Architecture Guided Path to help our OutSystems users, especially Tech Leads and Architects, access the latest and greatest best practices on architecture design for the OutSystems applications and factories.

All this work and the things we do each day came with a good amount of recognition for the team, especially the two impact awards that we received at LavaCon, one of the world’s leading content strategy conferences. These distinctions, one for our work automating online training creation and the other for our approach to documentation and training as technical knowledge, are the external recognition of our team as a leading team in this area of the software industry.

On a more personal note, another best moment — with the pandemic and everything going on — was having almost everyone on the team together in the same room!

It’s quite difficult to list all the year’s best moments because every day is a surprise, filled with great little moments. Thinking of the Product Content Team, something that comes to mind is that everyone really embraces what designing a product is about: collaboration, openness, and reflection. And we should never forget that writing is designing.

In 2021, our team grew globally. We’ve worked on evolving our practice, shaping our guidelines and processes. We started designing for Project Neo to help outline the best experience for our current and new users. For that, we decided to kick off a terminology initiative in which we’ve been running a lot of research and testing to choose the best words for our users.

It’s been about one year since I joined OutSystems, and I can say it has been a year full of great challenges!

This year, our team had the opportunity to work with two other teams, participated in different initiatives to enable our users to have a faster and better experience using Service Studio, and joined forces on Service Studio’s release for macOS. Working alongside these teams and in these initiatives was a great learning experience full of surprises.

Besides learning about different projects, it was also an excellent opportunity to get to know other colleagues, especially at a time when we were all working remotely. It was great to know other people, which is not so easy when we all work apart.

Given all the time we spent working with different teams, I would say the best 2021 moment was when we could finally get the team back together! A second highlight for me was when we gathered in person and even got matching t-shirts!

Even more exciting, we had new people joining the team and started working on a new AI-powered initiative full of surprises.

I look forward to seeing what next year will bring!

I joined OutSystems in May 2021, and people aren’t wrong when they say that OutSystems years are like dog years. Every day at OutSystems is so rich in experiences that I feel a little bit more grown-up each week.

It has been a journey that I would define as unique. Since my first day, a lot has changed, and I am sure there will be more changes ahead. Change is a constant at OutSystems, and our team is definitely not afraid of it. The group is incredibly adaptable and committed to the mission. You can feel it at any encounter, informal chat, or business meeting. Everybody is here to ensure we “Give Every Organization the Power to Innovate Through Software.” [That’s the OutSystems mission, by the way.]

Personally, I am grateful to OutSystems for my team. Together, we came a long way and built a strong team from the ground up. This year, we launched a new R&D Onboarding Program, among other milestones, and the team worked tirelessly to make this happen. It has been a success so far, and I could not be prouder of what we have accomplished, mainly being a newly formed team in a remote setup.

Much like my team, high energy and drive are common denominators for all OutSystems employees. The company enables that by giving every individual the autonomy to expand horizons, the freedom to experiment, and plenty of opportunities to prove value.

Now, I look forward to the new amazing achievements we will be able to unlock in 2022!

Happy New Year from the OutSystems Engineering Team!

Originally published at https://www.outsystems.com.

8 Best Moments of OutSystems Engineering in 2021 was originally published in OutSystems Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

At OutSystems, we believe in programing with good practices. We’ve seen so many cool stories about apps created to help people and fight the pandemic.

Moreover, the world needs more developers in the swiftly growing digital era. One LinkedIn search showed there are 719,074 developers vacancies worldwide to be filled — considering the U.S. alone, there are more than one million developer positions today. And if we narrow the search to “OutSystems developer,” our community has 358 jobs available.

This is undoubtedly the tech golden era. Covid-19 caused an impact in businesses with almost everyone working remotely, requiring fast and collaborative platforms. For the consumers and clients, the lookdown closed nonessential stores, services, and part of the solution — because consumer spending is one of the most important driving forces for global economic growth — was even more modern applications to keep customers consuming and users online. And the result was: the critical despair of hiring developers as we read in this piece about Romania, but the competition is so high that that’s happening in every country.

During pandemic peaks, people spent less but didn’t stop consuming — and in some cases, spent more compared to pre-pandemic levels — on some necessities such as groceries and household supplies. We know for a fact the shift to digital persisted just like in pre-pandemic times and that more people expect to purchase online post-Covid.

But, let’s cut to the chase and get to the part you want to know: Why OutSystems?

It’s All About Great People, Collaboration, and Solving Real-Life Puzzles

If you are wondering “why should I start developing with OutSystems or work at OutSystems?” Then this next part is for you. Well, it’s easy to answer the first question, our community of developers has shared their love for OutSystems and inspired so many. Did you know about Helena Lameiro’s story?

“Helena used to be a pharmacist in a pharmacy near the LaV office. Not very happy with the progression of her career in the bridge of 40, she did an ITUp OutSystems training course. A few weeks later, she was working at Everis where she is now a senior developer. She has since: achieved 9 OutSystems certifications, became an OutSystems community champion, was on a winning team of the Build for the Future Hackathon, gave two talks about becoming a low-code developer. She’s also one of the most active users in providing feedback on our documentation. For her, OutSystems opened a completely new career possibility she never thought she could excel on as someone that wasn’t an engineer.”

But, if you’d like to help build the OutSystems platform there is no one better than our engineers to tell you why the company — that helps to build applications fast, right, and for the future — is a good place to work. Let’s read from seven people working at OutSystems Engineering.

“In my mere 11 months at OutSystems, I was amazed by the way such a big company could hold up a healthy, transparent, and honest culture so well. Empathy, ownership, and autonomy are something I enjoy here and this lets everyone free up their mind and think innovatively and bring value.”

“I think OutSystems is a great place to work because it has a development culture that both attracts and retains great people. This means that, wherever you go in OutSystems, you tend to be surrounded by people who are growing and reaching towards the future. The company itself has both the vision and the ability to actually follow through with their vision.”

“Since I was a kid I always liked puzzles, OutSystems gives me the ability to solve real-life puzzles that can benefit the lives of millions, and that’s very gratifying. When I’m solving puzzles, most of the time I feel like the “Dr. House” of issues. I can do what I like while having fun and be with awesome peers that basically enjoy the same things. People around me are very happy and smart, and that makes me feel happy and smart.”

“Outsystems Engineering is the place where magic is made, with innovation and creativity. You just need to embrace it. From creating a new product from scratch, or just a feature to answer a customer’s question, or even to improve the way we do things faster. It is just there and there is no way you can miss it. And this is happening because we have talented and passionate people in our DNA. Even in the most challenging times, we don’t give up.”

“Here I feel fulfilled! I was part of the team that started OutSystems’ PAN branch in 2009. For most of my years I worked at Professional Services, travelling the world to support customers and find solutions, it was only two years ago that I switched departments to Engineering. I’m still here because OutSystems has the best collaborative work environment — everyone jumps in to help no matter the job description — I feel challenged everyday and on top of innovation.”

“I found a friendly and supportive environment where I can try a new career path. I could find leaders and mentors with whom I could learn from and grow in a different position. That helped me to acquire a number of skills that otherwise would take more time to get. I feel that every time I step out of my comfort zone there is a wave of support and empowerment and that is what I like the most about working at OutSystems.”

“Working at Outsystems is different from any of my previous developing jobs. I am amazed by the developing team size and talent, and the product it developed. The company just had its 20 years anniversary but yet the spirit still feels young and energetic. Everyone is very engaging and very responsive. It is truly a fast-paced environment, in a good way. Also, you can feel there is a strong sense of involvement within the company. People are not just doing their own daily work. They truly care about every aspect, from its customer, the product, company strategy to the working environment. There’s a lot of feedback and healthy discussion on all topics on all slack channels. Some of the discussions may sound blunt or may be carried too enthusiastically to new people. But I think this reflects the “Ask why” culture of the company best and it’s a good thing. I also appreciate that Outsystems’ employees come from different places and cultures of the world. One can learn a lot by interacting with people with different backgrounds, both in and out of work.”

Recently, OutSystems was featured in Wired in a story about engineers finding new workplaces to prioritize their own wellbeing. And even the reporter wrote to me, “Seems like a great engineering culture you’ve got over there!”

If you would like to be a part of OutSystems Engineering, click here to find our latest vacancies.

Why OutSystems Engineering Is A Good Place to Work was originally published in OutSystems Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Developer experience — think of it as the user experience of programmers. Or, as we like to say, developers are people, too. And this means that they also feel pain. It can be physical, of course, but the pain we want to highlight here is the rather intense emotional pain — which turns physical after you despairingly hit your head on your desk — that comes with the disruption of your programming and thought flow. And who’s to blame? The framework you’re using.

By now, you’re probably aware that we like to talk about frameworks. “We” are the Data Visualization Team at OutSystems, who, in the inaugural article of this series, advocated for building components with the mindset of creating a framework for added productivity and efficiency.

As a unit whose work revolves around creating components for developers who program with our visual, low-code platform, we explained that the first step for creating a fantastic framework is picking the adequate tools and technologies.

Aaaand if we had skin-itching, dev-ingrained qualms about using the word “fantastic” to describe frameworks in that first article, these evaporated as soon as we began talking about the kind of developer experience we aim to provide. It must, indeed, be fantastic — hey, you must always aim high…

Tag along as we guide you through the second step of building a framework: how to provide a fantastic developer experience. Now, where did we get that idea from? Customers, of course.

Developer Experience First, Technology After

Before moving to the OutSystems R&D Team, two of our team members worked closely with customers as part of the Professional Services Team. That gave them a unique understanding of how the OutSystems platform is used and what the requirements are of the developers who use it. And, this knowledge, of course, shaped our entire work and our approach to problems.

With our distinct vision and experience, we set out to define a few guiding principles that would become our manifesto. These are our seven commandments:

1. Experience first, technology after — we don’t follow fads and prioritize the developer experience over technology trends.

2. The world is our customer; a customer doesn’t rule the world — we deeply value our customer’s feedback, but we’re also fans of the 80/20 rule. Before implementing a new feature, we must assess how many people we’re impacting.

3. Do not reinvent the wheel. Period.

4. No one’s left behind — products exist because they are used. We believe that our mission is to listen to users and help them extract the best out of the product. We support them, listen to their use cases, and we never ignore them. To answer their issues, we can alter the product or send a custom sample (more on that below). By helping users, we are creating forward motion in two directions: they learn more about the product and see their use case resolved, while we lean on their feedback to improve the product, documentation, and even our backlogs.

5. No third-party lock-in — we don’t wish to be limited to a single provider. We built our code architecture and framework to facilitate work with different providers.

6. Doing it the right way takes the same time as doing it wrong.

And finally, last but certainly not least, as this is the major focal point of this article:

7. Keep the feedback looping — we work in close collaboration with the developers that use our components and the OutSystems platform. We have tools to monitor our user forums. Being close to the developers who build apps with our product allows us some complacency: because we keep such a watchful eye on their pains, we get away with breaking changes. There’s a margin error that comes with trust, and they are aware that as soon as they complain, we’re here to fix it.

“Hang on,” you may be thinking. “Didn’t they say that the first step to building a framework was choosing the appropriate tools and technologies?” You are correct.

But if the tools you’ve picked for the task don’t serve your users (remember that in a framework your users are other developers), they should probably be left in your toolbox. When building a framework, you’re not simply developing an app for customers; you’re creating modular blocks that other developers will use to devise apps for their customers. So you better make something freakin’ okay (read: fantastic) with developers in mind instead of tinkering with the latest hot tools that will deliver a flashy yet underwhelming result.

Remember point three: do not reinvent the wheel. Respect the industry standards and design for consistency.

You will find that we will refer to our principles many times throughout this article. Our seven-rule manifesto is crucial to our work because its guidelines aren’t ornamental; they impact our decisions, and we can trace back our choices to each of them. For instance, “experience first, technology after” is a great principle, but it only works when you live up to it.

The Decision Tree

So how do we do it?

With the help of our Product Designer Mariana Bexiga, we created a visual decision tree that we use every time we need to add a new feature to one of our components. The tree allows us to determine how we should add it and where and visually explains the reasoning behind that decision. All in all, it’s a unique tool within OutSystems R&D — for now.

Our decision tree works almost like a parameter or placeholder, adding to our efficiency as a team. Farewell two-hour meetings, good riddance! We can now make decisions in 15 to 30 minutes just by following our tree when adding a new feature.

Components were often built in an ad hoc fashion, and that is precisely what we tried to avoid by creating our framework and our manifesto. It aligns our team towards a common goal and enables us to make quick and productive moves. Much like programmers follow coding standards and best practices, we put together a few best practices for components, and our matrix is a vital part of it.

First, we start by evaluating whether the feature our users requested must be added or not — based on how much usage we predict it will have. If, for some reason, we decide not to add a feature immediately, we keep track of it and wait until we know that we must add it because the developers using the OutSystems platform truly need it. In this, we are quite medieval and believe that “pain will bring us the truth,” meaning that we purposely avoid giving viable workarounds to see how many people actually complain.

After that, we use the decision tree to understand how to add the new feature. This way, we can ensure consistency with other features, meaning that integration within the component and other components will be seamless, making our devs’ lives easier.

A Whole Branch of Questions

Let’s imagine that we want to add the Center property to the map. This property specifies the place where the map should be centered. The first question is, “Can it live isolated on the page?” In this case, we pick “no.” The Center feature can’t live isolated on the page and is intrinsically related to the map.

The next question is, “Can it be defined by a boolean, number, string, or identifier?” The Center needs to be defined by its coordinates (latitude and longitude) or address. So, the answer to this question is “yes.”

Those are some of the rules we follow when dealing with more complex properties. We like to provide a subset of options with relevant values instead of having an “open” field to ease the development process. For instance, in the case of Zoom, we decided to give devs a group of options (read a static entity) instead of having an Integer field (they can always extend it and add other values).

Next, we have the following question: “Is it mandatory or is it frequently used?”
We avoid having mandatory fields as much as possible and give smart defaults instead to speed up the development process. Usually, mandatory fields refer to lists or variables that the developer must define and that the pattern will not work without.

To answer the second part of the question — “Is it frequently used?” — we rely on data (from interviews, our community forums, and usage data). If we know other OutSystems / Forge components with similar properties, we check their usage to understand how developers are working with them. This way, we can make informed, data-driven decisions.

As far as the Center property, it wouldn’t be a mandatory field, but our developers would use it frequently. The answer is “yes.”

And we reached the end of a branch! According to the tree, the center of the map must be a property at the root of the block, that is, one of the properties that are immediately shown to the developer given its relevance.

Keep Your Users Close, and Your Pain Points Closer

One of the reasons why we felt we needed a decision tree to support our decisions is because we’re so close to our users (see point seven of our manifesto). For us, that is crucial to provide the best developer experience.

Being close, however, brings you new insight into their needs — and with new needs come new decisions, which lead us back to our tree. You get the point.

Fast decisions mean faster actions. And with every problem we solve, thanks to our users’ feedback, our trust capital continues to grow. Users trust that we will make their experience better, which is invaluable. It’s how we keep on growing and improving as a team.

One of the ways we keep in touch with the developers that use OutSystems is by inviting them to an interview with the team. Feedback can be scarce in the first few days after you release a new component, so if we get comments or questions in our forum, we reach out to those developers to question how we can further improve their experience.

(Again, keep the feedback looping.)

But that’s not the only thing we do…

How We Keep Track of Users Feedback

We have devised clever ways never to lose track of the feedback we receive. If you read our previous article, you know we are motivated by laziness. Why chase inputs in many different platforms when they can come to you?

Picture this: you have multiple threads from multiple components. Now, you have to keep track of them. By keeping track, we mean something as simple as knowing which threads you already answered and provided the user with the right solution so that you can act upon the unattended ones and don’t miss that precious feedback.

Well, this can be a nightmare to manage, as more and more components fall under our hat. So, we needed to develop a new way to control the threads from our assets. With the help of scraping tools, we created an internal application that combs through all the questions from our components’ forum pages and collects the following info:

• Title
• Date of creation
• Number of comments and likes
• Reply dates

The best part is that the app does all of this behind the scenes, which means that in short (and configurable) intervals, the scraping runs itself and collects the data to fill our five-component thread slots. It then highlights the ones that may need our attention either because they have new questions from our community or recent updates.

And, in case you’re wondering, the application could, of course, have been done differently, but it was built within the current limitations of the forum, which doesn’t have any supported or public APIs to analyze the community posts and group the threads to answer our needs.

Sampling for Success

Finally, there’s nothing wrong with a bit of show and tell.

To amp up our developer experience, we focused on building rich samples, full of real-life examples, to help developers understand how they can use our components. Our samples are available for download on Forge, allowing users a live sneak preview of our components.

Since we have experience with development, we know that an excellent way to learn is by seeing and doing. The samples that we build have a double purpose (check out the ones we created for the OutSystems Maps and Data Grid Reactive components). They are documentation but you can download the source code and, instead of just reading the documentation, you can check how the sample was implemented.

This really helps reduce the learning curve and gives a sense of openness for our users, since we are showing and sharing our code (just like Git, where our repositories for OutSystems Maps and Data Grid Reactive, for example, are public and we have even received and accepted pull requests from people outside OutSystems).

In the end, we build the documentation and samples that we wish we had when we were (or are) in the developer seat. And ultimately, that is why we work so hard towards a fantastic developer experience — it takes one to know one.

Originally published at https://www.outsystems.com.

Fantastic Frameworks and How to Build Them: Developer Experience was originally published in OutSystems Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Filipa Almeida, 28, thought she would be doing pastry for a very long time: comforting people’s hearts through desserts, seeing them smile, and feeling really embarrassed whenever she got a compliment as she is mostly a giver, not a receiver. Her career was doing great, working at movie sets, Marylebone Cricket Stadium, charming hotels and catering companies. But about one year ago a question came to her mind: why not turn into the technology business?

Born in Amadora, Lisbon’s outskirts, Filipa has a seven-year background in Pastry, a degree in Cookery and Food Production from Estoril Higher Institute for Tourism and Hospitality, and a Pastry diploma from Le Cordon Bleu — one of the largest network of culinary and hospitality schools in the world — a course she attended in 2017 in London to uplevel her culinary skills. Gordon Ramsay, one of her favourite chefs, was born there. The other favourites are: Dominique Ansel, and her personal hero Raymond Blanc, who have set up businesses in England.

Throughout all the places, different people and recipes, she gathered a bunch of neat moments and others not so great, but she was able to keep a positive attitude. “These experiences gave me experience in many things, especially soft skills like dealing with customers and deadlines, being organized, a team player, eager to learn and not afraid to ask for help. This is really the most similar thing between pastry and IT; the technical part I’m still learning every day.”

So what made Filipa change her career? In February 2020, when she was about to leave the front lines of baking cakes and start a new job as a human resources consultant in the same industry, something unexpected happened.

“Hospitality workforce is not an easy world, unpredictable work hours and the pressure of solving a problem on the spot — my body was not taking it lightly. By the age of 26 I already had experienced three burnouts. I was at a hotel doing the breakfast shift. Started my day at 4:30 AM and never got out before 4:00 PM. I had midweek days off, which meant I never got to have a social life outside my job. It started to affect my mental health in ways I can’t even put into words, and it manifested through some physical signs that made me stop working for a few days, so I decided it was time to think about my health first.” That was when Covid-19 hit, Food and Beverage businesses crashed, and it was almost impossible to get any related job. She became desperate about what she was going to do with her life and studies. “I had invested so much to just move along to some other career! Those first months of unemployment were really difficult.”

Recalling how she overcame that period, she said: “Everything has a reason. I’m a gamer and have a lot of family and friends working in IT. That made me think about it and see a big world of possibilities in the industry.”

Before, she never thought about programming languages and writing code itself, “It kind of bothered me, but the thought of being able to do it while using ‘low-code’ and logic brought me hope.”

She started taking small steps to understand the basics: a Microsoft SQL Server certification and a small diploma for Algorithms in C.

But how could she do it coming from such a different background? I wondered if she was good at math in school or if her head exploded while learning how to code. “Math wasn’t bad, but not my strongest suit for sure. The point was learning algorithms — the whole foundation of coding — the available course was in C. But yes, I struggled a lot. Thankfully a shiny light appeared: an opportunity to enroll in the Upskill Training Program to learn OutSystems. Low code made it possible for me!”

In December 2020 she enrolled in the Upskill program — the Portuguese government’s new measure to reskill people with non-IT backgrounds. After six months she was an intern at OutSystems. In 12 months, she became a full-time happy employee, working as an Associate Software Developer with Internal Apps. (This team maintains and develops applications for internal use, enhancing quality and user experience.)

“The community is amazing, the learning process, the challenges and I have everyone to thank for it. I can’t wait to keep growing with this environment.” To any person feeling desperate and stuck in any area her advice is: “You’re not alone, some opportunity is just waiting for you to embrace it. There isn’t any shame in not knowing or making choices that put your health as priority. And mostly, dreams can still have a place in your hearts, or become different ones.”

Filipa’s next career moves are: get some OutSystems certifications and strive to understand it better, learn about quality assurance and testing, some Python to broaden horizons and keep her SQL in check. Meanwhile, she keeps making cakes as a hobby and her team is very grateful for it!

Check some of OutSystems’ job openings here.

From Cakes to Code — This Is How My Career Changed was originally published in OutSystems Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

As Albert Einstein said, “Creativity is intelligence having fun.” At OutSystems, we want to stimulate creativity and have a more innovative R&D; that’s why we created the Open Days. A three-day event where our team can try new ideas, be creative, and feel powerful.

“A bookmark is a saved shortcut that directs your browser to a specific webpage,” according to website TechTerms.

Pedro Melo Rosa, Senior Developer at OutSystems, thinks it’d be good to have a bookmark feature in Service Studio. Let’s find out more about it.

Pedro, the Creator

I started as an OutContractor in October 2009, and in January 2021 I became an employee and part of the ART (Agile Release Train) Integration Builder, which is an add-on to the core product. I’d heard about Open Days, months ago, and I wished to take part but I hadn’t found the time. Eventually, with that wish and the company’s growth mindset goals, I could have the best of both worlds. I thought about an idea and applied it.

The Open Days are a great initiative to deep dive into our product, work, learn new things, and leave my comfort zone.

The Inspiration

Before I joined OutSystems I was working with .NET and Visual Studio, the integrated development environment (IDE). Visual Studio has a bookmarks feature. As it happens, sometimes I miss that feature so I thought, why not come up with some?

The Process

On the three days of Open Days, I worked on the idea by myself, although when I was blocking on something I’d talk to Team Lead Nuno Maurício. He always pointed me to the right people.

It’s a Hard Knock… Code Source

Setting up the environment to be able to use Service Studio was hard. There was a little mistake in Confluence’s tutorial, but someone fixed it after. It was also my first time working with our core product.

What Does the Bookmark Idea Consist Of?

In Service Studio you can open several modules at the same time. Each module has screens and server actions (where the code is at). When we’re working we open one server action here and there, we need to go to a screen and then be back to the first action — we need to jump around to see what to do. What happens is that sometimes we think, “I want to go back to that code that did that action and now I don’t remember where it was.”

With a bookmark, you can simply put several labels on specific points of the code, or in the diagrams, have a list of bookmarks, and directly jump to those points of interest.

Everyone who uses Service Studio would benefit from the feature. This is not related to code; the goal is to help developers navigate in Service Studio.

The problem I want to solve with this feature is speed of execution. Sometimes you can have a big project with a huge list of actions and it can be difficult to go from one point to another.

Of course, there’ll be more options in the context menu, two or three buttons in the toolbar but that’s it. No big cons.

After All, What Was in It For Me?

I believe that when ideas show up and when they are converted into reality the motivation to pursue more ideas increases. But I look at creativity as something intrinsic in people.

It was great to participate in the Open Days and to hear that people found my idea useful.

I dove into Service Studio code and learned new terminology. I became familiar with concepts I was hearing in other teams but were only abstract to me.

Now, your turn, what do you think about Pedro Melo Rosa’s idea? Share your thoughts with us.

Creative Ideas: Bookmarks in Service Studio was originally published in OutSystems Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

With the OutSystems Developer Conference (OSDC) 2021 starting today, some members of the R&D and Community Teams face a common challenge in every engineer’s life: public speaking. Whether you’re showcasing a demo, presenting new work to your team, or taking part in a public engagement, the perils of public speaking are there to haunt you.

But don’t freak out about that slide deck (or Powerpoint presentation if you’re old school) just yet. As every seasoned public speaker will tell you, this skill is a muscle. You need to flex it, much like programming.

Since practice makes perfect, we gathered experienced speakers within the OutSystems team — from communication experts to engineers and developer advocates — and asked them for tips on making public speaking (whether virtually or face to face, live or recorded) less scary than death.

The 30 plus answers were as diverse as our team, from motivational (Breathe, you’re the best!) to technical (Do you call that a proper mic?) and everything in between. We hope you learn from them and nail your next slide deck.

Flexing That Public Speaking Muscle

Often depicted as geeky, introverted nerds, some developers surprise people with excellent communication abilities when it comes to their work. It actually shouldn’t be that surprising, as engineers, as part of their everyday jobs, are constantly asked to speak up and share their knowledge, be it in the shape of tech talks, team presentations, or outreach events.

Melissa Perdue, a Senior Communications Manager at OutSystems, is part of a team of tech evangelists who supports the R&D Team in their communication endeavors, from social media to blog posts and internal and external talks. Besides international conferences, one of the initiatives where she helps devs flex that public speaking muscle is BridgeTalks, a series of internal presentations about any software development topic from one (or more) member(s) of the R&D Team to the others.

In her words, “the goal is to bridge the gap between groups in R&D, removing any silos. They aim to educate, provide training, and request help from other teams.” They are “informal and generate valuable conversations across teams,” she says. From polishing up the engineers’ message to reviewing slides, managing deadlines, and running through presentations numerous times in dry-runs, Melissa says she worries about the moving parts so that experts — that’s you, dev — can focus on the message.

Tips From the Specialist Communicator

In fact, according to communication specialists, one good way to perfect your public speaking chops is to stop thinking about yourself and more about others. In sum, think more about the content and less about the speaking.

The OutSystems expert takes it a step further by adding a little twist: boosting your confidence first will allow you to start thinking about your audience. “Everyone is here to listen to your expertise and what you’re saying. Be confident in that. Your audience doesn’t want to read your slides. Slides are visuals to highlight parts of your speech, so use them as aids and less as the whole presentation,” explains Melissa.

Now that you’re confident that people show up to hear you talk and you’ve pushed those jitters away, what do you have to say to your audience? It’s time to start thinking about them. How? Here are Melissa’s tips for great presentations, whether they’re virtual or in-person:

1. Start at the end. Meaning, think about the conclusion of your presentation first. What is the idea behind your presentation? Why would your audience care? What do you want them to learn or take away from listening to you? Then move to the opening and how you’re going to pull them into your idea. That will create a through-line for your audience, so they know from the start what you’re giving them.
2. Good visuals. This is more than slides or images on slides. Visuals can also be physical objects or how you gesture.
3. Less is more. If it’s on your slide and you do not mention it, drop it. Keep it simple.
4. Know your audience. Are they technical or non-technical? Managers? CEOs? Make sure you think about who you’re speaking to.
5. Practice. Practice. Practice. Record and watch it back. It helps to see yourself presenting to know where you might need to practice more, slow down, or remove a slide. It will also help with your time management.

Tips From the R&D Team

After establishing the baseline for an excellent presentation, it’s time to get personal. Public speaking is an individual deal, and every successful speaker has valuable tricks up their sleeve, so we’re sharing a wide range of advice on what works and doesn’t work for our R&D Team.

The first in line is Quality Practice Lead João Proença, who boasts an impressive track record of speaking at international software conferences and events. This year alone, you may have attended his workshop on biases with fellow quality engineer Michael Kutz at The Ministry of Testing. However, if you haven’t, you can still catch his keynote speech today at Agile Testing Days.

João’s advice is an excellent complement to the foundational tips above and a great reminder that your audience needs to come first:

1. Feedback is key! One of the best ways to ensure that you build an awesome presentation is to gather feedback simply. As others have pointed out, practicing is very important, so do some dry-runs with your teammates and allow for 20 minutes in the end to collect feedback on how to improve your presentation. If you’re making a presentation at an external conference, also consider delivering it in a smaller, local meetup, as you’ll be able to collect feedback from people without the contextual bias of working at the same place as you.
2. Slides are there to help you, not the other way around! You are delivering the presentation; the slides are not. Use them as an aid to convey your message. That means you don’t need the slides to be complete, or in other words, to contain all the info you will be talking about.
3. Engage with your audience. Sometimes, you have the opportunity to involve the audience in some of the moments of your session. Such is especially effective at the beginning of a presentation (as you will catch the audience’s attention early on). One example is demonstrating a specific concept with an exercise/question or launching a “short poll” with a quick show of hands.

Stay hydrated

Quality Group Lead Sérgio Amorim has already shared his path from introvert to prolific public speaker and member of the DevOps Lisbon meetups community. Buckle up; his tips for an easy delivery are incredibly detailed:

1. Breathe and hydrate. Breathing is essential to quickly rest and oxygenate the brain, allowing you a moment to think about what you’re going to say next. Use a glass of water to hydrate so that words come out fluidly and to create more breaks. Also, the first time you engage in public speaking, you’ll feel more nervous, and your mouth will dry up quicker. In my opinion, having a water bottle in my hand helps not only because it keeps my hands occupied (which is something that you don’t usually know how to do with them) but also because it reminds me to drink from time to time. The last time I presented in public, I didn’t have water; my mouth got parched, and the words didn’t come out as easily. So drink up!
2. Communicate to be understood. Think about how your audience will interpret the message. Communication is the art of others understanding you; it’s not about dumping information on people for 30 minutes. Do dry-runs with other colleagues or random people. Try to explain your talk to your kids, parents, friends. Would they understand the full story? Or just a part of it? As others have mentioned, you need to understand your audience. Knowing who you’re talking to (or with) allows you to adjust your communication style: can you use jargon freely, or should you explain it in a more detailed way?
3. Use your body language. We don’t communicate just with our voices. Use your hands and body. Display emotion, engagement, and power with the help of your body. That works for both physical and virtual events. Have you ever thought of leaning in on the camera to be closer to your audience? Wouldn’t that create a stronger message? Like: “Hey? Are you listening to me?” And by the way, stay straight, don’t curl your back. That will boost not only your self-confidence but also the audience’s.

You may recognize her from previous OutSystems Developer Conferences — or if you’ve ever run a half-marathon in the Lisbon area. Team Lead Sara Gonçalves is not one to shy away from a challenge, and public speaking is no different. These are her tips:

1. Use an icebreaker at the beginning of the presentation to help people disconnect from what they were doing before. That is a tip I learned during effective meetings training, but I think it can also work here! You can, for example, start by asking the audience a question that will get their attention or add a slide with a funny image to get them talking and which will allow you to make some sort of connection to what you will be presenting next.
2. Don’t end a presentation with “That’s it, thank you!” Choose your final sentence carefully because it will stay on people’s minds and help them connect the dots regarding everything you presented.
3. Use concrete examples and images to help people visualize and follow your chain of thought.
4. Tell a story. You need to think about who your audience is, what their context is, and start the presentation in a way that will make them want to reach its end to find out how it unravels. That is a great piece of advice I got from Miguel Ventura.

Show off your personality

With a Ph.D. in Social and Organizational Psychology and having worked as a postdoctoral researcher at New York University, Tânia Ramos lectured a fair share of academic events. More recently, the Senior UX Researcher at OutSystems also gave a talk on behavioral economics at Interact Global 2021, an international UX and Design conference.

Read her tips for frictionless presentations:

1. Don’t try to say everything in one presentation. Think about the three to five main points you want to convey and organize your narrative around them.
2. Be authentic, show your passion, and let the presentation reflect your personality. The audience can sense when someone is genuinely passionate about what they are talking about!
3. When I’m unsure who the audience is, I plan the presentation to suit people with less knowledge (novices) and experts. Use simple language and concrete examples, but include one or two more complex ideas for experienced people.
4. If you’re nervous, practice, rehearse and try to visualize yourself giving a fantastic presentation.
5. If the presentation lasts longer than 20–30 minutes, promote interaction with the audience (questions, quizzes, exercises, etc.) to keep their attention.
6. Try to anticipate questions for the Q&A and reserve some exciting ideas to share during the discussion part.

Finally, we couldn’t end the R&D advice section of this article without mentioning Team Lead César Afonso, an evil genius who is years ahead of us on this subject — that’s why we hired him in the first place.

Back in 2014 (??!!), César wrote a piece on how to prepare for a presentation and, four years later, he added a sequel on essential presentation skills. And yes, if you picked up on his Seinfeld reference about public speaking being scarier than death — we got that from him too. Always paving the way, this one.

Tips From the Trenches, a.k.a. the Community Team

Speaking to other developers or a general audience can be nerve-wracking, but have you ever tried speaking to your product’s users? If anyone has good advice on bullet-proof presentations, it’s your company’s community team.

So, we reached out to ours. Not to brag, but besides having *the best* community, we have the coolest bunch of people catering to them. If you’re a podcast fan, you probably have come across Sydney Lai, Developer Advocate at OutSystems, and host extraordinaire of the DE/CODED podcast series.

Needless to say, Sydney knows one thing or two about public speaking, whether she’s talking into a mic or not. So, without further ado, here is her advice to up your presentation game:

1. Remember to speak slowly and clearly. This helps with accents or tripping over your words.
2. When presenting:
   a. Tell them what you’re going to talk about.
   b. Talk about it.
   c. In the recap, tell them what you just told them.
3. Do not overcrowd the slides with too many words. (You’ve read this before, but if there is one takeaway from this article, this is it.)

Let’s get technical

Some people know so well what they’re doing that they will ask you questions that had never crossed your busy mind. When we set out to write this article, handing out advice for both physical and virtual events was a priority. But when we asked our teammate G. Andrew Duthie for his tips, he added an extra layer of abstraction: “Live or recorded?” he asked. “Or either/both?”

Sheesh, I wonder who would get into specifics like that?

Or, it turns out, a Developer Advocate. Here are his tips from the trenches for “either/both”:

1. Avoid reading your slides! Think of your slides as either an accompaniment to your talk (for example, graphic or photo-heavy slide decks) or a roadmap for your presentation to help keep you on track. Attendees can read much faster silently than you can out loud, so you will lose their attention if you read your slides.
2. Be aware of the power of silence. This is particularly important for live presentations in front of an audience. If you find that your audience is drifting, or seems distracted, try pausing for a few seconds. It can be really difficult, as we’re all tempted to fill the silence with our voice, but a dramatic pause will have those faces that were buried in phones looking up to wonder what they missed! But even in a virtual talk, a pause will catch the attention.
3. If you’re new to presenting, don’t forget to practice, practice, practice! Practice your demos repeatedly to ensure you won’t hit surprises during the talk. Practice your presentation end-to-end, so you have a clear idea of how much time it will take, but count on the live presentation being at least a bit longer, so you don’t run out of time.
4. When doing virtual presentations, or recording videos, these are the three most important technologies to get right, in order:

a. Audio — make sure you have a quality microphone (USB headset at a minimum. Avoid Bluetooth headsets, to avoid connection issues during a live talk), ideally a large-diaphragm condenser microphone, such as the Blue Yeti or similar. If you will be using it frequently, it’s a good idea to mount it on a boom arm with a spider mount to isolate the mic from noise from typing, etc. Also, double and triple-check that you have the correct mic selected before recording or presenting!

b. Audio — yes, I’m listing it twice; it’s that important. If your audience can’t hear you, none of the rest of the tech matters. Make sure you sound great!

c. Lighting — Regardless of the quality of your camera, more light will help it do its job well. If you are in a room with lots of natural light, make sure that the lighting doesn’t throw weird shadows on your face. For supplemental lighting, an LED work light bounced off a nearby wall can help fill in shadows without looking harsh.Purpose-made key lights such as the panels available from elgato are great for those who do lots of recordings/online presentations.

d. Camera — Lots of options when it comes to presenting or recording online. One thing to avoid, if at all possible, is using a built-in webcam on a laptop. These are usually poor quality, though good lighting can help (see above). A stand-alone high-quality webcam will bump things up considerably. You can also often use a modern cell phone to record good quality video, though if you’re doing that, you’ll want your microphone plugged into the phone, rather than running through your computer, to avoid sync issues later on. Best is a DSLR that supports video streaming to PC via a capture card.

5. Last note, also related to virtual presentations or recordings: be aware of your background. Avoid busy or cluttered backgrounds, and be aware of things you might not want to show. A virtual background can be a workaround, but in many cases, this can look a little odd, especially if you are wearing glasses or a headset, as the results can vary depending on the software used.

Let’s get motivational

Duthie’s amazingly hands-on, technical advice could only be offset by some motivational tips from our Senior Developer Marketing Manager. Known for spreading the word about developers and how great they are, public speaking is no match for Ricardo Miguel Silva.

Here are his top three tips:

According to Ricardo, “the best part of public speaking is learning how to feel the audience.” That is also a skill you will develop over time, he believes, especially “as your vision and focus can be funneled by the uncertainty of your first public speaking experiences.” You will need to push through it — no other way about it.

“But you’ll eventually relax enough to scan the audience. Find those people who are engaged, reel them in. Engagement is infectious, and if someone is having a good time while learning something new, that good energy tends to spread,” says the Senior Developer Marketing Manager.

• 2. Breathe. Be candid. Show emotion. You’re a human being presenting to other human beings. No one expects you to be a speech delivery machine. The certainty of your words is important, sure, but so is showing the emotion behind them. No one should speak to a group of people about a subject they’re not passionate about. If that’s the case, keep it for something you love more. There’s nothing duller or more unengaging than watching someone speak unenthusiastically.
• There is also a bizarre tip that I once saw spreading throughout the interwebs: that to feel a bit more relaxed, one should imagine the audience naked. While that seems strange and might not necessarily relax everyone, I understand the basic psychology behind that. It’s the essential acknowledgment that, deep down, we’re the same: we’re all just flesh and bone. I kid you not when I tell you that I’ve seen people more nervous about attending sessions than those on stage. It’s a two-way street.
  So, everything that makes you human is important, starting with the most basic of all human functions: breathing. Don’t spit out words. Pronounce them. Use your lips, use your tongue, fill your lungs, breathe it out. Use your hands — it’s not just for Italians — it’ll show expressiveness.
• And if you’re nervous, why not just say it? What’s the big deal? Wouldn’t many people from the audience be too if they were in your shoes? Vulnerability can be the best destroyer of walls. And people tend to trust what other like-minded people tell them. Make sure you understand how to use that to your benefit, and you’ll be golden.
• 3. Keep the rhythm of words and sentences in mind as you speak. This goes for speaking as it should go for writing. People generally forget about this, but even if you deliver with passion, you can still sound monotonic even if you put some emotion in it. Make it a bit more musical, then. Get into that groove and mix short, impactful sentences with some longer ones. Improve those dynamics as if it were a song. Just mind that while speaking, you need to make sure your phrases aren’t too long, as both meaning and lungs can (and will) quickly expire. If you’re running out of breath, take a breather. Sure, the message is the most critical part of the whole thing, but sometimes you can turn the most boring subjects into something cool to listen to if you just get into the right mindset.

Now, wouldn’t you give this a standing ovation?

Originally published at https://www.outsystems.com.

Geeks That Speak — 30+ Public Speaking Tips for Developers was originally published in OutSystems Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Co-authors: Bruno Martinho, Gabriel Lundgren, João Ferreira, Mariana Bexiga, Rúben Gonçalves and Tiago M. Pereira

Low code platforms, like OutSystems, greatly contribute to the democratization of app creation to solve real-world problems, and components are essential for this. Besides the obvious code reusability, they enable developers to build software faster without reinventing the wheel while (idyllically) simplifying the usage of said code or library.

Frameworks and libraries provide reliable and reusable code, allowing the developer to focus on app functionality. This is why good frameworks accelerate the development process, and the best ones are easy to use.

In this article, we’ll explain how a good component framework can save brain cells and make life easier. We’ll also get into the very first aspects you need to consider when building a framework — tools and technologies. And to illustrate just that, we will tell you a story based on a real-life problem.

But, before we dive in, know that this is the first on a series of posts on how to build a fantastic* framework. If you want to learn more on how you can divide and organize work, create a diagram that works as a decision matrix to help you build new components and improve the developer experience, among many other things, follow us on Twitter and we’ll keep you posted on upcoming articles.

*From dev to dev: sorry, but our editing team made us use this adjective for SERP (Search Engine Results Page) purposes…

Note from the editing team: The word grew on them, and look how high they’re flying now on your results page *wink*.

Who Are We, Anyway, and Why Are We Building a Component Framework?

Alright, let’s start with a little context.

Formed in February 2020, the Data Visualization Team was born out of the need to stabilize one of the OutSystems components, the Data Grid Web, and support its users. Data Grid Web allows developers using the OutSystems platform to build complex, scalable, and data-rich interfaces for apps. As a result, application users can securely view, explore, and edit large amounts of data in an Excel-style user interface.

Starting a Framework? Pick Your Tools

A wise man once said — actually, it was our Team Lead, Bruno Martinho — that pain leads to change. We were about to experience that first-hand.

As we rolled up our sleeves and began toiling away, we struggled — the effort required to maintain the existing code was excruciating (let’s not even mention adding new features).

Why? Due to the traditional way these components had been developed (there were a lot of difficult circumstances and constraints), altering them required wizard’s hands, black magic, and above all, plenty of time.

There was virtually no automation. Processes were primarily manual and error-prone. Imagine, just imagine, several people bug fixing and working on features in copies of a multi-thousand line JavaScript file — kept in OML — and then going for a manual merge, which of course, was done in Notepad++. The result was what one would expect, with multiple defects caused by merge mistakes, code losses, and worst of all: a lack of trust and confidence from customers.

As we are lazy (and strong contenders*), we decided to change things, starting with the obvious — tools — and forbidding ourselves from ever doing something similar, or else we’d be bound for some harsh physical punishment**.

* Yes, yes, we did notice the apparent contradiction.
** No developer was physically harmed.

Things turned out well, so after we stabilized the Data Grid Web component, we applied the lessons learned to its runtime Reactive counterpart, which we built from scratch. Then, as our team grew, we consolidated our framework while redesigning two other reactive components — OutSystems Charts and OutSystems Maps.

When you’re building a new framework, the first thing you need to do is pick the appropriate tools and technologies. So that is where our story will really begin. Here’s what we learned.

Good Old Git

Most of the issues we told you about began right when we started tackling our web component and can be summarized by the old pasting code motto.

We have, however, a new mantra for you. Repeat after us:

• Copying and pasting JavaScript code is bad.
• Manually merging JavaScript code is horrible.
• Maintaining JavaScript in an OutSystems module is worthy of punishment.

Yet, as you now know, that was the problem we faced.

To make the process more agile and our lives easier, we needed the right tools. And sometimes, the easiest solution is right in front of you. So, the first thing we did was move our JavaScript code to GitHub, which instantly solved many of the issues we had. Faster merges? Check. Code traceability? Check. Code reviews? Check.

Performing code reviews was nearly impossible before as we had no means to compare what had been added to the code and were, therefore, unable to track changes properly. Git got that out of the way. Bang.

Our spirits were lifted, but we weren’t completely satisfied, so we turned our heads to our next big pain. To deliver a feature, you need to have a sandbox, so that you can fix, test, and generally mess around with your code without standing in the way of other developers (or the other way around).

We needed the ability to create a new application that contained a replica or clone of those modules but there’s no magic button for that…

Or so we thought. The plot thickens.

Saved by the API

Meanwhile, some of our colleagues encouraged us to use TypeScript, so we decided to convert our JavaScript code base into TypeScript. We thought it would be a much more complex move, but we benefited simply by changing the extension from js to ts — and starting to use Visual Code. With these changes alone, we could unleash TypeScript’s potential, our code could be compiled, and we could start catching mistakes even before they’d get to the browser.

With Git and TypeScript, merges were now mostly automatic, meaning that two engineers didn’t have to waste a whole eight-hour day copying and pasting code — and then validating the copying and pasting — every time we did a release.

But, for a team who likes to be as efficient as possible and save time on tedious tasks to focus on what we really enjoy doing, it still wasn’t good enough. Setting up a sandbox took about an hour because the process involved cloning three or four different modules and then changing all the references to the right modules.

There was indeed no magic button, but instead, two magical, underdeveloped, experimental, and fantastic APIs.

And you know the saying, “Give a developer an API, and they’ll create a whole application around it” or something like that. We got not one, but two APIs! JUST PICTURE our happiness!

Using these #blessed APIs (our codename for them, as we are not authorized to reveal their names), we created a new app that allowed us to clone entire applications, change the references to the cloned modules, and publish them to our environment.

But, much better than that, we designed it with the concept of “templates.” What exactly is this? A “template” is a virtual app that features all the modules (which actually belong to different apps) that a developer needs in its sandbox to build a new feature or fix an issue (in our case, we needed the DataGridWeb, DataGridSampleWeb, DataGridExample, DataGridTestsWeb modules).

The result? Our one-hour-long step to set up the sandbox, now became a five-minute step, including the login time on our app and on Git to create the branch.

All Hail Pipelines

With things finally on the fast track, we took another step towards automation. We didn’t want to compile the TypeScript code in our machines only to realize that other devices would compile the same code differently, thus generating problems we wouldn’t pick up on easily.

So, using Azure DevOps, we created a new pipeline that would compile our TypeScript code after each pull request, so that the final code was available to download and insert in the module. That ensured that the released code was always compiled under the same conditions.

However, we still had to open the DataGridWeb module, add the latest version of previously compiled code, and of course, open and update the consumer modules. Not good enough for our books.

How did we skip this step? By now, you already know the answer… Using the #blessed APIs, we created yet another app. This application begins working its magic when Azure finishes compiling the code.

We summarized its inner workings in this very plausible monologue: “OK, the code is compiled. This is the JavaScript code, this is the CSS code; now where shall I put it? Oh, I must send it to this environment, so I will open this module, place the JavaScript and CSS code folders inside, publish the module and, obviously, also publish all the other modules that use the same code.”

“Holy cow!” you might say (as we did back then). This means that when a pull request is accepted, the TypeScript code is compiled to JavaScript, which is then sent to our environment, inserted in the correct module, published, and the consumer modules refreshed. Hypothetically, every time a pull request is accepted following the code reviews, our components are ready to be uploaded to the Forge by the time the app completes its job. Who needs magical buttons, when you can create buttonless magic?

Once two people accept the pull request, the code will be merged, and the magic we described kicks in — we are now down to a 10-minute process.

What About Testing?

While shortening the whole process was a much anticipated happy ending to this story, using the right tools and technologies has brought us other benefits from an engineering perspective. Testing is one of them.

Thanks to our Azure setup, we now have a whole new pipeline of automated tests (using a framework that our R&D Team built, but that is another story). Every time there’s a pull request, the tool will run hundreds of automated tests (462 x 4 browsers, to be precise) in the respective sandbox of the issue to validate the changes’ impact. That is particularly useful for those carrying out the code review, as they will immediately find out if the changes cause collateral impact or not.

In order for the pipeline to be able to execute the tests, we created a naming convention for the sandboxes and the branches in Git (e.g. RGRIDT-0000 — yup, JIRA issue number! :D). So, every time there’s a pull request, the pipeline knows what to do: it knows which environment it must access and will then find the sandbox with that specific name, and run the automated test list. It doesn’t get any greener than this.

If at this point you’re wondering why we’re so obsessed with automation, it’s easy to explain. When you’re a developer programming on your own, you probably won’t face these challenges. You’re in charge of all your code, and you perform one task at a time. However, if you have three or more developers working simultaneously on the same component, it’s easy to understand how things can go wrong.

You change the code. You run the tests. You get the all-green go-ahead. As simple as that, and everyone is happy.

The End (at Least for Now)

The main takeaway from our story — and which only gained momentum since we first tackled this project — is that building components should be done with the mindset of building a framework.

And for that, you will need to choose the right technologies and the right tools. While it may be tempting, don’t just stick to what you know, because when the only tool in your toolbox is a hammer, everything looks like nails. Remember that this is only your first step, as you’ll need to look into many more things to build your framework.

As we mentioned, we will address them in other articles, but you can also catch up with our team member, Rúben Gonçalves, in his talk “Building Frameworks: From Concept to Completion” at the OutSystems Developer Conference 2021, on November 18 at 12.15 p.m. (EMEA). He’ll be there to answer your questions and dive into the complexities of building frameworks.

For now, if this looks like a lot of work, know that it is. But…

Originally published at https://www.outsystems.com.

Fantastic* Frameworks and How to Build Them: Tools and Technologies was originally published in OutSystems Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this series of interviews, we talk to an OutSystemer from the engineering team about their role, interests, and expertise.

Sandra Rodrigues was born and raised in the north of Portugal and lives in Braga now. She graduated in mathematics and computer science — a choice she made upon her love for math. Sandra is a true engineering role model. Let’s find out more about her journey at OutSystems Engineering.

Why did you choose an engineering career?

I’ve always liked mathematics and chemical physics and making things happen. To do something small and prove it, like do an exercise and get to a result. I didn’t like to study language and history disciplines, with all the dates to memorize. By 10th grade, I didn’t have a computer at home, but the first Information Technology (IT) disciplines were appearing and I thought, why not if it has a lot of math thinking behind it? That was my first contact with the programming language Pascal. I really loved thinking about algorithms and the logic behind a program that’d do something with half a dozen letters. In the 1990s, I already was a huge believer in automation. Eventually, I chose Informatics with natural and neurologic systems in my second cycle degree.

Why did you shift from software development to quality engineer?

I’ve always liked to dive into details and to know how things work. When I was a software developer I liked to try and break down the program to make sure the final customer didn’t complain about quality. In 2008, I changed to quality because Microsoft bought the company I was working for (MobiComp) and I heard for the first time about quality roles. Up until then I was a fullstack developer, doing documentation about customer pre-requirements, development, installation, product releases and support. Software engineers’ specialized roles didn’t exist. I think that a multitasking background helps in my professional path and in the quality role’s principals.

Quality is a set of practices (mainly manual and automatic) that should start as early as possible in the software development lifecycle and make sure the product is at its best when it reaches the customer. And the final customer — internal or external — it’s our main goal and my main focus in the quality role.

To transition to a quality role I think you need to be curious about why things break, why the customer wants things in a specific way, or what’s the use case or journey in mind. Sometimes, our customers are the product owner and product manager informing us through requirements of the product, features, etc. Other times scenarios can be very abstract. As a quality member, I need to face the scenarios assertively, without subjective interpretations. That way all the process lifecycle — development, testing, releases, support — is clear to every team member.

How was joining the OutSystems Engineering team?

I didn’t know the company and one colleague from Braga’s office, a university buddy, told me about the company’s quality openings. First, I had a smooth interview with Eduardo Andrade, People Success Manager. OutSystems was shifting to focus on product quality. It looked like just what I wanted: a less technical role with a chance to start guiding people. (Enabling teams to be fully accountable and autonomous in owning product quality.) The second interview was an informal conversation with the quality engineer manager in Braga. All the questions were about technologies, product, product quality, and how’d I face challenges.

Describe the roles you have worked on since joining OutSystems in 2017.

I joined as a senior quality owner and my job was to help two Braga-based teams spot quality challenges, improve processes, research for quality product frameworks, releases, bug reporting, and listen to customer’s feedback. We identified quality priorities, made changes in manual process validations (adding exploratory and user acceptance testing to the development process), and added more test automation (increasing the coverage of unit tests, integration tests and end-to-end tests). One of our goals was a smooth journey when picking up parts from all teams to assemble the OutSystems product. Of course, bugs will always exist but we’re making new validations sooner to avoid critical things when the customer starts using it.

OutSystems Quality members suggest new tools for specific needs, so the teams are able to define a Quality Operating Model that allows them to autonomously make 90% of the quality decisions and to create quality built-in assets.

The instruments we use for the model are diverse: help the teams to set a Product Quality Goal that answers to what is quality to them and their products, and how they can measure it to achieve that goal; Maintenance guidelines — for example assess the priority of issues backlog; Risk Assessments, to help anticipate and mitigate risks; Quality Radar, a set of quality related practices, tools and techniques to reflect on their behaviours and practices, providing guidance on possible next steps in their quality journey.

Since quality is context driven, testing is context dependent. This means use different approaches, methodologies, techniques and types of testing (unit, integration, component, service, contract, exploratory, performance, security), depending upon the application type. Quality at OutSystems is a huge field with different challenges and goals.

Because of my enthusiasm for quality, in 2019 I was invited to a Lead position. I continued to work as an individual contributor (quality engineer) with a few teams but added the mentoring part. As a quality mentor my goals are: sharing guidelines, new practices and frameworks, such as finding industry knowledge and helping teams implement these theories into practical terms — not only with quality members but outside teams that need a push to reach minimum quality standards. We’re not as many in quality yet that’s why we’re hiring.

What do you like most about working at OutSystems?

The culture is great. There are no issues with being a rookie and make stupid questions because everyone, at all company levels, is available to explain stuff to you.

At the Braga office we have so much fun, it’s like a family. We used to celebrate Halloween and Carnival with a mask contest.

OutSystems might be a visual development platform but the challenges behind the product are huge. We know that software engineers that use our product like to code and sometimes they think with OutSystems they’ll not have code, architecture, or solution challenges. That’s not true.

Don’t look at OutSystems as drag-and-drop dots that do stuff — behind the visuals is a gigantic software world that requires a lot of work and follows the software engineering principles: design, develop, maintain, test, and evaluate the product delivered.

What excites you most about working on quality engineering?

I’m happy when the area I’m most involved in reaches its goals and when my team doesn’t need to deal with a lot of customers’ complaints, even when those customers are internal. That means the product doesn’t have serious bugs.

Two years ago I switched to the mobile team, which is very important for the final customers that need to create a mobile app. For example, we have challenges every year when Apple or Google launch new operating systems because the team is dealing with the unknown. So it’s very rewarding when teams can put up an automatic framework validation, creating a set of tests that run in real devices. It all started with a proof of concept and today we have more than 500 automated tests running in the cloud in different iPhones and Androids supported by OutSystems. This is a huge step to identify problems that run in mobile apps. Our goal is always to anticipate and correct issues before production. However, that’s nothing compared to our entire product that has thousands of quality tests. The OutSystems product is huge; we start testing the smallest components individually and move to collective tests.

We have a lot of investment in test automation because we want to be quicker and quicker in minimum validation before delivery.

The other parts of the job are: to monitor product and customer product interactions, collect feedback, find issues through that monitoring before the customer finds them, react and if needed send a new version.

What’s your advice for aspiring engineers?

I always say if you want to join a quality engineering team you don’t need to be an expert, you need to be eager to learn, to explore product features, and face challenges. Having a software development background is good; it’s not mandatory to know JavaScript or .NET, you can learn languages. For example, someone with test experience, who has done manual product validation, we need these types of people to evolve and teach how you can validate a product manually like if it was a customer. There’s no recipe to be a quality engineer, if there’s a will everything is possible.

What do you like to do in your free time?

I love knitting and crochet, it’s something that makes me feel very good mentally.

I like to read romance, science, and detective fiction and to be with my family. I have a 14 year old daughter and a nine year old son. My daughter is very good at math like her mother. I think intelligence can be inherited but you need to work hard and be driven to succeed. That’s what I tell my children.

Interested in a quality engineering career? Explore our open roles.

OutSystems Engineering has a lot of interesting things to say! Be part of our conversation on Twitter or Facebook.

Inside OutSystems Engineering —  Sandra Rodrigues, Quality Practice Lead was originally published in OutSystems Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hi! I’m Dan and I’m in charge of OutSystems’ Romania Delivery Center. Let me tell you a little about my career journey.

I started writing code in high school. I wrote my very first program in 1992. I remember I was writing in BASIC, there was a game called Green Beret and we were trying to change it. I went to college in Romania, studying Computer Science, but then I immigrated to the US in 1996 and I had to start all over again because nobody recognized a Romanian degree.

In 2001 I decided to move from New York to California because I had a job promised. That was a mistake! I was driving from New York to California and I got a phone call.

“Hey, we got some good news, we were acquired by Oracle, but the bad news is that we’ve frozen all the opening positions,” said the recruiter.
“Wait a second, what does that mean?” I asked.
“Well, that means you don’t have a job.” answered the recruiter.

I was in Utah when that happened, but I continued all the way to California.

I had to start everything from the ground up, again. I found a job in a big civil engineering company, doing Visual Basic development for cranes that were controlled by GPS. At the time it was a really big deal. I stayed with Graniterock for sixteen years.

It was there that I met Patrick Jean, who became OutSystems’ CTO.

OutSystems has been doing expansion for the past year and half, and I reconnected with him to create the Romania Delivery Center.

This particular job I’m in is different from your typical engineering director; it’s a lot of recruiting. I’m spending most of my time sourcing, trying to figure out how to get the development center up and running, trying to understand exactly the skillset I’m looking for to build the teams.

Building the Finest Delivery Team

We’ve just finished building a delivery team of six engineers: a product owner, a team lead, a lead senior engineer, a mid-level developer, a junior developer, and a quality engineer. Now the thinking is just do it again and build another one.

After building the second delivery team, we’re going to do some out-of-ART features for O11 and the IDE group. The hiring managers will see there’s a fully functional development team from Romania that they can request to work on their efforts.

So far, we’re offering remote positions because we don’t know where we’ll end up with the biggest presence. It might be in Constanta, or in the capital, Bucharest.

The Struggles

It’s very difficult to find technical people in Romania because it’s a market dominated by other firms — Oracle, Amazon, IBM, Microsoft. OutSystems is already considered a big firm, however Romania’s big talent still associates quality and future to those firms, not with us, so we’re competing for visibility within the market. It will take time but we’ll get there.

Another challenge we have while recruiting in Romania is that engineers come in different flavors and some flavors you don't find unless you go compete head-to-head with the big firms. So internally we’d say, “Okay we’ll focus our needs in Romania looking for C# and SQL knowledge,” but the bigger firms are holding people’s attention.

OutSystems is here to stay, and that typically comes with creating a unique culture, but we need to bring a Romanian flavor in to it. Romanians need to feel the company is here to do business with and for them.

Romania is the fourth largest market in Europe by volume. Its capacity is twice as big as Portugal. In Eastern Europe, only Poland is bigger than Romania. From a skillset perspective, it is extremely diverse because we have built big delivery centers for the main technology companies in the world. The country has 8,000 graduates a year, so the talent pool is solid.

I do enjoy building teams, even if sometimes it’s really hard. The most rewarding thing is dealing with people, talking to them in general and helping them. This will be the third delivery center that I’ve undertaken to build — one for the construction firm, my own outsourcing company, and now with OutSystems Engineering.

What Can Engineers in Romania Expect From OutSystems?

Romania is an exporter of software. The majority of people employed work as outsourcers, so they never get to choose their own projects. If you work for OutSystems, you work for a product-based company, so instead of being just a muscle for hire, where a client will dictate what you’re doing, you become an investment. OutSystems will invest in you because our purpose is to retain you, grow you, and make an OutSystemer out of you.

The company invests in you as a person, in your career, not because you’re making a client happy. There’s no competition between what OutSystems offers, and what the others do.

Check out our Engineering openings in Romania here. For more thoughts and musings from the OutSystems Engineering team, follow us on Twitter.

Seeking Technical Talent in Romania was originally published in OutSystems Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Sudhakaran Nair was the first VP of Engineering to be hired outside OutSystems. Looking at his CV, it’s not hard to understand why. His wide range of experience impressed the OutSystems Chief Technical Officer (CTO), Patrick Jean (PJ), from their very first conversation: “He has grown teams and companies rapidly. But most impressive was his curiosity, obvious passion for what he does, and frank discussion about his past failures and what he’s learned from them,” said PJ.

“This is so relevant to us at OutSystems, our learning culture with a growth mindset and the drive to change the world through easily accessible software development. I’m looking forward to the experience and drive he brings to R&D,” he added.

With 25 years of experience in the tech industry, Sudhakaran has, in fact, built up several startups, growing their teams, improving their product, and putting them on the map until larger companies can’t help but notice them. However, his core lessons come from Apple, where he learned to simplify software development, to the delight of users.

At OutSystems, his focus from day one is on hiring a great team. And while he admits he is still learning every day about low code, this avid bike rider and occasional drum player is definitely into the OutSystems beat.

Tell us more about your experience and background. How did you end up at OutSystems? We heard that you actually reached out to us!

I’ve been in the industry for 25 years now. I started my career at Apple and then worked in four startups, two of which I founded. In all of these, I built up small teams and grew to hundreds of engineers. Three of my startups were acquired by big corporations.

That’s how my career has been: building engineering teams and delivering products, taking it from concept to an enterprise-class product that can be repeated and used by the customers quickly.

“I was really excited when I began learning more about the company, looking into its website, and reading articles. The low code domain, especially now, is very exciting”

In the past 18 years, I’ve been in areas such as distributed systems, databases, real-time platforms, and cloud technologies. I started as an engineer but in the past eight years, I haven’t been doing much coding, although I get involved in architecture and strategy.

Now, how did I reach out to OutSystems? I first saw OutSystems on LinkedIn. My recent company, Dashbase, got acquired by Cisco, and I decided to leave as Cisco is a huge enterprise, and my passion is to work for a company where things move quickly, much like a startup. I started looking out to see what was out there and found OutSystems.

I was really excited when I began learning more about the company, looking into its website, and reading articles. The low code domain, especially now, is very exciting. Because of the pandemic, every company is trying to move to digital or undergoing a digital transformation. I felt it was a very interesting domain.

I don’t have much experience with low code, but I am extremely interested in that domain.

Being your first time in a low code company, what is your vision?

That’s the first thing that caught my attention — low code. I know a lot of companies and have a lot of experience with startups. Getting something up and running is very hard. Even for technology folks, you need to have a team of people.

To do good full-stack application development is very hard, especially if the companies don’t have many engineers and have to hire a team of engineers. That’s always an entry barrier for many of these companies, and that’s what instantly caught my attention: the opportunity of how time can be reduced for these companies.

You’ve been the VP of so many companies. From what you’ve learned so far, what is the number one experience you’re bringing to the table?

I can quickly build a team, hire the right way, and add good folks from my network. Secondly, I have a lot of experience with cloud technologies — like Amazon, Azure, and Google Cloud — and many distribution system technologies, like various databases, such as Elasticsearch, Cassandra, Hadoop, Spark, Kafka.

I have a lot of big data experience that I can bring to the team, distributed systems knowledge, and I’ve also delivered enterprise-class products many times. That delivery knowledge, I think it’s very valuable. I’m a customer-obsessed person, and in all the companies I worked in, the teams also became customer-obsessed. I always develop everything based on customer needs — this experience will be invaluable at OutSystems.

“Typically, I adapt to the company culture and try to learn the product. That’s my first task. Then, I identify the gaps, the weaknesses and try to fill the gaps. That’s how I get up to speed”

You probably get asked this a lot, but you mentioned that you’ve worked for Apple — did you meet Steve Jobs? And how was working at Apple at that time?

I worked for Apple right at the beginning, it was my first job. This was at an early stage, so before the iPhone, right? But it was very exciting because I was working on the first object-rendered software development project. They were trying to develop an object-rendered operating system, which is actually how the Java language was born — it started from that concept. So it was very exciting to be there.

The culture was very good, although Steve Jobs had left by that time. But he left his user-centric approach, it was all about the usability of the product. And they tend to simplify things at every level, right? I got very good training in all those areas. When you build software, you simplify it so that the users can use it easily — those concepts I learned from Apple. And they had great engineers at the time, passionate engineers, people who worked at Apple because of their passion.

When you step into a new company, what is your strategy for building a team?

I joined at a very early stage in other companies, so it was easier to build a culture and strategy. You don’t have a lot of legacy or existing history. And also, the product is not so mature; at OutSystems, the product is mature. I have a lot more learning to do.

Typically, I adapt to the company culture and try to learn the product. That’s my first task. Then, I identify the gaps, the weaknesses and try to fill the gaps. That’s how I get up to speed. And of course, I get to know the team and be helpful as early as possible.

What do you enjoy doing in your spare time?

I bike regularly and hike whenever I can. I play drums, not so well, but I keep playing them once in a while.

VP Snapshot

Originally published at https://www.outsystems.com.

When Building Up Teams Is Your Favorite Job — Meet the VP, Sudhakaran Nair was originally published in OutSystems Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.