What it Means to Care as a Developer and Why You Should Want to

One of our core values is “care.” This blog post is about how Cory interprets “care” as a developer.

Identifying your company’s core values helps in many ways. It helps you identify the right people to hire and justify firing the people who aren’t a good fit. It helps you choose which projects to take on and which to let go of. And it gives your team a clear model to aspire to. BizStream lives by seven Core Values, one of them being “Care”. The following is my interpretation of one of the ways it means to care at BizStream. 

What Does it Mean to Care?

There are many ways to care at BizStream. Here is the “official” list:

  • Give a $#!%.
  • Take care of our house and the people who live in it (our office environment, our team).
  • Care about your work, the project being successful, the client being happy, and the team working well together.
  • Care about following and improving our processes and policies.
  • Find joy in helping others solve problems.

This blog post will focus on, “Care about your work, the project being successful, the client being happy, and the team working well together.” During my time working at BizStream as a web developer and leader, it has become easy to tell when a person has put careful thought into what they are delivering versus just getting a task off their plate as quickly as possible—often making more work for others. Here are some things to consider before handing off your work.

You Should Know Your Task is Done to the Best of Your Ability

Too often, developers get caught up in deadlines and schedules, and the temptation to check in code that “probably” works is great. The problem is that making those assumptions, more often than not, leads to more work later because you have to get back in the headspace of the project and spin it all back up. It’s better to be 100% sure it’s ready now.

  • You should KNOW your code works.
  • You should KNOW your test plan is detailed and complete.
  • You should KNOW your report is flawless.
  • You should KNOW your work is done on time.
  • You should KNOW you communicated everything that needs to be said.

QA Should Find Nothing

Within reason, of course. We’re all human, and we all make mistakes.

Anything that could be found, should have been tested for by you. You know what your code does, you know what it interacts with, you spent time at the beginning identifying potential weaknesses and a test plan. There’s no reason QA should find big obvious problems. 

Anything big that could be found, should be found in PR. When you’re putting your pull request together, feel free to point out any areas of your code that seem weak or you don’t feel great about. This is the last opportunity to have someone else weigh in and help out.

QA should be looking for edge cases and that your changes flow well with the rest of the app. They should not be your last line of defense against 404 pages and buttons that aren’t wired up. In the course of development, you should have been clicking everywhere and doing tests on the fly. You know that when you parsed that string, you need to check inputs that are too long or too short. You know that when you filter on a date range, you need to test dates and times right at the limits of the range to be sure you got your “<” and “>=” right. And if you don’t know that, it will come with experience.

Take the Time to Review Your Work

Take deliberate time to review your work. A self-review of your work is a given. It’s a part of development. Senior devs, how many times in all your years have you been in a hurry fixing a “simple” bug, checked it in without testing, only to have it blow up for QA, and they send it right back to you because you spelled something wrong? Something that would have been obvious if you took the 5 seconds to pull up the UI and hit F5. Just one example, but there are so many places to take deliberate time to ensure success down the line.

Don’t do this:

  • Finish coding up your last story
  • Test the story
  • Check in the code
  • Create PR

Do this:

  • Finish coding up your last story
  • Test the story
  • Test all the functions surrounding the story
  • Search for “//TODO”, “//HACK”, “//FYI”
  • Review all your code changes
    • Did you leave any console.log?
    • Did you test everything that the code touches?
    • Is there anything you wrote that you don’t feel 100% on?
      • Fix it or make a note of it in the PR so someone else can weigh in
    • If you were reviewing this PR, what would you think?
    • If you had to come back and maintain this code in 5 years, could you?
    • Check in the code
    • Create PR

Caring Every Day

There are hundreds of ways to show you care in any job on any project, and the effects of the caring you put out there can be felt throughout your team. Imagine being the QA person for someone who obviously never tests their own work and uses QA as a catch-all for their bugs. Resentment would, understandably, creep into that relationship quite quickly. These are just a few examples of how a developer can show they care on a daily basis, and how we at BizStream try to live up to our Core Values every day.

About the Author

Cory Vandenbout

In an office of eccentric teammates, Cory brings the normal. Low key and mellow, Cory has been developing software for BizStream since 2006 and leads the development team for YouthCenter and CaseStream, two of our products. In his off time, Cory digs home automation, movies, and plays sports and games. He enjoys spending time with his wife Becky, daughters Zoe and Ella, and his dog Leia.

Subscribe to Our Blog

Stay up to date on what BizStream is doing and keep in the loop on the latest in marketing & technology.