Badges
Certifications
Work Experience
Software Engineer
BairesDev• January 2022 - Present
BairesDev is an IT nearshore outsourcing company that focuses on recruiting the top 1% talent in Latin America and allocates them in the US and around the world with close time zone alignment. Manages over 5,000 engineers in around 35 countries, in start-ups, middle-market businesses and above 10% of Fortune 500 companies, like Google, Rolls-Royce, Johnson & Johnson, Pinterest, ViacomCBS, among around 270 clients. I’m currently outsourced to one of their clients. Respecting confidentiality agreement, I can only describe a few characteristics. It’s a US based public company with over 3000 employees. Its core business is managing venture capital investments in roughly 15 digital platforms with global reach. The platform I work in has approximately 10 teams. Most of them are verticals. However, I’m part of a horizontal team. Each team holds between 15 and 20 professionals, which includes: creative directors, designers, product and project managers, engineering directors or manages and software engineers working in a mature, fast-paced, heavy workload, agile environment. I’m allocated as a full stack software engineer in a squad of 5 multidisciplined engineers. Our team is responsible for: - building out cross-vertical components; - developing unique web pages within our platform; - debugging occasional failures; - creating design guidelines and design systems to enable other teams to work with; - occasional backend solutions in tandem with the team that handles the architecture scope, quality control and standardization of the platform. The platform focuses on quality content publishing in a specific niche. Gets over 30,000 hits a day, so it consists of multiple CMS to enable editors to build content and web frontend to display it (no app). As for the tech stack we work with, it's pretty broad: - Laravel as the main code base for backend and frontend (PHP 8); - Blade components to optimize design consistency; - Storyblok headless CMS to account for one end of the publishing experience, integrated with Blade components; - WordPress as another CMS publishing experience, integrated with Storyblok and Blade components, along with backend endpoints to serve the content in specific areas in the frontend; - Alpine for JavaScript optimization; - Tailwind based proprietary CSS class library with SuiteCSS standard; - Vanilla JavaScript for specific cases; - LaunchDarkly for feature flags management, especially handy for development of non-production features; - Fastly CDN / Cache; - Nova for data storage; - React for special packages / components, integrated with the website; - AWS for the infra-structure; - CircleCI for CICD pipeline; - Automated deploy testing with jest, PHPUnit and Cypress; - Dev environment running on Laravel Valet, Terminus, Docker, NVM; Some types of work I led or actively participated directly in: - Laravel / Blade / Storyblok component development: The goal was to adopt Storyblok as the most used CMS in our stack, as we can build components that are user-friendly and, at the same time, allows for dynamic and flexible visuals. The design squad would create the detailed mocks for page layouts and the engineering team would organize the concepts into reusable components and develop them in Laravel / Blade with Storyblok integration for content consumption. Layouts would be built almost pixel perfect and with a full responsive behavior. Code review by team members and architectural team, along with UAT review for final adjustments, were part of our process. - Laravel / Blade / Storyblok Templates: We also developed templates to be used as for full page build. With Storyblok, it was possible to define and lockdown how components would look and behave in the page, depending on their optional features. It also gave us the ability to restrict component types that could be incorporated in any part of the template. These efforts required a higher lift, as the responsiveness would sometimes be complex. - Documentation: Besides documenting any new component or templates we developed, we would also write tutorials and general guidelines about processes and component usage to be used as handoffs for vertical teams to adopt their usage and integration with. - One off web pages or campaigns: Sometimes, our team would handle page builds that weren’t specific to any verticals. Normally, we would build and deploy in Storyblok, with existing components. If a component didn’t exist, we would build the component and the page itself. - WordPress ACF: For some features in one of our CMSs, we used ACF (advanced custom fields plug in) to build a better user experience for the editors. Occasionally, we combine ACF with short codes for features that require a higher flexibility on positioning a feature within the content or for multiple instances of it. - WordPress short codes: Periodically, the editors would ask the creative team to extend existing components in Storyblok to be used inside WordPress posts. It required some bridging architecture. - Code base migration: When I arrived in the team, the platform was in the middle of the process of turning down a code base and migrating content and components to a new code base. Our team was one of the main drivers of that effort. Part of the process was organizing work and decision-making to target for the lower impact on the team to handle these tasks. - Calculator builds: One of the main attractions of the platform was calculator built for special situations. Our team handled a few of calculators redesign and development. Most of them were built in React or HTML / Vanilla JS with fully responsive navigation. - SPIKES: From time to time, we would research a new tech to integrate our code base, or research level of effort for higher lift tasks and think out best optimized solutions. Some SPIKES required auditing and documenting. Others, required proof of concepts. - Bug fixing / accessibility compliance: An ultimate goal was to address the website's accessibility issues, so it could result in higher SEO rankings. We used lighthouse auditing along with a tool called AXE to log and track the fixes. - A/B testing: Occasionally, our team would handle A/B testing to increase revenue and engagement. We used Preamp, which was an in house built software that operates fully in the frontend. Our team would create the assets in the software standards and product squad would set up the tests. - Nav Redesign / Rebuild Effort: At one point, leadership started to select developers to lead each project within our team. One of the first projects to roll out this way was the website nav redesign. After the creative team built the layouts/prototypes and ran some user testing combined with polls, they landed in a solution that had multiple levels. The link tree would be dynamically managed by the publishers through our main CMS. Next, we built the components that would make part of the nav. Lastly, we ran a broad UAT in the QA environment before the launch date. For the official launch, we gathered all our engineers to be prompted for any unpredictable behavior. As a rollback plan, I had set up a LaunchDarkly feature flag so that, in case of a major break on revenue pages, we could quickly switch to the “old nav” and figure out the issue in a follow-up action. The launch went better than I expected. We did have some bugs out, but they were minimal and didn't break pages completely. We took about 2 days to get all major issues fixed. By far, the most successful effort I had the opportunity to lead. Not only had the highest visibility, since the nav was present in all the 25,000 pages, but also because of its financial outcome. Through the data tracking, we learned that it resulted in a 20% increase of the total platform’s revenue. Creative team was the main squad responsible for such an unexpected result, as they were thorough with the prototype user testing and polls, going through a few rounds of redesign. The engineering team also held their end on converting such a complex navigation system into a fast and responsive solution, within accessibility standards. - Test coverage plan: When I started working in the company, there was already unit test strategy established. However, the E2E strategy was in its early stages. As soon as my managers prioritized it, I started leading the effort. Cypress was the testing framework hooked up with our stack. We started presenting the approaches for broader team discussion – especially for the backend architecture team. Once the green light was given, I started to build the basic standard for vertical teams to adopt later. As mentioned, our tech stack was a mix of content management systems (WordPress and Storyblok), wired up with Laravel to manage all. The first part of the effort was to divide the types of components into what we called as "testing assets". Then, we determined how each type of asset would be tested. Afterward, I developed the pieces of additional architecture in which the components would be tested on. The main idea was to create bare pages to serve as endpoints and inject each component in each endpoint separately, so the components would be tested isolated – simulating component testing. The main advantage was that we could pinpoint a component failed test which sped up debugging time. The website was built with over 20 page templates. Each template had its own testing cases and, most important of all, would test live high value pages. In order to discover which page within a specific template had the highest value, we built a spreadsheet with all pages separated by template and asked for SEO team to build a report, so we could determine which pages had the highest revenue in their group and used it to determine which "live" pages to test out to guarantee no new code would break high revenue pages. Our GitHub/pull request configuration was built in a way that, for each PR/branch, a “virtual environment” was built on the fly targeted to that branch, replicating almost 100% of our website with a temporary URL, which meant that the tests could run in that virtual environment before merging in new code. There were about 8 types of assets. Besides setting the standard, developing the isolated environment and creating an example test for each asset, I also wrote the documentation, tutorial and guidelines for the verticals. I consider it to be one of the most successful projects I led, since teams did adopt the standards we designed.
Education
UniverCidade (Former Faculdade da Cidade)
Industrial Design, BE• January 1998 - December 2001
Industrial Design – Graphic Design, completed in the second half of 2001.