Gallery
Amply Dev Library
Share
Explore

icon picker
Core Standards

Listed below are the core guiding standards that we expect from all of our developers. If you want to improve as a developer, continuously evaluate how you are doing at following these standards.

1. Communication

When working on a project, it’s always better to over communicate than under communicate. Here’s some examples of great communication:
Asking the Dev Lead or others involved in the project if you have questions
Sending a Loom video if it’s easier to explain
Leaving detailed comments/questions on Figma files
Providing instructions beneath CMS collection fields
Give the Amply team daily updates on your overall progress on the project
When at a crossroads in a project, send a message outlining the pros and cons of your possible decisions (i.e. building an animated section that could be built multiple ways)

2. Quality

We pride ourselves in building extremely high quality websites that meet the best practices across the web. We expect our developers to go above and beyond to make sure every component is completely responsive, optimized for site speed, and meets web best practice.
Quality Is More Important Than Speed
We find that a lot of developers have a tendency to try to build as fast as they can, which is a good trait, but often leads to mistakes and a lack of quality. This can be shown in the difference between 2 developers:
Developer A - Builds a Page in 1 hour, but page requires 10-15 edits after it is reviewed.
Developer B - Builds a Page in 2 hours, and the page requires only 1-2 edits after it is reviewed.
Some may say that Developer A is the better developer, as the mistakes may only take 15-20 minutes to fix. However, we prefer Developer B every single time over Developer A. The reason for this is because Developer A requires others to spend more time on the project. It takes more time for those reviewing to leave detailed remarks, sometimes videos explaining how something should be fixed. Then there is a delay between when the edit is requested and when it is fixed by the developer, which can lead to delays in the project itself.
Develop With The End User In Mind
We look for developers who are problem solvers, and can think through difficult problems on their own. We aren’t looking for developers who can only copy a Figma file robotically. As a developer, you have the opportunity to work closer to the final product than just about anyone else. This means that you may catch things in a design that might not have the best user experience, for various reasons. If you notice problems like this, or things that could be better, we encourage you to reach out to the Dev Lead, or Design team to discuss your suggestions.
QA Your Own Work First
As a developer, you should do your own Quality Assurance before handing a page off to anyone else. While we will have a formal review sheet that you can review yourself before you handoff a page off for someone else in the future, the following should always be reviewed yourself before handing off to someone else.
Page is checked on all breakpoints & is fully responsive (not just on the 3 main breakpoints)
Every button/link goes to the appropriate place
Images have Alt Text added
Images are Optimized
Page is tested on a browser to make sure animations & other components work properly.

3. Efficiency

While we never want to sacrifice quality for efficiency, efficiency is really important as well. We expect our developers to use their time wisely and work efficiently while working on projects at Amply. Here are some examples of being an efficient developer without sacrificing quality:
Build all components first and optimize them for each breakpoint. Then copy and paste quickly to save time.
Use keyboard shortcuts to speed up workflow. Check out this page for tips on speeding up your workflow:
Reach out for help when stuck if you can’t figure it out yourself in less then 1 hour.

Bad practices we want to avoid:
Leaving mobile optimization until the end of a project. (Components should be optimized for mobile as they are built so that work isn’t done twice if they are copied.)
Waiting until the end of the project to optimize images









Share
 
Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.