Every day is a bit different. You may have new priorities and problems to solve. Meetings and issues that require your attention. Developers need to focus on the code they are writing. When you stop working, it can be hard to get back into a development flow.
What is flow? Flow is described as a cognitive state where you are completely absorbed in an activity. You are intensely focusing on your chosen activity.
Returning to your work
There are times when you need to stop working. You have to go to a meeting, eat lunch or leave work for the day. When you return, it takes time to get back into state of flow. What can you do to help get back into your development flow?
1) Leave yourself note
The simplest thing you can do is leave yourself a note. You can leave a comment in your code to remind yourself what to do next. Use email or have a tool like Slack remind you of what you were working on.
2) Rule of 3
Before you leave for the day, write down three things that you want to accomplish. When you start work the next day, work on those three things. J.D. Meier explains why the rule of three is a simple way to get results.
3) Make a shutdown process
A shutdown process is a set of tasks that you do to help you finish up for the day and prepare for the next work day. Workday shutdown rituals help you to separate your work day and personal time.
What is accessibility? It is making your website as usable for as many people as possible. You want to make sure it works on different devices and slow networks. People with changing abilities due to aging, physical issues or situations.
To make your website or app usable to as many people as possible, you’ll need to use different accessiblity resources and tools.
Color is one tool that can make or break a design. Choosing the right colors can be hard. Radix Colors helps you to select colors to design beautiful and usable websites and apps.
Many web development teams use style guides or a design system. These tools help to make your website or apps consistent. A11Y Style Guide gives you tips, tools and WCAG guidelines for developing. It includes a pattern library focused on accessibility. You can use their guide as a reference for your own style guide.
You want to build things that people want to use. What do you need to know? You need to understand how people use websites and what you need to know to optimize it. The Accessibility Developer Guide explains what to look for and how to fix it. Many problems can be fixed by looking at how you write HTML.
As a developer, you need to test your code. You also want to test how use to easy your UI is as well. There are different tools to choose when you test the accessibility of your website or app. Here are a couple to start with:
Your keyboard. Many blind users navigate a website using their keyboard. Use the WebAim guide to Keyboard Accessibility.
What is technical debt?
Technical debt results when a programmer or team chooses speed over perfect code. They make decisions that focus on shipping code instead of following design considerations. Product Plan gives you an in-depth look at technical debt.
Is all technical debt bad?
No. Like financial debt, technical debt can be a necessary tool to help you achieve your goals. It becomes a problem when you haven’t managed it.
How do you manage it?
1. Treat tech debt as a tool
Every tool has its benefits and issues. When you are building new product, you need to decide how you are going to solve certain problems. You may create some technical debt while solving certain problems to get your app out the door.
2. Build it into your processes
Tech debt becomes a problem when you ignore it. To prevent it from becoming a problem, add it to your development processes. Track what debt you can and need to address and what you can live with. Document everything. Good documentation helps you understand the difference between debt, quirks and configuration needs.
3. Good testing can catch issues
Do you test all your code? Make sure you have enough testing to cover all your code.
4. Dedicate time to work on it
Plan on addressing the “bad” debt as part of your work load. If you schedule time to address it, bad tech debt won’t adversely affect the performance of your app.
5. Manage FOMO
There is always a new library, framework or programming language to learn more about. You want to limit the new things that you want to add or try out. Save the new things for a different project. Then, you won’t introduce unintended tech debt that you will have to fix.
When you write software, you’ll create technical debt. It doesn’t matter how good your processes. You can’t eliminate it. Tech debt can be managed.
Font sizes are tricky to get right. If you choose a size that is too small, you text becomes too hard to read. Make it too large and users can’t won’t read it as well. What looks good with one font won’t work for another. CSS-Tricks explains how to resize your fonts.
Use color and contrast to help guide your users
Color and contrast can help user perform tasks, keep track of where they are and pick out links from text. Choosing the right colors for you users can be challenging. Some color combinations are difficult for users with vision problems. The Web Accessibility Guidelines v1.0 explains Contrast and Color. Plus, it gives you a sample color palette to choose from.
Make things easy to click
Older users can have trouble clicking on buttons and links. You want to make the big enough so they can click on them.
Use UI patterns that are easy to remember
Establish a design style that is consistent and easy to use. Use icons, fonts, text, photos and other design patterns to help reduce the learning curve. Include breadcrumbs to help users keep track of where they are.
Your CSS isn’t working right. Sometimes your styles don’t do what you expect them to do. What can you do to find the problem and fix it? Debugging CSS can be challenging.
Check for syntax errors
Typos and other mistakes can creep into your CSS. Read it from the bottom to the top. When you read it backwards, you may spot errors.
If you don’t see anything wrong, try using the W3C CSS Validator. It may find something that you missed.
Use the Browser DevTools
Most browsers include developer tools. Use these to help diagnose the problem. You can change, update or comment out code. On MDN Web Docs, you can learn more about FireFox’s Developer Tools. If you prefer Chrome, check out Chrome DevTools.
Does your browser support it?
If the browser you are using doesn’t support the CSS property and value you are using, it will ignore it. You can use Can I use to learn if your browser supports this feature.
Comment out or disable the code
When you comment out the code, you can test and figure out where conflicts are occurring. If that doesn’t work, use DevTools to see if one rule is overriding the one you are working on.
Add a border to styles that are causing you trouble. The border can help you to see the relationships between elements.
Double check you are editing the right file
Are you sure that you were editing the right file? Did you copy it from your local development machine to the production server? When you are writing code, it can be easy to have many files open at once. Double check to be sure you edited the right one.
Take a break
Sometimes you need to take a break. Go for a walk, talk to a friend, get some water. Time away from a problem can help you figure it out.
Debugging CSS still not working?
Explain the problem to a coworker or a pet. Sometime talking to someone else about the problem helps you figure out what to do next.