Our dependencies provide myriad functionality such as frameworks for making network calls, async image loading, testing tools and other existing solutions that solve common Android development challenges. Some of these dependencies are required to leverage core Android libraries while others help solve common software challenges without having to write all the code from scratch. Each dependency allows us to leverage functionality without having to reinvent the wheel.

At the same time, each comes with a responsibility to keep them current to ensure we know of new performance, security, and feature updates. This sounds great on paper, but as any mobile developer knows, manually tracking these updates can be a real burden.

One of our values on Sprout’s engineering team is to act with purpose and focus. In that spirit, we decided to implement a smarter solution so we could spend more time building impactful features for our customers. To accomplish this, we used the automated dependency management first party plugin, Dependabot. Dependabot reduces our volume of outdated dependencies, simplifies the effort needed to update them, and streamlines our overall development process.

Moving away from manual dependency maintenance

In native Android development, dependencies are declared in a build.gradle file. By specifying the dependency we need with its version, Gradle will resolve it from a central repository and retrieve it for us to be able to use within the application. If an Android app is multi-module, each module has its own build.gradle file that declares the dependencies for that module.

Maintaining these dependencies efficiently is critical for a smooth development process and providing customers with an effective social media management application that can keep up with the speed of social. But keeping dependencies up to date becomes a daunting task that requires an assessment of work, version compatibility checks, potential code changes and testing.

Before Dependabot, we had a manual dependency management process. As the complexity of our application increased, so did our time spent on dependency management. It took significant effort for the team to identify the need for a dependency, then process it through our agile development workflows to get it prioritized and up to date. We’d often discover that dependencies needed updates during feature development, which introduced the always dreaded project scope-creep. We needed a better way.

Introducing: Dependabot

Dependency management is not a new concept. Given that most of the work required to manage dependencies is repetitive and monotonous, our team thought this would be the perfect candidate for something that could be automated (without falling into the trap of having to write the automation ourselves).

We found Dependabot suited our needs well—it is a GitHub first-party tool that automatically detects newer versions of dependencies and accounts for any compatibility issues that may be caused by upgrading them. It surfaces any version upgrades as they become available and creates pull requests (PRs) containing information about the upgrade, which we were able to seamlessly integrate into our normal engineering workflow. Suddenly, we didn’t have to spend long hours manually making sure everything was current.

Implementation

Dependabot intelligently analyzes our build.gradle files to determine our dependency tree and creates PRs for any dependencies that need to be updated. In order for the implementation to be a success, we needed a way to carefully review each PR and streamline the merges of the PRs.

During any application release of our Android app, we assign a release manager. We decided to integrate this responsibility into the release manager’s process, with the expectation that up to five dependency upgrades be completed during each release cycle. The release manager reviews the dependency updates uncovered by Dependabot, ensures that our continuous integration tests on the PR pass and there are no breaking library changes, then reviews the upgrades provided by this version bump, and brings the list of PRs to the team for approval to be merged.

The benefits of automation

Automated dependency management is a powerful tool that significantly enhances our development process, and the quality of life of our engineers. It also provides users with high value and the latest features within our native mobile application. With a tool like Dependabot, we streamlined the retrieval, integration and versioning of dependencies, reducing the amount of manual effort engineers have to spend and lowering the chance of conflicts in our dependency tree.

As the complexity of Android projects continues to grow, adopting automated dependency management was a high-value step in order to ensure a world-class development process for our team, and a world-class Android application for our customers.

To learn more about Sprout’s engineering team and culture, visit our careers site.

The post Automating dependency updates with Dependabot appeared first on Sprout Social.

For years, the Sprout engineering team got by with a custom localization solution, since open source solutions were still maturing. It allowed us to accommodate our largest customers in our supported languages, but lacked some useful features. In this article, I will outline our new localization system, how it tackles the most complicated localization scenarios, and how we incrementally introduced those changes across the web engineering organization.

Our old system

To understand our new localization system, you first need to understand how our old system worked and the areas where we could improve it.

Message Syntax

Application localization works by abstracting the text that is visible to the end user into string units, called messages. These messages are extracted and submitted to translators. By abstracting these strings, we can easily swap them out depending on the end user’s preferred language.

These messages can be simple static strings like “Hello, world” or have placeholders like “Hello, {name}” or rich text formatting like “Hello, <bold>world</bold>”. Since these features need to be serialized into strings, you need a syntax that both the translators and the application code understands to properly translate and render the text.

Part of what made our old localization system difficult to use was that we made up our own syntax and maintained a homemade “parser” for said syntax. This code was time consuming to maintain and the syntax was pretty minimal. We wanted additional features to help render more complex messages.

Example: In the Sprout application, we need a way of rendering “You have X posts” where X is a dynamic numeric value.

Consider the plural case, “You have 5 posts”. Consider the singular case, “You have 1 post”. Consider the “0” case. Consider languages that might have a grammar for the “1” case like Chinese and Japanese. Consider languages that have a grammar for the case when X is a “large number” like Arabic, Polish and Russian.

Message management

We have messages that we can send to translators and swap out in our application. Our application needs a way of storing these messages and serving them to our end users.

Our old system stored all our messages in JSON files (we called “lang files”), which were managed manually. We referenced the messages in these files by using IDs in our source javascript code. When a user wanted the application in Spanish, we would serve our Spanish language files, and then the javascript would render the corresponding Spanish message using the ID.

For performance reasons, we tried to only serve the user messages that were on that page, so we had separate lang files for the different pages of the application. This was a valid system, but as our team and application scaled, it meant more manual developer time creating and managing these IDs and lang files.

To add a new message to the application, developers had to manually add them to the correct lang file with a unique ID to reference that message. At times, we would run into issues of ID collisions and ID typos leading to missing lang in the application. Adding text to the web application felt tedious with numerous steps that weren’t intuitive.

Our new solution

Knowing these shortcomings, web engineers from across the Product organization created a localization working group to develop a solution. We met regularly to brainstorm. After an in-depth research process, we decided to migrate the Sprout application from our homemade localization system to use FormatJS’s react-intl library and build infrastructure around it for managing our messages. React-intl was the most feature-rich and popular open source localization library in the javascript ecosystem and integrated well into our codebase.

Message syntax

We wanted a more robust solution and didn’t want to create something from scratch. We adopted the ICU message syntax, a standardized syntax that is used in Java, PHP and C applications, and captures the complexities of dynamic application messages. The react-intl library also supports parsing and rendering ICU message syntax messages.

This is an example of how ICU message syntax captures plural cases. This is the message in English and Russian. Notice how when the translators convert this message into other languages, they can add and remove cases as necessary to properly support the language. The Russian translation of this message adds “few” and “many” cases.

The ICU message syntax has been battle-tested by many applications in countless languages. We could trust that it could support our sophisticated customer needs, and that there were many solutions and/or educational resources for any localization questions we ran into.

Message management

We developed a system using tooling provided by FormatJS that would automate the process of adding, removing and storing messages. This involved some philosophical changes in how we approached message storing and referencing.

A major change from our old system that FormatJS encourages was using our UI code as the source of truth for messages. In our previous system, the source of the messages and the usage of the messages were in two different places, which meant we had to keep them in sync. Our new system keeps the message sources with the rest of the UI code. We simply need to run a script that will extract all the messages from the UI files to generate our lang files, and the message content becomes the unique IDs with the help of a hash function.

This change colocates the messages with the UI code and had several benefits:

• More readable: No more IDs that are designed for robots in our UI code. Now we can read the English messages in the UI code and understand what text the user will see.
• No manual IDs: These IDs which were only used by machines are now generated by machines, and by definition, unique per message.
• No manually managed lang files: Developers should not need to touch these lang files. Our scripts manage the adding and deleting of the messages.

How did we migrate?

But how did we migrate our entire web engineering team and codebase to this new system? We broke this out into four milestones: piloting the new system, educating our team, deprecating the old system and migrating to our new solution.

Piloting the new system

The working group piloted the new system in specific sections of the application to get a sense of its best practices and the full migration scope. This got the new system set up on the client-side (poly-fills, etc.) and the build side of the application. This allowed us to iterate on the developer experience and mitigate risk.

Education

We took what we learned from the pilot and used it to educate the entire web engineering team. We developed an FAQ and other educational documentation and presentations to aid developers using the new library. It’s easy to undervalue this step, but this part of a migration is extremely important. It doesn’t matter how good your new system is—people need to know how and why they should use it.

We also developed an ambassador program where each web feature team at Sprout had an appointed Localization Ambassador, who was responsible for helping educate their team on the new system and reporting issues or pain points to the working group.

This allowed us to delegate the education responsibilities and identify issues specific to individual teams.

Deprecating the old system

After we felt confident in the developer experience, shared knowledge and scale potential of the new system, we deprecated the old system. We created some custom eslint rules and used the linting tool, esplint, to block usage of the old system while allowing existing usages. From this point on, web engineers were expected to use the new system when writing new code.

Migrating to our new system

With confidence in our new system and a fixed number of old usages, we started migrating.

A lot of usages had one-to-one equivalents in the new system. Where these equivalents exist, we were able to automate the migration by writing a code-mod using jscodeshift. We were able to iteratively run the code-mod over sections of the codebase, learning and fixing issues as we went. There were few enough remaining edge cases that could not be easily code-moded that we felt comfortable fixing them manually.

Rollout

Why did we opt for such an iterative approach instead of trying to migrate everything at once? Using an iterative approach is part of Sprout’s Engineering culture, and we believe in constantly learning and improving.

By approaching the migration this way, we were able to learn as we go, adjusting and fixing issues in real time. We could also roll back the changes if the migration started to block application development. Our iterative approach allowed us to make progress while working on other initiatives, and empowered us to feature-flag major changes with a smaller group before rolling it out to everyone. The same principles of feature development for an application apply to the development of internal developer tools.

Learnings and takeaways

Reimagining our localization system was a massive undertaking across the entire web engineering organization. My advice to others facing similar projects or challenges would be to:

• Use widely adopted standards: Why create a custom message syntax when engineers who have spent years thinking on this problem space already developed ICU message syntax?
• Consider collocating related items: It will make adding, changing and deleting them much easier.
• Embrace an iterative rollout: Design the rollout of your change in a way that allows you to learn as you go. You can’t anticipate everything, so build in space for recourse into your plan.
• Share your learnings: Education is half of a rollout. It doesn’t matter how good your new system is if people don’t know how to use it or why it is better.

For more information about Sprout’s Engineering culture, check out our careers page today.

The post Lost in translation: Upleveling Sprout Social’s localization system appeared first on Sprout Social.

Here are some of the highlights of my career so far, and a few important lessons I’ve learned.

My Sprout Social Beginning

I started my career at Sprout in November 2016, focusing on Product Education. Our small but mighty team produced, facilitated and expanded the two-week product training every employee at Sprout experiences as a part of the onboarding process.

Right off the bat, the thoughtful space Sprout created never failed to astound me. Each new cohort of colleagues brought interns, engineers, designers, marketers, salespeople and executives into the same room–one named after computer programming pioneer Grace Hopper.

Rear Admiral Hopper once said, “The most damaging phrase in the language is, ‘we’ve always done it this way.’” Even as I found my footing in that role, Sprout continually showed me that solving hard problems was about finding individuals with different perspectives who wanted to try new approaches. I was one of those individuals, and over the course of the next three years, I trained each new employee on the Sprout product.

Over time, my increased responsibilities led to a curiosity for the project management space, and a position for an Associate Corporate IT Project Manager opened up. I knew professional development was at Sprout’s core when I broached the topic with leadership; not only did they offer support, but I was encouraged to seek other ways to expand my skills and knowledge. It didn’t matter if it meant “losing” a valuable team member to another part of the organization, so long as I continued to grow. At Sprout, you are emboldened to take a non-linear path, not shy away. So I went for it.

Project Management in a Global Pandemic

If you ask people what a project manager does, you’ll find varying answers depending on industry, organization, and department. At Sprout, it’s not only important to build the space for others to learn and grow, but to help define what roles look like and how they best support the business. When I stepped into the role, the world was in the midst of figuring out how to exist in our new reality. What was initially supposed to be two weeks at home turned into more, and suddenly, my reality became learning the ropes of a new job remotely while building relationships with a new team and leading projects to success.

If you told me back then that managing the build of a new office in a city 2000 miles away across multiple internal departments and external vendors was possible, I would’ve laughed. But that’s exactly how we had to execute. I learned a lot working closely with our Workplace Experience team to ensure IT was informed and prepared to equip our new space in Seattle. It was like one big puzzle, and one that involved brainstorming, discussion, sequencing, and collaboration. No one individual could have completed that initiative on their own, and it could have been the moment in time, but the feelings of togetherness and teamwork really shone through and made me proud of what our team accomplished.

The Seattle office build is just one of many projects I’ve been able to manage from the Corporate IT side. Many others sprung up as Sprout kept scaling and requiring solutions that grew with us, including the migration of our Human Resources Information System (HRIS), the removal of physical phones and commitment to digital, our Dublin office build, introducing Sprout’s Employee Stock Purchase Plan (ESPP), plus several iterations of Return to Office, to name a few.

This is what project management currently looks like at Sprout: it’s the ability for one person to gather the right stakeholders to discuss and agree upon a project’s goals, milestones and target timeline. We define what project management is, given our different ways of working, as opposed to forcing rigid structures and tools across teams. While we leverage many best project management practices, we aren’t beholden to them. Once a project plan comes into fruition, it’s about keeping the project team on track, engaged and informed. Project risks are omnipresent and one (or many) things may fail in the process, but out of failure comes growth.

Fail fast, fail forward

In Agile methodology, failing fast is the concept of experimenting while working towards a desired outcome, often gathering feedback and pivoting, or adapting, as needed.

You’d be hard-pressed to find an environment like Sprout that not only embraces this notion, but also encourages the exploration of ideas from everyone. Individual contributors are not only invited to share ideas, but to step up and own the vision and projects they’re most passionate about while determining how to execute on the strategy set forth by senior leadership.

If that ultimately leads down a fail fast path where an idea or project doesn’t pan out as initially hoped, the fail forward learning and development that stems from it is embraced and applied to future ideas and projects. This leads to a deeper culture of transparency and accountability, one where issues or failures are identified more quickly and efficiency in development projects is improved.

Onwards and upwards

I share a few of my experiences and career path at Sprout to demonstrate our team’s mobility, encouragement and accountability as continual strengths. If you have an idea, you’re encouraged to share it. If a process is broken, you’re empowered to fix it or, at the very least, initiate a conversation and assemble a group of individuals to brainstorm solutions and fix it together. If new opportunities spring up within the organization and you feel drawn to the challenge, you’re supported to go after it. Sprout is not only a place where you can be your authentic self, but a place where you can grow both personally and professionally. Where you have the ability to carve out the path that isn’t quite defined yet. Where you can make your mark.

As for what’s next, I plan to continue amassing knowledge, gaining perspective, and building myself and others up to achieve the goals we set. Interestingly enough, it only seems to get better with time.

If you’re interested in joining our growth-oriented team, check out our open positions and apply today.

The post Project management at Sprout Social: Growing always, in all ways appeared first on Sprout Social.

Since we store multiple versions of messages, Sprout engineers are tasked with “recreating the world” several times a day—an essential process that requires iterating through the entire data set to consolidate every part of a social message into one “source of truth.”

For example, keeping track of a single Twitter post’s likes, comments and retweets. Historically, we have relied on self-managed Hadoop clusters to maintain and work through such large amounts of data. Each Hadoop cluster would be responsible for different parts of the Sprout platform—a practice that is relied on across the Sprout engineering team to manage big data projects, at scale.

Keys to Sprout’s big data approach

Our Hadoop ecosystem depended on Apache Hbase, a scalable and distributed NoSQL database. What makes Hbase crucial to our approach on processing big data is its ability to not only do quick range scans over entire datasets, but to also do fast, random, single record lookups.

Hbase also allows us to bulk load data and update random data so we can more easily handle messages arriving out of order or with partial updates, and other challenges that come with social media data. However, self-managed Hadoop clusters burden our Infrastructure engineers with high operational costs, including manually managing disaster recovery, cluster expansion and node management.

To help reduce the amount of time that comes from managing these systems with hundreds of terabytes of data, Sprout’s Infrastructure and Development teams came together to find a better solution than running self-managed Hadoop clusters. Our goals were to:

• Allow Sprout engineers to better build, manage, and operate large data sets
• Minimize the time investment from engineers to manually own and maintain the system
• Cut unnecessary costs of over-provisioning due to cluster expansion
• Provide better disaster recovery methods and reliability

As we evaluated alternatives to our current big data system, we strived to find a solution that easily integrated with our current processing and patterns, and would relieve the operational toil that comes with manually managing a cluster.

Evaluating new data pattern alternatives

One of the solutions our teams considered were data warehouses. Data warehouses act as a centralized store for data analysis and aggregation, but more closely resemble traditional relational databases compared to Hbase. Their data is structured, filtered and has a strict data model (i.e. having a single row for a single object).

For our use case of storing and processing social messages that have many versions of a message living side-by-side, data warehouses had an inefficient model for our needs. We were unable to adapt our existing model effectively to data warehouses, and the performance was much slower than we anticipated. Reformatting our data to adapt to the data warehouse model would require major overhead to rework in the timeline we had.

Another solution we looked into were data lakehouses. Data lakehouses expand data warehouse concepts to allow for less structured data, cheaper storage and an extra layer of security around sensitive data. While data lakehouses offered more than what data warehouses could, they were not as efficient as our current Hbase solution. Through testing our merge record and our insert and deletion processing patterns, we were unable to generate acceptable write latencies for our batch jobs.

Reducing overhead and upkeep with AWS EMR

Given what we learned about data warehousing and lakehouse solutions, we began to look into alternative tools running managed Hbase. While we decided that our current use of Hbase was effective for what we do at Sprout, we asked ourselves: “How can we run Hbase better to lower our operational burden while still maintaining our major usage patterns?”

This is when we began to evaluate Amazon’s Elastic Map Reduce (EMR) managed service for Hbase. Evaluating EMR required assessing its performance in the same way we tested data warehouses and lakehouses, such as testing data ingestion to see if it could meet our performance requirements. We also had to test data storage, high availability and disaster recovery to ensure that EMR suited our needs from an infrastructure/administrative perspective.

EMR’s features improved our current self-managed solution and enabled us to reuse our current patterns for reading, writing and running jobs the same way we did with Hbase. One of EMR’s biggest benefits is the use of the EMR File System (EMRFS), which stores data in S3 rather than on the nodes themselves.

A challenge we found was that EMR had limited high availability options, which restricted us to running multiple main nodes in a single availability zone, or one main node in multiple availability zones. This risk was mitigated by leveraging EMRFS as it provided additional fault tolerance for disaster recovery and the decoupling of data storage from compute functions. By using EMR as our solution for Hbase, we are able to improve our scalability and failure recovery, and minimize the manual intervention needed to maintain the clusters. Ultimately, we decided that EMR was the best fit for our needs.

The migration process was easily tested beforehand and executed to migrate billions of records to the new EMR clusters without any customer downtime. The new clusters showed improved performance and reduced costs by nearly 40%. To read more about how moving to EMR helped reduce infrastructure costs and improve our performance, check out Sprout Social’s case study with AWS.

What we learned

The size and scope of this project gave us, the Infrastructure Database Reliability Engineering team, the opportunity to work cross-functionally with multiple engineering teams. While it was challenging, it proved to be an incredible example of the large scale projects we can tackle at Sprout as a collaborative engineering organization. Through this project, our Infrastructure team gained a deeper understanding of how Sprout’s data is used, stored and processed, and we are more equipped to help troubleshoot future issues. We have created a common knowledge base across multiple teams that can help empower us to build the next generation of customer features.

If you’re interested in what we’re building, join our team and apply for one of our open engineering roles today.

The post Reinventing Sprout Social’s approach to big data appeared first on Sprout Social.

If you ask me the same question today, I would give a slightly different response. Software engineers are tasked with solving the right problems through code—and when solved effectively, they accomplish business goals. Figuring out which problems to solve and how to solve them is the most important part of being a developer, with the actual implementation details being secondary.

My path to software engineering

I became interested in programming after taking a class at Upperline Code the summer before my freshman year of college. I got this opportunity through a college and career readiness program that I was part of called The Opportunity Network.

Upperline Code was my first introduction to programming, and where I quickly realized I was interested in learning to code. Later that summer, I received my Notre Dame enrollment packet and switched from the College of Arts and Letters to the College of Engineering so I could major in Computer Science (CS).

Some of my favorite CS courses were Design/Analysis of Algorithms, Cloud Computing and Programming Challenges. The problems were interesting and the professors were great at presenting new ideas and explaining concepts.

Throughout undergrad, I knew that I wanted to work as a software engineer and use the technical skills that I gained. Thankfully, the summer before my senior year, I had the opportunity to intern as a software engineer at Kantata and pair-program with other engineers to help deliver features.

My internship experience, along with pep talks from my professors, gave me the confidence to not settle for any other role when I first started applying for jobs. After plenty of time spent in office hours, I graduated in 2021 with a CS degree and accepted an offer to be an Associate Software Engineer here at Sprout Social.

Settling into Sprout Social

Part of being new to the role and new to the company was having to develop both general software engineering skills and Sprout-specific domain knowledge. I found that tasks which required general programming knowledge to understand were the easiest for me to solve. However, tasks that required knowledge of Sprout’s architecture took time for me to tackle and I had to rely on my team for help. While there are some problems you can solve by reading documentation online, you can’t always find information that is relevant to the work that you’re doing—being able to ask others for guidance is crucial.

One of the first things that stood out to me when I joined Sprout was how collaborative the development process is. I knew that it took entire teams to develop features, but I didn’t know what that looked like in practice. I quickly realized that releasing a successful feature required many people in different roles working together—from product managers defining project requirements, to designers creating mockups and engineers implementing features. Collaboration wasn’t something that was optional, but a necessity in accomplishing our team’s goals.

Learning how to navigate through the various codebases and building a mental model of how different services interacted with each other was a steep learning curve. Since Sprout’s core business is software, its architecture is heavily shaped by its business requirements. As I was ramping up,  I had to be aware of the business problems developers were trying to solve and why previous architectural decisions were made.

Initially, I was a bit intimidated that pull requests required reviews before they could be merged into the codebase. Understanding that the main purpose of code reviews is knowledge sharing and maintaining code standards helped change my perspective.

Going through code reviews has helped sharpen my technical skills and improve the quality of my pull requests. Having peers give me advice on what to change, introduce me to new patterns, and point me to relevant areas of the codebase has been really helpful. Reading the pull requests of other engineers has also given me valuable visibility into other services that I am not directly working on.

Your previous experiences matter

There is a prevailing idea that as you enter new stages in life, your previous experiences no longer matter. Once you enter college, your high school experiences no longer matter. Once you enter the workforce, your college experiences no longer matter.

But something that is often overlooked is that our experiences, knowledge, and habits have a compounding effect. We usually are only able to achieve new things thanks to the work we’ve done before. The knowledge and skills that I previously gained have greatly influenced how I approach new challenges as an entry-level software engineer.

The classes during undergrad that had the most direct impact on my day-to-day work at Sprout were Programming Challenges and Database Concepts. The former taught me how to break apart large problems into smaller pieces to solve them more efficiently. It helped me become more intentional on how I structured my code and improved the readability of my code.

Database Concepts taught me fundamental relational database concepts and covered topics such as database schema design and SQL. I learned how to write queries, which has been extremely useful since I frequently need to query our databases to solve problems or answer questions.

The opportunities I had outside of the classroom were equally as valuable. Java wasn’t a language that was covered in most of my courses, however I had the opportunity to work on it for a business project that one of my professors was leading. I gained hands-on experience writing Java, working with MySQL databases and creating Docker images. Learning Java was especially helpful since most of Sprout’s services are written in it.

There are a lot of other skills that I gained over my time in undergrad that I take for granted, like navigating the command line and understanding core programming concepts. It’s a common misconception that since most of the topics covered in undergrad are theoretical in nature, they won’t prepare you for software engineering careers. However, I believe the opposite is true—the skills you learn in undergrad matter, even if they aren’t directly applicable to your day-to-day work.

Computer Science is an extremely broad field

CS covers a variety of specializations such as artificial intelligence, machine learning and data science. The experience you gain in undergrad serves as foundational knowledge that can serve you well in a variety of entry-level roles not exclusive to software engineering. Making the jump from undergrad to a full-time position provides an opportunity to explore what kind of role and specialty is the right fit for you.

If you’re looking to start a career in software engineering, Sprout’s a great place to begin.

The post Lessons learned as an entry-level software engineer appeared first on Sprout Social.

Starting my career as a woman in software engineering

How humans interact with and leverage technology has always been an interest of mine–in my adolescence, social media and smartphones began their ascent and suddenly handheld technology was everywhere. By the time I left for college, almost every teenager had a laptop and I knew I wanted to study computer science.

At the University of Michigan, engineering was a fascinating but daunting space. Almost all my peers were male and the halls were dusted with aggressions—from being labeled by a new classmate as “worthless” simply for being a woman, to worse. Asking questions or being honest sometimes felt unsafe, out of a fear of appearing ignorant or stereotypical. Taking each barrier as a challenge, I pushed to excel in my program and defy the negative expectations.

In those four years, I had only two female engineering professors—the most engaging by far, bringing the complex and intimidating specialties of machine learning and artificial intelligence into my world. With their fire as my inspiration, I joined a lab as a human-computer interaction researcher, studying the role of human biases in reinforcement learning agents. I would hold on to that momentum when I joined the workforce, seeking out strong, diverse mentorship and opportunities to grow in fast-moving spaces in all of my roles.

Sprout Social’s engineering culture

When I first heard about Sprout Social, it was a return to my passions—people and social technology. I was thrilled to join the team last summer, with an engineering squad that was nearly half women and an engineering culture that rallied around learning and growth.

In my first weeks, I found the motivation and strength of the team to be evenly matched by its humility. I was encouraged to ask questions publicly and honestly, to admit knowledge gaps without judgment, and to reach out to anyone at any level. Moments that could have been intimidating became genuine learning opportunities and my confidence grew alongside my technical skills.

An exciting early project was our partnership with TikTok, integrating the viral platform as a new social network in our suite. Designs and technical documents evolved into TikTok posts popping up in our message and calendar tools, and the effort that came between was fluid and impressive. For me, there was plenty to learn—our designs dipped into less familiar waters, from webhooks and asynchronous processing patterns to data model compatibility. Working closely with other engineers and designers (and syncing often with TikTok) I became friendly with these concepts and many more. By the time we went live, it was clear we took both our wins and losses as a team, and I found that to be true even outside of engineering.

Finding solidarity through Community Resource Groups

In our hybrid work world, I searched for spaces to build connections and relationships. Knowing the power and bond of minority communities, I joined two of our community resource groups almost immediately: Underrepresented Genders in Tech@Sprout (UGIT) & Asians@Sprout.

In our organized Slack channels and meetings, real and authentic conversations bloomed. Members in each community supported each other through both work and personal issues. Each group had at least a handful of fearless members, driving vulnerability and honesty through even the most difficult of topics: from work-related themes like burnout or promotion advice to more emotional fronts like mental health.

Even painfully relevant issues like pandemic-spurred Asian hate crimes or political threats to women’s rights were discussed and grieved in the open. It was a breath of fresh air. In a mostly virtual environment, these communities had carved out a safe space to be unapologetically yourself, and the relief that came with it was evident. I found the effects on my comfort and confidence to be far reaching, extending past our gatherings to my every day work.

I wanted to give back—to be a driving force for the communities that had taken me in, especially for other women in engineering. So in early 2022 I joined the leadership board of UGIT and have spent the last several months alongside an incredible team working to further disrupt the gender narrative in technology. We foster discussions and social initiatives aiming to empower our community and provide opportunities for learning and recognition.

Finding an organization that will give you the space to be your authentic self is rare, but you shouldn’t settle for anything less. If you’re interested in joining our team, check out our engineering careers page and apply today.

The post Vulnerability in the workplace: A career differentiator for women in software engineering appeared first on Sprout Social.

My shyness and social awkwardness have always been my Achilles’ heel, but I ended up attending Texas Tech University and found myself in a lecture hall filled with almost thirty men and one other woman. I remember my professor making a point of calling on me during class, and while he may have thought he was helping me gain more confidence, it was an extremely stressful experience. I wasn’t afraid because I didn’t know the answer, I was afraid of being wrong.

I made it through with top grades and decided that from then on, I wanted to make sure women in engineering would not have the same experience as me. I started to get more involved in outreach programs and activities that allowed me to connect with other women in engineering. Around this time, I decided to help revive our small women’s computer science group: Extraordinary Women of Computer Science (EWoCS). Being part of EWoCS helped me gain confidence in my schoolwork and empowered me to tackle a new beast: how to find a job as a software engineer.

Finding Sprout Social

As I started looking into how to get a software engineering job, I discovered that the environment of some of these companies were all too similar to what I experienced in college: all-male teams and all-male leadership. The percentage of female software engineers is small to begin with, as women made up only 14% of software engineers in 2018, and I started to question if the gender gap in engineering would ever change. I am a firm believer that diverse teams bring incredible value to both the organization and the product, and I decided to only look for companies that valued culture and diversity as much as they did technical skills.

Enter Sprout: a company whose vision and values highly align with my own. I was hired as a front-end software engineer intern on the Analytics team. Not only was there another woman in my cohort of interns, but there were more than a handful of full-time women in engineering that I got to know and connect with. 

During my internship, I was blown away by the diversity of the engineering team and the efforts the company made to maintain that. For example, Sprout holds monthly diversity, equity and inclusion (DEI) Guild meetings that focus on educating our team about different cultures, identities and societal issues. I was surprised to see the team willingly talk about topics like systemic racism and women’s rights, and after my first DEI meeting, I decided that Sprout was the place I wanted to work long-term. I was offered a full-time position as a Software Engineer in July of 2018. 

Starting a Business Resource Group

Engineers are constantly faced with complex problems that need to be broken down into smaller tasks. Even though Sprout had a more diverse team than any other company I looked at, it was not perfect—but I wanted to help change that. I knew that if I could tackle a problem as difficult as supporting women in engineering and our underrepresented community, I could apply similar learnings to my everyday work as an engineer. 

I started to get involved by joining a Slack channel aimed for women in engineering called #BarbieIsAProgrammer. We would share resources, volunteer opportunities or just chat about what we were going through as non-male tech employees. Over time, Sprout’s DEI efforts grew and with this came the emergence of Business Resource Groups (BRGs). BRGs are employee-led groups for traditionally underrepresented communities who share a common purpose, interest or background. So when applications for BRGs opened, three amazing colleagues and I decided to help turn #BarbieIsAProgrammer into an official BRG, which we called “Underrepresented Genders in Tech,” or UGIT for short.

Like the name suggests, UGIT provides a space for underrepresented genders who work in tech fields at Sprout, including engineers, designers and people from our product team. Our first goal was to raise internal awareness and build a community so that people could connect with one another and meet potential mentors. Now that we are more established, we’ve been able to host events, coordinate panels with our own engineers, participate in community outreach programs and foster an intimate and safe space for our members at monthly meetings.

One of my favorite speakers we’ve hosted to date was Natalie Kissinger, a corporate litigator, who talked to us about how to negotiate—a simple and broad topic, but one that I have personally struggled with as a female engineer. After this event, I walked away with new techniques on how to communicate effectively while sharing my thoughts and ideas in a way that I was comfortable with. It’s events like these that keep the retention in our group high, as we’re all trying to learn how we can succeed in the highly competitive tech space. 

Looking forward

Through UGIT, I have been able to meet a group of people who are eager to learn and prove to themselves, and the world, that our perspectives offer a unique point of view to the engineering field. Together we are learning how to be more confident, embrace our mistakes and reinvent the status quo for engineering as a whole. Since I started, I have seen more women, LGBTQIA+ people and other underrepresented individuals joining our company, which shows me that representation is improving bit by bit.

My advice to women and other underrepresented genders who are wondering how to get a software engineering job is simple: own it, and don’t give up. It may not be an easy road, but I guarantee that once you get involved and reach your goals, you will feel accomplished. This journey will give you the greatest experiences and lessons you can imagine that apply not only to work, but to your life in general.

If you’re interested in joining our team, check out our engineering careers page and apply today.

The post Women in engineering: How I found and started my career as a software engineer appeared first on Sprout Social.

In my three and a half years working on a small Android team at Sprout Social, one of the main things that motivates me to come into work every day is the freedom and trust from our company to tackle a problem in whatever way we deem best.

The freedom to research and explore many different solutions to a problem we deem necessary, while accounting for a timeframe to deliver on product updates, enables us to find the best solution for both our customers and our software.

One such challenge involved building a UI component for our new Mobile Reporting feature. This new component was a month picker, which allowed our users to scope a date range for an analytics report.

The starting place we picked was the existing Material Components Library. Rather than starting from scratch, this library is actively maintained and aligns with the Material specifications. With this library as a foundation, we could likely reduce the amount of logic we’d have to write ourselves.

In this article, I’ll cover how we approached this process, some unique factors in building for the Sprout Android app, a few “gotchas” that came up (and were fixed) along the way, and what to know if you’re working on a similar project.

Introduction

The Android Material Components 1.1.0 Release introduced a new Date Picker UI Component. One of the welcome additions of this new MaterialDatePicker over the AppCompat CalendarView is the ability to select a range of dates using either a Calendar View or a Text Input Field.

The old AppCompat CalendarView was not very flexible. It was a good component for the limited use case it was meant to solve; that is, selecting a single date and optional minimum and maximum dates to specify an allowed date range bound.

The new MaterialDatePicker was built with more flexibility to allow the use of expanded functionality of behavior. It works through a series of interfaces that one could implement to tweak and modify the behavior of the picker.

This behavior modification is done at runtime through a set of builder pattern functions on the MaterialDatePicker.Builder class.

This means we are able to extend the base behavior of this MaterialDatePicker through composable interface components.

Note: While there are a number of different components the MaterialDatePicker utilizes, in this article we will cover the Date Selection Component only.

Date range picker

The Sprout Social Android team was in the process of building our Analytics Reports Section.

This new section would allow our users to select a set of filters and a set of date ranges that the report would cover.

The MaterialDatePicker came with some pre-built components that we could leverage to accomplish our use case.

For our most common case, allowing a user to select a range of dates, the pre-built MaterialDatePicker would suffice:

With this code block, we get a Date Picker that allows users to select a date range.

Monthly date picker

One of the Sprout Social reports that has more unique date selection is the Twitter Trends Report.

This report differs from the others in that instead of allowing any kind of date range, it enforces a single month selection, meaning a user can only select March 2020 vs March 3 to March 16, 2020.

Our web app handles this by using a dropdown form field:

The MaterialDatePicker does not have a way to enforce such a restriction with the pre-built Material Date Range Picker discussed in the previous section. Fortunately, MaterialDatePicker was built with composable parts that allow us to expand the default behavior for our particular use case.

Date selection behavior

The MaterialDatePicker leverages a DateSelector as the interface used for the selection logic of the picker.

From the Javadoc:

“Interface for users of {@link MaterialCalendar<S>} to control how the Calendar displays and returns selections…”

You’ll notice that the MaterialDatePicker.Builder.dateRangePicker() returns a builder instance of RangeDateSelector, which we used in the example above.

This class is a pre-built selector that implements DateSelector.

Brainstorming a monthly date selection behavior

For our use case, we wanted a way to have our users select an entire month as a selected date range; e.g. May 2020, April 2020, etc.

We thought that the pre-built RangeDateSelector referenced above got us most of the way there. The component allowed a user to select a date range and enforce a [lower, upper] bound.

The only thing that was missing was a way to enforce a selection to auto-select the entire month. The default behavior of RangeDateSelector has the user select a start date and an end date.

We wanted a behavior so that when a user selects a day in the month, the picker will then auto-select the entire month as the date range.

The solution we decided on was to extend the RangeDateSelector and then override the day selection behavior to auto-select the entire month instead.

Luckily, there is a function we can override from the interface DateSelector called: select(selection: Long).

This function will be invoked when a user selects a day in the picker, with the selected day passed in UTC milliseconds from the epoch.

Implementing a monthly date selection behavior

The implementation turned out to be the simplest part, since we have a clear function we can override to get the behavior we want.

The basic logic will be this:

1. User selects a day.
2. The select() function is invoked with the selected day in a Long UTC milliseconds from the epoch.
3. Find the first and last day of the month from the given day passed to us.
4. Make a call to super.select(1st of month) & super.select(last day of month)
5. The parent behavior from RangeDateSelector should work as expected, and select the month as a date range.

Putting it all together

Now that we have our Custom MonthRangeDateSelector, we can set up our MaterialDatePicker.

To take the example further, we can process the result of the selection like so:

The result will look like this:

Gotchas

There was just one major issue that made it difficult to arrive at this solution.

The primary components used to build our MonthRangeDateSelector were the class RangeDateSelector and the interface DateSelector. The version of the library used in this article (1.2.0-beta01) restricted the visibility of these two files, to discourage extending or implementing them.

As a result, although we could successfully compile our new MonthRangeDateSelector, the compiler did show a very scary warning to discourage us from doing so:

One way to hide this compiler warning is to add a @Suppress("RestrictedApi") like so:

This experience illustrates how, even though the Material Components Library has provided some great new components to the Android Developer Community, it is still a work in progress.

A great part of this library is the openness to feedback from the Android Community! After discovering this component visibility restriction, I opened an issue on the Github Project, and even opened a PR to address it right away.

This open feedback loop between the Material Components Team and the Android Community breeds great collaboration and results for everyone.

Conclusion

The new MaterialDatePicker has some great out of the box functionality that will likely cover most use cases of date selection.

However, the best part of it over something like the AppCompat CalendarView is that it is built in a composable way. Therefore, it can be easily extended and modified for specific use cases, whereas it would be much harder to accomplish such things in the CalendarView.

Special thanks

I’d like to highlight some folks that helped peer-review this article:

• Nick Rout (Github)
• Mike Wolfson (Github)
• Ryan Phillips (LinkedIn)
• Lucas Moellers (Github)
• Mit Patel (LinkedIn)

The post Engineering at Sprout: Building an Android month picker appeared first on Sprout Social.

Justyn is a leader whose vision not only drives the growth of our business, but also inspires our team to do and be better each day. He is committed to a culture of openness and has worked tirelessly alongside our executives to create a workplace where team members are empowered to share their ideas, work collaboratively and embrace the diverse qualities and characteristics that make each employee unique. This has helped Sprout to maintain a close-knit, yet scalable culture that has developed organically over time.

“Being named to this list for a second year is a true honor and I am grateful to the team for their steadfast belief in our vision for the business and product,” Howard said. “I’m as excited about Sprout’s future as I was eight years ago when we started, and that is due in no small part to the nearly 500 team members that show up ready to tackle the toughest problems in the industry each day, while continuing to provide great value for our customers.”

So, what are employees saying on Glassdoor about leadership at Sprout?

“I have never worked with a more hard working, talented group of people! I look forward to coming to work every morning. It all starts with the leaders at the top who have been a consistent group from the very beginning.”

Anonymous Employee

“Sprout continues to foster a collaborative workplace. There’s tremendous opportunity to make an impact as leadership encourages feedback to shape company goals and processes. Sprout is routinely recognized as a best place to work for good reason.”

Account Manager

CEO approval ratings are gathered through Glassdoor’s online company review survey, which gathers current and former employee sentiment about job and company satisfaction, the work environment and the culture. Among the 770,000 companies reviewed on Glassdoor, the average CEO approval rating is 69%.

We are thankful to our team members who have taken the time to share their experiences on Glassdoor. And more than ever, we are proud to have a leader who is fiercely dedicated to team and customer success.

Want to join Team Sprout? We’re hiring.

The post Sprout Social’s Justyn Howard Named a Glassdoor Top CEO for Second Year in a Row appeared first on Sprout Social.

Nearly every application you will work on requires the use of time in some way, meaning that at some point you’re going to have to collect, store, retrieve and display dates or times. There’s no silver bullet for dealing with dates or times and you can never escape the inherent complexity that comes with our concept of time, but there are steps you can take to make it less of a pain.

In the years that I’ve been working with time across different programming languages, I’ve found the following knowledge goes a long way.

Choosing the Right Data Format

The first step when working with times and dates is to choose a representation for your data. While different formats may seem more or less the same, the format you choose will have a large impact on how you write and debug your code.

Using a numeric timestamp when you need a date will mean parsing the date timestamp and retrieving the date from that, which may or may not be straightforward depending on the time zone.

Using a custom string to represent a span of time seems easy to store and manipulate, but it’s difficult to query. Additionally, using any kind of representation that isn’t immediately recognizable by the human eye is going to make debugging your code more difficult.

When choosing a format for dates or times, I abide by the following rules:

1. Never use numeric timestamps. They’re often the easiest to obtain by standard libraries among various programming languages but they’re not human readable and the temptation to manipulate them is too strong.
2. Abide by ISO 8601, a standard that defines a format for date and time-related data. It’s trivial to find a library for any language that can handle the variations of ISO 8601.
3. ISO 8601 is a standard, but it has many variations. You should always choose the most human-readable variant of ISO 8601. This requires no extra effort but makes debugging easier.
4. Your timestamp string should only contain data you absolutely need. When working with times your string should not contain a date and when working with a date that is time zone-agnostic your string should not contain a time zone. Adding extra information adds ambiguity to the parsing operation and to the intent of the data for future developers
5. When storing time zones always normalize to the same time zone in your timestamps. This not only makes it easier for a computer to sort and process the data but it makes it easier for a human developer as well.

Abiding by these rules won’t cost you much up front but they will make your life easier when your application is established and you find that your usage of times and dates isn’t what you expected.

Choosing the Right Tool

As with most problems in our industry, time and date handling comes down to picking the right tool for the job.

It’s tempting to use the tools in your favorite language’s standard library, but that might not be the best choice. While some standard libraries have fantastic date and time features (Python), others are downright pitiful (Javascript). Using the wrong tool makes it that much more difficult to develop features based around time and that makes it easier for bugs to slip into your application.

A good library for handling dates and times will allow you to follow the 5 rules mentioned above. Specifically, it should be able to:

• Parse any date representation you may run into (including external representations.)
• Output to any date representation you may need (including external representations.)
• Manipulate dates and times by adding or subtracting units of time from them.
• Compare dates and times.
• Correctly convert between time zones.

It’s important that your library supports these features, otherwise the temptation to try to implement the functionality yourself will be too high. And just to be clear, if you try to implement any of that functionality yourself, you will fail.

Don’t parse your own timestamps with regular expressions, don’t add seconds to a numeric timestamp because it seems like a normal number and don’t compare dates and times using the equality operator. These libraries exist because these problems are hard to solve and reinventing the wheel in your application is just going to leave you with a broken wheel.

Below I have a few suggestions for libraries that fit these criteria:

If your language isn’t listed (because I’m not familiar enough with it) just search for <language> date and time library. Chances are you’ll find a good library that will do everything you need.

Knowing About Time

The final bit of knowledge I have to share isn’t specific to working with dates and times, but is more of a general philosophy to help us avoid problems and it applies to date and time handling as much as it does every other problem in programming.

Always check your assumptions.

We approach every problem presented with a large body of knowledge and an even larger body of assumptions. When handling dates and times it’s more important than ever to check your assumptions to ensure that they still hold for your scenario.

This list, titled Falsehoods Programmers Believe About Time, gives many excellent examples that illustrate time probably isn’t what you thought. When you’re designing or developing a feature that centers around time I encourage you to grab a partner and go through this list ensuring that you’ve avoided the pitfalls listed.

Time bugs are notoriously difficult to catch and even more difficult to test for. If you develop with this list in mind you may be able to avoid subtle bugs that would affect your customers but that they might not catch (the worst kind of bug!)

Time Zones

No discussion about times or dates would be complete without mention of time zones. In addition to familiarizing yourself with the common falsehoods listed above, also familiarize yourself with the basics of time zones.

Time zones will consistently be a pain point when working with time, even if you think you have them “all figured out”. Having a bit of knowledge about time zones will help you center your thinking and help ensure that you don’t make any logic errors when manipulating times.

Unfortunately there is no way to completely avoid the difficulty of storing and manipulating times and dates when programming. But if you follow these steps and work with this knowledge in mind, you can make the task easier by cutting down on the amount of code you have to write and forcing yourself into paradigms that are less likely to cause issues.

The post Working with dates & times in your application appeared first on Sprout Social.