Principles and Guidelines For Contributors

Ben B | 1/7/19

The following Principles and Guidelines are outlined to help new contributors get up to speed quickly. The original title for this post was “New Contractor Training” and the purpose is still very similar.

Principles

Principles are fundamental propositions that can serve a foundation for a system of behavior. In other words, these principles will help you make decisions that will lead to your success at Buink, your success in our industry, and may even improve your success in life.

Although “what you do” while you’re billing time is important to Buink, even more important is “why you do” what you do. Use the following principles to help you decide why one decision may be better then others:

Guidelines

Guidelines are examples and recommendations for ways to implement the principles.

Honesty/Transparency Guidelines

Easy Time Tracking

Time tracking at Buink should be easy if you’re doing it right. Just click the start button (as shown in the GIF below) and let the Toggl Chrome Extension do the rest. When you start a new sub-task, the previous one automatically ends, so you can focus on what is next and move efficiently between tasks.

Granular Time Tracking

To avoid and reduce mistakes in tracking time, we suggest that you continually note and consider what you’re billing for at any given moment. To make this easy, use checklists to create a plan for all substantial tasks. Items in the checklist are sub-tasks and you can easily track time against any sub-task. The checklist item should describe what you’re doing at any given moment.

Weekly Review

At the end of each week, you’ll get an email from us asking you to review your time and send a summary. The goal is to first, make sure there were no mistakes, and second, write a summary of what you did for each client. We like to be transparent with our clients, so they get a full breakdown of every time entry and your summary with their invoice.

 

Efficiency Guidelines

Card Priority

Trello boards have columns of cards called “lists” and each list has one or many cards in it. All cards on the top left are higher priority then the bottom right. So, you’d always want to work and communicate in order of priority. For example, if you had a card “In progress” and a team lead moved another card above it, you’d want to switch your efforts to the higher priority card.

Urgent Cards

Urgent cards should never be blocked. Whenever an urgent card is waiting on someone they need to be notified via chat. The most common way cards become blocked is waiting in review, so when this happens, you’d copy the link to the task and send it to the team lead via chat.

One Card At A Time

In a perfect world, you’d only be working on one card at a time. When you finish that card it would always be approved and you’d move on to the next card. You’d never start two cards at a time because it is impossible to work on two cards at one time and doing so could cause delays in the project.

Unfortunately, we don’t live in a perfect world. Sometimes cards get sent back for more changes or sometimes cards you’ve worked on become blocked waiting on communication or for other reasons. That said, we always want to strive for the perfect world.

 

 

Clarity (communication) Guidelines

Communication in Context

The most common place for communication is on the Trello card because the card is the official work order and we want to keep a record there of all requests, comments, and questions. That said, it doesn’t make sense to ask complex code related questions or detailed design related questions anywhere other then in the best context. So, if your comment is about code, ask it within a pull request (PR) and add the link on Trello. If your comment is about a design, ask it on the design and add a link on Trello.

You can see that the card becomes the hub for all communication. Even if your comment is urgent, you’d make a comment in Trello and then copy the link to the comment to send elsewhere.

 

Quality Guidelines

Production Ready Deliverables

Although a team lead reviews every deliverable, you should not rely on them to catch mistakes of omission, misunderstanding, or inattention. Mistakes are inevitable, but the best team members take accountability for their work and try to deliver it fully completed the first time.

All completed tasks are eventually sent to the client for approval, which closes the loop and secures their happiness (and payment). We can’t have that closure with partially done tasks.

We should always assume that clients don’t have a great imagination (mostly because they don’t fully understand your job, so it is impossible to imagine what you’ve done). They want it done right, the first time, quickly, and exactly.

Because clients don’t typically know how to code or design, it is hard for them to use their imagination to see the value they received for incomplete work.

Review Your Own Deliverables

Before submitting a deliverable for review, take a minute to review it for the following two things:

First, take a step back from the minutia and look at the overall quality of what you’re sending. If you’re a developer, take a look at the finalized code (your PR) and see if you left any debugging or unused code. If you’re a designer, review the finished product from the eyes of the client. Then make any final changes (if needed).

Second, double check that you satisfied all the requests and goals of the original task. Very often you’ll find that in the effort to get some of the large parts done you overlooked easy requests that when missed could slow the task from completion.

Proud of Every Deliverable

Every contribution should be your best work. You should push back on anyone who tries to stifle that. Sometimes you’ll have to push back hard and sometimes you’ll have to pick your battles, but every time you deliver a finished product, you should be proud of your accomplishments.

If your quality is being stifled by other team members, let them know. If your quality is being hindered by a team lead, make sure they understand why you did it the way you did and continue to mention it in the future. If your quality is being suppressed because of the client, use your best persuasive power to try to get them to do what is right for the project, but know that the customer is always right.

Self-documenting Code (developers only)

This guideline falls under Quality, but it is actually related to communication as well. Most developers think that when they write code they’re communicating with a computer to tell it what to do. What they are actually doing is communicating to future developers what the computer is supposed to do. As such, we write code that anyone on the team can (or should) understand.

In other words, we call variables what they are, we call functions what they do, we call classes what they are, we define complicated logic with descriptive variables, we call files what they are, we locate files in an intuitive location, and we take every opportunity to use code to document what the code is doing.

Consider the following:


if(person & person.id !== null & person.children[i].in_school & person.spouse.favorite_food === 'chicken'){}

There are lots of assumptions in that logic that may be true now, but need to change in the future. It is also very long to read and difficult to understand.

The following example is the same logic, but easier to read. Some developers would prefer the first, but only because they think they’re writing for computers.


var personIsSaved = person & person.id !== null;

var hasChildInSchool = person.children[i].in_school;

var hasSpouceThatLikesChicken = person.spouce.favorite_food === 'chicken';

var shouldGetDiscount = personIsSaved & hasChildInSchool & hasSpouceThatLikesChicken;

if(shouldGetDiscount ){}

Thinking in terms of communicating to future developers causes us to focus more on the language we use. It become very important that we create and use language in a way that reinforces our system and it’s objects, relationships, functionality, and logic.

About The Author

Ben currently works as a senior developer and technical business consultant outside of Boulder, Colorado.

Read more about Ben

About Buink

Buink Web Development is a development shop founded in 2009 by Ben Buie. For years, Ben built and modified web assets for clients in Utah. In 2011, he moved the company to Colorado and in 2015 he started taking on new clients full-time.

Buink’s Core Values:

  • Cost effective technology (with business strategy in mind)
  • Eloquent, maintainable code
  • Responsive and transparent communication

Read more about Buink

Seth Lofgreen
Seth L.
21:36 29 Jun 19
Ben and team are incredible to work with. They are reliable and proficient. I'd highly recommend hiring them for web development work. SethVOLTAGE
Craig Adams
Craig A.
20:50 18 Jun 19
It was a pleasure to work with Ben and his team. It is rare to find such attention to high standards of coding and devops.
Lexi Steele
Lexi S.
15:36 18 Jun 19
Grateful to have Ben and his team as such a capable, reliable partner for completing client work!
Tom Showalter
Tom S.
13:18 14 Jun 19
I reached out to Buink after finding Ben’s name in a local developer/consultant listing in 2017, and I have to say, it has been an absolute pleasure to work with Buink. Ben consistently understands not just the development task laid in front of him but the business application behind the task. I’ve never felt more comfortable with a development team than I do with Buink. I truly feel Ben and his team are integral partners in the success of my business.read more
Craig Scribner
Craig S.
22:01 13 Jun 19
Buink saved my company's bacon at a very critical moment during my company's evolution. With almost no warning we had found ourselves stranded without any dev support, even though we had hundreds of users from big brands every day logging into our application and relying on things to keep working. We couldn't afford to have system failures, and I was amazed at—and will be forever grateful for—the way the Buink team stepped in and calmly assumed control of the craft. We and our clients were safe in their expert hands from that moment forward. I whole-heartedly recommend the quality of their work and the dedicated and ethical leadership they continually provide.read more
Marilyn Ference
Marilyn F.
22:47 13 May 19
I could not recommend Buink Web Development more highly. Ben and his team have recently developed a budgeting app for me (both web and IOS). I have had the opportunity of working with them for over a year and I am extremely happy with the results. I would say that the biggest plus for me is that I trust Ben completely. From the very first, Ben has helped me make decisions that were in the best interest of my company. I have never felt like he is taking advantage of me. Ben does his best to keep the whole process very open and upfront. I have really appreciated that.I tell people all the time that I love my developers. And I do. I'm very happy that I chose to use Buink to develop my apps. It was the best business decision I could have made.If you are looking for someone to develop a website or app, I strongly suggest choosing Buink Web Development. They are fantastic!Marilyn Ference, President, Defend Your Money, LLCread more
James Landon Buie
James Landon B.
01:33 28 Aug 18
Great company to help with all your web design needs!
Next Reviews

Connect with Buink

Connect with Buink via email, send us a message, or subscribe to our blog.