Non-coding tips a coder should know (w/memes!)

Thu, Jan 14, 2016

If you are anything like us, coding is what you love the most. But you also know there are many different aspects to be aware of beside coding that are important parts of a healthy development process. When you work as a developer you usually face clients or stakeholders that expect results and part of your job is managing their expectations. This is as important as delivering high quality code.

We've compiled a list of, what based on our experience, are some important guidelines, ideas, tips and tools to use while developing software projects, that are not exactly related to coding, but will help you achieve great results and keep clients and users happy.

These tips are useful for different stages of a project and for your overall programming methodologies, so keep them in mind all the time and use them wisely!


Talking to clients and showing results:

Getting clients to understand the value of what you are doing is 50% of the problem. Work on interesting and comprehensive examples for demos. Show as close as you can a real life scenario, clients will be able to understand much better the value of a feature if they see it with real world example and are not worried about technical details.

Managing expectations:

Sometimes a project starts with a requirements document. Requirement documents are like movie trailers and each deploy is like a movie premiere. It all looks great in the trailer, but after showing the movie we all know what could happen: It may suck.

In the software world, during the screening, the audience will go out (probably after seeing less than half of the movie), ask the director for changes in the script, special effects and even leading actors and requesting a new premier a week later and for free.

So, avoid surprises! Always remember what the audience wants to see from the trailer and make it work in the final version of the movie. That one is for you too, Christopher Nolan.



Meetings are our best friend and worst enemy. If you have experience using agile methodologies you know that meetings can be productive and fast. Just try to get things done and make sure you leave the room with a clear idea of what everyone is going to be working on.

Long meetings can be a productivity killer and deplete what's left of your precious development mojo, so careful with that.

Agile helps! Even using basic standup meetings via Slack and Hipchat could make a huge difference in team productivity and awareness of objectives, using only the necessary time.


Knowing how to prioritize tasks and what’s their main objective is critical in all projects and require us to be very organized and share our progress with stakeholders, clients and the rest of the team.

In terms of tools for organizing priorities in projects, possibilities are endless. Fortunately we narrowed down an endless space to only 2 options , so you can pick one and go on with your day: Trello or Asana. Yeah, that's it.

Learn how to use your organization tool and make it work for you not the other way around.

Priorities that matter:

Here is a tip we've learned from working with many clients in different projects:

The way we see it, there are 3 priority types in projects:

  1. Extremely Important.
  2. Really Important.
  3. Out of scope.

Seems easy enough. First tip: think about 3 after (and if) 1 and 2 are done.

But what's the problem? Problem is: many times clients will only be aware of 1 and 3. 2; you have to figure it out for yourself and make sure the client understands why it's necessary and why it's called "Really Important". Quick example: It's extremely important for me to get payments from users. That's what the client knows. We know that in order to achieve that It's really important to integrate with a payment system, have user models that can be used with it, saving all transaction data, being able to get all events so in case of a payment or subscription failure we can react, and so on and on.

Explain clearly why it's important to work on some base code that will lead to the extremely important part and make sure the client knows how much effort it takes. They need to know that they are not asking just for one feature but for all the base code it requires.


Estimating work:

Estimating projects is the easiest way to make mistakes. As a mega experienced client told us once "Estimations are the biggest lie in software development". Nevertheless it's usual to have no choice but to estimate something.

Agile again will give us very interesting hints here. One thing we use a lot here is thinking about small sprints and creating tasks and stories for it. Estimating what's going to happen in a few days with a clear work plan is way easier than a 4 months plan.

Always try to base your estimates on previous projects and similar things you have worked on or ask someone who has.


Research then do.

The best way to start working on something is to hold on a minute and see what’s out there that can help you be more productive and reach better results. Put on the researcher hat once in awhile, and stand in the shoulders of the Open Source giants, that usually leads to great solutions.


Love <3 the development process:

Teamwork doesn’t mean just getting along with everybody, it also means organizing work so that the whole team moves forward in the right task to reach the big objective. This is especially hard when working remotely, but becomes easy if we establish a good development process that everyone follows. It’s important that your mind works in this framework, knowing the development process and also being aware of their vulnerabilities and improvement opportunities.

As software evolves, often processes do too, so it’s the team responsibility knowing what new challenges appear and preparing to tackle them in time.


After you have a running server with your code on it you may engage in maintenance mode. Always code thinking that you may have to review the code months or years after, so document, comment and be good with your future self. If code is not flexible enough you will find yourself doing some ugly patches and after some time it may become unmanageable.


It’s important to have tests and code reviews as part of the process. Apart from the automated ones it’s healthy to use the system yourself and try to be in the shoes of a user.

A thorough test could mean the difference between "Eating your own dog food" and "Drinking your own champagne".


Being a coder is more than writing great software, knowing all MEME references in this blog post and daily writing hurtful comments in the Internet; it also requires to be organized and to know how to communicate with your clients and with your team.

We hope these few tips are a good reminder of what to have in mind during the day to day development process and can help you be more productive and achieve great results!

Wondering how AI can help you?

This website uses cookies to improve user experience. Read more