Development Articles

Tips For Testing Developers

The best way to see if someone can write code is to have them write code. Therefore, we test everyone! 

The trick is to make the test as similar to your every day work as possible. Don’t send them through a list of multiple choice questions on the finer points of JavaScript. In my experience, there is very little correlation between book smarts and streets smarts.

I had a client early on who thought the answer would be to hire computer science grads from Columbia (he lived in New York at the time). This was before we did testing. Anyways, after 4 weeks and 3 graduates, we hadn’t moved the company forward at all. They had all the books but hadn’t done anything on the streets. 

Don’t test as part of your filtering process. Filter well, then choose your horse and make your bet. Some developers won’t take tests without pay. We tried compensating, but it ended up being too costly, so we switched to just guaranteeing work if they pass the test. Passing is as easy as submitting code we could bill for. 

You’ll definitely need to test every person on your team, but that can be a challenge for non-technical founders searching for a tech lead. There are lots of third party test administrators out there, but we find that most if not all are too theoretical. We don’t have a good solution for this problem except that we could help you set a test if you need.

As a benchmark, of the 1% of developers that make it through our filters and to a test, only about 1/2 of the devs pass.

With all rules, there are some exceptions. A coding test is less important, like when you’re hiring a dev shop with lots of past experience, a solid online reputation, and public reviews.

As mentioned previously, you shouldn’t use testing as part of filtering candidates. If you’d like to read more about how to filter well, download our free Guide to Tech Projects for Non-technical Founders.

If you need hands on help with your project, Buink has years of experience managing and completing technical projects on time, under budget, and with a high level of quality. Contact Buink today.

Filter Candidates Well

We use a combination of cultural fit, confidence, and reputation.

Cultural Fit

Cultural fit varies based on the company, team, and project so there isn’t much value I can add for you here, except that you need to determine what your values are (e.g. Quality, Value, Clarity) and find people who share them. It isn’t so important that they have the same personality, hobbies, etc., in fact, a lot of diversity is great, it is more important that they share the same values.

Confidence and the Dunning-Kruger Effect

When doing hard, new things, you have to find people who are confident in their abilities. In development, we call these abilities skills. They include languages, frameworks, paradigms, patterns, etc. We look for developers who are confident in the skills we need. 

The problem with confidence is best illustrated by the Dunning-Kruger Effect. This term was coined by two Cornell psychologists who found a “cognitive bias whereby people who are incompetent at something are unable to recognize their own incompetence.” Forbes 

In one experiment, for example, they asked participants to rate how funny jokes were and then asked them how good a judge of humor they think they are. They found that those that were the worst at judging which jokes would be funny, also rated themselves the best judges of humor. 

This and other studies led to the conclusion that less experienced people overestimate their abilities; in other words, they’re more confident than they should be, so their confidence doesn’t mean anything. Confidence is good, only if they have the experience to back it up.

We ask developers about their confidence in the skills we need in several different ways during pre-screening as well as in the interview, but given this human bias, we can’t just take the developers confidence at face value. We must discount their confidence rating based on their level of experience.

For instance, if our project requires a high level of confidence in React, a JavaScript front-end framework, we ask about the developers confidence in that skill in several different ways, both in ranking as well as imaginary tasks. If the developer rates themselves at an expert level, but they have only 1-2 years of experience, we must discount their level of confidence. The only exception to this is if the developer has a lot of experience in a related technology like Angular or Vue.

Reputation Economy

We’re in a reputation economy now. Gone are the days when we check references, I’m more interested in online reputation, connections, followers, recommendations, and reviews. The best guarantee that you won’t be stiffed by a bad developer is if you can leave them a review that hurts if they do.

We only end up considering about 1% of applicants. That means based on our filter questions and resume review, we only end up sending 1% of applicants to the hiring manager.

Conclusion

Filtering candidates based on fit, reputation, and confidence is the first step, testing is the next step. Learn more about how we test developers and get other tips in our free Guide to Tech Projects for Non-technical Founders.

If you need hands on help with your project, Buink has years of experience managing and completing technical projects on time, under budget, and with a high level of quality. Contact Buink today.

Finding Good People Is Hard

Unemployment in web development has been very low and wages have not been stagnant. To make matters worse, Google and other tech giants are literally printing money and inflating salaries.

Good news is that advertising is only a small portion of the dev industry and working at the giants involves mindless, soul sucking work. So, finding your tech lead and other developers isn’t going to be easy, but it is possible. We find good people all the time, but it took us years to hone the process.

We use a process of filtering, testing skills, and testing behavior that we’ll be outlining over the next couple weeks on our blog. If you don’t want to wait, you can download our free Guide to Tech Projects for Non-technical Founders. This is our gift to you!

If you need hands on help with your project, Buink has years of experience managing and completing technical projects on time, under budget, and with a high level of quality. Contact Buink today.

The Divine Estimate

Projects can fail for many reasons and unreal expectations are high on that list.

At Buink, we measure our success by the success of our clients, which is why we’re always looking for clients who have a strong business plan, some business expertise, a good idea, and a good team. It is our job to deliver quality code that is bug free, intelligently written, and easy to maintain. It is our client’s job to be able to sell the project or features to customers or investors. When both of these jobs are accomplished, we’re all happy and we all WIN. When one job fails, then things get messy, and we work very hard to make sure it isn’t development that fails.

Our extensive experience in the industry and our ability to make development succeed is a source of pride for us. We’re experts at development, solving difficult technical problems, writing clean code, and delivering value.

That said, there is one part of our job where expert skill is very hard to attain: estimating.

When I started in this industry, I had no idea how important, and even vital, this very difficult skill would be. I had no idea how quickly my clients would assume we can do this easily, despite our lack of a reliable crystal ball. I had no idea how closely connected the success or failure of our work and reputation would be to this divine skill. Most of the time, this skill affects us negatively if we underestimate, but I also had no idea how easily we would loose potential work if we prophesy too many hours and too much cost.

Through time we’ve honed our skill, particularly with greenfield projects (projects that we build from the ground up). But even with existing projects, even sometimes projects that we build, things can get impossibly hard.

For example, the version of a coding language we use was recently depreciated and that forced us to upgrade several of our existing codebases (this is never a problem, by the way, for clients who sign up for a website maintenance agreement, but several don’t till a bug bites). We typically estimate an upgrade like this at about 12 hours. One project took less than half of that at a very happy 5 hours. The client was happy and we were a hero.

The upgrade on another project didn’t go so well. It triggered several bugs, which triggered issue with their IOS app, which required an upgrade to all front-end packages, which introduced other bugs, some of which were very difficult to solve. We were able to get the client back up and running, but not without a lot of unexpected work. The final time came in at a shockingly unsatisfying 50 hours. ALMOST 5X THE ESTIMATE! We worked closely with the client the entire time, but I can assure you, this wasn’t pleasant for anyone. You might think getting more work is good. Sure, we get more work, but it throws off our schedules, adds a lot of unneeded stress and pressure, and leaves the client unhappy.

The client who only had to pay for 5 hours of work was very pleased and we looked like a hero. The project that took 50 hours created all sorts of questions in the clients mind. Our skill level didn’t change between them. Neither did our expertise or our ability to estimate. Neither did the software choices we made. The only difference was the unique business logic and features of the project which become difficult to predict.

Here is the sad truth, ESTIMATES ARE ALWAYS WRONG! Even the project that took only 5 hours had an estimate that was drastically WRONG. Sure, it was wrong in a good way, but wrong nonetheless. I’ve never seen an estimate be exactly right. Never.

So, what is the solution? How can I keep all clients happy? The truth is, I can’t always keep all clients happy when part of my job requires the divine attribute of predicting the future.

Maybe I should always estimate the upgrade at 50 hours to make sure we never go over. But if we do that, there are no shortage of developers in the market place who will say anything to get the work. Then, if they land the project they’ll cut corners, ignore security best practices, forget to built the code in an easily maintainable way, and still probably go over estimates.

Do I estimate the update at 5 hours given that we were able to do one at that length? No, I don’t feel right about that either.

Instead, I try to give a number that will be closest to the average, which is 12. But again, 12 is wrong, except hopefully in a good way.

As you can see, estimates are an extremely hard problem to solve, and that is why I believe that the estimates are a wrong way to think about development work.

David Hansson, the creator of Ruby on Rails and co-founder of Basecamp, said the following in the article It’s not a promise, it’s a guess, “If you treat the estimate as a “best guess based on the limited information available to me before I start the work”, … you’ll change the frame and break the cycle of deadline anguish. Now the task becomes collaborative and you can share new discoveries with the stakeholders.”

Collaboration is the key here. If the developer is the right person, with the right skills, and the right dedication to the project, then estimates become an opportunity to communicate, not a breach of contract. At Buink, we rarely fail at delivering valuable code that meet business objectives, but if we do, it is usually related to an estimate being interpreted as a promise, not a best guess.

When we get in situations where expectations are increasingly unrealistic, I often feel like the developer in A letter from a technical founder to non-technical founders when he was trying to explain to his co-founders why the code was taking so long. He asks, “Have you ever started a project thinking that it is going to take an hour only to spend eight on it? This is just like that.” I think we’ve all had that happen and more so in development than any other type of task in my career.

Luckily, as we get more experience in the industry, we get better at predicting. We also get better at turning around projects if estimates turn out to be poor guesses. But, I’m quite sure we’ll never be perfect at it.

If you find yourself struggling to understand your engineering team, I’d highly recommend the book Shape up, written by Ryan Singer also of Basecamp. He says that we need to start thinking about development tasks in terms of appetite not estimates. Appetite is how valuable a given feature is to the business. When you combine appetite with priority, then you have a powerful framework to help product teams and developers stay on the same page, achieve business goals, and work together in harmony.

Here is a good summary video of Ryan’s book, Shaping in a Nutshell.

Hopefully, this information is useful to you as a non-technical founder trying to understand your technical team. If you’re ever in doubt about your technical team, we’d love to jump in and lend a hand. We can offer some valuable insights into how your team is running, how to improve their productivity, and how to know if things are moving in the right direction.

Fractional Technology Leader

If you’ve been reading our blog or downloaded our free Guide to Tech Projects for Non-technical Founders, you’ve learned how important a team is for completing technical projects successfully.

The most important person on the team is the technology lead. This goes without saying, but must be said given how often this rule is ignored.

You’ve got to have someone on the team that is experienced. I’m not talking about someone who has built a couple sites, this is your general contractor! I’m talking about a solid 10 year, 10,000 hour person

And what they’ve been doing for those hours is important as well. If they’ve been pigeonholed in the back office server room only tinkering with networks and IT infrastructure for 10 years (although some of that might be helpful), they’re not a good fit. They need to have worked in all aspects of web development, from design through devops and back again. They also need to have a couple big wins: big projects that went from start to finish successfully.

The more experience the better, but the problem is that experience is expensive. These people are pricey because they’re in a high growth, high demand industry where wages have not been stagnant. They’re going for anywhere from 150k – 300k per year right now according to salary estimates online.

If you can’t afford someone like that full-time (most startups can’t), you’ll want to look for someone who could join you part-time. Do a search on LinkedIn for a fractional CTO or fractional developer, or lead developer contractor, etc.

One thing you’ll definitely want to avoid is the “Amazing Technicolor Dream coder”. If you’d like to read more about that and other tips for successful technical projects, we have a free gift for you.

Download our free Guide to Tech Projects for Non-technical Founders.

If you need hands on help with your project, Buink has years of experience managing and completing technical projects on time, under budget, and with a high level of quality. Contact Buink today.

Scale Your Development

One of our core competencies is to help you scale development. This article dives into those capabilities and outlines exactly how we can help.

Scale Your Business

Have you ever seen a business plan that doesn’t expect exponential growth? If you’re going to achieve an exponential growth plan, you’re going to need your technology and workforce to scale with you. We offer four ways to help you scale your workforce and three ways to help you scale your technology.

Scale Your Workforce

We can scale your team in four ways: utilize powerful team technologies, implement better team processes, add people quicker, and fill out your team with fractional resources. Any one of these ways can accelerate your growth, and we can combine all four to help you ride a rocket ship.

Scalable Team Technologies

Everything starts with getting team members up to speed quickly and keeping them in sync. In an industry that expects new developers to take days to add value, we can do it in hours. We can also get them adding value with little to no training. We use a combination of proprietary and open source code to run your codebase with infrastructure-as-code. When we’re done, your team can spin up your codebase in minutes by running one command. They can see the code locally in an almost identical environment as your production server and they can start making changes immediately.

Scalable Team Processes

If you’re going to scale your team, you need robust processes that have been time tested. Some tough problems you’ll need to solve are (1) coordinating multiple developers from idea to production, (2) keeping changes independent of each other so you don’t have blockers, (3) preventing code conflicts that arise when developers are working on the same codebase, (4) understanding the value each developer is providing, (5) ensuring developers aren’t introducing security loopholes, and several more. We bring a unique version control process, coupled with an issue management process, and combined with a code review and quality assurance process that sets the foundation for you to scale.

Add People At Scale

As your business grows, you’ll find that the work piles up as you’re trying to hire, onboard, and engage new employees. Working with a company like Buink can flatten out the piles when your needs are high and slow down quickly when your new hire starts carrying their weight. We have a constant flow of top talent and we stand behind their ability to deliver quality and value. We vet all our technical resources to ensure that only the best of the best are working on your projects. We can find people faster and engage them quicker than you could on your own.

Scalable Fractional Team

When you’re small and growing, you can’t afford a full-time team of top talent. As revenue grows, you’ll be able to hire the perfect team, but you still need someone that can fill that role now. Buink can help by providing someone for a fraction of their time at a fraction of the cost. If you already have a killer full-time developer, let us add a fractional project manager to make sure your developer is always unblocked and adding value. Every team needs a good CTO, but they’re usually not your first hire because they’re expensive. We can engage one on your project for only the time you need. Fill out your team now with fractional resources.

Scale Your Technology

It isn’t cost prohibitive to start with the ability to scale before you need it, so why not start with the end in mind. We have a very affordable set of technologies that can help you scale your business, traffic, users, and servers.

Scallable Boilerplates

We’ve been maintaining and improving several boilerplate codebases built on open source foundations. These boilerplates are already optimized to scale. If we build your project from scratch, we leverage these proprietary boilerplates at no cost to you. Our code can scale from one visitor to millions, from one paying subscriber to millions, and from one dollar to billions.

Scale Servers Vertically

At first, you won’t want to waste money on large servers. Our default servers have enough resources (RAM, CPU, and storage) to service thousands of subscribers, but as you grow, you may need to quickly increase your server resources. We utilize cloud resources that allow us to scale your servers vertically at the click of a button. That means we can handle massive traffic spikes without giving visitors a dreaded busy signal. With the ease and affordability of hosting in the cloud, there is no need to get stuck on shared servers with high switching costs.

Scale Servers Horizontally

As your traffic and revenue increase, you’re not only going to need bigger servers, you’re going to need more of them. Because we setup your infrastructure-as-code by default, you can add servers easily when the time is right. Infrastructure-as-code means that setting up a new server requires little to no work, which saves you a lot of money on expensive DevOps engineers. Paying for DevOps engineers every time you need a new server isn’t scalable and it isn’t affordable. We’ve perfected scalable infrastructure and we can implement it for you at a very affordable cost.

Avoid The Amazing Technicolor Dreamcoder

I’m not sure why most people’s first reaction to tech projects is to find a nerd genius in his parent’s basement who’s a jack of all trades: The Amazing Technicolor Dreamcoder.

Building something on the internet is surprisingly similar to building something in real life, let’s take for instance building a home. It would be rare to find an electrician that is also an expert framer or a drywall-er who is also a great plumber.

When I was working to build the first space for student startup at CU, Spark Boulder, none of our mentors and advisors told us to remodel the space by ourselves or find a local jack of all trades civil engineering student. They told us to find a general contractor who can engage a team of skilled people.

Sure, you could find someone handy who could “figure it out” but you’d be making a significant sacrifice in quality and jeopardizing the project immensely.

The same is true for the web.

Modern development has become too complex to expect one person to be able to perform at the top of their craft across disciplines like design, user experience, front-end development, back-end development, devops, security, digital marketing, etc. You need to budget for a team. I don’t care if you find that team all at one dev shop or if you piecemeal it together, but you do not want to be putting all your eggs in one basket with the amazing technicolor dreamcoder.

If you’d like to read more about who should be on your team and how you can find them, also other tips for completing technical projects successfully, I have a free gift for you.

Download our free Guide to Tech Projects for Non-technical Founders.

If you need hands on help with your project, Buink has years of experience managing and completing technical projects on time, under budget, and with a high level of quality. Contact Buink today.

Avoid This Nightmare

I’m going to talk a little bit about a nightmare I found myself in as a non-technical founder and what you can do to avoid it.

I was a young professional with a small family and a 9-5 job in corporate America. I had big dreams of starting my own business. I was a glutton for punishment and I couldn’t get this idea out of my head.

I needed a web application but at the time I didn’t even understand the difference between a web app and a website. Maybe you can relate? I didn’t understand a lot of things.

My idea was to be the Groupon of products for parents. This was about a year before Groupon became well known, so it actually wasn’t bad timing.

I had a 2-year-old at home and another one on the way and I noticed there are a lot of junk products on the market. I figured I could leverage reviews and giveaways to help other parents find the great stuff.

I reached out to some local web developers and they were quoting a minimum of 25k. Talk about sticker shock! I had only 10k to my name and I didn’t want to risk it all, but I kept searching. Eventually, I found an onshore company that used offshore resources. They quoted 5k and I signed on the dotted line for my first website, my first golden shovel.

I sent them the requirements and I quickly realized how literal they interpret and execute everything I said. The communication barrier is real! With the differences in timezone, misunderstandings would take days to correct. But I pressed on.

Finally, months later, I had what seemed like a working app. Sure, it cost me twice as much, coming in at a cool 10k, my entire savings, but it worked! At least appeared to work. Up to this point, they wouldn’t let me see any of the code. I guess they were worried I’d just cut and run.

What I saw taught me a lesson I’ll never forget. I could not believe it. I was ruined! I’d spent all my savings and I was out of business before I’d even launched.

The code was bad. I’m talking, spaghetti code with a side of logic noodle knots. They had hacked the WordPress core files making my site impossible to update automatically. Worst of all, they had left many security loopholes. As I looked through the code, even with my non-technical eye, I could see opportunities for a hacker to exploit or dump customer lists and emails (these days you can be sued for less than that).

I spent the next year, plugging up the holes of that ship. I’ve since spent 11 more years learning how to complete technical projects successfully, on budget, and on time.

I’ve written a guide to help you avoid this nightmare. This free gift is the best of what I’ve learned.

I’m not holding anything back. Why? Because I haven’t written a book yet. 🙂

Download our free Guide to Tech Projects for Non-technical Founders.

If you need hands on help with your project, Buink has years of experience managing and completing technical projects on time, under budget, and with a high level of quality. Contact Buink today.