DEV Community: FeaturePeek

How can new developers gain experience?

Brad Johnson — Wed, 30 Dec 2020 18:15:31 +0000

Eric Silverman, CEO and cofounder of FeaturePeek, discusses how new developers can gain experience, why it's important to read other people's code, and how contributing to open source projects can help you learn and look attractive to potential employers on your job hunt.

Eric's GitHub: https://github.com/eric-silverman

Learn more about FeaturePeek: https://featurepeek.com/
Learn more about the Mintbean developer community: https://mintbean.io/

Why are interpersonal skills so important on software development teams?

Brad Johnson — Tue, 15 Dec 2020 18:16:44 +0000

Eric Silverman, CEO and cofounder of FeaturePeek, discusses why interpersonal skills matter on software development teams and how having a Growth Mindset can set you up for success as a software engineer.

Eric's GitHub: https://github.com/eric-silverman

Learn more about FeaturePeek: https://featurepeek.com/
Learn more about the Mintbean developer community: https://mintbean.io/

What jobs should new developers apply for?

Brad Johnson — Mon, 14 Dec 2020 17:28:22 +0000

Eric Silverman, CEO and cofounder of FeaturePeek, discusses how many new developers aren't aware of job roles that would be a great fit for them, things developers should know when starting their first software engineering job, and lesser-known roles that new developers should consider to improve prospects on the job hunt.

Eric's GitHub: https://github.com/eric-silverman

Learn more about FeaturePeek: https://featurepeek.com/
Learn more about the Mintbean developer community: https://mintbean.io/

How did you get started in software engineering?

Brad Johnson — Fri, 11 Dec 2020 16:53:21 +0000

Eric Silverman, CEO and cofounder of FeaturePeek, discusses how he got started in software engineering and answers questions about his first role as a software developer, what he learned while working at his first startup, and the benefits of working at a startup if you're a new developer.

Eric's GitHub: https://github.com/eric-silverman

Learn more about FeaturePeek: https://featurepeek.com/
Learn more about the Mintbean developer community: https://mintbean.io/

Why learn software fundamentals?

Brad Johnson — Thu, 10 Dec 2020 23:48:08 +0000

Eric Silverman, CEO and cofounder of FeaturePeek, discusses why it's important for new developers to learn software engineering fundamentals, the things he knew when he got started as a new software developer, and strategies for overcoming impostor syndrome.

Eric's GitHub: https://github.com/eric-silverman

Learn more about FeaturePeek: https://featurepeek.com/
Learn more about the Mintbean developer community: https://mintbean.io/

Getting started in DevOps, CI pipelines, and setting up your first GitHub Actions

Brad Johnson — Tue, 08 Dec 2020 23:28:35 +0000

Last November, FeaturePeek cofounder Jason Barry joined Mintbean to talk DevOps and help new Mintbean developers set up their first continuous integration pipelines. If you're not familiar with Mintbean, it's a growing community of dev bootcamp graduates, self-learners, and other beginning developers that participate in weekly hackathons together. Past hacks have included trivia apps, stock trackers, chatbots, and lots more. Along with the hackathons, Mintbean offers free workshops and presentations that feature helpful speakers from relevant startups and industry leading companies. All Mintbean hackathons and workshops are all intended to help new developers build their portfolios and ultimately find their first jobs in software development.

One of the best parts of the Mintbean community is that every participant, code mentor, speaker, and community organizer at Mintbean are there to collaborate together and help each other learn. This focus on helping one another leads to a vibrant enthusiasm in Mintbean communities and chats, and new Mintbean participants always seem to think they've stumbled into a community that's too good to be true. Except that it's the real deal! That's why the FeaturePeek team are so proud to be sponsors of the Mintbean community, as well as frequent presenters on DevOps and career soft skills topics.

Automate and Deploy with GitHub Actions

On that note, FeaturePeek cofounder and frontend developer Jason Barry joined a recent Mintbean cohort to discuss continuous integration and setting up your first CI pipelines. In this presentation, Jason chose to feature GitHub Actions for its ease-of-use and for its generous free tier. In this talk, Jason discusses the important of continuous integration, how to set up GitHub Actions, as well as some simple tests and automations you can integrate.

Don't worry if you weren't able to join us on 11/16. That's why we recorded Jason's session, and this way you can watch it on your own time. Before you start, make sure to check out Jason's GitHub Actions Starter Pack repository on GitHub.

7 ways frontend developers can improve collaboration on UI/UX teams

Brad Johnson — Mon, 16 Nov 2020 20:18:40 +0000

When building anything, there is a necessary conflict between form and function.

Entirely functional products lack visual appeal and can be uninspiring to use. While products too obsessed with aesthetics can be confusing to handle, or expensive to make.

As a frontend developer, you’re on the frontlines of the battle between form and function. Because you’re the bridge between visual designers and functionally-focused developers, when deadlines start closing in and feedback flies fast, you’re the one on the hook. Whether that’s fair or not, frontend developers are responsible for ensuring effective team collaboration when it comes time for final review, bug fixes, and finally, delivery.

In this article, we'll show you how to balance form and function; collaborate effectively as a frontend developer:

Why it’s important to think like a user
Speaking up early and frequently
Essential tools for effective team collaboration
Continuous learning makes you a better frontend developer
Feedback is essential and how small 'picky' design changes can add up to a big problem
How to make front end collaboration an organizational priority

We'll also recommend some of our favorite tools and resources to make it easy, too.

1. Thinking like a user

The key to achieving a good balance between form and function is to get to know your users — and how they intend to use your product.

Good design and product development teams build intimate familiarity with the various personas of their users. By building empathy with your audience, you'll be able to spot issues with usability in advance and make better decisions when prioritizing new features or bug fixes.

Some of the most successful startups start by developing their products to solve actual customer problems - where the customer need precedes the product itself. Regardless of the role your customers play in the creation of your product, it’s critically important to maintain direct feedback channels with your users.

By seeing the issues your customers experience with your product, you'll identify where pain points occur in real life — not just in Figma or VSCode.

If you are building a website or other product without ready access to customers, try one of the websites below to gain impartial insights:

UserTesting: Used by Facebook, eBay and Walmart, UserTesting is the quickest way to get impartial feedback from customers. You pick your target market, assign them a series of tasks to complete and get a screen recording, spoken commentary and written feedback within hours.
UsabilityHub: Amazon, Google and AirTable use UsabilityHub. They allow you to create your own surveys (first click tests, preference tests, five second tests and design surveys) and invite your own participants, or make use of the UsabilityHub panel — comprising over 170,000 users.
Remote Testing: You can also use stakeholders or your existing contacts to get insights on your product. The U.S. Department of Health & Human Services has put together a guide on how to test remotely here.

2. Speak up early and frequently

You’re sitting in a planning meeting with the product manager, designers, management and other developers. You listen carefully, as the stories for the next sprint are discussed or longer term issues are debated.

Inside, you know there are usability problems with the product — and that while these issues would be simple to fix, they’re being ignored by the rest of the team. Whose responsibility is it to speak up?

This is a common pattern in many development teams, where opinions are bottled up and frustrated developers eventually move to a new job.

The good news is, it doesn't have to be this way. By speaking up, you'll improve the overall quality of the product, have a say in the direction of the product and work on improving your soft-skills.

As a frontend developer, you bridge both design and development. You are uniquely positioned to see when design or functional issues are harming product quality. And, as such, you should never be afraid to share your insights.

3. Leverage productivity tools to stay on track

Even if you're the quiet type, preferring to focus on work rather than attend meetings, effective collaboration still requires communication.

You should make a continuous effort to be aware of what the rest of your team are doing - and that means staying on top of your team's productivity tools. The benefits are:

Alignment: Teams that share a common vision build incredible products, as everyone is working towards the same goal.
Empathy: By staying in touch, you'll understand your teammates skills sets and how you can help them be more effective.
Compromise: Make designers aware of technical limitations early. Cutting back an overly ambitious design around technical limitations can be soul destroying for a designer. By communicating early, you can avoid these issues before they occur, proactively compromising on form or function, as appropriate.

You should also frequently reach out to your designer during the development process. This certainly beats waiting until the end of the development cycle, to discover a design issue.

Some tools we recommend are:

Framer

Framer is a great design tool for building advanced prototypes that look and function like the final product. It works a lot like Sketch or Figma and should be familiar to both designers and developers.

You can see some examples of what is possible with Framer here.

Prototypes are a critical but often forgotten part of the development process. They allow designers to think of the product in a tangible way (rather than an abstract design) and let developers flag complexity early in the design process.

FeaturePeek

With traditional development environments, you need to deploy a branch to staging before you can get feedback, or hope the designer knows Git enough to set up a local environment. This wastes time and makes it difficult to roll out quick changes. In short, working with the design feels laborious rather than inspiring.

With on-demand staging from FeaturePeek, a preview URL is generated for every pull request with built-in feedback tools, allowing you to share and get valuable feedback quickly. When collaborators do give feedback, FeaturePeek automatically records the URL they are on, and their browser metadata, making it easier to resolve issues.

4. Always be learning

Frontend development is always evolving. New tools and frameworks are released almost weekly, each unlocking new possibilities to build better websites and products.

As a frontend developer, it is your responsibility to continually learn and adopt new technologies, as they might make a technically difficult design more feasible.

But how should a frontend developer approach continual learning? Here's what we recommend.

Subscribe to newsletters and RSS feeds

Great newsletters keep you informed with no action needed. Just hit ‘subscribe’ and once a week you'll get curated insights in your inbox. Some newsletters we recommend are:

Daring Fireball: A sarcastic weekly forum on technology (especially Mac-related), design, and culture
The CodePen Spark: A weekly newsletter, podcast, and community oriented around frontend development
JavaScript Weekly: A weekly email roundup of JavaScript news and articles
Frontend Weekly: A weekly roundup of front end related articles and news
Frontend Focus: A weekly email newsletter covering HTML, CSS, WebGL and other associated technologies
Pony Foo Weekly: A deeper dive into web technologies, sent every Thursday

Join online communities

Just lurking in online communities is fine for entertainment, but relevant online communities are a great way to stay at the cutting-edge of web technologies. Here you'll find discussions about real issues other developers are facing — and how they solved them. Become an active contributor through comments or, even better, post original content about your own trials and experiences.

The top online communities for frontend development are:

Hacker News: Ignore the dated appearance, this online community is at the forefront of software development and entrepreneurship. People post links they find interesting, then (attempt to) have civilized discussions about the topic. You can also post your projects in the 'Show' section and get feedback from the community.
Dev.to: DEV is a "community of software developers getting together to help one another out". DEV is a unique hybrid platform, feeling like a blogging platform, forum and chatroom all at the same time.
Indie Hackers: If you are building a product of your own, talk about it on Indie Hackers — a community for tech entrepreneurs.
Product Hunt Makers: You might have heard of Product Hunt as a place to discover new products, but they also offer a 'virtual co-working space' for 'makers'. With over 25,000 members, this is one of the fastest growing communities in the space.

Learn by doing

Adopting an unknown technology on an urgent project is a recipe for disaster. New technologies are often poorly documented, so there’s not a lot of support if things go wrong.

Instead, create a sandbox project around the new technology and try it out. By building a tiny application or tool with no repercussions on your larger project, you'll learn the new technology and discover it's limitations first-hand.

Other examples of side projects you could build with a new framework are:

To-do list: A basic to-do list is a great way to learn a new language. There is an on-going project on GitHub which aims to build the same to-do app in every programming language — check it out here.
Weather: Try displaying the weather by using an innovative web technology. Could you use Lottie to animate weather icons, or WebAR to show the forecast?
Calculator: A calculator is a great way to learn state management frameworks, like Redux, Mobx or Flux.

Once you're ready to test your new skills, or just want to build up a portfolio of side frontent projects, check out Mintbean. They host weekly hackathons with simple frontend challenges, as well as free workshops to help you upskill and improve job hunting strategies for new developers.

5. Get feedback often

Feedback is a key part of effective front end collaboration.

Developers should give feedback on designs as they are being created, flagging technical limitations as early as possible. Equally, designers should give continual feedback throughout the development process, too.

In the past, this was difficult for both parties. Designers could not see in-progress development work and developers couldn't see design locked away in desktop applications.

But in 2020, cloud design tools like Figma, Sketch or Framer include commenting tools. Designers can see in-progress development work by using on-demand staging environments when using FeaturePeek.

6. Small design changes; big impact

Have you ever reacted badly to negative feedback, particularly 'picky' or small changes to the design?

Sure, you could choose to ignore these small tweaks, but they eventually build up — taking a big toll on product quality.

Remember, design is a highly skilled job that requires years of experience and specialist knowledge. If a non-programmer told you that a bug-ridden function was ‘good enough’ and ignored your feedback, you’d be frustrated too.

The next time you receive feedback from a designer, react positively and consider the change as an essential part of refining the overall product. You’re all on the same team, and small positive interactions over time are what make up great work cultures!

7. Change your organization

If collaboration between designers and developers within your organization is difficult, you might need to discuss a few internal changes.

Teams with effective front end collaboration:

Include developers throughout the process: By including developers from the start of the project, technical limitations can be considered and overcome at the start of the design process — rather than worked-around later.
Choose balanced project managers: Some project managers have tunnel-vision, focusing too much on one particular discipline, such as business, design or technical considerations. This works well for highly specialized teams, but is a blocker when front end collaboration is needed. A well-rounded project manager understands all disciplines involved in the project; facilitating collaboration and compromise.
Work closely: Where possible, designers and developers should have tight, frequent feedback loops. Remote teams can use video chats and screen sharing to help with this.
Avoid jargon: Just like developers, designers have their own jargon. A designer might ask for more kerning, tracking and leading and get blank stares from a developer. A developer might ask for the 'letter-spacing' of a H3 and get the same blank stare back. Instead of relying on technical language, encourage your organization to adopt tools for visual communication — a screenshot, Loom recording or Figma design is much clearer than a written or verbal explanation alone.

We hope these tips help you work more collaboratively with designers (and fellow developers!) to build high-quality products.

In 2020, it is not enough for a frontend developer to just write code. You are responsible for effective frontend collaboration. Truly exceptional frontend developers bridge the gap between design and development, helping the designers and developers on their team to build the best possible product.

Learn More

FeaturePeek deployment previews are the easiest way for UI/UX teams to collaborate on frontend code.

FeaturePeek provides collaborative frontend staging environments on-demand, so you can collect implementation feedback from stakeholders sooner. FeaturePeek works with all frameworks and hosting providers, so you can keep your tools and you’re never locked in.

Learn more about FeaturePeek Teams, our collaborative tool that supercharges deployment previews for development teams.

It's Not Design Culture Anymore, It's DevOps Culture. And We Should Adjust Accordingly.

Brad Johnson — Wed, 28 Oct 2020 20:59:39 +0000

Have you noticed that a lot of your friends who used to be Designers are now UX Architects?

Did their jobs really change? Or is their output being used and valued differently by the organizations that employ them? As a mainstream culture, we've really only become comfortable with design-thinking over the last 50-75 years. Today, designers are more important than ever to facilitating the product development process. But designers' roles are undergoing a critical transformation.

In the modern workplace, design culture is everywhere and it's had a lasting impact on the way organizations function. But while we've been paying attention to one very important way that work culture has changed, we have been potentially ignoring another, even more significant shift. Software development, and increased demand for software developers by both technology and more more traditional businesses, has shifted the culture of our workplaces and changed our expectations for how work gets done.

Like designers, software developers have never been more in demand. Today they can command high salaries and frequently can improve their prospects by 50% or more simply by moving jobs. Companies are now employing recruiters whose sole focus are attracting technical talent. And more developers are represented in business and technical leadership positions than ever before. These are relatively recent changes, but they're already beginning to affect our workplace cultures. In this blog post, we'll explore how increased the increasing gravity of developers is shifting the balance of our workplace into becoming DevOps cultures.

Using the mainstreaming of "design thinking" a template, we'll look at some design collaboration tools that have been adopted by mainstream businesses. Then, we'll look at some developer-centric collaboration and productivity tools and discuss how their adoption could impact the ways software development teams and entire businesses will work together in the future.

How DesignOps Tools Changed the Way We Work

Designers have a whole assortment of tools at their disposal. But most of the tools that designers use can be distilled into one of two categories. The first type are design tools, in that they are the bits of software like Figma, Sketch, and Adobe XD, where the primary purpose is to enable the act of designing and creating. The second type of design tool is one that helps designers communicate and collaborate with other stakeholders, sometimes referred to as "DesignOps."

AirBnB explains their need for DesignOps tools, as their product teams are "working daily across so many disciplines, from Engineering to Product Management, Research, Content Strategy and an array of Design specialties, every little overhead in the transfer of information compounds. Inversely, every optimization and positive connection significantly lowers friction for everyone." DesignOps tools ensure that cross-functional product design teams have visibility into each others progress, and removes friction by enabling each discipline to contribute, in context, whenever is convenient (within the project schedule).

Tools like Zeplin help designers make their design systems shareable and accessible to developers and other designers on their team. In other words, the Zeplin app helps with the people-side of design operations. This is why it's helpful to view DesignOps tools as platforms for facilitating team collaboration. Because DesignOps tools make information accessible, teams can rely less on in-person or virtual conferencing more productively allocate their time resources.

The benefits of DesignOps tools are clear, so much so that traditional design tools are incorporating collaboration features as part of their longterm product roadmaps. In the same way that introducing collaborative features will enable traditional design tools to adapt to the requirements of DesignOps culture, businesses will increasingly turn to collaborative design experiences to enable their internal design processes and procedures.

How DevOps Tools are Changing the Way We Work

Like design tools, developer tools also come in many flavors. Traditionally, developer tools have focused on enabling the act of software development, as in coding. These take the forms of text editors like Sublime and IDEs like VS Code. But a developer's everyday experience isn't just limited to what gets deployed. Like designers, developers also rely on tools to help them collaborate, make their work accessible to others, and ultimately deploy to production. These tools are commonly described as having to do with DevOps.

DevOps is really just a way to describe the design, development, deployment, and continuous operation of software code, including all the tools and mechanisms that support those processes. Atlassian warns that DevOps is "not a matter of simply adopting agile planning or automated testing or continuous delivery." Instead, they describe that "DevOps culture is all about a shared understanding between developers and operations, and sharing responsibility for the software they build."

As developers become increasingly central to business operations, the tools that they use to collaborate with peers and non-developers on product teams will play an outsized role in facilitating everyday business operations. You can already see evidence of this now. For example, even if you're a non-developer you feel the impact of a Slack or Zoom outage. And if you are a developer, you know exactly how (un)productive your day is when GitHub is down. Just like these examples, new tools are being created everyday to support DevOps and remove the daily frictions experienced by software developers. Ultimately, these are the tools that will deliver immense future value.

Here are the main types of DevOps tools that have already become, or will become, ubiquitous for modern software development teams:

⚙️ Platform-as-a-Service (PaaS) and Serverless
There are lots of ways to build and host your web application. Platform-as-a-Service providers like Netlify and Heroku provide a more streamlined user experience compared with AWS, Microsoft Azure, or Google Cloud, while all four provide scalable infrastructure services to support applications of all sizes. Serverless architectures take the notion of abstracting-away infrastructure a step further, and adopt an overall philosophy of offloading all (or as much as possible) of the infrastructure responsibilities to third-party services.
🚧 Deployment Staging and Visual QA
Every software development process that has a visual component or user interface will have some sort of visual review process. Web platforms like Netlify and Heroku have native deployment preview solutions to preview UI/UX work. FeaturePeek is a developer tool that makes deployment previews collaborative, so designers and other non-engineer team members can easily comment and leave annotations on the in-progress UI/UX.
🚢 Containerization and Deployment
Containers, like those used in Docker, can make it easier to operate your application, especially when dealing with complex deployment environments. Services like Kubernetes can help you orchestrate and monitor your containers. Some of the benefits to adopting a container-based architecture include the ability to build once, run anywhere - a self contained process, and the freedom to package absolutely everything needed to run your application in a convenient way. Containers are modular, interoperable, portable, reproducible, and scalable. So it's no surprise that while containers are not used everywhere, they're quickly getting there.
🔄 Continuous Integration and Deployment (CI/CD)
Integration is the act of checking that the code you just wrote didn't break something you weren't working on directly. Continuous integration, or CI, is doing this continuously to make sure issues are caught and addressed incrementally rather than all at once. Tools like Travis CI and CircleCI are good bets when considering continuous integration. Deployment is the process of launching your code onto the server, and there are lots of different ways to accomplish this. You'll want to think about choosing an automation server like Jenkins and whether you'll need a delivery platform like Spinnaker. Together, CI/CD is the collection of integration checks and test run to ensure code properly integrates, along with the steps needed to safely and reliably deploy your code onto your server environment.
🌡️ Performance and reliability monitoring
In order to effectively operate a software application, you need to be able to troubleshoot when issues occur. But before you can identify a fix, first you need to know what happened. Logging is the continuous recording of application events, so that developers can assess and problem-solve issues as they occur. But logging itself is a passive activity. Monitoring answers questions about how the system is running, and involves continuously observing a set of KPIs about performance and resource usage. Datadog, AppDynamics, and New Relic are some of the leading providers of monitoring solutions.

Learn More

FeaturePeek brings DesignOps and DevOps together. The easiest way to set up on-demand frontend staging environments, FeaturePeek creates a deployment preview of your frontend every time you open a pull request. A drawer overlay makes it easy for your reviewers to leave comments, take screenshots with annotations, capture screen recordings, create tickets on popular bug-tracking platforms, and more.

FeaturePeek works with static sites and sites containerized with Docker. Best of all, you don’t have to migrate to a new cloud ecosystem. Whether your company’s website is hosted on AWS, Google Cloud, Heroku, Digital Ocean, whatever — since FeaturePeek is infrastructure-agnostic, you can use FeaturePeek no matter who your hosting provider is.

Try the 2-week free trial to see how FeaturePeek can improve your team’s development productivity.

The benefits of on-demand staging environments

Jason Barry — Mon, 19 Oct 2020 18:28:55 +0000

TL;DR: Test features in isolation. Test releases as a whole.

You know the drill: it’s the night before a release, and your dev team is scrambling to address last-minute feedback before deploying to production. Most of the feedback surrounds tiny changes that are trivial to fix -- but some of the feedback requires larger, substantial change. These long feedback loops reveal a more fundamental issue of communication breakdown. This should have been discussed earlier. Now you’re left wondering if it’s worth delaying the release to help ensure the stability of the build.

Sound familiar? I experienced this first-hand while working at a small (~6 engineers, ~2 designers, 1 PM) B2B SaaS startup. The product team would give feedback about the latest build on staging with only a day or two left in the sprint, causing a last-minute rush by the dev team to implement those changes. Corners were cut to meet deadlines, and hastily-written workarounds were rarely refactored, adding to the backlog of technical debt as the next sprint was already underway.

If you experience these symptoms during the development of your product, then chances are that your team doesn’t have the right tools at its disposal. It turned out that the product team left feedback late because they didn’t have a stable URL where they could verify UI/UX until changes were on our staging server.

We needed a way to get stakeholder feedback earlier in the development cycle -- well before features landed on staging.

What is a staging environment?

A staging environment is a replica of your production environment. There shouldn't be any significant differences between your staging environment and your live website, with one notable exception: the staging environment is private.

Think of staging as the ultimate quality assurance check, where you can make sure everything works in as close to launch conditions as possible. You'll catch bugs, avoid costly downtime, and give your developers the confidence to take risks.

How do you deploy to a staging environment?

The traditional deployment process to a single staging environment usually has four steps:

The developer builds and tests in a local environment, running on their machine.
Once they are satisfied with their work, the developer pushes their changes to a branch on the git repo, where they open a pull request. Continuous Integration runs automated tests — like linting, type checking, and unit tests — to catch any issues. If issues are found, the developer goes back to step
Once Continuous Integration passes, the developer's peers conduct a code review. This is necessary to gain consensus among your team that the proposed changes are greenlighted to be merged into the codebase. Not only should reviewers look at the code, but they should run the code to confirm that the code operates as intended. The developer goes back to step 1 to address any feedback left by reviewers.
Once the changes are deemed copacetic by automated tests and peer reviewers, the developer's branch is ready to be merged into the main branch. If Continuous Delivery is enabled, then merging to the main branch kicks off an automated task to deploy the changes in the pull request to your company's internal staging server.

Depending on how your DevOps team configures your git repo's webhooks, merging to the main branch may trigger additional steps. If your org follows the practices of Continuous Deployment, merging to master could roll the latest changes out to production automatically (hopefully behind a feature flag). Every DevOps team is different — check with yours to see which practice your company follows.

Why multiple staging environments instead of only one?

Instead of being constrained by all upcoming changes landing on a single server, you could have temporary, ephemeral environments that exist solely for the purposes of hosting the build of a given pull request. This is what we mean when we say that you should test features in isolation. Giving every branch in your git repo a dedicated environment is very freeing for both your developers and reviewers.

What you might not is realize that this comes with more benefits than just testing features.

Code review won’t block gathering product feedback

With a single staging server, your code won't be deployed until code review passes, and you won't have a link to share with other people on your team. If you want to double-check with a UI/UX designer that the animation you made is up to snuff, too bad — you're gated upon code review passing before you can Slack over a link.

If any stages above fail (red), you have to go back to square one. This can be costly if you’ve already performed code review, a time-consuming operation.

But UI/UX designers don't care about the quality of the code — so why should code review be a bottleneck for gathering UX feedback? Ideally, you'd be able to get their opinion before asking your dev peers to give your code a once-over. That way, you'll eliminate an extra speed bump when shipping your feature.

Ephemeral staging servers that spin up on demand allow for product feedback and code review to occur before (or at the same time) as code review. If there’s something that needs to be addressed, going back to square one isn’t very detrimental, since not much time has passed. You eliminate a speed bump by batching product feedback with code review, rather than having one be a dependency of the other.

Prevent an integration warzone

Sure, your new feature that you've worked hard on works now — but since a single staging environment is the landing pad for your entire engineering team's upcoming changes, a developer on your team may inadvertently push code that breaks what you wrote. Even now that you have an internal link you can share with a non-technical stakeholder, there are no guarantees that the link will continue to work, since it is actively being integrated with!

While a single staging environment is useful for testing a release as a whole, features should be tested in isolation. This means that an environment's purpose should be dedicated to testing the functionality of a single feature, rather than a collection of many features. Save testing the collection of features for your QA server, after you’ve already tested each feature individually.

Lower the barrier for running peers' code

Developers face a large amount of context switching when they are asked to review someone else's code. The process is unnecessarily interruptive, and looks something like this:

Stop what you’re doing
Stash any unstaged changes
Fetch from origin
Checkout their branch
Install dependencies (and potentially restart your development server)
➡️ Actually verify the new feature and provide feedback
Checkout your original branch
Pop your git stash
Reinstall dependencies (and potentially restart your development server)

With on-demand staging environments, on the other hand, the running branch is waiting for you to verify and provide feedback. Developers can jump into the deployment preview straight from the pull request without needing to checkout files, install dependencies, restart their development server, or change anything about their local environment.

Avoid redundant code reviews

The point of getting feedback is to make more implementation changes that address the issues raised in the feedback session. The problem is that this will require another code review! Even though the proposed changes the second time around are (hopefully) small, your reviewers will experience déjà vu because they are now going over the same lines of code for the same feature implementation.

With multiple staging environments at your disposal, you could spin up a preview environment for your designers to critique while your pull request is still open. You wouldn’t need to request a code review from your developer peers until your designer gives the thumbs up ahead of time.

More opportunities for testing

On-demand staging environments can be configured to be accessible behind a shared URL, which unlocks a wide range of testing and quality assurance opportunities.

Cross-browser testing: Ensure your product or website works perfectly on a wide range of browsers and devices.
Accessibility testing: Run accessibility tests to ensure your content is accessible to individuals with disabilities.
User testing: Create a pool of test users or use a crowd-testing platform to discover usability issues before you launch.

Avoid environment drift

Single staging environments are often configured once and left to decay, becoming a DevOps chore. This leads to drift between the staging and production environments, as similarities between the two decrease. This increases the risk of bugs appearing in either staging or production, which makes bugs difficult to reproduce.

Examples of these drifts include:

Environment and configuration files getting modified by unsuccessful staging deploys, leading to extraneous or incorrectly named settings.
Time-sensitive security vulnerability updates being applied to production in a rush, leaving staging several versions behind.

Whereas your production environment is under constant care and attention from the DevOps team, an infrequently used staging environment is lower on the priority list.
This can lead to an unreliable staging environment, which blocks your development team from launching new features.

More stakeholder engagement

In the past, stakeholders didn’t get to use the finished product until it was live. Instead, they got a brief scripted demo at the end of the sprint.

By giving stakeholders access to your staging environment, they can help with the quality assurance process and ensure that the development work completed meets their expectations. This saves time and prevents mistakes from accidentally shipping.

Increased developer productivity

With on-demand staging environments, developers can create as many staging environments as they require without asking DevOps to configure a new environment. Developers love it because they have the capability to spawn new servers, and DevOps loves it because they don’t need to field manual tasks of spinning up a server only for it to be taken down shortly afterwards.

Save your company time and money

Single staging environments are typically available 24/7 on a dedicated server or virtual machine. This is a waste of resources that could otherwise be used for production.

Furthermore, if you have several development teams, the single staging environment can become a bottleneck. Teams must wait for a staging environment to become available, waiting for other teams' quality assurance processes to complete. This could waste days of developer productivity and encourage teams to skip straight to production, losing all the benefits of an effective staging environment.

Each on-demand staging environment, on the other hand, is only online for the duration of the pull request. When the PR gets merged or closed, the environment gracefully shuts down, so you only pay for what you use.

Single vs. on-demand staging environments

Instead of the single staging environment decaying while it waits for someone to use it, an on-demand staging environment is created dynamically, triggered by a CI/CD pipeline.

This means developer teams can have access to staging whenever they need it, simply by opening a pull request. As you’d imagine, this boosts productivity and encourages developers to use staging environments, reducing the chances of costly production bugs. Once a developer is done with the staging environment, the staging environment is destroyed, along with any configuration, environment, or installation inconsistency.

	Single staging environment	On-demand staging environments
Developer self-serve	❌	✅
Low maintenance	❌	✅
Prevents redundant code reviews	❌	✅
Can test features in isolation	❌	✅
Can link to a build while pull request is still open	❌	✅
Number of environments	1	Unlimited
Cost	Pre-allocated	Allocated on demand and reclaimed automatically

Having said that, you should still have a staging server where you can do QA before rolling to production. This is where you should do a final spot-check to ensure that everything is working as expected before going live. The difference is that the purpose of this server is to test the release as a whole, rather than each feature on its own. How do the new features operate together? If there’s a bug found, which pull request and which lines of code introduced the bug? These questions are much easier to answer when features are tested while the pull request is still open.

Shorten cross-functional feedback loops with on-demand staging environments

As a front-end developer, being able to dynamically create a dedicated environment for an unlimited number of branches is a very powerful feeling. I can control my own network of machines without needing to ask for cycles from DevOps! The asynchronous nature of asking for feedback on a fleet of ephemeral environments is liberating -- I know that each deployment will be waiting for my reviewer exactly how I left it. And while I review my peers’ code, I can visually review the build alongside it without having to check out their branch locally.

It’s not only helpful to the developers on my team, but also helpful to the non-technical stakeholders too -- they get a lens into the engineering process, and can voice their opinions while the implementation details are still fresh in the developer’s mind.

If your organization is struggling with shipping features (on time) that meets everyone’s acceptance criteria, the solution may lie in tooling. Notice where and when the speed bumps occur -- handoff, development, code review, etc -- to help identify bottlenecks. Ask yourself whether your single staging server is a limiting factor during your team’s development processes.

Learn more

The easiest way to set up on-demand frontend staging environments is with FeaturePeek. FeaturePeek creates a deployment preview of your frontend every time you open a pull request. A drawer overlay is added on top that makes it easy for your reviewers to leave feedback by allowing them to leave comments, take screenshots with annotations, capture screen recordings, create tickets on popular bug-tracking platforms, and more.

FeaturePeek works with static sites and sites containerized with Docker. Best of all, you don't have to migrate to a new cloud ecosystem. Whether your company's website is hosted on AWS, Google Cloud, Heroku, Digital Ocean, whatever — since FeaturePeek is infrastructure-agnostic, you can use FeaturePeek no matter who your hosting provider is.

Try the 2-week free trial to see how FeaturePeek can improve your team's development productivity.

Pull requests are the new design handoffs

Brad Johnson — Wed, 30 Sep 2020 23:12:53 +0000

The line between UI/UX designer and developer grows blurrier each year. Every day, more designers are leaning into software development and learning to code. This has led to a new class of "full-stack designers." The Flatiron School describes a full-stack designer as one with the ability to "single-handedly tackle every layer of software development." With the ability to produce and communicate with both technical and non-technical stakeholders, full-stack designers are exceptionally valuable for cross-functional teams.

Similarly, design-literacy has become table stakes for many developers. Most UI/UX developers work closely with designers, and a certain aesthetic sensibility is required to produce polished UI/UX work. So it's no surprise that many UI/UX developers find themselves picking up tools and skills that are more typically associated with designers in the course of their regular work. Additionally, smaller teams lacking available design resources may turn to frontend developers, or even product managers, to take on additional design responsibilities in support of existing projects.

Job roles will continue to blend, and UI/UX developers will require new tools to better collaborate with increasingly cross-functional teams. There will always be a need for practical tools that make the act of coding easier, but it's a new class of social, collaborative developer tools that promise to play an outsized role in the workplace of the future.

🛠️ The Collaboration Toolbox: What tools UI/UX teams use to collaborate

In the past five or so years, we've seen an explosion of collaboration tools to support professional teams. While the list of collaboration tools may be endless, when it comes to UI/UX teams, they all boil down into four basic categories:

Communication tools 📺

Not much is getting done if your team can't communicate. Out of sheer necessity, most teams already have this category squared away, for better or worse. These are your big names like Zoom and Slack, but there are also some smaller startups like Loom, Tandem, and others making moves in the team communication space.

You can check out this blog post, if you'd like to learn more about our thoughts on some of the leading communication apps available to development teams today.
Project management tools 📊

Project management software helps to ensure that requirements are clearly communicated and contributors stay on top of their tasks. Project or product managers are responsible for aligning stakeholders so that designers and developers can focus on executing the project objectives.

Whichever tools you choose, the point of adopting project management software is to facilitate the design and implementation conversations that happen as a product is being developed. There are a ton of great options to choose from like Clubhouse, Trello, Monday.com, Basecamp, Asana, and JIRA.

Before investing time in a new project management solution, consider choosing one that integrates with any important internal tools to minimize headaches down the road.
Design collaboration tools 🎨

Not until the last few years have a crop of upstarts begun to unseat the incumbent Adobe, for the hearts and minds of designers. Today, there is a triumph of options when it comes to collaborative design software and they all have their unique offerings.

Designer-centric tools like Figma, Sketch, InVision, Adobe XD, and Balsamiq all go various lengths to make wireframes and other handoffs tolerable for UI/UX developers. Handoff tools like Zeplin make it easy for developers to interpret wireframes and must straddle both the design and development worlds.
Developer collaboration tools 💻

The universe of devtools is myriad and comes with all sorts of solutions for problems that developers may face in the course of their work. But for collaborating with a team, there aren't as many options as you'd think.

Version management platforms have achieved outsized importance in developer life. GitHub, and to somewhat lesser degrees, GitLab, Bitbucket, and others are the de facto public forums for software collaboration. Organizations large and small rely on these platforms to organize and document their software code.

Then comes the challenge of previewing, and more importantly collaborating on, still-in-development projects. Some web platforms like Netlify offer deployment previews, but there's no way to collaborate or leave feedback in context, within the preview itself. That's left to Slack, Zoom calls, or email.

Team-focused tools like FeaturePeek prioritize the collaboration aspect and make it easy to review and leave feedback on deployment previews. Reviewers can record screens, annotate screenshots, and even review responsive layouts on multiple devices.

🤦‍♀️ The Collaboration Conundrum: What tools do my UI/UX team really need?

With so many tools, and so much cross-pollination occurring between developers and designers today, it's difficult to determine which tools your UI/UX team really needs to communicate and collaborate together.

In a design process, it's often the handoff points where team communication can breakdown. Consider:

What are your handoff points during the product design and development cycle?
What tools do you use to facilitate collaboration during these handoffs?
What are the potential communication gaps during your handoffs?

By identifying the handoff points between different roles on your team, you can begin targeting the tools necessary to keep your team on track. Remember, the initial exchange of wireframes isn't your only handoff. Designs and prototype versions are constantly being handed off between team members for development, review, and QA. While some handoffs may already have established tools and processes (ex. handing-off wireframes), others may lack an established process or tool (ex. doing visual QA for pull requests).

↕️ Pull Requests: It's not just the deployment preview that's important

Design handoff tools are great, but why aren't we talking about developer handoffs? Tools like Zeplin are great for ensuring developers have convenient access to the information within wireframes. But how do non-engineers engage with pull requests, and collaborate as a team on constantly changing code previews?

There are many good solutions if your end goal is simply the deployment preview itself. For example, if you're a Netlify user, they have a reasonable deploy preview tool. Similarly, there are available tools like Tugboat, and a few others. If all you want is a staging environment for your pull requests, then most solutions are essentially equal.

But the reality is that real people are collaborating on this deployment preview, and they need to do more than just look at it. That's why the actual deployment preview itself isn't the point. It's the collaboration that matters.

🚀 Why the next killer enterprise app will be a developer collaboration tool

Like Slack, GitHub, Zoom, and Clubhouse, it's the tools that change the way we communicate our thoughts and ideas with others that change the ways we work. Each of these applications helps us communicate and organize with our own teams. But none of these tools extends fully into the world of software development. As developers become a larger demographic in the workplace, collaboration tools that enable the way developers work, and make that workflow accessible to others will find eager adoption.

This is why developer-focused collaboration tools like FeaturePeek are so unique and exciting. Developer collaboration tools bridge the world of pull requests and GitHub into an experience that is accessible for all (especially non-engineering) users, and ultimately into a more social context altogether. Just like design handoff software does for designers, and project management software does for product managers, developers also need their own tool to present pull requests in an accessible hub for the rest of the UI/UX team.

There's an elegant simplicity to focusing on pull requests as the final handoff of the UIUX process. By taking a basic developer action (creating a deployment preview for a pull request), and turning that step into a collaborative effort, every pull request becomes an opportunity for a just-in-time iteration or optimization. It's a more efficient way of working for UI/UX and serves to reinforce a notion that developers long ago intuited: Pull requests are the new design handoff.

The WFH edition. Our ultimate remote working stack for frontend devs

Brad Johnson — Wed, 23 Sep 2020 21:59:01 +0000

Let’s be honest, frontend developers kinda had this remote working thing figured out before our latest post apocalyptic reality. Now, it’s still been difficult for us all to adjust. But if there were any demographic that already had the know-how and the tools to stay productive while collaborating remotely, frontend teams had it covered.

The challenge, most of the time, is just sorting through the overlapping options and developer-targeted Google Search ads to get to the tools that actually make your workflow easier.

Don’t worry. At FeaturePeek, we’re devtool nuts. And we try out just about everything we discover. Along the way, we’ve earmarked our favorites and fully incorporated many into our regular internal workflows.

You could try out everything by yourself. Or you can learn from what our team figured out. But before we jump into our favorite little-known remote working tools, let's start by covering the basics.

Remote Working Essentials

These are the fundamental tools every remote worker needs. Most development teams will already be using these in their day-to-day efforts, but if you skip over these fundamental tips and tricks, you'll struggle to make the most of the other tools we mention in this article.

The Basics: Team Chat Tools

Email isn’t exactly dead, but it’s no longer the standard for asynchronous communications. Development teams have used text chat to collaborate since the internet was invented. So if you aren't using a communication tool like Slack already, adopting one should be your first step towards productive remote working as a development team.

Are there other chat alternatives? Sure. But we haven’t found any we like better than Slack yet.

Here are the key features of Slack that make it work for developer teams:

Channel Messaging: You can create unlimited channels dedicated to tasks, projects, issues, or initiatives. For example, you could make a #webbugs channel to triage issues in your web app or a #marketingsite channel to discuss a website update. By working in a channel, you can be sure that all the right people see the right messages at the right time.
Searchable Knowledge: Slack is a single place where you can find conversations and files related to your work. Never again lose an email attachment in a crowded email inbox.
Integrations: Bring all the activity you care about into Slack so you never miss a thing. For example, a new Jira ticket could trigger a chat message or a new pull request to notify the right people to review it.

The Basics: Version Control

It doesn’t matter whether you’re working remotely or not. Version control is a critical part of modern software development, for both remote and co-located teams. Whether you use GitHub, GitLab, Bitbucket, you’ve likely already adopted one that makes sense for your team.

Regardless of the platform you choose, the benefits are the same:

Collaboration: Without version control in place, you are probably working in a shared directory and hoping your colleagues don't modify the files you are working on. Eventually, someone will save over your changes and you'll lose your work. With version control, you can work on any file without disrupting your colleagues. If there is a conflict, your version control system will let you merge these files later.
File History: Without version control, keeping a file history is almost impossible. With version control, changes to files are automatically tracked along with a commit message (a brief description of what has changed) and you can view the history of a file whenever you like. This makes it easy to see how files have evolved and what might have caused that annoying bug.

The Basics: Video Conferencing

I, for one, welcome our new Zoom overlords. Video conferencing is inescapable in the new shelter-in-place environment. And while we’ve all suffered from Zoom fatigue at points this year, sometimes you just need to discuss a bug or issue face-to-face.

At FeaturePeek, we actually find ourselves using a few different video conferencing solutions. But if you need one platform to rule them all, Zoom is easy to use and includes features that are essential for development meetings, including screen sharing, annotations, and support for whiteboarding sessions on select plans.

Other solutions are available, including Cisco Webex, Jitsi Meet, Google Chat, and Whereby. If you pay for the Standard, Plus, or Enterprise version of Slack, you get video call capabilities, too.

Little-Known Remote Working Tools

With the basics in place, you'll be able to chat with your team and keep track of development work. Now, let's level up your remote working productivity so you don’t skip a beat while skipping the office commute.

Miro: Online Whiteboard

If you’ve ever found yourself wishing that your development team could just meet for an in-person whiteboard session, Miro is the next best thing.

By being physically present and taking turns to write or move ideas around, it's easy to plan, share complicated ideas, and leave key information on display, such as project timelines or key tasks to be completed.

Miro brings that whiteboard online and enables remote teams to collaborate in real-time in a free-flowing and creative way — just like a real-world whiteboard.

Miro also doesn’t just try and replicate the meatspace whiteboard experience. They explored what being a digital whiteboard can enable, and it actually has some key advantages over a real whiteboard:

Infinite Canvas: There are no limits to the size of the Miro whiteboard. Create a single whiteboard for every project in your company, all reviewable from one place.
Add Files: You can add files from Google Docs to the whiteboard, which will be automatically updated and synced.
Collaboration: All team members can make changes simultaneously from wherever they are in the world.

Loom: Video Messaging

At FeaturePeek, we use Loom for all kinds of our video needs. Instead of writing a long email or Slack message to explain that annoying bug, try using Loom to record a quick video instead.

We also use Loom to generate quick and dirty developer how-to videos to share later as an .MP4. Unlike normal screen recordings, Loom captures your screen, microphone, and face at the same time. This encourages users to explain their thoughts as they record; perfect for highlighting bugs or creating demos to be circulated within your team.

Loom recently launched for iOS, enabling app developers to record and share issues quickly.

FeaturePeek: Deployment Previews

Sure, we're biased in recommending FeaturePeek. But the benefits of on-demand staging environments are huge for remote development teams:

Quicker Design Feedback: Get feedback from designers by just sending them a link. No need to manually deploy or help the designer set up a local environment. When they do give feedback, FeaturePeek automatically records the URL they are on and their browser metadata, making it easier to resolve issues.
Review Others Work: Switching to a colleague's branch to review their work takes time. With FeaturePeek, every branch is a dedicated environment, instantly available for your review.
Quality Assurance: "Well it works on my machine" is a thing of the past. Get an instant preview of how your branch will work on any server.

Want to see how this could work for your team? Our entire website is open source on GitHub, so you can take a peek at the preview environments that deploy on our open pull requests.

Headspace: Meditation

Being productive isn't just about tooling and apps. Being productive is also a state of mind.

Sometimes a project requires you to hype up. But more often than not, these days you’re probably having trouble winding down.

Research shows that mindfulness can help improve mental health. And according to a 2020 study, meditation reduces stress and improves cognition.

Headspace is an app that aims to make meditation accessible to everyone. Taking a few moments to re-calibrate can help when development work becomes overwhelming or deadlines start to cause stress.

When To Chat: Timezone Sync

If your team is distributed around the world, it can be impossible to figure out a mutually convenient time to meet.

With When To Chat, you enter your timezone, the timezone of the person you are meeting with, and your availability. It'll automatically suggest a range of times instantly.

If you use Slack, you can add it to your workplace here. Then, just type /whentochat, then @ your colleagues. For example: /whentochat @gary @tom "Dev Meeting"

What's Your Favorite Tool?

Let us know how your remote team stays productive by sharing with us in the comments!

The 8 part guide to better code review checklists

Brad Johnson — Wed, 02 Sep 2020 23:01:47 +0000

Of all the productivity tools available to UI/UX developers today, few are as ubiquitous and effective as the humble checklist.

In "The Checklist Manifesto", Atul Gawande explains that simple checklists can transform the way we work. In his book, Gawande was trying to find a way that doctors, surgeons, and nurses could deliver better, more consistent outcomes when working in an operating room - a literal life-or-death situation.

"We have accumulated stupendous know-how," Gawande writes in his book. "We have put it in the hands of some of the most highly trained, highly skilled, and hardworking people in our society. And, with it, they have indeed accomplished extraordinary things. Nonetheless, that know-how is often unmanageable."

Although software development isn't exactly a life-or-death endeavor, we can apply the same lessons by using the power of checklists to prioritize effectively when collaborating.

What is a code review?

When a software developer on a team wants to contribute code they've worked on back into the main project, they need to do a 'pull request' or 'merge request'. It's the main way developers contribute to software projects, but sometimes getting pull requests approved can be agonizingly slow.

Before this code can be added to the project, other team members will do a code review. This means checking for bugs, issues and suggesting improvements.

Why make a code review checklist?

Generally speaking, code reviews are great. They radically improve code quality, increase developer productivity and prevent bugs from ever reaching customers.

But without a good process, code reviews can be, in a word...painful.

Code review checklists help ensure productive code reviews. A code review checklist prevents simple mistakes, verifies work has been done and helps improve developer performance.

1. Pull Request Etiquette ✅

Start with the basics. Is the pull request you are looking at actually ready for review? To determine this, here are some key principles that should apply to all code reviews:

Frequent — To make pull requests more manageable, submit them little and often. If a pull request covers multiple days with no good reason, it should be split into smaller chunks.
Bitesize — If a pull request is too large, it's difficult to understand. It should be broken down as much as possible.
Well documented — Does the pull request have enough comments to make it easy to review?
Follows the Single Responsibility Principle — Code should only ever solve one problem. If a piece of code affects a lot of the rest of the code in the project, it's difficult to review.

If these conditions are not met, return the code to the contributor to be improved or separated into different pull requests.

This might seem initially harsh or counter-productive, but over several weeks your team's outputs and productivity will improve.

2. Styling 🎨

Set some basic styling rules for your team and ensure these are followed. Consistent code styling is essential to ensure future developers can understand code easily and work productively.

Some basic rules:

Are variable names sensible and consistently capitalized?
Are there sufficiently descriptive comments throughout the code as required?
Are formatting preferences followed? For example, tabs or spaces, curly brace on the same line or new line, 80 character width or 120 character width?

To save time, you could check these rules are followed with an automatic code linter. Prettier is a good example for JavaScript projects.

Again, if these standards are not met, stop checking the code and return it to the contributor for review.

3. Security 🔐

Set security standards for your project and check these are being followed religiously. The rules to be checked will vary depending on your project and organization, but some best practices are:

Run your project through vulnerability scanning solutions, like LGTM
Don't hardcode credentials for testing or include secrets in the repository
Don't disclose too much information in error messages, which might give hints to an attacker
Ensure any database queries are parameterized
Don't trust user or client input blindly — your client or web application can be modified. For example, URL parameters that access resources should be checked.

If you identify security issues in a code review process, stop and speak to the contributor. It might be a sign of a more serious issue in the project or a lack of training, both of which will need follow on interventions.

4. Performance 🏎

Is the project as performant as it could be, or are these obvious optimizations that might improve performance?

For example:

Can any of the code be substituted with a more performant library or a language native function?
Is there any debug or logging code that could be removed?
Is caching being used if applicable?
Are images and assets appropriately compressed?

There are a myriad of tools that can help you optimize the web performance of your project. Good places to start are Chrome Lighthouse (also called PageSpeed Insights) and DebugBear for frontend projects.

5. Testing 🧪

Tests automatically check that code does what it should, making them a key part of the code review process.

Firstly, check that tests are present and well documented for all common functionality. If some functionality isn't covered by testing, it should be well documented why this is the case.
Secondly, make sure that tests are well isolated, so you can find the problem quickly if a test fails.
Finally, do the tests test the code? Often, they claim they do, but don't actually assess the intended functionality of the application.

Jest is a good option if you're looking into automated unit testing. For automated end-to-end tests, check out Cypress and Reflect.

However, always remember that not all tests are bullet-proof and shouldn't be relied on completely, as the next checklist item proves…

6. Does it actually work? 💩

It seems simple enough, but we've all made this assumption before.

If you are on an agile sprint team, the code should always be checked against the acceptance criteria provided by your Product Manager or Product Owner. If acceptance criteria are not met, ask the contributing developer why.

Another common issue is that code works locally but not in production. All code being reviewed should be deployed to a staging environment that is consistent with your production environment. This prevents environment specific issues.

FeaturePeek users don't have to worry about inconsistencies between staging and production environments, because it automatically deploys branches into a dedicated environment every time a pull request is opened. This allows the reviewer to see the changes instantly and share this with designers, managers and other non-technical stakeholders for further feedback.

7. Positive code review culture 😻

Before you send your code review feedback or sit down for a meeting, check that your comments will help your team to improve rather than be seen as criticism.

Code reviews are one of the most regularly occurring interactions you have with the rest of your team. Take the time to ensure you've framed code review feedback in a positive way, so that you're contributing to a positive, collaborative code review culture over time.

It can help to reframe critical feedback as constructive statements. For example, if the code is missing test coverage, suggest "could more test coverage benefit us here?" to test and challenge the understanding of your team members.

8. Review the checklist constantly 🤔

Your checklist is only good if it's up to date. That’s why it's important to continually review your checklist and ensure it meets your needs.

Your code review needs will change over time as new team members join or your project gains new requirements. For example, if you added new tooling to your CI process, this should be included.

FeaturePeek gives reviewers a floating UI overlay for your deployments, making it easy for your them to leave great feedback. This way, reviewers can leave feedback sooner and it's easier to keep your code review checklist up to date with the latest requirements.

Learn More

Checklists are just one of the many tools UI/UX developers use to keep productive. Let us know how your team stays productive by sharing with us in the comments below.