Skip to main content

5 Good Programming Habits to Be a Better Designer

Ravi Rajan is a program director working in India. He writes articles on management, creativity, and creating user-centric design philosophy

Thinking like a programmer is an excellent way to be a better designer. Once you start doing it, you learn faster, iterate more, and build creative and feasible solutions.

Thinking like a programmer is an excellent way to be a better designer. Once you start doing it, you learn faster, iterate more, and build creative and feasible solutions.

Do Designers Need to Know How to Code?

Before I answer this question, let us admit the truth.

As designers, it is easy to get annoyed with developers. Perhaps, they cannot get the alignment of a button right, or the functionality beautifully designed by you is deemed "technically unfeasible" by them, or even worse, they put some shocking color combinations on the screen and say casually, “it does not matter” and so on,

The reality is that we get annoyed with developers mostly because we need to understand their world. The same goes for developers who need to understand design. They get upset with us too. And I know this because I have spent most of my career trying to fill both shoes at some point.

As designers, we wear our blue-sky hats and think everything we design is doable. And as developers, we put on our fiery red hats and write shiny Code with design considerations, the last thing on our backlog list.

Bridging this gap requires us, as designers, to know more about development.

Designers need not be full-time programmers, but I firmly believe in having a basic understanding of some technical concepts. Programming is much more than writing lines of Code. It is all about logic, the mindset to solve problems, and making complex things simple, which defines a good programmer.

In short, thinking like a programmer is an excellent way to be a better designer. Once you start doing it, you learn faster, iterate more, and build creative and feasible solutions.

And here are five programming habits that can help you to be a better designer.

1. Variable names are important
2. Good programmers document everything
3. Debugging is a lifesaving skill
4. You aren’t Gonna Need It
5. Make the simplest thing that could possibly work

Variable names are important

Variable names are important

1. Variable Names Are Important

Kendrick Lamar nailed it when he said.

“If I’m gonna tell a real story, I’m gonna start with my name."

Names are everywhere in software. We name our functions, classes, arguments, packages, and whatnot. We name source files and the directories and everything within that. Your name should reveal the intent. Choosing good names takes time but saves more than it takes when the going gets tough.

Always remember the name of any variable, function, or class should answer three big questions,

  • Why does it exist?
  • What does it do?
  • What is it used for?

Thus, good naming requires descriptive skills and a shared cultural background that transcends boundaries. And no one can teach you this better than yourself.

Thinking like a programmer, you start picturing a variable storing a value as you, let us say, design a toggle button on the screen. You need to put a default value to the variable –will the button be on or off initially? Clicking on the button will change the value of the variable. How will the default value be used if the button is not clicked? And so on.

Your mind churns out multiple logical possibilities, which make your design robust and feasible.

Good programmers document everything

Good programmers document everything

2. Good Programmers Document Everything

It does not matter how good your software is because people will not use it if the documentation needs to improve. Even if they are forced to use it, they will not use it effectively or how you would like them to.

And nearly everyone understands this. Every developer knows they need good documentation, and most try to create it. But they fail.

Why is it so?

Because documentation is nobody's favorite thing to do, everybody wants to be a good developer. That is why we have exciting catchphrases like DRY, KISS, SOLID, etc. But when it comes to documenting the Code, there is not even a single catchphrase.

That said, documentation is not just for other developers but often for our future selves. When we return to a project after a period, we will appreciate the work we put into clear and up-to-date documentation. Whatever the deadline, workload, or excuse for not documenting, any software without documentation is a dead Dodo. Simple as that!!!

And the same applies to designers also. Good documentation is like casting your thought process in stone. Sharing it can help others learn the what, the how, and the why!

3. Debugging Is a Lifesaving Skill

If I were to sum my programming career into two hard truths, they would be the following.

  • Anything that can possibly go wrong will go wrong.
  • Code smells, and it smells badly at times.

And the only skill that is required to counteract these bitter realities is debugging.

Yes, Debugging. No one (or almost no one!) starts off programming with love for debugging. Instead, it is often a source of frustration and dread. “How many hours am I going to waste fixing this bug?” many of us wonder. We would instead go back to building cool stuff. (Because who does not like making cool stuff!?)

Yet it is hard to find a developer we admire that does not consider debugging important. That is because they know that it is an invaluable source of growth for them. There are a few situations that will test your abilities as a developer to the extent that debugging will. That is why you should start approaching debugging as a learning opportunity. Sure, the pain will still be there, but you keep it under control by doing it the right way.

Similarly, as a designer, troubleshooting (or debugging) closes the gap between your design and what the user wants. Troubleshooting is an essential skill you can learn! It takes both knowledge and skill (and sometimes a lot of luck) to be good at troubleshooting.

You need to develop the capability to isolate the problem, assess dependent and independent variables, and test it iteratively until you get it right to the user's satisfaction. The more troubleshooting you do, the faster and more efficient you become at it, and your design will improve.

You Aren’t Gonna Need It

You Aren’t Gonna Need It

4. You Aren’t Gonna Need It

“YouArentGonnaNeedIt” (often abbreviated YAGNI) is an Extreme Programming practice that states:

“Always implement things when you actually need them, never when you just foresee that you need them.”

Even if you are totally, totally, totally sure that you will need a feature later, wait to implement it. There are two main reasons to practice YagNi:

  • You save time because you avoid writing code that is not required
  • Your code is better because you avoid polluting it with guesses that turn out wrong but stick around anyway.

Remember, good programming is a few brief moments of sublime elegance embedded in months of niggling, exacting, precise trivialities. Make that sublime elegance stand out by eliminating the unnecessary. This earns you accolades and gives others a readymade platform to add, learn, and work as a team.

In designing, we call this minimalistic design. The main idea in minimalist design is to say more by showing less. Minimalist design is clean, crisp, and timeless. Unnecessary objects and flashy flourishes are left on the drawing board. Only the necessary is included to get the message across.

Remember, the key to minimalism is keeping the design to the "bare minimum.”

Make the simplest thing that could possibly work

Make the simplest thing that could possibly work

5. Make the Simplest Thing That Could Possibly Work

Extreme programming mentions two golden rules to writing simple code:

  • First, implement a new capability in the simplest way you can think of that could possibly work. Do not do anything fancy. Just put it in to make it work. Make the code pass the unit tests for the new feature, and that is it.
  • Second and this is critical to the rule, refactor the system to be the simplest possible code, including all the features it now has. Follow the rule of “OnceAndOnlyOnce” to make the system as clean as it can possibly be.

Always remember, we are looking for more than the quickest way. We are looking for the most direct result. So, we first break the existing method into simple pieces. Then we modify one of the simple, little methods to handle the next test case and so on.

Similarly, a good design minimizes human and computer interactions to the bare minimum. And when there is no interaction, there is no user experience at all. And the aim is to create a design having no experience at all.

Yes, great designs have no user experience. They incorporate naturally occurring patterns and rhythms that merge with the user's daily activities. That is the ultimate sophistication.

Simplicity, in design, is about minimizing and refining the process to the point it becomes evident to the user. But that does not mean stripping down complex tasks or losing important information.

Instead, it is about finding a sweet spot between design elements and their usability so that users can quickly complete one task after another without rhythm breaking. Always remember a simple design is simply non-existent. In other words, an experience-less experience. That is it!

As Steve Jobs has rightly said:

“Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.”

Sources

This content is accurate and true to the best of the author’s knowledge and is not meant to substitute for formal and individualized advice from a qualified professional.

© 2022 Ravi Rajan