As an engineer, it is natural to want to optimize your time. 

When you are at the forefront of new revolutions in the tech industry, spending hours doing manual tasks seems almost unacceptable. 

So if you’d want to save hours finding, requesting, and accessing links you use in your everyday work, we’ve got you covered. 

Here are ten shortcuts you can instantly create to knock off hours you spend every week being not so productive after all. 

1. Create variable shortcut o/issue/{id} to instantly open a ticket

Whether you use Linear or Jira, it is inconvenient to open the platform every time you have to look for a ticket. 

At OSlash, we use variable shortcuts to do away with the manual task of opening a platform and searching with the ticket ID. 

With a variable shortcut such as o/issue/{id}, you can fire up the relevant page from anywhere on the browser, such as with o/issue/63. It’s that easy.

2. Contribute actively to the writing culture with o/documentation

More than 90% of software engineers feel that documentation is boring, something that takes away their focus from more pressing issues at work. 

Well, it may be boring, sure, but without proper documentation, software is just a black box. 

The question persists: How do you make documentation a priority when there are always so many things on an engineer’s plate?

Here are a few ways: 

i. Make sure documentation is inherent in the company culture by tying it to every engineer’s evaluation

ii. Educate engineers about how much the company values good documentation during their onboarding

iii. Reduce friction by creating a shortcut o/documentation for Confluence, Slab, Notion, or any other tool used for this purpose

3, Monitor all releases in the pipeline with o/releases

Our engineering team finds this shortcut immensely helpful to directly view all the releases on GitHub once they’ve pushed something to production. 

This is one of the most frequently visited pages in the company. And directly shaving two minutes each time this page is viewed cumulatively saves the team many hours every week. 

4. Check the status of your system with o/dashboard 

By capturing the downtime and other network events in Datadog, at OSlash, we monitor our performance and event analytics with o/dashboard. 

It helps the IT and the DevOps teams to minimize downtime and prevent critical issues by swiftly identifying the right alerts to provide a reliable product to all users.

The shortcut allows the designated on-call engineer to quickly take a look at network issues as and when they are reported and brought to attention. 

5. Go through the pull requests using o/open-pr

You can save minutes of your time every day by creating a shortcut o/open-pr for everyone in your workspace. 

This way everyone would be able to view the list of open pull requests in GitHub or GitLab and review them to merge PRs faster. 

6. File and know which bugs to prioritize with o/bug-tracker

Bug-tracking and bug-bashing projects are often shared across the frontend, backend, testing, and QA teams. They form the backbone of a flawless, complaint-free product and user experience. 

It is sound to streamline the debugging process by providing everyone in the company a common platform to register bugs they (or users they’ve interacted with) have encountered in the product. 

This can as easily be an Airtable spreadsheet as a Notion document or even a simple Google Sheet to make it easier for the teams to work together without wasting hours scouring for scattered bug reports. 

You could add the ticket ID, the priority tags, DRI etc. to the list. 

7. Switch between different environments in a jiffy with o/(environment)

Developers usually work across multiple code bases for different environments such as staging, demo, development, and production. 

Not only do engineers find it difficult to access and find these links, even the sales team run the risk of demoing in the wrong environment. 

To improve this aspect of a coder’s life, we have different shortcuts for each environment - o/staging, o/dev, o/demo and the like. 

Turns out that separating your app environments in a readable and flexible way from the very beginning saves hours of time and improves the code quality.

8. Reflect on the sprint gone by with o/retrospective

Retrospectives, held at the end of every sprint, are important to discuss and deliberate what went right and the scope for improvements. 

Here are the questions teams must probe into to benefit from a retrospective: 

i. What worked well for us

ii. What did not work well for us

iii. How can we improve moving forward

A Miro board is a great place for teams to come together and reflect on the sprint gone by. 

With o/retrospective, you would allow everyone to be on the same page, and benefit even those who could not attend the meeting.

9. Keep your team up to date with the progress with o/demo

Software development generally moves faster than any other function in an organization. The end product continues to undergo changes as software engineers deploy code. 

But without frequent demos, it moves ahead in a silo. No one likes to find out about a feature after it’s been released. Sales, marketing, customer support, everyone needs to be updated because the lack of it might hamper their work in turn. 

The recommended way to keep everyone in the loop is by conducting regular team-wide demo sessions or sprint demos. 

The purpose of such demos is to showcase all that’s gone into improving the product and building new features. It allows everyone to chime in with questions, suggestions, feedback, and understand the progress on the product. 

To make sure that the exercise is a success, here are some good tips: 

i. Hold the demo at the end of the sprint to showcase all that has been done during the time. You can rope in the entire company or the leads of each function

ii. Save the last part of the demo to invite questions, feedback, and suggestions from other team members

iii. Create a living deck with a few slides dedicated to each sprint. Start creating the slides for the latest sprint right after the slides for the previous one. 

Building on a living document o/demo would help everyone follow what’s happened in the past few sprints and keep track of the progress from the first to the latest. 

A good demo culture is a prerequisite for a culture of sharing and transparency. And o/demo, accessible to everyone in the company, is the first step in that direction. 

10. Empower your team with a mutual understanding if what's required with o/trd

While every engineer’s first impulse would be to get a problem and jump right away to writing a solution, that is often a terrible idea. 

The first action should be to consolidate every feature’s product development workflow and provide a readable summary of what’s required from the team technically. 

The document that helps everyone come to this mutual understanding is called a technical requirements document or o/trd. 

This doc outlines how you’re going to address a technical problem by designing and building a solution for it. It forces engineers to examine the problem, end to end, before jumping to code. It helps in ensuring all scenarios are addressed, all checkboxes are ticked, and makes for a better scoping mechanism. 

For a comprehensive guide to writing such documents, here is an article we hope you find useful. 

‍