Tech Roots » Jeff Lord http://blogs.ancestry.com/techroots Ancestry.com Tech Roots Blogs Mon, 14 Apr 2014 16:49:18 +0000 en-US hourly 1 http://wordpress.org/?v=3.5.2 All Work and Some Playhttp://blogs.ancestry.com/techroots/all-workd-and-some-play/ http://blogs.ancestry.com/techroots/all-workd-and-some-play/#comments Wed, 19 Mar 2014 17:38:15 +0000 Jeff Lord http://blogs.ancestry.com/techroots/?p=1686 When I joined Ancestry.com, we were a small start-up of a few hundred employees in some cramped offices behind the post office in Orem, Utah. Now almost 15 years later, we’re an international organization of more than 1,400 employees with offices around the world. Yet despite our growth, Ancestry.com has continued to provide employees with… Read more

The post All Work and Some Play appeared first on Tech Roots.

]]>
When I joined Ancestry.com, we were a small start-up of a few hundred employees in some cramped offices behind the post office in Orem, Utah. Now almost 15 years later, we’re an international organization of more than 1,400 employees with offices around the world. Yet despite our growth, Ancestry.com has continued to provide employees with a close knit work environment that makes you feel like you’re part of a family and not just another employee.

One way Ancestry.com shows it’s appreciation for all of our hard work is with a monthly morale budget, which our front-end development (FED) team has used to do some pretty interesting team building activities over the years. We started off just going to lunch together as a team, then slowly branched out to the occasional movie. Over time, we’ve started pushing the envelope and found some pretty interesting ways to spend our monthly morale budget.
FEDbowl
Some of our more memorable morale activities have included indoor rock climbing, frisbee golf, Nickelcade, family BBQ, bowling, and even archery. Simply doing these activities eventually wasn’t enough, so our intern now doubles as our audio/video specialist and documents all the fun we’re having:

The post All Work and Some Play appeared first on Tech Roots.

]]>
http://blogs.ancestry.com/techroots/all-workd-and-some-play/feed/ 0
Why Have a Browser Support Policy?http://blogs.ancestry.com/techroots/browser-support-policy/ http://blogs.ancestry.com/techroots/browser-support-policy/#comments Mon, 06 Jan 2014 21:21:44 +0000 Jeff Lord http://blogs.ancestry.com/techroots/?p=1649 With the growing number of web browsers and mobile devices being used to access content on the internet, it has become increasingly important for organizations to solidify a browser/device support policy. Internally, this type of policy can help with the development and testing of new features and pages by focusing time, effort, and resources on… Read more

The post Why Have a Browser Support Policy? appeared first on Tech Roots.

]]>
With the growing number of web browsers and mobile devices being used to access content on the internet, it has become increasingly important for organizations to solidify a browser/device support policy. Internally, this type of policy can help with the development and testing of new features and pages by focusing time, effort, and resources on a select set of browsers and devices. Externally, users will have a clear understanding of expected functionality and the adjustments they can make to ensure the best experience possible when using the site.

With approximately 2.7 million subscribers and hundreds of thousands of unique visitors a day all using their preferred browsers and devices to access our site, Ancestry needed to define where our teams should focus and prioritize their time. To accomplish this, a committee of development, product, and QA representatives was organized and tasked to develop a browser support policy that accurately reflected the latest industry standards, as well as our particular users’ preferences.

As a result, the following tier system is based not only on the latest global web browser and mobile device usage statistics, but also specific analytics and percentages for our own unique users.

 

browser

Tier 1 – Both Functionality and Visual Design
Browsers accounting for at least 10% or more of unique visitors for two consecutive months will be fully supported. This includes basic functionality as well as proper visual design behavior. These browsers will be tested during regular regression and when pages are changed. All bugs will also be triaged and fixed in the indicated timeframe. Browsers in this category will continue to be fully supported until they account for less than 10% of visitors for two consecutive months. Those browsers will then receive Tier 2 support (until/unless their usage drops below 5% for two consecutive months).

Tier 2 – Functionality
Browsers accounting for 5-10% of unique visitors will receive Tier 2 support. This means visual elements on the site need not appear perfectly, but all features must be functional. Basic testing is required, and major bugs will be triaged and fixed in the indicated timeframe. A browser whose traffic falls below 5% for two consecutive months will receive Tier 3 support.

Tier 3 – No Support
Browsers accounting for less than 5% of unique visitors in two consecutive months will not be individually supported. This group will be separated into two groups: uncommon browsers, and out of date browsers. Since the majority of uncommon browsers tend to follow web standards, they will generally receive an adequate experience on Ancestry.com and therefore shouldn’t be prompted to download a supported browser. Visitors using out of date browsers who can upgrade to a supported browser, however, should be prompted to do so.

As for mobile devices, we have designed a majority of our pages to be responsive to the width of the browser. Pages that have been converted receive Tier 1 support, with all other pages receiving Tier 2 support.

The hope is that with this policy in place, it will save time and effort internally, while providing customers and users with the best experience possible on the browsers and devices they use the most.

The post Why Have a Browser Support Policy? appeared first on Tech Roots.

]]>
http://blogs.ancestry.com/techroots/browser-support-policy/feed/ 0
Hiring: First Test Then Assesshttp://blogs.ancestry.com/techroots/test-then-assess/ http://blogs.ancestry.com/techroots/test-then-assess/#comments Thu, 25 Jul 2013 19:50:54 +0000 Jeff Lord http://blogs.ancestry.com/techroots/?p=927 Hiring awesome people who are also talented developers is often times easier said than done. Having grown tired of sifting through endless resumes and conducting countless mind numbing interviews with unqualified applicants, our team has uncovered the filtering power of a FED (front-end development) specific assessment test. While some like to schedule time during the… Read more

The post Hiring: First Test Then Assess appeared first on Tech Roots.

]]>
Hiring awesome people who are also talented developers is often times easier said than done. Having grown tired of sifting through endless resumes and conducting countless mind numbing interviews with unqualified applicants, our team has uncovered the filtering power of a FED (front-end development) specific assessment test. While some like to schedule time during the onsite interview to complete coding tests, it’s worked best for us to email our assessment to potential candidates and allow them to complete and return it on their own time frame before scheduling an interview. This helps avoid wasting everyone’s time by bringing in people who aren’t qualified to handle the technical requirements of the position.

Our assessment test provides candidates with a layered .PSD (PhotoShop) file, as well as a simple list of requirements to consider:

  • Pixel-perfect quality level (Mac and Windows)
  • All text to be real text
  • Optimize page and improve performance where possible
  • No inline styles unless absolutely necessary
  • All containers must be vertically expandable
  • Cross browser compatibility
  • Utilize latest technologies (CSS3, HTML5, responsive design, etc.)

pixel_perfect

An experienced developer should be able to code the page in a few hours, which is enough of a time commitment to filter out those that aren’t truly interested in the job. The page also contains a wide variety of front-end challenges including a modal overlay, a form, multiple images, customized buttons, unordered lists, and overlapping elements. We can compare the code structure, CSS styling, and choice of JavaScript frameworks used in meeting the assessment’s requirements, which allows us to evaluate each candidate on a level playing field prior to scheduling an interview. We can also look at how they optimized their code to consider performance, requests, and load time of the page.

Our team reviews the tests and gives each assessment an overall rating from 1 to 10, with candidates scoring a 7 or better being considered worthy of an interview. That way, we’re only meeting with the best of the best and can more easily make a decision on who would be the best fit for the position and team. In addition, the assessment serves as a talking point during the interview, allowing the candidates to walk us through their thought process and providing us a chance to ask questions and give feedback about the coding choices they made.

In the end, when candidates are given a coding test comes down to personal preference and what works best for you and your team. Some might prefer to meet candidates first, then assess their technical skills to see if they can do the job. For our team, finding out whether they can do the job before ever meeting them in person has proven successful and allowed us to assemble a talented group of 18 front-end developers in just a few short years. If you’re interested in potentially being one of them, check out all of our current job openings at Ancestry.

The post Hiring: First Test Then Assess appeared first on Tech Roots.

]]>
http://blogs.ancestry.com/techroots/test-then-assess/feed/ 0
Creating Consistent Coding Standardshttp://blogs.ancestry.com/techroots/consistent-coding-standards/ http://blogs.ancestry.com/techroots/consistent-coding-standards/#comments Tue, 07 May 2013 17:25:23 +0000 Jeff Lord http://blogs.ancestry.com/techroots/?p=546 One of the key initiatives that our front-end development (FED) team has been tasked with at Ancestry.com is to help define, develop, document, implement, and enforce a global set of CSS/HTML standards for the organization. The fact that our team is in the business of creating standards (laws) and working to enforce (govern) them makes… Read more

The post Creating Consistent Coding Standards appeared first on Tech Roots.

]]>
One of the key initiatives that our front-end development (FED) team has been tasked with at Ancestry.com is to help define, develop, document, implement, and enforce a global set of CSS/HTML standards for the organization. The fact that our team is in the business of creating standards (laws) and working to enforce (govern) them makes calling ourselves “the FEDs” even more appropriate.

While there are obvious high level standards and best practices defined by W3C, there are a multitude of techniques that can be used to achieve similar results when coding web pages. Those differences have been the source of some lively, heated debates (and one near fistfight) among the FEDs on our team as we’ve tried to come to a general consensus on what should be considered a site-wide global standard. Just a small sampling of the topics that have been discussed by email and argued about over cubicle walls include:

  • Single vs. multi-line CSS properties
  • Alphabetical vs. grouped declaration order
  • Spacing after brackets, commas, colons, and selectors
  • Naming conventions (camel case vs. hyphens vs. underscores)
  • Lowercase vs. uppercase
  • Tables vs. divs for tabular data
  • Etc. etc.

In an effort to resolve our differences, we turned to the most knowledgeable and complete source of information known to man … Google. After tirelessly researching and scouring endless blogs and articles to defend the use of a preferred coding style, it became increasingly apparent that for every argument in favor of a particular technique there was an equally convincing case against its use. The only thing industry experts seem to agree on is that there’s disagreement when it comes to which coding style is best. Much like selecting a preferred browser, it’s difficult to convince a Firefox user that Chrome is the better choice since they both essentially do the same thing with subtle differences.

While we’ve had to agree to disagree on several of these topics, the biggest takeaway from our research is the importance of consistency. Even WordPress has documented its own defined set of coding standards it expects contributors to follow in order to maintain consistency. When a comment was made asking why they recommended avoiding the use of underscores, the simple reply was, “Because that’s our particular style.” What we have chosen for our standards at Ancestry.com might be different from what WordPress decided to go with, but that doesn’t necessarily make us right and them wrong as long as we’re both pushing for consistency.

Long story short, being consistent is more important than whether you use camel casing instead of hyphens or choose single lines over multi-lines in your style sheets. Having a consistent coding style based on your particular preferences will generate cleaner code that’s easier to read, use, and maintain going forward.

The post Creating Consistent Coding Standards appeared first on Tech Roots.

]]>
http://blogs.ancestry.com/techroots/consistent-coding-standards/feed/ 0