Women in Tech

Feb 04 2020

Letting Go of the Formality

It wasn’t that long ago that suits, ties, knee-length skirts, heels and pantyhose were required wardrobe staples. In fact, many enterprise Fortune 100s upheld a formal dress code as part of their HR Policy Handbooks. Goldman Sachs, the last bastion of formality on Wall Street, finally relaxed its dress code and offered a “flexible style” option. They only did so last year. Their updated policy permitted men to choose garments other than suits. Admittedly, this made things more complicated for women but that’s a topic for another blog.

Since we’re agile practitioners here at InRhythm, it made sense to look at our own approaches to talent and acquisition. Not to mention retention. Practices and policies drive corporate culture. Here, Agile Platinum Principle One: resist formality, must serve as one of the pillars of our talent strategy.

If your company doesn’t offer a culture that’s aligned with the needs and expectations of today’s job seekers, then, as Hiring Manager or Chief People Officer, you’re going to have a really hard time. At best, you’re going to struggle and slog through your days and recruiting campaigns. At worst, you’re not going to have any people to serve as Chief over!

The link between informality and tech

Ask anyone within the technology field, or external to it, to describe or draw a person in tech, be it a software developer or a startup founder. The universal response is a male, typically Caucasian, dressed in sloppy jeans and a hoodie. Where did this level of informality originate?

Many would cite Lou Gerstner’s (former CEO of IBM) decision to roll out “casual dress.” Even the New York Times balked with a headline that read, “Black Jeans Invade Big Blue.” Shortly thereafter, Hewlett Packard (HP) introduced “Blue Sky Days” which permitted employees to wear jeans to work on Fridays. From there, dress code devolved or evolved – it depends on your perspective – into what we see today.

However, the Platinum Principal of resisting formality is not restricted to dress code. It extends into everything that we do. Formality also has implications with unconscious bias, how we greet and interact with people, the forms that we require candidates to complete and so on. Tone and style go hand in hand.

How are we resisting formality?

We are constantly taking steps to increase our awareness and connection with our prospective employees, candidates, contractors, staff and employees. Efforts are made to understand what they need so that we can craft our talent, acquisition and retention strategies around their needs and expectations versus requiring that they conform to ours. Here, we have embraced an agile culture across the company, not just in our product development efforts.

As agile craftsmen, with respect to HR recruiting and retention strategies, we have adopted an approach that is more responsive than it is prescriptive. Our applications are deliberately designed with brevity in mind to expedite the hiring process. We measure how long it takes from the time that an application is submitted to an open job posting until someone is seated in the role. A conscientious effort, with monitoring, is made to ensure that we are constantly moving our candidates through the hiring process as swiftly as they seek to do so.

Another way that may come as a bit of a surprise is the effort we make to create a relaxed culture that allows for flexibility and downtime. We understand the enormous pressure and stress that our employees feel as they do all that they can to deliver on our clients’ needs. It’s okay to push through a couple of scrums or back-to-back sprints but it’s not sustainable. Over the holidays, we relaxed with an in-house office party and gave people some bonus time. This week is Valentine’s Day: celebrate it or not, you don’t need to make it about sending flowers and chocolates to your partner. Use it as a reminder to resist formality, take some time and reach out to whomever it is that you care about, be it a parent or sibling or a friend.

Resist formality! Make strides to emulate the people and culture around you. Forcing people into a process defined by its rigor and inflexibility is the antithesis of what a company should do. Particularly a company who’s purpose is to bring agile methodologies and success to our clients.

Stu Weiser,

Director of Talent Acquisition
Image created by katemangostar – www.freepik.com

May 02 2019

The Magic of Service Workers

When we think about building modern web applications, we think about being online, about updating users with the latest news and offers. We think about flashy, and attractive animations. In the process of building a web application we often forget that the reality can be dramatically different. We are so busy focusing on the design, content, digital marketing that we forget one of the most important parts of keeping the website running – the users. In reality our users are located in various parts of the globe. They could be offline, or browsing on an old device using often flaky connection, or simply have limited data. How can we make sure that everyone has relatively the same experience using our product, no matter in what conditions they are using it?

What is a service worker?

If you heard of PWAs, you also heard of service workers, but what are they, how do they work, and what does it have to with anything?

A service worker is a JavaScript execution context that has its own event loop and node document dependency. In simpler terms, service workers are simply event driven JavaScript scripts running on their own thread in the background, separate from the browser. They don’t have access to the DOM and they are not attached to a single page, like regular JavaScript files. Their main role is to handle events fired by the browser, or your webpage, and intercept network requests.

You can think of it as a gatekeeper for your network requests. Service workers have a total control over every request made from a website. Since they run in the background, they don’t need the webpage to be open. That gives them ability to listen and respond to events such as push messages sent from the server to the browser.

How does a service worker work?

As we said before, service workers are based on JavaScript. Now, how do they do all that magic? Why would you want to add more code to your project? Why can’t you just use regular JavaScript file? Let’s consider two scenarios – a website with and without a service worker.

Scenario no. 1 – without service worker

You go to a website. Your browser makes a request to the server. The server responds with index.html file. Your browser parses through that file and makes additional requests to the server for the remaining files necessary to render the page. After the page is rendered you can enjoy using the website. You close the tab. What happens when you come back to that page? The process starts all over again. Now imagine that in the middle of that process you lost the connection. Bad news, once the connection is back the process will start all over again. Simply said, every time the connection is lost, the page is gone. If you don’t have access to the server, you simply don’t have access to anything.

Scenario no.2 – with service worker

You go to the website. Your browser makes a request to the server. The server responds with index.html file. Your browser parses through that file and finds service worker. The service worker is being downloaded, installed, and activated. Your browser continues making requests as usual, then renders the page. You use the page, and as usual, leave the page at some point. The process doesn’t seem any different, until you come back to that page. The logic behind service workers kicks in after it was installed and activated. With that being said, service worker won’t work until you return to the page after initial installation. From that point service worker will handle all coming and going requests. In the case that you lost connection, the page can still be loaded from the cache. The true power of service workers is ability to run in the background. This means that even if you leave the page, service worker will make sure that the content gets updated, and when you return, it’s ready to be loaded immediately. Imagine working all day and not using your precious phone. After work you get on the train, the connection is lost immediately and you can’t access any social media. Aha! Here comes a surprise. Your best friend service worker was busy all day preloading all new content for you. Now you can open your favorite page and be updated on what your friends ate for a dinner. How awesome, right?

Security concerns

What about malicious code running in the background of your phone hijacking all requests, you may ask?

With great power comes great responsibility. Using service worker, you can easily hijack connections, modify them, and fabricate responses. To prevent these malicious activities service workers can only be registered over a secure connection. You don’t need to worry about it during development process – localhost is considered to be secured. However, you definitely have to take care of the SSL certificates once your web app goes live. You can opt for paid or unpaid certificate. Should you decide to save some money on that step Let’s Encrypt is a free, automated, and open certificate authority.

Service worker lifecycle

Since service worker runs in the background, it has a separate lifecycle from the web page. Let’s have a look at its cycles.

Registration

In order to use its abilities, service worker has to be registered first. You should be aware that service workers are fairly new technology, and they are not yet supported by all the browsers. According to caniuse.com the browsers that are currently not supporting service workers are: IE and IE Mobile, older versions of Edge and Firefox, Opera Mini, and Android Browser. Hence, before we register service worker, we should check if the browser that is currently used by our user supports service workers. In the case that service workers are not supported, JavaScript code will skip service workers, and continue running. If the browser supports service workers, and the page never had a service worker before, or the current service worker had been updated, the browser needs to fetch a new service worker, register and install it. Service workers don’t require user’s permission in order to be used. The user won’t be even notified of their existence.

Installation and caching

After the registration of a service worker is completed, it triggers installation process. This is a perfect time to pre-cache all of the resources needed for the shell of our app.

Activation

Once the service worker has been installed it’s then activated. The service worker will now control all pages under its scope. You may now ask: what happens when after some time our cache gets outdated? The browser doesn’t know which cache we are going to use, but storing all outdated caches takes a lot of space. The activation process seems to be a great place to solve this issue.

Fetch and updating cache

After the service worker was activated, it can now control events such as fetch, message, and push events which occur whenever network request or message is sent from the page.

Termination

In order to save memory, the browser can terminate the service worker. It will be restarted as needed.

Scope

When the service worker is registered, it will only handle requests within its scope. What it really means is that your service worker will only have a power over the scope that it is placed in. If you place the service worker in root folder, that service worker will be in control of all other pages. However, if your service worker is placed in a particular folder, it will then have control over that folder only.

What you should also remember is that any page can register a service worker, there are no limits to the amount of service workers, but once they are installed, they will be there forever, or until they are manually unregistered by the user.

Caching strategies

There are a handful of useful cache strategies, but choosing the right one always depends on the needs of your application. Let’s have an overview of a few of most common strategies.

Cache first, then network – if the request matches the cache entry, otherwise try to fetch the resource from the network. This is a great strategy for storing commonly used files such as components. However, you should be careful when using this strategy for the application data or resources that change often – you may get old data.

Network first, then cache – using this method you will try to fetch the resources from the network. If the network request is unsuccessful, the browser will try to fetch the resource from the cache. This is a good method to use for the apps containing a lot of fresh data, such as social media platforms, game leaderboards, or articles. This method guarantees that the network request for freshest data will be attempted, however it is unsuccessful, you will still see the old data. The major flaw of this strategy is that when the user has a slow or intermittent connection, they will have to wait either until the data gets loaded from the server, or until the request times out.

Cache only – using this method, your browser will try to resolve the request from the cache. If the resources are unavailable, the request fails. This is a great option for making sure that no network request is made, for example when you turn on save battery mode on your device.

Cache then network – this strategy is ideal for data that updates frequently or when it’s important to get the data on the screen as fast as possible. Using this method, you would make two parallel requests – one to the network and one to the cache, then display the cached version first, and update the UI once network response arrives, unless the network data returns before the cache.

Progressive enhancement

Service Workers are a new technology, currently supported by Chrome, Firefox, Opera, and Samsung Internet (coming up in Edge and Safari). What happens if the browser that you are using doesn’t support them? The browser will simply ignore the part of code responsible for Service Worker and default to its natural behavior. Simply said, you won’t benefit from Service Worker, but it won’t break anything as well.

Push Notifications

What are push notifications?

Push notifications are messages that are ‘pushed’ from the server user’s device. They allow us to communicate with the users even if the browser is closed. The ability to reach out to users at any time gives us a is incredibly powerful way to engage with the user, bring them back to the application.

Structure

Push notifications consist of two building blocks: the Notifications API, and the Push API. The first one lets us to display the messages to the user, while the latter is responsible for handling the Push Messages received from the server, even when the app is closed. The Notification and Push API’s are built on top of the service worker API, which responds to push message events in the background and links them to the application.

Push API

Push messages meant to become notifications are sent from a server directly to the push service, and contain the information necessary for the push service to send it to the right client and wake up the correct service worker. This process happens even when the browser is closed and the service worker is deactivated. When the service worker receives the message, it wakes up to display the message and then deactivates again. However, if the user decides to interact with the notifications service worker wakes up again, this time to handle that user’s interaction.

Notifications API

This API is solely responsible for displaying the notifications to the user. This API uses the same mechanisms as native apps, giving the notifications a completely native look and feel.

Permission

Before the notifications can be displayed, the applications need to prompt the user with permission request. The user’s response is the stored along with the app, so when the user comes back, the window does not pop up again with the same request.

Background Sync

Background synchronization is a relatively new but very important feature, as it allows you to synchronize the data even if the user is offline. Let’s imagine, that the user started filling out the form while online. By the time the form was ready to be sent, the user was already offline. How frustrating it really is when at the end of filling out form you can’t save them, all the data is gone and you have to start over when the connection is back? Thankfully using background synchronization allows us to proceed with sending the data to the server. How does it work? You would probably think that we simply send the request, that request is stored in the cache until the connection is back, right? Unfortunately, you can’t cache ‘POST’ requests. So how do we do it then? We need to register sync tasks, in other words we need to tell the service worker that there are some tasks that require to be taken care of when the connection is back. But where is that data that we want to send stored in the meantime? IndexedDB is the best place to store the data requested to be sent. When the connectivity is reestablished the sync event fires, and the service worker executes all tasks it has stored. The beauty of this feature is that user doesn’t have to have the browser open – everything happens in the background!

Summary

Service workers possibilities are countless, and this article only touches on a few of them, but be sure that mastering your service worker skills and caching techniques will make your web apps reliable, fast and engaging whether your users are offline, online or using flaky connection.

Apr 10 2019

Recognizing and Remembering the Importance of Women in Tech Communities

Women in Tech at InRhythm has always been an evolving group that has taken different shapes to meet the needs of its members, but throughout we’ve always recognized the importance of women in tech and the need for representation. For a while, our leaders were stuck in a rut on the direction of the group, so we returned to the original mission statement from the group’s founding:

“Women and non-binary people are alarmingly underrepresented in technology. The Elephant in the Valley survey found that 84% of women ‘have been told they are too aggressive,’ and ‘60% of women in tech reported unwanted sexual advances.’ Queer, non-binary, trans people, and women of color experience pay disparity, discrimination, racism, homophobia, transphobia, and sexual harassment in the workplace.

At InRhythm, we want to provide our female and non-binary engineers, designers, and operations professionals with a network and support system as they learn and grow. We aim to develop programs and initiatives that will help our team integrate and communicate with one another.

The goal of this community is to facilitate communication between women and non-binary members of IR across clients, and to create a safe space to talk about issues we may experience specific to our identities.”

In our quest to move fast and evolve constantly, it’s easy to forget to take a moment to see what’s at the heart of what we’re working towards. Returning to our mission provides an important grounding and realigns our vision going forward. All that said, we’ll be continuing to align ourselves around our mission to continue to move the needle on the issues that are important to our members.

Community Outreach

One of the biggest issues the Women in Tech community has been trying to address is increasing our membership numbers here at InRhythm. Driving change here involves commitment at all levels: one, in the hiring process and the people we recruit, but also in the foundation we create for future women to enter the field. Young girls and women are dissuaded and disillusioned from pursuing careers in development—and involvement in STEM in general—due to systemic factors, gender biases, and disparities in the workplace.

We know there’s an issue, so how do we solve the problem? Women in Tech is taking a proactive approach, creating future initiatives with the aim of starting ripple effects that turn into waves. Our partnerships, with organizations like Girls Who Code, is one path to reaching young girls and women to open up their minds to the possibility of careers in software development. The group has reached over 90,000 girls in just six years through initiatives like local clubs and immersion programs, providing critical opportunities for girls to see themselves represented in the field and get hands-on experience in this exciting industry.

Through our research, we know that one of the primary challenges that girls face in pursuing computer science as a career is a lack of female role models. Girls are more likely to grow up to be innovators themselves if they have access to women already in the field, underscoring the importance of representation, mentorship, and self-image. The Women In Tech Lesson Plans introduce middle school students to female role models and spark the interest of girls to pursue an education in computer science.

Investing in and bringing in prominent speakers will also help to inspire not just the InRhythm community, but external Women in Tech members within other local chapters. A special shout-out to Sandro, our Web Practice Lead and Brian, a senior engineer, for mentioning Compassionate Coding co-founder April Wensel. She has been in the software industry for many years and has tried and tested different solutions to harness the power of kindness and compassion through her company.

Changing the status quo when it comes to gender representation can be a monumental task, but by laying the groundwork for the future and reaching out to the young girls who are would-be women in tech, we can enact lasting change. Gender disparity is a difficult chicken-and-egg problem to solve, but in our experience, the women of InRhythm are proactive, exceptional leaders and we believe there is room for everyone in the development space. If we continue to encourage STEM-field participation and support fellow women in the field, we know the next generation will rise to the challenge.

Feb 19 2019

Kickin’ Axe and Spreading the Galentine’s Love—Life at InRhythm

InRhythm’s Women in Tech group kicked off its first offsite event of 2019 with a Leslie Knope-inspired, Parks and Recreation-themed “Galentine’s Day” event on February 13th celebrating the women of InRhythm and all that we do for each other. Our goal? To bring together the diverse group of women working at InRhythm for an evening of fun and togetherness. In attendance were designers, engineers, and operations team members, all united in support of representation in the tech field. Our night at Kick Axe Throwing in Brooklyn began with dividing our group into two teams—Kick Axe and Triple Axe.

Stakes were high between our fiercely competitive group members. We can code and design for high-level industry-leading clients, but the aerodynamics of axe throwing proved to be a new challenge. While Triple Axe ultimately won the contest, we count all our members as winners.

[desktoponly][/desktoponly]

The women of Women in Tech bring diverse experiences and skills to our group, and that’s what makes us stronger together. From recent grads to seasoned engineers, making strides toward equality takes all kinds of people united behind a good cause. Even the act of working as a woman in the field is progress, so we’re all advancing the cause with everything we do. We think that’s worth a little bit of appreciation and celebration.

Want to learn more about Women in Tech in New York and at InRhythm? Subscribe to our blog below, or follow us on Twitter @GetInRhythm for the latest from our group.

Feb 13 2019

Little Wins from Women in Tech

Happy Galentine’s Day! InRhythm’s Women in Tech group is excited to continue working and promoting fellowship between women 2019. On this day, we’ll be celebrating each other’s accomplishments, spending time together, and talking about our future plans to continue to move the needle on diversity and inclusion in tech. With every new year, it’s common to set goals and make resolutions for all that we want to accomplish throughout 2019. This year already promises to be full of innovation and excitement, but before we look forward it’s important to reflect on all of the amazing things—from little wins to big changes—our group members have accomplished, in and outside of the workplace:

“[2018 was about] getting over my fears and leaving my job of 5 years (and becoming an InRhythmer!). I went on my first solo trip and picked up reading again (self-empowerment was a reoccurring theme towards the end of the year).”
–Eileen, Senior UX/UI Designer

“Incorporated more exercise into my life, my Fitbit really helped me meet daily goals. The second was getting a job at InRhythm!”
-Tricia, Client Partner

“I graduated from college, got a job and moved to NYC from Michigan!”
-Taylor, UX/UI Design Associate

“I moved countries and had to manage my toddler alone, which was a huge thing, being cut from all the help my family offered back in my country. Led a new platform in my work—which was a great learning experience for me.”
-Sushmita, Technical Project Manager

“Getting a job with InRhythm, and moving into my own place.”
-Samantha, UX/UI Design Associate

“My biggest accomplishment was getting my first job as a Software Engineer. I was a bartender 4 months prior to landing that job, so it was a huge change but also a huge risk that I took to immerse myself completely in learning and job searching.”
-Kate, Software Engineer

“Transitioned to a new industry.”
-Jill, Program Manager

“I helped my boyfriend—who also works full-time—with a second, new business. The fact that the business is growing and we are still talking to each other is a huge accomplishment. There were rough points. I have incredible admiration for anyone who tries to start a business. It is not for the faint of heart.”
-Adrienne, Senior UX Designer

“After a gap year, the biggest challenge was to start development again. I joined AmEx [through InRhythm] and a different journey began! I was never a consultant before so stepping into that and being the lone consultant on the team was a challenge.“
-Anuja, Java Engineer

“In 2018 I started a new job at InRhythm!”
-Jessica, Technical Recruiter

“I moved to an apartment that has a washer & dryer!”
-Amanda, Talent and Growth Associate

—

As we look forward to the months ahead of us, we have so many different things we want to accomplish in 2019. Our diverse group of women—from different cities, departments, and projects—have an array of different goals that they’re looking to achieve:

“Get back into coding and visiting a new country.”
-Eileen, Senior UX/UI Designer

“My goal for 2019 is to close new business at InRhythm and figure out how to enjoy exercising at 5am!”
-Tricia, Client Partner

“A goal I hope to achieve in 2019 is to go beyond the basics of HTML, CSS, and JavaScript and learn to code well enough to build my own website.”
-Taylor, UX/UI Design Associate

“I want to be stronger emotionally, physically and technically (workwise). I wish to master the new platforms I am now working on.”
-Sushmita, Technical Project Manager

“Traveling to at least 2 more countries on my own and going to more networking events to grow my network of designers.”
-Samantha, UX/UI Design Associate

“For 2019 I want to expand my knowledge of CS fundamentals and explore dev-ops, save some money, and get my blue belt in Jiu Jitsu!”
-Kate, Software Engineer

“Complete my EMBA”
-Jill, Program Manager

“I’m not a big fan of yearly goals, however, I do plan on getting personal documentation together (e.g. will, power of attorney forms, beneficiaries on bank accounts, etc.) in case I die. I have had to help several friends deal with the estates of deceased family members who did not have anything written down and it was a nightmare. If you love, or even remotely like, your friends and family, don’t do this to them!”
-Adrienne, Senior UX Designer

“For 2019, my biggest goal is to get back to a balanced life and be focused on a healthy lifestyle.”
-Anuja, Java Engineer

“In 2019—stop procrastinating and apply to grad school!”
-Jessica, Technical Recruiter

“My goals for 2019 are to learn how to stand up paddleboard, brush up on my Greek, and get my SHRM-CP certification.”
-Amanda, Talent and Growth Associate

One of the things that makes our Women in Tech group strong is the diversity we bring to the table. Our group members run the spectrum from single young professionals to working mothers, and fresh college grads to experienced industry experts. Each of us has our own goals and dreams, and every small victory we achieve is, in its own way, a win for all women fighting for representation. What are your wins from 2018? What are you hoping to accomplish this year? Share your story with us @GetInRhythm or in the comments below.