There has probably never been a better time to be a software engineer. It seems like every day another big tech company is offering a new absurd perk that comes with employment. I’m not kidding, I saw an article on a company in China where developers get massages while sitting at their desk.

It all sounds great, till you realize they give you those perks because your job is a mind numbing path down a dark hole of irrelevance.

While some smaller companies have trouble competing with the giants, Buink doing well for the following reasons.

As a developer at Buink, you will…

Be a Change Maker

Code is powerful. The better we can write and maintain it, the more power we have. The more power we have, the more good we can do. Yes, power goes two ways and with it you can definitely make the world a better place.

We love projects like one we did for Summit Access. They invented a new type of surgical needle that helps prevent nurses from getting poked with contaminated fluids. We helped them build a site to share their product with hospitals and surgeons and our code helps save lives in a very real way.

Our code helps save lives in a very real way

Another project of note is a web app for Best-Line. They’re a “Made in USA” window shade manufacturer and our app is helping them build and track orders from start to delivery. Our code increases their productivity, reducing the cost of their product, keeping manufacturing jobs in America, and keeping food on the table of many families.

Lastly, FESTV is an ambitious startup in the streaming video space. We built and maintain a consumer facing, streaming video site that is interesting for a couple reasons: not only is it rewarding to help an entrepreneur realize his dream, but it is also rewarding to help many small independent filmmakers distribute their films directly to consumers allowing them to spread their messages without the Hollywood industrial complex deciding winners and losers.

Be Best in Craft

We’re passionate about delivering the best, most intelligent, most readable, most efficient code in the industry and we look for developers who have that same hunger.

It isn’t important that you’re already the best in craft, what is important is that you want to be and you’re willing to work for it. We find that this type of person comes ready to both share what they know, and learn what they don’t. This mentality is crucial to our success. The minute a developer thinks they know it all, they stop learning. The minute they stop learning, they stop moving towards the goal of being best in craft.

One huge way we support this goal is code review. Unlike other companies where code review is an exercise of patience and often the blind leading the blind, Buink’s code review is always done by lead developers who have proven themselves and their code, and also mastered Buink’s methodologies.

Some of the best athletes get there by having incredibly high performing competitors. Although we don’t encourage rivalries within our team, we do look to other team members as a standard to meet. In addition, we often compete on teams that have both in-house and/or overseas developers. This forces us to innovate and improve so we keep our seat at the table.

Be Challenged

In addition to challenging ourselves to be best in class, we are also challenged by Buink’s growth culture.

One guiding principle in our culture is that we want to give our developers experience in all aspects of web development. All new developers start by writing code (even the most experienced) in an effort to help them learn our methodologies. Then our goal is to push them through the full-stack and beyond as quickly as possible. As soon as they’re trained in the “Buink Way” of doing things, we can have them lead a team, manage code review, and be the point person for code quality on a project. The next step is to get them working with the client, architecting solutions and managing production environments.

Regardless of where you find yourself on a project, we push to always give you opportunities to put your pen to the paper (so to speak) and write code with at least part of your time. This keeps your mind fresh, keeps you challenging yourself, and keeps you learning.

Be Valued

Buink’s clients value solid, intelligent, well written code, this is why they hire us. We look for that type of client as well. They’re focused on long-term success and they value a thoughtful code base over a plate of mashed potato code. This gives you an unusual amount of freedom to not only improve their code base, but also your own skills.

Be Balanced

Although we know you are passionate about your craft, we also know that career is only part of a balanced life. We work hard when we’re billing hours, but we’ve designed our company to allow you flexibility for time with your family, time for your spirituality, and personal time.

One great example of our commitment to being balanced is the fact that remote work is the norm, not the exception. From our communication and collaboration software to our processes and operations, everything is designed to allow you to work from anywhere: the beach, the local cafe, a co-working space near your home, or your home.

Another example is the fact that we don’t really care when you work, but just that you complete tasks assigned to you in a timely manner and that you let us know what to expect in terms of your availability.

Be Marketable

One of the beauties of working for a “dev shop” is that you’ll always be working on something new and different. Just when a project starts to get stale, you’ll be added to another one. It’s almost impossible to get pigeonholed into working on outdated stuff.

We put a lot of effort into choosing our recommended technologies and our clients almost always accept our recommendations. New projects are started using the latest technologies that have been proven to add value.

At Buink, you will not feel stagnate in your career working on last decade’s language or software.

Be Transparent

Honesty and integrity are deeply held values of our founder and an important guiding principle of the company. We find that transparency reinforces our value of doing what we say, delivering the quality our clients expect, and always seeking to represent things as they really are.

One of the guiding principles at Buink is to be a code butler. Although our dress is a lot less formal, our attitude should be no less helpful.

The butler is there to serve, to make life easier. The butler is faithful; they’re sure to complete all requests without being asked twice. The butler avoids saying no and never has a bad attitude. They’re not yes men/women, but they’re helpfully humble and they’d only say no if it were illegal, unethical, or counter productive to the interests of their family.

If the butler is asked to do something that seems as if it is not in the best interest of the family, they make sure to voice their wisdom and help the family understand why it may be a bad decision. After making the family fully aware of the trade-offs, they cheerfully complete the request. They understand that they don’t always have the full picture.

These are qualities we try to embody at Buink. We’re wise and experienced. We’re happy to help and we’re ready to share our expertise so our clients know the trade-offs of what they’re asking. If you know me, you’ve heard the phrase, “happy to help.” Whenever I say it, I’m reminded of my true purpose as a servant coder.

The following are a few ways we strive to embody these butler attributes.

We Know What We Don’t Know

You’ve heard the phrase “the customer is always right” but what do you do when, in the famous words of Steve Jobs, “people don’t know what they want…”.

I’ve found that Jobs’ was correct, particularly when we’re talking about new technology. The reason clients don’t always know what they want is that there is a big difference between using technology and building technology.

You can quickly discover this truth for yourself by using a website builder to create a website from scratch. These builders allow you to give the site any look and feel that you want without knowing any code. If you have time, give it a try and you’ll quickly start thinking, “something is off, but I can’t quite put my finger on it.” I know the feeling, because that was exactly how I felt when I built my first site in 2006. I added images, links, and content, but it just didn’t have the professional feel of the sites and apps I know and love.

Through years of experience, developers learn the tricks of the trade, but this knowledge often tricks them into thinking they know what the client wants. Truth is, developers don’t know what the client wants EITHER!

Just two weeks ago I had an experience with a new developer where the client asked for a particular feature but the developer thought it was too expensive, so without circling back to the lead developer or the client for more information, they went off in left field writing code they thought was better. Needless to say, the code had to be trashed and their time had to be discounted. Rather then learn the business case for the change, this developer took matters into his own hands.

So, if no one knows what the client wants, where do we start?

We start with the business needs and goals. Luckily, the client knows their business better then anyone.  So, it is the developer’s job to fully understand the business case and business goals; and then use their web development expertise to show the client solid solutions. Also note, it is not the job of the developer to decide if the business strategy is good, but more on that later.

The second part of the Jobs’ quote is probably more important than the first, he said people don’t know what they want “…until you show it to them.”

If developers take the time to learn the business, they can truly shine by creating descriptions, wireframes, designs, or web interfaces that satisfy the case or goals.

We Try to Ask Good Questions

From a very young age my dad taught me the value of great questions. Questions are the door to the human mind; with them we can dig into what clients say and find out what they really mean; in other words, what they really want (cha ching!).

“The wise man doesn’t give the right answers, he poses the right questions.” – Claude Levi-Strauss

We start with good questions because we need to fully understand the client and the business needs. Some examples of good questions are the overall goal of the desired web asset, the top three goals of a new feature, expectations for the final product, deadlines, and budget requirements.

There are bad questions, if you don’t believe me, take 3 minutes to watch “No Such Thing as a Stupid Question.” Bad questions are ones that can be answered by materials given to you already, answered by google within 10 seconds, or questions that are unrelated to the task at hand. Our time with a client is precious and we don’t want to take too much of their time or waste their time in any way.

We Love To Listen

Client feedback is gold no matter how they give it. If they give us praise, that is an opportunity to understand and pay attention to what they value. If they give us criticism, that is an even better opportunity because we can really get a feel for what they value.

We can dig in and understand what we can improve or how we can provide more value in the future. We need to listen intently and even take notes and review them from time to time. We can also look for thoughtful questions we can ask about the feedback.

You may be thinking, “Sure, but feedback hurts sometimes.” I’ll say this, if you learn to like it, you’ll benefit from it immensely. I used to lift weights quite frequently when I was younger. I remember when I started, I hated the feeling of being sore. It was torture! The day after a big leg work out I had a hard time even walking. So I started telling myself that the feeling of being sore was my body getting stronger and bigger, swole. 🙂 You might not believe it, but I love the feeling of being sore now.

The uncomfortable feeling of feedback is just the feeling of you becoming better at your craft. There is always something to learn from it. Code butlers look at feedback as a valuable opportunity to dig in, understand, and improve. I love the quote from Dr. Stephen R. Covey, bestselling author of “The 7 Habits of Highly Effective People”, he said, “seek first to understand, then to be understood.” This mantra is the easiest way to build trust and confidence with a client.

We’re Not The Super Hero

Think of the butler for a second, the movie is never about them; they’re there to support the super hero or the lead role. They want to make the hero shine. So do we!

Remember, we’re here to solve the client’s problems, not to give them more. We should never assume that a client has more time than we do or their time is less valuable then ours.

Let’s take a real world example; a client asks for a change to all product pages on a site but we find that this change will require some manual work in the admin (changing text, etc). We obviously don’t want to bill at a developer hourly rate to do data entry. We also don’t want to give our client more work.

This situation is a perfect opportunity to strike up a conversation (using good questions and great listening) about ways the client would like to address the problem. A bad question would be, “how do you want to solve this problem?” A good question would be, “here are three options, which one do you think is best?”

I want to emphasize that we should always try to give them three options and let them make the decision. One option is that we could have one of our people at a lower rate do the data entry. Another option would be that maybe the client has someone that could do it. Lastly, we could write a script to update the data all at once, or we could just have the developer do it manually. Each one of these options has trade-offs but we never want to assume that we know what the client wants.

We Align Our Incentives

Our desire to serve our clients is a big reason that we don’t charge by the project; we only do hourly work. We always want our incentives aligned exactly with our clients. We only charge for the value we provide, nothing more and nothing less.

We have many reasons to operate like this, but here are a couple that come to mind quickly: we never want to be tempted to cut corners or sweep things under the rug if a project goes over an arbitrary budget unsuccessfully predicted at the beginning of an agreement, we don’t want project deadlines to be jeopardized by a disagreement of scope or inability to agree on a scope, and we don’t want to make excess profits on one client in hopes that when we lose money on future projects it all evens out.

We also don’t set one blanket hourly rate for the whole company. Some developers provide less value then others; so, each developer has an hourly rate that reflects the value they can provide to a given project. Every hour they work, we get paid, every hour they work, the client gets code, and every hour they work, the project has a developer with no other incentive then to deliver high quality, high value work.

Conclusion

Hopefully, this article was helpful. Have you ever worked with a code butler? Or the opposite? I’d love to hear your thoughts in the comments below.

I’ve been heads down, fingers coding, energetically building Buink for over a year with no time for writing. In truth, I’ve been barely keeping my head above water! We keep adding new clients and we keep delivering great solutions; all the while, I’m getting even more busy.

About a month ago, I decided it was time to hire employee #1 and I started the search. I’ve long had several contractors working for me, but it was time to bring someone in-house (although not really “in-house” because Buink is a remote-friendly company). During the search, I had Makency (my HR representative) research everything that comes with being an employer, like benefits, taxes, and all other costs. Her deliverable was an employee cost calculator that I could use to plug in an estimated salary and understand what I need to charge per hour for their time. My findings were interesting, to say the least.

I’ve written in the past about the benefits of using contractors over employees for web development but now I have some numbers to back it up. I’m confident that both employers and employees underestimate the true cost of an employee.

Both employers and employees underestimate the true cost of an employee.

Let’s take for instance an entry level software developer. Glassdoor.com estimates the average starting salary for this position would be $88,863 / year. Yes, I am even a little surprised by this number. If you do a quick back-of-the-napkin calculation on this salary (salary / 40 work hours / 52 weeks) you’ll find that this is $42.72 / hour; not a bad wage for coming right out of school and seemingly a bargain compared to a contractor rate.

But is that the true cost? No.

Do they really work 52 weeks? No, you’re still paying their hourly rate even when they’re out sick, on holiday, or living it up on the beach with Buink’s unlimited paid time off. At Buink (at the time of writing this), we offer unlimited paid time off, 9 holidays, and 2 weeks of sick leave. This leaves on average about 46 weeks of actual value to the employer.

Do you really get 40 hours of value from an employee every week? No! People are only really productive with portion of their time at work. Having painstakingly tracked all my work time for 5 years now, I’ve realized that even the best employees can only bill about 80% of the time they’re at work, so if you estimate a 40 hour work week, then you’re lucky if you get 32 hours of productivity.

So, the back-of-the-napkin calculation that many people unwisely use is wrong! The true cost of the entry level software developer is really $60.37 / hour or $125,567 using a more accurate back of the napkin formula: salary / 46 weeks / 32 hours.

Keep in mind, that isn’t including taxes, medical/dental/vision insurance, equipment costs, workers compensation, office space, retirement matching, and administrative costs. Not to mention bonuses (we don’t offer them at Buink because we’d rather just pay a fair salary then offer a phantom carrot).

When all is said and done, you barely break even on this entry level employee at $77.14 / hour or $160,442.

Unfortunately, this break even number doesn’t take into account the risk associated with hiring, the risk associated with the economy in general, and the ubiquitous need get a rate of return on your investment (in this case, their salary and benefits).

Adjusted for risk and return, my estimate is that this entry level developer is costing about $93 / hour or $193,440.

In light of this, I can’t help but chuckle a bit when I see the irrational bias to “bring people in-house” that permeates startups, tech companies, and businesses in general. There are good reasons to bring developers in-house, like gaining more control over their work schedule, enticing a particular person to stay long-term, or security concerns; but I’ve said it before and I’ll say it again, hiring contractors should still be part of your over all strategy.

I think this is why Buink is growing so quickly. We’re not only gaining the expertise to find and engage high quality developer resources wherever they may be (contractor/employee/remote/local), but our processes and practices allow us to even out compete in-house resources.

Many of you know one of my passions is entrepreneurship. This is part of the reason I became a web developer and one of the reasons I love building Buink.

Part of entrepreneurship is hiring the right people. Hiring is hard and it can make or break your project and company. Hiring developers is even harder because of the lack of supply, the difficulty in assessing skills, and the long-term consequences the wrong hire can have.

This is why I enjoyed reading Fletcher’s recent post this morning, “The hacker’s guide to hiring software engineers.” He included tons of great resources and ideas. It is definitely worth a read.

Inspired by his post I thought I’d add two additions, from my point of view, relating to hiring contractors vs employees and testing potential developer hires.

Contractor vs. Employee

I agree with his section on contractors vs. employees in many instances, but being that I’m a contractor and not interested in being an employee (and probably never will again) I’ve put a lot of thought into the question and summarized several good reasons startups and other companies may want to consider contractors as part of their technical strategy.

Testing Potential Developers

Fletcher has some great recommendations on testing potential developers and in many instances, a test can be helpful. However, I’ve never seen this done well and I have been asked to take these kinds of tests many times. I’m not saying it can’t be done, but I would love to see it improved in the following ways:

1.  Only send people a test if you’re serious about moving forward with that person. Vet them quickly over the phone first.
   • I see companies all the time that ask 10 or 15 developers to take an hour test (unpaid) when they’re only planning on hiring one. I think everyone could agree that is a waste and, some might say, even disrespectful to other people’s time.
2. Make the test relevant to the type of work you’ll be asking of the developer. This seems obvious, but trust me, it is not.
   • Decide on the first task you’d ask the developer to do and make that the test question. If it is database work you need, ask them to setup a model. If it is css work, ask them to create a list of items that is responsive. If it is Angular work, ask them to create a directive that has an api.
   • Too many times people get these questions that have nothing to do with day-to-day coding but have too much to do with nuances of a language that are rarely used in practice.
   • So, they end up hiring book smart developers that sometimes have little experience in practice. The questions you choose should be geared to the types of coders you want to hire, street smart, or book smart.
   • That is not to say that some theoretical questions aren’t good, but in my experience, the biggest driver of projects coming in under budget and on time is street smarts.
3. This leads me to my #1 recommendation for hiring developers. It is related to Fletcher’s tip on a contract-to-hire relationship but a little more specific. Send them a small paid task, maybe 8 hours of work. Have them track their time and see the quality they send back. If they do well, send them more work. If they keep doing well, make them an offer. I’ve had ton’s of success with this strategy.

I recently finished an IOS app using the Ionic framework. I really enjoyed the experience. Ionic has tons of time saving features, and it is based on Apache Cordova, so you can use Cordova plugins to make apps that feel quite native.

My project comps required a button that would allow the user to choose a picture from their library or take a picture. As I searched the web for the easiest way to do this, most of the articles talked about using two plugins ( cordova-plugin-camera and cordova-imagePicker). This made me cringe. Wasn’t there a plugin powerful enough to do both? Not only that, but I got down the road a little bit and couldn’t get cordova-imagePicker to work on my project.

Hopefully this article will save you some time. 🙂

Some caveats:

• I’ve only tested this on IOS, but in theory it should work on Android too.
• I have the following dependencies in my package.json:

{  
  "dependencies"   {    
    "ionic": "^1.7.14",    
    "cordova": "^6.1.1",   
  } 
}

Install Cordova Camera Plugin

You need to install the Cordova Camera Plugin (e.g. I’ve installed [email protected])

ionic plugin add [email protected]

Using the Ionic CLI is important here (as opposed to the cordova CLI) because the ionic automatically adds the following line to your package.json

{
 "cordovaPlugins": [
  "[email protected]",
 ],
}

Make sure your package.json updates. An updated package.json file is helpful because then you can run `ionic state restore` and instantly have the same exact plugins as required by your code. 

Install ngCordova

You can install inCordova with bower:

bower install ngCordova --save

Then include the new file in your index.html file:

<script src="lib/ngCordova/dist/ng-cordova.min.js"></script>

Now you can inject it into Angular:

angular.module('myApp', ['ngCordova']);

See the official ngCordova install directions here.

Start Using The Camera

Here is were the magic happens! Like I mentioned, other articles were saying that you needed both cordova-plugin-camera and cordova-imagePicker, but the latter isn’t necessary.

The most important part of what I’m going to show you is…

$cordovaCamera.getPicture(uploadPhotoOptions).then(takePictureSuccess,takePictureError);

A full list of options (uploadPhotoOptions) can be found at the cordova camera plugin github repo.

The most important option for our purposes is…

uploadPhotoOptions.sourceType = Camera.PictureSourceType.CAMERA;
OR
uploadPhotoOptions.sourceType = Camera.PictureSourceType.PHOTOLIBRARY

It should be pretty self explanitory. Just call $cordovaCamera with the sourceType = Camera.PictureSourceType.PHOTOLIBRARY for photolibrary and Camera.PictureSourceType.CAMERA for camera.

One gotcha…

Camera.PictureSourceType.CAMERA only works on an actual device, unfortunately you can’t test in the Ionic emulator (i.e. `ionic run emulate`).

Full Code Example

I’ve included a full working sample below.

$ionicActionSheet.show({
 buttons: [
  { text: 'Take Photo' },
  { text: 'Choose Photo' },
 ],
 cancelText: 'Cancel',
 titleText: 'Take or Choose a Photo',
 buttonClicked: buttonClicked,
});
function buttonClicked(index){
 var uploadPhotoOptions = {
   quality: 50,
   destinationType: Camera.DestinationType.DATA_URL, //FILE_URI, NATIVE_URI, or DATA_URL. DATA_URL could produce memory issues.
   sourceType: Camera.PictureSourceType.PHOTOLIBRARY,
   encodingType: Camera.EncodingType.JPEG,
   allowEdit: true,
   targetWidth: 300,
   targetHeight: 300,
   saveToPhotoAlbum: false,
 };
 if (index == 0) { // Take photo
   uploadPhotoOptions.sourceType = Camera.PictureSourceType.CAMERA;
 } else if (index == 1) { //Choose Photo
   uploadPhotoOptions.sourceType = Camera.PictureSourceType.PHOTOLIBRARY;
 }
 $cordovaCamera.getPicture(uploadPhotoOptions).then(takePictureSuccess,takePictureError);
 function takePictureSuccess(success) { 
   vm.userProfile.image = "data:image/jpeg;base64,"+success; //this is how I store the image to firebase
 };
 function takePictureError(error) {
   $ionicPopup.alert({
     title: 'Photo Error',
     template: error,
   });
 };
 return true;
}

I’m happy to answer any questions you may have, just post a comment below.

The purpose of this post is to outline some of the guiding principles of code we use at Buink. These principles inform how we review  and write code and we ask all our contractors and employees use these as well.

Summary:

• Cost Effective Technology (efficient, maintainable)
• Responsive and Transparent Communication
• Quick Turn-Around
• Eloquent, Simple, Maintainable Code
  • Organized Code
  • Readability vs. Performance
  • Self Documenting
  • Collapsible
• Less Code, Less Problems
  • Code Reuse
  • Code Refactoring
• Intelligent Solutions
• Test Driven Development

Cost Effective Technology (efficient, maintainable)

One of the things you’ll notice as you read these principles is that almost all of them relate directly to making your code cost effective. I’m a developer, but I also call myself a business technologist because I’m constantly looking for ways to make:

1. technology affordable for business
2. business better with technology.

Focusing on cost effective code seems like a no-brainer, but you must realize that this isn’t the norm. Every day I see articles written about this or that best practice which may be bad for business.

I’ll give you an example: test driven development. I’m a huge fan! I love the benefits that tests can provide your code, but you have to understand that testing has trade-offs. Tests add about 30% to 40% of time to your project. This means your end-product costs more. So, if your project is a minimum viable product, then adding tests may be overkill. Also, tests can be done poorly. The big takeaway here is that testing is important but not for all projects.

Another example is WordPress. A big portion of my colleagues hate WordPress and actually mock WordPress developers. Why? Because they are threatened by the fact that WordPress comes out-of-the-box with tons of features they usually get paid to add. On the other hand, I look at WordPress as a tool perfectly suited for some jobs. If you’re looking for a simple site, I often call them brochure sites, then there is no need to code it from scratch. WordPress is a time-tested piece of software perfectly suited for the job.

This principle really sets us apart at Buink. I was an entrepreneur before I was a coder, so I see the trade-offs and try to educate my clients about them. I’m also constantly on the look-out for technologies (frameworks, platforms, etc.) that give more bang for the buck.

Responsive and Transparent Communication

Many of my clients are surprised when I add them to our internal project management software or give them access to the code during production. They’re also surprised how quickly I respond to email and how easy it is to reach me via phone, “call anytime” I say, and I mean it.

I find that being as transparent as possible with clients reduces misunderstandings and improves relationships.

I take communication to the next level by sending weekly invoices so clients know exactly how much of their budget is being spent. I also include a detailed breakdown of every minute of work in each invoice.

Quick Turn-Around

If you have a deadline, we’ll do everything we can to hit it. We’re not like other developers who try to manage their own schedule at the detriment of their clients. We’ll come up with a plan that works for your timeline and we’ll focus on hitting it.

Eloquent, Simple, Maintainable Code

Reading code can be a exercise in patience, particularly code that is not your own. Stringing functions together with intertwined dependencies increases the complexity of the code. Some people think complexity is just the nature of code. We don’t! The more complex the code is, the less readable, maintainable, and manageable. We strive to make our code simple and readable in the following ways.

Organized Code

There is a reason that organization is a synonym for business. Organization systematically reduces cost and increases benefit. With code there is no difference. Organized code is readable code, organized code is easy to maintain, and organized code makes us happy! 🙂

There is nothing worse than opening a file only to find a jumbled pile of mess (spaghetti anyone?). You have no idea which variables are used throughout the file and which are used only once. You have no idea where features start and stop. You have no idea which functions have which dependencies.

Our goal at Buink is to write code that you can get a feel for quickly. This is why we put the most important variables/functions/apis/references near the top of the file. We use setup functions to dispatch other important functions and to organize important variables. We use cutting edge technologies to separate components and make them reusable and updateable. We do all this so that your code lest costly in the long run.

Readability vs. Performance

At Buink, we operate under one simple rule: people are more expensive than servers. Hopefully this is self-evident, but if not, just look up the average price for a developer per year vs. the average price of a server. You’ll quickly find that it is much cheaper to throw more computing power at a problem than it is to throw another developer at it. This becomes less true when your site is getting billions of page views a year, but most projects won’t and don’t need to.

This doesn’t mean we throw best practices out the window. No! But when we need to decide between simple, readable, maintainable code vs. performance, we lean towards readable.

If performance does become an issue, we circle back and attack the bottlenecks that are hit by the end users most often.

Self Documenting

One problem with documentation is that it is constantly outdated. You make a quick change to line 300 and your documentation on line 1 is now misleading. I can’t tell you how many times I’ve tried to understand code and wasted money trusting the documentation. Things are constantly added, moved, changed, removed, and documentation is very poor at keeping up.

The only surefire way to keep your documentation up-to-date is to make it part of your code. With this, you cannot change the code without changing the documentation. Rather than spend time updating the documents, you spend time updating the variable names and function names. Then, when future developers take over the project, they find it easy to read and update.

I cannot stress how valuable a principle this is; this principle alone has saved our clients tens of thousands of dollars. This mindset isn’t easy to attain. It takes a little extra thought about what could be confusing for future developers and how can I write the code to make the intent clear, but this extra effort is well worth it.

Collapsible

One aspect of code that is often overlooked is proper indentation and closures. Most modern code editors allow developers to collapse code based on indentation. Writing code using closures and uniform indentation can allow a thousand line file to collapse into 6 or 7. Then you can drill down to the parts of the code most important to you. This speeds up development and reduces the overall cost of software.

Less Code, Less Problems

There are many ways to skin a potato. 🙂 There are tools and techniques you could use. Code is similar; there are always many options to accomplish the same task. Often, the first solution you think up/find is not the best. We’re constantly pushing to find the best, most intelligent, and simplest solutions to client’s problems. Reducing the lines of code is one technique we’ve found that skins our code potato well.

Building features with the least amount of code has many benefits including less bugs, less problems adding or updating features, and more clairty when reviewing code. We use the following strategies to reduce the number of lines in our code.

Code Reuse

The most important principle here is we NEVER copy and paste code. Ok, I’m exaggerating a little, but for the most part, the rule is to avoid copying. Whenever we’re tempted to copy and paste, we catch ourselves and start thinking about how we could make this into a reusable component or function.

This doesn’t mean that we just create reusable components for every little feature. A re-usable component costs a little bit more than a functional component and there is no reason to incur this cost if the code may never be reused. Also, making re-usable components reduces the readability and clarity of the code. For this reason, we wait to make re-usable components until we need them (i.e. until we’re tempted to copy and paste).

When reusing code, we strive to make it independent of its environment. In other words, we want it to plug-and-play in multiple areas of the website. We pay attention to adding default options to the code so it requires almost no setup and can be extremely customizable.

Code Refactoring

After building complex features/functions, we generally review the code to see if there is any ways we can make it more eloquent. Goal #1 is to get the feature working. Goal #2 is to reduce its size and make it more efficient.

Intelligent Solutions

Again, there are many ways to skin a potato. Some are more wise then others and the truth is most of the easy to find solutions are not good. Many of the previous principles can help us arrive at the smartest code, but there is still something to be said for thoughtful code. We don’t just find the first thing that works and throw it in. We have to consider the impact of our design on the whole system. How well does each solution address the overall business need? Is a solution forward thinking; in other words, will it set us up for success in the future or will it introduce technical debt?

Given the complexity of code, it is rare that future developers praise the code they inherit from us, and yet, that is our goal. To solve problems in such a way that enlightens those who read it.

Test Driven Development

Yes, tests are important and we push all of our clients to let us implement them. We’re constantly trying to improve our mindset around tests. Test driven development (TDD) is a buzz word these days, but 80% of the tests we see written by outside developers are useless clutter, and many time detrimental bloat. At Buink, we push our developers to think deeply about the type of tests that are valuable and the best ways to write them.

I’d love this post to spark a conversation because I’m still formulating this opinion.

In building Buink Web Development, I’ve worked with over 15 clients all over the country and close to home. The interesting thing is that I’ve met very few of them face-to-face. This is true of both my clients in San Francisco/LA/Utah as well as my clients right here in Denver. In fact, 3 clients come to mind that operate nearby and whom I’ve never met.

One good example is a client that I worked with last year for about 6 months, I’ll call them GameChanger. They operate probably no more than 20 minutes from my house. They were referred to me by someone I’d met at the grand opening of Confluence, a co-working space in Lafayette. They had an existing code base and I cleaned it up, re-designed the UI, added pages, and added some really complex features. We’d use phone, email, and Jira to communicate and if there was something really complex, we’d use Google Hangout.

I share my experience with GameChanger because we could have met in person if we wanted to, but why? Most of our communication didn’t require a time-consuming meeting. Ninety percent of it could be done via email and Jira, and for the couple times we needed to meet, a quick chat via Google Hangout saved close to an hour of drive time.

Today, face-to-face meetings are an expensive nice-to-have.

Despite the fact that face-to-face meetings are just an expensive nice-to-have, I find myself constantly trying to avoid them (I think it is my obsessive focus on efficiency :)). Many people have it set in their mind that they have to sit across from someone to work with them.

I’ll admit, in-person meetings are more memorable. Their face is more indelibly imprinted on your mind, their mannerisms are more noticeable (or more distracting), the things they carry with them tell part of their story, but I’m not sure that these niceties are necessary. They are, however, costly.

I’m not sure that these niceties are necessary!

I went to a meeting last week to provide technical direction for an IOS app that I hope I get to build. I got a first impression of the company, where and how they work, who works with them, and a little about their background. It was pleasant. I like to meet with people, but it did take two hours of drive time for a two hour meeting. And, unfortunately, I don’t own a self-driving car (trust me, I will!).

Luckily, I did get paid for the time in the meeting, but the client wasn’t planning on paying for drive time. I don’t blame them, who pays for drive time? No one. No one, that is except for the person driving.

I guess I could just raise my hourly rate. That is probably the most common reaction to covering incidental costs, but I’d rather push the clients to realize the true cost of development. They may value in-person meetings more than I do, so I want to happily give them the option rather than avoiding it. 🙂

So, I’ve decided to charge for drive time. I have to admit, that it doesn’t always go over really well, but I think I just need to work on my delivery. Thoughts?

UPDATE 2018.05.11

So, I tried the charging for drive time thing and it didn’t work out so well. 🙁

I mentioned it to a couple potential clients and the reactions I got were as expected. “I totally understand where your coming from, but…we’ve always done things like this.” So, I made several exceptions and then just stopped mentioning it all together.

I keep experimenting with ways to get out of face-to-face meetings and a couple weeks ago I lost a potentially lucrative client related to this. I didn’t even mention drive time but I did say, “I’d don’t typically like to meet in person at this stage of the conversation, but because you’re a referral from ZZZZ, I’ll make an exception.” Referrals almost always become clients, so I’m ok bearing the cost.

She responded, “That is honestly one of the strangest responses I’ve ever received. . .Not sure that this will be the right fit.” Ouch.

Frankly, I’m not too hurt by her response because she probably would have expected me to waste a lot of time just to work with her, but it did cause me to pause.

I’ll continue to experiment but I find it interesting how adamant people are about meeting in-person and interesting how they bristle when I ask them to bear the cost.

I think part of the reason is that people don’t often look at the true cost of doing business. They have this nebulous “administration” expense that includes lots of wasted time by sales people, executives, and others.

At Buink, we understand our costs exactly! That is how we can deliver maintainable, intelligent, simple code and a price that competes with the best onshore and overseas teams. That is how I know every person on my team is delivering value that exceeds our competition, even if our competition is in-house talent. This is possibly why I can’t keep up with demand for our services.