Developers Don’t Try

Written By Edwin Klesman

As a developer, we often tend to “try out” stuff to see if it works and throw out the results if they don't live up to our expectations.

Whether you're creating this nice generic function to make things in your app more reusable, implementing another framework, writing a technical blog post describing the latest problem that you've overcome, or creating an online episode for your Swift 1-0-1 Pluralsight course, developers are always taking new ideas for a spin and spending time and energy creating something.

In all of the given examples, it basically comes down to making an effort to create something that you want to use or share with other developers.

Although a trial-and-error approach can be rewarding, I've found that it can drain a lot of time and energy if it isn't performed with focus. Vaguely “trying stuff” tends to have a negative vibe associated with it, so let's look at how you can get from that negative vibe into a more positive and rewarding mindset.

After all, as a person but even more so as a developer, time is a crucial resource that you need in order to get your product out to customers.

Trying Is Evil

For some years now, I've come to believe that “trying” is not really a positive thing. When looking into the definition of the word on, you find as the first definition:

verb (used with object), tried, trying.

  1. to attempt to do or accomplish

That doesn't sound too confident or result-driven now, does it? Trying to get those unit-tests to go all green sounds far less confident than stating you’re going to get them to go all green.

If you want to spend your precious time as optimally as possible and get the best buck for your efforts, you don’t want to “attempt” to have that website done in time, right?

If you're a freelancer working to deliver value for each hour that you spend, time equals money, and pushing code should be executed as optimally as possible.

By removing as much friction and resistance from the process as possible, from concept to a sprint's end product, agile teams work hard to get the processes of testing, Source Code Management, and deploying products automated and done as fast as possible.

That gives the team more time to actually implement your product with all of its features. Wouldn't it be a shame to spend that time “trying” to get stuff done?

I'm not saying the impulse to try something out isn't valuable. It is a clear indication that there is a need for change. It may also indicate that the road ahead is unclear, and you want to remove that fog of war to see what's out there.

A signal to take action is actually really good and should be valued.

The question is: How are you, as a developer, going to deal with that impulse and avoid losing valuable time? Trying out this or that route on your project just isn't going to cut it. You can do better than that.

Let’s look at how you can wire that “trying” mindset into something more productive, so you can achieve sharper focus and deliver better software in a more meaningful way.

Breaking Down the Habit of Trying

When you look at it, there are three things that you can break “trying” down into:

1. Just do it

Yoda said it back in the day: “Do, or do not, there is no try,” and that is the bare truth. If you want to get a result out of your efforts, you need to stop “trying” to get it. You need to DO IT.

Prepare for your efforts by planning what you need to research, set the steps that you see fit to reach your goal, and execute them.

You want to go and develop a mobile app or a SaaS product as a side-project or your next business opportunity? Split all your main tasks into smaller pieces and lay them out somewhere where you can view and edit them from your laptop, tablet, or smartphone.

Whether you’re going for the Kanban approach ( or an online integrated agile SCM and task handling environment (, or something more straightforward like card-based layouts (, there are lots of ways to define and track your goals and the necessary steps to complete them.

Set your mind to reaching your goal and expect that the knowledge you have today may be challenged during the process. You might need to alter your views or research some new topics before you can proceed.

In the end, it’s that attitude that will get you to ship that app. Taking action is what separates hobbyists from entrepreneurs.

This is a much more positive, and more importantly, a much more realistic approach to the task, one that makes you more likely to reach the desired result.

2. Learning instead of trying

Sometimes “trying” is not done to create a useful end product. It might just be something you want to do in order to learn from it. The result is subjective to the learning process of your actions.

But wait a minute, that is not called “trying”?! No, that is called learning. Research, if you will. When you're putting in the effort and the product is not important, but the process of creating it—and gaining knowledge—is, you're in learning mode.

If you decide to code your next side project in Angular 2 or Aurelia because you want to learn how to code with those frameworks, that’s fine. Yes, you might be slower or it might be harder than using ye olde Angular. But as long as you’ve made a conscious decision to do this because learning is your goal, you’re all good to go.

Want to test out that cool new cloud-based mobile testing service that uses hundreds of physical devices? Set up a quick and dirty test project and hook it up into the service, so you can learn how to use it.

Throw away the code afterwards or keep it as a reference. It isn’t the product that you’ll have gained, but the knowledge.

Just be sure to describe in a sentence or two what you're trying to learn and why you're learning it. This will keep you from losing focus.

3. Testing your hypothesis

When you're trying something in order to see how it works out, you're actually testing a hypothesis. For example: “I'm creating this function to see if it performs well.” This is not really trying. It is actually the definition of a test. often called creating a Proof of Concept (PoC).

The result (the function you're coding) might be less relevant. Really, it’s the confirmation of your hypothesis (i.e. the function performs well) that you are after. Defining your hypothesis in a SMART way will help you to perform a rewarding test.

Even if the outcome of the said test is negative and the function turns out to be slow as a snail, you will have gained knowledge (see the overlap with #2) that will help you make the right implementation decision.

There Is No Try

There you have it. Whether you're learning, testing your hypothesis, or going for a result that works for you, it’s important to analyze what you’re “trying” to reach and make a conscious choice on how to reach your goal. Thinking this way will allow you to be more critical of how you spend your time and will make shipping your product, reaching your goal, and writing beautiful code much easier.

Just test it out for yourself and learn if the hypothesis will bring you the results I think it will bring you.