The Winning Tech Resume

Tech jobs across the world are rapidly increasing and can be found in most industries. The rise of such jobs is due to organizations increasingly relying on computer systems and technologies. 

Examples are the adoption of cloud computing and cybersecurity. As a result, employment in IT occupations is predicted to increase by up to 12% between 2014 and 2024. 

Some specialized tech jobs that are expected to increase in demand include:

  • Software developers
  • Web developers
  • Information security analysts
  • Mobile application developers
  • Computer system analysts

These jobs will require you to have specific skills that you will have learned and practiced. Some of the most important IT skills you may already possess are:

  • Coding
  • Application development
  • Cloud services
  • Cybersecurity
  • Database administration

Combined with the below ‘soft’ skills, you will be able to fit into a tech role of your choice. 

  • Communication skills
  • Time and project management skills
  • Analytical skills
  • Problem-solving skills

These are the basics that will enable you to work within an IT department, as well as interact with high-level management. 

Note: Though the terms are interchangeable, do not confuse tech skills and technical skills. Tech skills relate to IT skills associated with digital technology. Technical skills are a broader range of abilities, such as accounting which is not a tech skill.

Each type of tech resume needs to be tailored to the role and this is the tricky part for job seekers in the industry. 

You will need to be able to showcase your specific skills. At the same time, you need to differentiate yourself from people with similar skills and highlight relevant experience. 

How do you make your resume stand out among the thousands that employers receive? 

This guide will give you an overview of what to consider when creating a tech resume that will get you hired. 

Once you have an impressive resume, the next step is to find jobs to apply for.

By targeting employers who are looking for someone just like you, there is a better chance to be called in for an interview.

Using the Quantic platform is an ideal solution to finding new opportunities. The platform is specifically designed to connect students with top employers and every job seeker has a chance at success.

This is why we have developed sample resumes for the most popular tech jobs. Just like we did for data analysts

The format of your resume is also an important factor as employers only take a few minutes to skim each CV. 

Let us help you create a winning resume and take the first step towards landing your dream job.

What Makes a Good Tech Resume?

Several features that make for a good tech resume. Let’s look at 4 of the top tips.

Use the Correct Format

Structure Your Resume in Reverse Chronological Order

You need to start with your most recent job – the pinnacle of your career. After this, list all the relevant previous jobs in reverse order. 

This will draw attention to your growth path and act as a way of putting your best foot forward. 

Use Professional Fonts and Spacing

The top three fonts to use are Calibri, Cambria, and Helvetica; being the neatest and most legible. The size can be either 12 or 10 in order to be legible and headings can be either size 12 or 14.

With regards to spacing, stick with single-line spacing.

Set the Correct Margins

You don’t want to cram your resume with text as it will look unprofessional. Large margins on the other hand make it look empty. Your best option is to use one-inch margins on all sides.

Use the Correct Format – Word vs PDF?

Firstly, read the job description and follow the employer’s instructions. Send whichever format they specify and send their preferred format.

If there are no specifications, usually a PDF document is a safe choice. It will preserve your formatting and open as a professional-looking document.

One disadvantage is if the recruiter is using an applicant tracking system, (ATS). The software may have trouble scanning your CV and skip crucial information.

If unsure, you can show some initiative and reach out to the hiring manager and enquire about their preferred format. Alternatively, simply send CVs in both formats. 

Proofread Your Resume

Take the time to ensure 100% correct spelling, grammar, and formatting. Sloppy mistakes on your CV are a sure-fire way to demonstrate to your potential employers that you don’t have attention to detail.

Highlight Your Strong Points

To avoid sending a generic resume, you will need to address the needs of the company. 

To do this showcase your skills at the top of your resume. Pay close attention to the necessary skills listed on the job posting and match your strong points to the advertised position.

This is one of the tricks to creating a successful tech resume that will get you into the interview room.

Write an Engaging Experience Section

The work experience section is probably the most important part of a tech resume. Employers know what you did by looking at the job title. They are more interested in how you well did it. 

This section will be proof that you can perform the technical skills you have described. 

To make your experience section engaging, follow these tips:

  • Make use of bullet points
  • Use short, descriptive sentences 
  • Prove your experience with links to your previous work or portfolio 
  • Include the duties and responsibilities of the jobs you provide

Write According to Your Experience Level

Those with extensive experience have very different CVs compared to recent graduates.

For an expert, their education level is not going to be a deciding factor. They can simply write:

2011 – 2015

Stanford University

B.Sc., Software Engineering

This section should be placed directly under your career statement. 

For those without an extensive work history, place your degree and learning institution below your education level. This means your education section will be more detailed, like so:

2011 – 2015

Stanford University

B.Sc., Software Engineering

  • Chairperson of IT-Hub, the campus machine learning club, 2014 – 2015.
  • Completed eight advanced Java programming classes to cement my knowledge.
  • Broadcasted an online webinar on best practices for security in cloud services.
  • Wrote for the S.U. Mag, specializing in IT-related topics on a monthly basis.

Use Sentences That Get Straight to the Point

Do not use overly-long sentences when writing your resume. You want to keep the sentences short, and preferably in bullet point form. Here are some tips when writing the bullet points; 

  • Start with an action verb: Oversaw 
  • Describe a specific task: Software upgrading campaign 
  • Complete with a quantifiable point: Cost reduction of 10% 

The final sentence will read:

Oversaw a software upgrading campaign that resulted in a cost reduction of 10%. 

Your resume should also get straight to the point. 

“I want to be able to quickly glance at a resume and make sure they meet the criteria for the level of position I’m looking for and then if they do, I’ll read their resume more closely,” Melissa Wallace, Talent Acquisition Partner 

Because most tech jobs are results-oriented, provide context on how you have used the skill to achieve results. 

Use metrics to quantify your success. Using percentages is a great way to quantify your abilities. 

Some bullet points to quantify your results could be: 

  • Achieved X results in Y amount of time. 
  • Reduced costs by X amount using XYZ software. 
  • Ensured X customer queries were resolved using XYZ methods. 

You should also include details of your skill level. Are you a beginner or an expert? Mention this along with each skill. 

If you don’t, the recruiter may find your CV to be lacking and assume you do not have the correct qualifications. 

You also don’t want a resume that is too long, and tiresome to read. However, do not leave out important information; striking a balance is key. 

How Is a Tech Resume Different From Other Industries

All tech jobs require very specific skill sets and in addition, many companies are looking for a well-rounded individual. 

You need to have a section assigned where you can list your skills. Make a table and include it just after the experience section of your resume. 

Some of the major skills for the most popular tech jobs include: 

IT Technician

  • Front and back end development 
  • Cloud computing 
  • Network structure and security 

Software Engineer

  • Programming languages 
  • Databases 
  • Encryption and cryptography 

Web Developer

  • Website design 
  • Digital advertising 
  • Mobile and social marketing 

Data Analyst

  • Data analysis and exploration 
  • Creating dashboards and reports 
  • Statistical knowledge 

Data Scientist

  • Probability and statistics 
  • Multivariate calculus and linear algebra 
  • Programming packages and software 

Product Manager

  • User experience (UX) design 
  • Data understanding and analytics 
  • Product engineering 

A Winning Tech Resume Template

There are some major things that you must include in your tech resume. 

Some of these include;

  • Contact Information: Include your name, professional title, phone number, email, LinkedIn handle, and personal portfolio, blog, or website.
  • Career Summary: A short introduction that highlights your career progress and specific skill set. It should only be a few lines and encourage the employer to read the rest of your resume.
  • Experience Section: Up to six bullet points describing the roles and responsibilities of your previous jobs.
  • Education: List your schools and degrees achieved, as well as the corresponding years. Include honors and awards, and if you are fresh from school, you can add your GPA grade. Under this section, you can include certifications and professional memberships as well as achievements and awards.
  • Skills: Use our tips to create a skills section to grab the reader’s attention. Even if creating a tech resume, some skills are desirable across the board. Here are a few:

– Leadership

– Teamwork

– Research

– Analytical thinking

  • Optional Sections: If you have space, create a hobbies and interests section. It should reflect your personality and fit in with the company culture.

To stand out, show that you have enough business acumen to perform high-level jobs. You need to be able to manage teams of technicians and communicate with high-level management.

Studying a solid, certified MBA program is a great addition to your job-specific skills and will help you go up a level – especially in the eyes of the employer.

A free Quantic MBA has been developed by leading professors to create a comprehensive 9-course curriculum.

Once completed, the areas covered will earn you a DEAC accredited degree. Some of these include:

  • Accounting and finance
  • Data and decisions
  • Markets and economics
  • Marketing
  • Strategy development and entrepreneurship

Want to Get Hired in Tech?

Quantic’s students only have good things to say, but as a tech worker, you may have some doubts about delving into the business world.

You can rest easy and be sure you are making the right decision, just like Front-end Engineer, Robin Lu.

And that dream job, won’t just land on your lap. You will need to spend time and possible money getting your resume to the right recruiter.

As a Quantic student, you will be able to apply to exclusive positions in your chosen field. 

The Quantic Talent platform gives you access to recruiters who are looking for Software Engineers, Data Scientists, Product Managers, UX/UI Designers, and more at top tech companies.

Student Spotlight: Innovation to Bridge the Gap for Deaf and Hard-of-Hearing

MBA Student, Eva Michalkova, has obtained an Ivy League diploma, worked for a former US President, has been a contestant in multiple beauty pageants, and has been a world traveler since the age of six. But what is her life’s mission? Eva’s goal is to empower, lead and support the independence and integration of deaf and hard-of-hearing individuals into the hearing-dominant world. 

When Eva was two years old, she was taken to an audiologist for examination because she did not respond to sounds. The results confirmed her hearing impairment – 99% hearing loss in both ears. Her mom became her rock and inspiration for Eva’s innovative career path. “My mom has been a huge inspiration of mine since I was a small kid,” says Eva. “When my hearing impairment was discovered, she did not give in, and she devoted all her time and effort to my personal development and spoken language acquisition. My mom is a truly capable woman who worked hard in silence to bring out the best in me. She was a leader who has shown incredible resilience during the most challenging times, and her determination over so many years has inspired me to be a resilient, responsible, reliable, and hard-working person.”

A few years ago, a visit to her audiologist led her on a path that would inspire her next career move: “I was handed a pair of the most advanced hearing aids, wired to a computer. They were so small — if they fell out you could accidentally swallow them  and not even notice. Increasing music volume, turning on ‘zen mode,’ setting up a restaurant mode, or pairing them with my iPhone —  I became a superwoman. I left the office so excited; I was blessed to have had my ears upgraded. But I also realized that not all people with hearing impairment are fortunate to communicate with their physicians so seamlessly and have the same advantages as I did. Therefore, my fiance and I signed up for two hackathons to address this obstacle and create a solution. That’s when the No F-ears mobile app prototype was founded.” 

The app was instantly popular and cleverly named to convey the idea, “No ears, no fears.” Its main goal was to dramatically improve the most important aspects of the deaf-hearing community experience, including booking appointments and doctor visits. A live chat tool facilitates a real-time conversation between a hearing doctor and deaf patient, simultaneously translating text into spoken words and vice versa. Since its launch, it has won multiple awards, including two international startup prizes: the 2018 Social Innovation Weekend Hackathon Award and the 2019 Social Impact Award in the Czech Republic.

The hackathon weekends proved to be a pivotal time in Eva’s career. “Both events provided us with a unique opportunity to meet new people and broaden our horizons. Executing an idea requires dedication, persistence, money, and time — not just a marketing budget. To solve the problem you have to know it from top to bottom. Innovators usually rise to the top as a result of substantial life-long expertise in their field, not from problem-solving in a vacuum.” Eva realized the problem was much more significant than just the communication barrier. Her vision could go far beyond a single app, so she created MIRAIO

MIRAIO is the world’s first go-to platform for all people with any hearing loss, at any stage of their lives. Unlike traditional organizations in this industry that communicate with their customers mainly through newsletters and blogs, MIRAIO connects with its audience through social media support with closed captions. The platform guides the viewer through real-life scenarios to ensure a successful integration into a hearing world. 

The global company has become even more popular during the recent pandemic. “COVID-19 and its stay-at-home measures have sparked a massive change in how deaf and hard-of-hearing people access information and healthcare,” says Eva. “The existing institutions’ traditional processes don’t focus on younger customers’ needs, use twenty-first technology, social media, or other modern tools and technology. We are the leaders, the advocates who speak up, and help both the hearing and deaf world move forward. We challenge the deeply-rooted status quo of the deaf society and its identity, and change the narrative of how people with hearing impairment are perceived in the hearing world” 

With the creation of MIRAIO, Eva was inspired to pursue her MBA with Quantic to continue to expand her platform and inspire others to become advocates for her cause. She knew she would need a flexible program to optimally fit into her busy schedule. “To succeed in the fast-paced business world, I aspired to obtain the business skills I needed to accelerate my career. I was looking for a solution that would be flexible with my schedule so I didn’t have to choose between my job and education — with Quantic, I could do both!” 

Eva’s goal is to have the global community eventually reach a point where deaf individuals can seamlessly interact with the hearing world and be independent, with no need for sign-interpreters. “The first and most essential step is to acknowledge the importance of inclusion and awareness of the deaf and hard-of-hearing community. Equity, inclusion, diversity —  when “hearing peers” use these terms, there is often a lack of understanding in regards to what it means to be truly inclusive of the deaf community. There needs to be profound and consistent efforts to make our voices heard, so that we can enact real change in this world.”

Student Spotlight: A Deeper Meaning to Architectural Design

How would you define architecture? Steve Kredell, Principal Architect at McLeod Kredell Architects, has always believed that architecture is more than a simple building to shelter and protect its inhabitants. His innovative, sustainable and clean-lined designs have won countless awards. This year, he received global recognition when MKA was selected by Architectural Record as one of the top ten worldwide Design Vanguard firms.

Kredell’s passion for architecture started at a young age. His childhood walks with his father ignited his inspiration to look at the world differently. “He used to go out of his way to take me to look at what seemed to be very ordinary things,” says Kredell. “For instance, we looked at a lot of bridges when I was a kid. Through his eyes, I realized that there’s nothing “ordinary” or mundane about any human-made intervention. Those bridges weren’t just ways to get from one side to the other. They were beautiful in their own right, but, more importantly, they also enabled us to see the river, where we were going, and where we were coming from in a different way.  I believe this is what can be wonderful about buildings. They can help us see the environment and the world in a different way.” 

Photo courtesy McLeod Kredell Architects

This passion continued to grow and Kredell began collaborating with John McLeod, in the mid-90s, after meeting in graduate architecture school at Virginia Tech. The two created McLeod Kredell Architects, which is now built around the practice, teaching and community engagement of architecture. They believe, “Architecture grows out of its particular place and time–yet at its best it also transcends those limits. In the end, architecture should be inspiring–for the client, the architect, the builder, the passerby.”

This belief especially rings true now that the majority of people are spending more time at home than ever before. “We all need to ask more from our buildings – especially given the amount of time we spend indoors by ourselves now,” says Kredell. “We need to look at how buildings can be regenerative and how they can contribute to not just serving a need to house and protect us, but as part of a global environmental solution. But, we cannot lose sight of the fact that our buildings aren’t merely machines.  As our lives become dominated by screens and images, architecture has to continue to serve as a means to be connected to the natural world.” 

Connecting to the natural world has been a big initiative for MKA. The two architects bring a team of Middlebury College students to Penobscot Bay, Maine, for a weeklong design-build class each summer that results in such useful community projects like composting stations. It also has an ongoing partnership with Habitat for Humanity of Addison County and Middlebury College, where McLeod teaches, to design and build houses in the county for those in need.

“We believe that anyone and anywhere deserves design,” says Kredell. “We believe in spreading the wealth of architecture through teaching, working with private clients, partnering with communities, and building alongside students and volunteers. Good design should be for everyone. That’s a trend that I sincerely believe has to continue.” 

It was this passion for volunteering that actually led Kredell to pursue his MBA with Quantic. “My business partner and I started a non-profit program that brought community based designs to places and projects that typically wouldn’t have access to design. This opened my eyes to help me understand that we weren’t being as creative with the “design” of this new venture because we didn’t have an understanding of the nuances of a new business. I believed that Quantic’s MBA would allow me to be more creative and, really, to have a new experience and more well-rounded world view.”

As the world continues to change, so does the future and importance of architectural design. “We need to realize that architecture at its best allows us to touch the world in so many different ways. Just like those original bridges, architecture allows us to understand our world and nature in a more meaningful way. I think that’s more important than ever.” 

The Quantic community has no doubt that McLeod Kredell Architects will continue to push architectural boundaries and their designs will continue to inspire others to look at the world in a different light.

Student Spotlight: Chief Scientist Helps Broaden Biotechnology Field

Bit Bio, the U.K.-based startup, only needed three weeks to raise $41.5 million in a Series A funding round that will be used to support the company’s goal to transition biology into engineering. 

This synthetic biology team was founded by stem cell biologist and neurosurgeon, Mark Kotter, in 2016 to commercialize biotechnology that can reduce the cost and increase the production capacity for differentiated human cells. These cells can be used in targeted therapies and as a method to accelerate pharmaceutical drug discovery. Bit Bio’s goal is to be able to reproduce every human cell type, boosting basic research and enabling a new generation of cell therapies.

How can this type of cell therapy specifically help? By generating every cell type in the human body, this biotechnology will help unlock solutions for tackling cancer, autoimmune diseases and neurodegenerative disorders. Bit Bio’s approach will also help reduce expenses, aid drug discovery, and decrease the reliance on animal studies. 

Quantic alum, Grant Belgard, is the Head of Bioinformatics at Bit Bio. The company’s website explains the centrality of computation: “Bit Bio represents the two fields: coding and biology that determine the identity of every human cell. Ultimately, bits are the building blocks of code, just as cells are the building blocks of life. This is reflective of what Bit Bio does: precise reprogramming of human stem cells.” 

Belgard is also the Chief Scientist and CEO of The Bioinformatics CRO. The company was developed as the subject of his Capstone project in Quantic’s Executive MBA program. The flexibility of the curriculum enabled Belgard to learn, while simultaneously building his new company and pursuing his professional goals.

Now, Belgard’s goal for The Bioinformatics CRO is to streamline biomedical research worldwide. This represents a new breed of contract research organization that offers quality customized bioinformatics services to global biotechnology companies.

Biotechnology companies, like Bit Bio and The Bioinformatics CRO, will help merge biology and engineering and can help bring about long-awaited precision for stem cell research and help improve the lives of millions.

The Quantic community is thrilled for Grant and his colleagues. We can’t wait to see what he does next and how this combination of data science and biology will help code cells for the well-being of humanity.

Blankets: Not Just for Snuggling

When we think of blankets, we often think of cozy nights and hot chocolate. But what if they had the power to change the course of healthcare technology, especially during the coronavirus pandemic? Executive MBA student, Olivia Lin, had this exact same thought. She wanted to combine her strong tech background and desire to create textiles with a purpose. Olivia and fellow EMBA student, Edward Shim, soon launched their start-up, Studio 1 Labs, specializing in cutting-edge textile technology. 

Their first product? A “smart” bed sheet that can be used in hospitals to monitor patients’ vitals. This has been crucial during the COVID-19 crisis because it continuously monitors for respiratory distress. The bed sheet detects respiratory patterns and transmits the data to a computer terminal for healthcare workers. With advanced data accuracy and analytics, this technology can also predict the onset of health decline and emergencies like apnea, heart attack and stroke.

Olivia is originally from Taipei, Taiwan and grew up in Canada. She studied psychology at the University of Toronto, and earned a Master’s and later a Ph.D. in cognitive psychology from the University of Waterloo. While studying psychology, Olivia was drawn to subject matter known as Human Factors, a field focused on the application of psychology in society.

When asked how and why she made the transition from psychology to starting a textile tech company, Olivia laughed — the transition even surprised her. She had a friend who worked in textile technology and saw how she combined fabric, art, and modern technology to create clothing with a purpose. This sparked Olivia’s interest and curiosity and she asked for her friend’s help in learning how to sew fabrics infused with tech. 

While completing her Ph.D., Olivia met Edward, and her hobby soon turned into a business idea as the two began researching the commercialization of fabric sensor technology. They had identified a growing trend in healthcare of using everyday objects as tools for monitoring vitals and felt that textiles might just be the perfect canvas for such a device. This kind of application had particular relevance to Edward, who, when serving in the military, sustained an injury which left him experiencing respiratory issues. He was well aware of the processes in place for patients to have their breathing monitored and knew there had to be a better way. Both he and Olivia saw a need for improvement in this space and after enlisting the help of a few more colleagues, Studio 1 Labs was born.

“There was a lot of exploration and experimentation and finally we found an application that really works,” said Olivia.

Studio 1 Labs’ fabric sensor bed sheets are a glimpse at the future of health technology. These sensors monitor a patient’s respiration pattern, location, movement, and prolonged pressure. The patient does little more than lie in bed and his or her vitals are measured and reported. This is especially important for elderly patients, who are less able to adjust their lives for doctors to gather the data they need to make an informed diagnosis and treatment plan.

Beyond product development, Olivia had also recognized the need to increase her knowledge of business and strategy. This is when she decided to pursue an Executive MBA. With Studio 1 Labs having locations in both Canada and Taiwan, Olivia was constantly traveling and Quantic’s mobile-first design enabled her to learn no matter where she was. 

“Being an entrepreneur, I felt like I had gaps in my knowledge and I couldn’t keep pace in conversations with executives and potential partners to the degree I needed to. I wanted more of the knowledge that would enable me to carry on and lead these conversations.” said Olivia.

Olivia’s impressive efforts in creating this business have not gone unrecognized. She was featured by Girls in Tech Taiwan 40 Under 40 and Studio 1 Labs won the Markham Board of Trade Aspire Startup Award in 2018. Outside of being the Executive Director of Studio 1 Labs, Olivia was a mentor for the City of Waterloo’s initiative, Girls in STEAM, a program that promoted tech and other STEAM careers to local girls to spark their interest at a young age. Olivia now lives in Taiwan, as she continues her rewarding (and challenging) entrepreneurial journey and helps to continue to #ChangeTheCourse of healthcare technology. 

Git Bisect Debugging with Feature Branches

Inspectocat, courtsey of GitHub
Inspectocat, courtesy of GitHub

At Pedago, we follow the GitHub Flow model of software development. Changes to our app are made in feature branches, which are discussed, tested, code reviewed, and merged into master before deploying to staging and production. This approach has become pretty common, and in most cases does a good job of balancing our desire to ship quickly with the need to control code quality.

But, what happens when a bug inevitably creeps in, and you need to determine when it was introduced? This article describes how to apply git bisect in the presence of numerous feature branches to quickly detect when things went awry in your codebase.

Enter Git Bisect

git bisect is tool for automatically finding where in your source history a bug was introduced. It saves you the pain of manually checking out each revision yourself and keeping a scratchpad for which ones were good and bad.

Here’s how you get started:

# start up git bisect with a bad and good revision
git bisect start BAD_REVISION GOOD_REVISION

At this point, git is going to start checking out each revision and asking you if the commit is good or bad. You tell git this information by typing git bisect good or git bisect bad. Git then uses binary search (bisecting the history) to quickly find the errant commit.

You can also further automate things by giving git a script to execute against each revision with git bisect run. This allows git to take over the entire debugging process, flagging revisions as good or bad based on the exit code of the script. More on this below!

Example

Imagine you go back to work from a vacation and discover that the Rails specs are running much more slowly than you remember before you left. You know that the tests were fast at revision 75369f4a4c026772242368d870872562a3b693cb, your last commit before leaving the office.

Being a master of git, you reach for git bisect. You type:

git bisect start master 75369f4a4c026772242368d870872562a3b693cb

…and then for each revision git bisect gives you, you manually run rake spec with a stopwatch. If it’s too slow, you type git bisect bad, and if it’s fast you type git bisect good.

That’s kind of monotonous, though, and didn’t we mention something about automating things with a script above? Let’s do that.

Here’s a script that returns a non-zero error code if rake spec takes longer than 90 seconds:

#!/bin/bash

start=`date +%s`
rake spec
end=`date +%s`

runtime=$((end-start))


if [ "$runtime" -gt 90 ]
then
    echo TOO SLOW
    exit 1
fi

echo FAST ENOUGH
exit 0

Let’s say you save this script to /tmp/timeit.sh. You could use that instead of your stopwatch and keep manually marking commits as good and bad, but let’s go further and have git bisect do the marking for us:

git bisect run /tmp/timeit.sh

Now we’re talking! After waiting for a bit, git tells us that the errant revision is:

31c60257c790e5ab005d51d703bf4211f43b6539 is the first bad commit
commit 31c60257c790e5ab005d51d703bf4211f43b6539
Author: John Smith john@example.com
Date: Wed Jan 21 12:02:38 2015 -0500
   removing defunct jasmine-hacks.js
:040000 040000 94ff367b586ec62bacb3438e0bc36ae62f90da22 bd3b447e7fc8ce782a7a4c01d11d97383bf06309 M karma
bisect run success

OK, so that sounds good. But wait, that’s a commit that only affected javascript unit tests! How could that have caused a problem with the Ruby specs?

Damn You, Feature Branches

The problem is that git bisect is not confining itself to only the merge commits in master. When it narrows down the point in time when things got slow, it isn’t taking into account the fact that most revisions are confined to our feature branches and should be ignored when searching the history of changes to master.

What we really want is to only test the commits that were done directly in master, such as feature branch merges, and the various one-off changes we commit directly from time to time.

git rev-list

Here’s a new strategy: using some git rev-list magic, we’ll find the commits that only exist in feature branches and preemptively instruct git bisect to skip them:

for rev in $(git rev-list 75369f4a4c026772242368d870872562a3b693cb..master --merges --first-parent); do
  git rev-list $rev^2 --not $rev^
done | xargs git bisect skip

In short, the above chunk of bash script:

  1. Gets all revisions between the known-good revision and master, filtering only those that are merges and following only the first parent commit, and then for each commit
  2. Gets the list of revisions that only exist within the merged branch, and then
  3. Feeds these branch-only revisions to git bisect skip.

Pulling It Together

Here’s the complete list of commands we’re going to run:

$ git bisect start master 75369f4a4c026772242368d870872562a3b693cb

$ for rev in $(git rev-list 75369f4a4c026772242368d870872562a3b693cb..master --merges --first-parent); do
>   git rev-list $rev^2 --not $rev^
> done | xargs git bisect skip

$ git bisect run /tmp/timeit.sh

This runs for a while, and completes with the following chunk of output:

Bisecting: 14 revisions left to test after this (roughly 4 steps)
[086e45] Merged in update_rails_4_2 (pull request #903)
running /tmp/timeit.sh
....................................................................
....................................................................
....................................................................
....................................................................
....................................................................
....................................................................
....................................................................
....................................................................
....................................................................
....................................................................
....................................
Finished in 1 minute 21.79 seconds (files took 6.63 seconds to load)
719 examples, 0 failures
Randomized with seed 54869

TOO SLOW

There are only 'skip'ped commits left to test.
The first bad commit could be any of:
342f9c65434bdeead74c25a038c5364512d6b67e
9b5395a9e1c225f8460f8dbb4922f52f9f1f5f1d
dcb1063e60dbcb352e9b284ace7c83e15faa93df
027ec5e59ca4c380adbd352b6e0b629e7b407270
1587aea093dffaac2cd655b3352f8739d7d482dc
2ff4dee35fd68b744f8f2fcd5451e05cb52bff87
73773eae4f6d283c3487d0a5aea0a605e25a8d3f
1cf615c6fa69e103aea3761feaf87e52f1565335
26d43d2060880cb2dbe07932fe4d073e3ccb7d44
293190779e33e26b9ceabfcff48021507591e9d1
77d504ee4b52b0869a543670cd9eb2fb42613301
3f25514f793e87549c9d64ddcfe87f580b29f37e
d43d1845b9fd6983ff323145f8e820e3aea52ebd
32a9e3c879546d202c27e85ab847ca9325977d5c
ea3e3760fb06e3141e5d12f054c1153e55b5cc67
9665813264a5e0d7489c43db871b87e319143220
b8f5106a8901d56621e72ba6b8bd44d4d5471dd2
086e45a2c0a2ed2cd26eeb48960c60048af87d0a
We cannot bisect more!
bisect run cannot continue any more

Hooray! We’ve found our offending commit: Merged in update_rails_4_2 (pull request #903). That makes sense—we upgraded RSpec and made a bunch of testing-related changes in that branch.

Furthermore, we see a list of skipped commits that git bisect didn’t test. This also makes sense—those commits are all within the update_rails_4_2 branch.

Conclusion

With a bit of git magic and some scripting, we’ve completely automated what could have been a very tedious exercise. Furthermore, thanks to the judicious use of git rev-list and git bisect skip, we’ve been able to cajole git into giving an answer that takes our branching strategy into account. Happy hacking!

Fixturies: The speed of fixtures and the maintainability of factories

 

We had a rails app. We used factories in our tests, and it took ten minutes to run them all.  That was too slow. (spoiler alert: by the end of this blog post, they will run in one minute.)

We suspected that we could speed up the test run time by using fixtures instead, but worried that fixtures would be much more difficult to maintain than our factories.

As it happens, we are not the first developers to deal with the issue that factories are slow and fixtures are hard to maintain.  I cannot explain the issue any better than the following folks do, so I’ll just give you some quotes:

“In a large system, calling one factory may silently create many associated records, which accumulates to make the whole test suite slow …”

“Maintaining fixtures of more complex records can be tedious. I recall working on an app where there was a record with dozens of attributes. Whenever a column would be added or changed in the schema, all fixtures needed to be changed by hand. Of course I only recalled this after a few test failures.”

“Factories can be used to create database records anywhere in your test suite. This makes them pretty flexible and allows you to keep your test data local to your tests. The drawback is that it makes them almost impossible to speed up in any significant way.”

In our case, 99% of our tests were using identical records.  For example, we were calling FactoryGirl.create(:user) hundreds of times, and every time, it was creating the exact same user.  That seemed silly.  It was great to use the factory, because it ensured that the user would always be up-to-date with the current state of our code and our database, but there was no reason for us to use it over and over in one test run.

So we wrote the gem fixturies to solve the problem this way:  Each time we run tests, just once at the beginning, we execute a bunch of factories to create many records in the database.  The fixturies gem then dumps the state of the database to fixtures files, and our tests run blazingly fast using those fixtures.

We saw a 10x improvement in run times, from ten minutes down to one.  We still use factories here and there in our tests when we need a record with specific attributes or when we want to clear out a whole table and see how something behaves with a certain set of records in the database.  But in the vast majority of cases, the general records set up in that single run at the beginning are good enough.

If you are using factories in your tests to re-create the same records over and over again, and your tests are running too slowly, give fixturies a try and let us know how it goes.  It only took us about half a day to refactor 700 tests to use fixturies instead of traditional factories, so there is a good chance it will be worth your time.

text-transform: An Unlikely Source of Jank

Here at Pedago, we take a hard look at the performance of our applications so that our users don’t have to experience any troublesome hiccups (or “jank”) that might otherwise sour a sweet learning experience.

While “performance” can cover a wide array of metrics, we tend to be extremely critical of browser overhead (script execution, rendering layout, and painting). While others have covered optimization of these metrics in great detail, we came across an unlikely jank-vector that we thought was worth mentioning.

When analyzing CSS performance in relation to browser lifecycle, there are a few notorious styles (eg: border-radius, box-shadow, transform, backface-visibility, etc) that tend to slow down frame rate. Some of these are obvious as they dramatically influence the rendering process or add additional calculations for stylistic ooomph. One might be extremely likely to overlook the rather mundane text-transform while focusing on that list, though.

We had several elements each containing a finite number of additional elements that all were performing CSS-dictated uppercasing on their text content. Now, this might not be a significantly intensive operation in itself, but combined with some excessively spastic scrolling, it degraded the user experience somewhat significantly. After we updated the content to be rendered in uppercase without the need for CSS text transformation, the improvement was obvious.

Here’s how things looked on a common mobile platform, prior to the change (FPS is the key metric, with 60FPS as an ideal target):

with CSS text transform

As you can see, we were barely hitting the 30FPS threshold and often even missing that window. Here’s what we observed after we removed the relevant text-transform styles:

no CSS text transform

As you can see, we’re now closer to consistently hitting that golden 60FPS benchmark! Granted, we were probably abusing a CSS style that was intended for narrower application, and the DOM of this particular page meant that there were a lot of them, so your mileage may certainly vary. However, this might help serve others in the war against jank!

How do I read the AngularJS message: [$rootScope:infdig] 10 $digest() iterations reached. Aborting! Watchers fired in the last 5 iterations

I’ve been using Angular every day for over a year, but have always been too intimidated by this error message—and the crazy list of information that comes along with it—to really dig into it and find out how to use it to my advantage.

Building a new product at Pedago, I see this error happen from time to time in production (possibly related to a user using an old browser), but never when developing locally. So I have the error message from our error logs, but I can’t reproduce it or debug it by making changes in the code.

After researching the issue, here’s what I found out on my own.

After the colon there are two brackets. (…’atchers fired in the last 5 iterations: [[{“msg’) The first bracket is the beginning of a json block. Copy from the first bracket to the end of the error and find a way to pretty-print that json. (Use your favorite code editor or an online json formatter.)

Now you have a pretty-printed array with 5 entries in it. Each entry represents an iteration in the digest cycle, i.e. one pass through all of the active watchers in your app, looking for changes. Angular will repeat iterations until it does one in which no watcher has a changed value, or until it hits 10 iterations, at which point it will error. That’s what happened in this case.

There were 10 iterations before the error, and 5 are included in the error message. Presumably that means there are 5 more iterations that happened earlier than what is included in the error message. The first entry in the error message is the 6th iteration, and the last entry in the message is the 10th iteration.

The entry for each iteration is also an array. In this case it is an array of objects, and each object represents a watcher whose value changed during this iteration. Each object will give you the text or the function that defines the watcher, the old value for the watcher before this iteration and the new value after this iteration.

Read it from top to bottom like a story, adding commentary based on what you know about your app. In my case, I was able to see how the changes in each iteration caused new watchers to be created, requiring yet another iteration. “In the 6th iteration, this watcher changed, causing this new stuff to be rendered on the page, creating new watchers which were assigned values in the 7th iteration, and then …” There was no infinite loop or anything. In fact, if Angular had been willing to do just 1 or 2 more iterations, it would have finished.

I hope this is helpful to anyone else experiencing this issue.

Five key principles that make geographically split software teams work

Geographically distributed teams can work. How? In my experience, there are five key principles that make all the difference.

The other day, I realized that I have worked on geographically split software teams for the last decade. I didn’t set out intending to do so. When I got my first job out of college as a software engineer, I thought being in the office was non-negotiable. If you ask company recruiters, most say in no uncertain terms they are not looking for remote employees.

But the reality on the ground is that many software companies end up letting most full-time engineers work flexible hours, from anywhere. Yet few companies acknowledge or advertise this explicitly. You can’t get this opportunity by asking for it in your interview, but after you are in the door, the opportunity arises. There are a few ways this happens.

Software companies with heavy on-call burdens, like Amazon for example, end up with an unspoken but widespread assumption that people can work from anywhere because they are working all the time. Since most engineers are contractually obligated to be on-call, and emergency issues arise at all hours of the day and night, these engineers start working remotely out of necessity. Soon, whole teams realize there is no barrier to working where and when they are most productive. On any given day during my tenure at Amazon, maybe half of my teammates weren’t in the office when I was.

 I’ve worked for several startups with surprisingly similar team environments. At one, people preferred to work at nearby coffeehouses with outdoor porches that made it easier to work while smoking. At another, unreliable wireless bandwidth in the office drove people to work from home out of necessity. At another, almost every person employed there lived in a different time zone, because this startup needed a very specific set of skills that happened to be scarce at the time.

Later I went to work for Rosetta Stone, which had three offices when I started, and grew to six offices when I left . Most of the teams I worked on ended up having people in at least three office locations, and as many time zones. Only one of the four bosses I had during those years worked in the same office as me. Not only were the teams geographically split, but once a team is split across two or more time zones, for all practical purposes, this team is also working flex time hours.

 These teams all worked well together. No matter where and when we worked, everyone still was accountable for meetings and deadlines. I never felt particularly disconnected from my team, and I had rapport with and support from my bosses.

Today I work for Pedago.com, a startup company that is geographically split and has been from the very beginning. It is the most productive team I have ever worked with.

Geographically distributed teams can work. How? In my experience, there are five key principles that make all the difference.

1. Shared chat room where all team communication, questions, updates, and banter happen

I’ve used Skype, IRC, and HipChat for this — there are many viable options. In a geographically split team, showing up to the chat room is the same as showing up to work. Conversely, not showing up to chat is like not showing up to the office, with the same professional and social side effects. Knowing everyone will be in one place means you always know where you can ask questions if you have them. And if you are ever away and need to catch up on team discussion, there’s a nice transcript of all the debates, conversations, and decisions the team made while you were away that you can easily read to catch up.

2. Shared “online” hours

These are the hours everyone is guaranteed to be available in the shared chat room. No matter how scattered the team is, there will always be some set of hours that work for everyone. Everyone is assumed to be available during these hours, and if any person can’t make it or needs to leave to run errands, they are expected to notify everyone.

3. Short daily video check-in meetings

If your team uses Scrum as its project management strategy, these are just your daily standup meetings. It makes a huge difference to see peoples’ faces once a day, if only to remember that they are human beings in addition to being demanding product owners or cantankerous engineers. The visual feedback you get from face to face conversations helps facilitate complex discussions, amplifies positive feedback, and the subconscious pressure to announce a socially acceptable level of progress helps hold everyone accountable.

4. Teammates need to be aggressive about helping and asking for help.

However tempting, no one should ever spin their wheels when stuck. Teams should declare that ad hoc pair programming, calls, and hangouts are a part of their team’s working style, and developers should be aggressive about picking up the phone or screen-sharing whenever they get stuck or need to ask a question.

5. Everyone on the team needs to buy into these rules.

No exceptions. If even one person refuses to get in the shared team chat-room or doesn’t feel like showing up to the video check-in meetings every day, these strategies won’t work for the rest of the team. Everyone on the team has to buy in, and in particular, managers and team leads need to lead by example, being disciplined about leading discussions and disseminating information only in the team’s shared forums.

But how do you know people are working if you can’t see them?

Simple answer. The same way you know they’re working when you can see them: you talk to them about requirements, check in on progress, look at what they deliver. If you are a technical manager, you monitor deployments or skim the latest check-ins. Software management really isn’t very different with distributed versus in-house teams. The secret to success is still the same: clear direction, well-defined, prioritized requirements, and carefully managed execution.