“Whatever is worth doing at all, is worth doing well.” — Philip Stanhope, 4th Earl of Chesterfield

In the workplace however, and especially in software development, this can lead to opportunity costs, over-engineering, complexity, and tech-debt!

I witnessed this first hand when a task given to a new team member (let’s call him John) to fix a Xero to Slack integration workflow. Slack notifications were sent to our customer team based on certain invoice conditions in Xero. We previously had it setup running through out backend system — but it had stopped working, so the task was to investigate and fit it.

John was quick to realise Xero had deprecated an old API and webhooks which we had been using. The new API however wasn’t as easy to get the data we needed. Ideas on how to get around the new API were discussed with other team members — it was an interesting and challenging problem after all. The only solution John and the team could come to was implementing a headless browser, where a scheduled task would programmatically login to Xero through the web UI, navigate to the data, and parse it into a usable format. He did it, and it almost worked! But the time on the task had blown out to almost a week now.

And here’s the thing. Everyone’s eyes were on the challenge of achieving this one low-level goal, but no one stopped to even ask if the higher-level goal of the Slack messages were even worth it given the cost, or if other solutions could be implemented instead.

After talking with the customer team, they were happy with a mix of Slack messages through Zapier (a simple integration tool), and emails direct from Xero.

The lesson I learnt is that overachieving a low-level goal at all cost can lead to underachieving higher-level goals.

I’m not sure why over-achieving low-level goals is so easy... Maybe we want to be seen doing the best we can in our part? Maybe the parent goal isn’t always well known? Maybe the goal/task is coming from a manager that we don’t want to question? Maybe we are scared of setting back a project to reevaluate the solution? I don’t know.

I do know what the solution is however. Be more lazy!

“I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it.” — Bill Gates

When something seems hard, look for the bigger picture goal, and see if there’s another way to achieve it, or if it’s even worth achieving at all given the cost. That’s it.

As a hypothetical example, imagine an Article class that has a method named publish(), and it works like this: First it autocorrects any spelling mistakes, and then sets the status to "published". This ensues writers always appear professional. Cool, right?

Not so fast. Imagine you’re the one writing an article for other developers. After hours you’re happy with it, and you click publish. Suddenly the published version shows all the camelCase variable names you wrote with spaces and in a different case. What a pain! You quickly go back to the editor, fix the errors, and hit publish again. But it autocorrects it again! Mildly fuming, you hit unpublish, and spend the next three months building your own blogging platform.

“Dumb Code” on the other hand are the lines of code that do exactly what you expect them to do, nothing more.

If our publish() method, was Dumb Code it would simply set the status to "published". Nothing more.

This example may seem obvious, but I see issues just like this all the time in my own codebases and in others. Whether we write it to flex our computer science knowledge, save time, save lines, impress our colleagues, or to accommodate that future unspec’d feature that’s just sure to be needed, we’re addicted to writing Smart Code.

But here’s the thing, Smart Code by definition is unusual code. It’s doing things that were unexpected, or in an unexpected way. This can make it hard to read, to understand, to maintain, and to optimize. It’s also a safe haven for ill-intentioned bugs to hide out.

You don’t need to write Smart Code to prove yourself. Writing and promoting Dumb Code can show far more wisdom.

In another example, how about when viewing articles — should we filter out any articles that have empty bodies? Surly the writer doesn’t actually want their unfinished article to be visible by accident? (We’ll get back to this).

The solution is not just about just having pure functions with no side effects. It’s also not about creating more work for you, or your users. It’s all about providing control.

To write Dumb Code, you have to provide control

Dumb code does the exact amount of work that you’d expect it to do.

If I flick the light switch, it won’t try and adjust the brightness and color to match the room — the light will instantly just turn on, or off. It’s boring, it makes no assumptions, and most importantly I never have to worry about it (Hey Google, you might want to listen in).

So how do you stop being so damn smart?

Live up to your naming

To write Dumb Code, start by thinking about the name you’re giving your class or function. If the name is publish, then what would you expect it to do? Would you expect it to autocorrect your work? Remember, the only rule you need for writing clean code is to always be referencing a mental model.

If the function was instead called autocorrectAndPublish, what would you expect it to do? I’d argue you may still have a terrible user experience because the control provided just isn’t granular enough, but it would be Dumb Code because it does exactly what is expected.

Don’t make assumptions

Being able to realize when you truly know something, and when you’re just assuming something because it’s logical is an incredibly underrated skill to have (in coding and in life). While coding, if you can notice the times when you’re slightly unsure of what to set a value, or whether or not to call some function, it likely indicates you’re about to make an assumption.

In times like this, you might also think you can infer the value, or figure it out by doing some automated work — but the thing is, you’ll be wrong. Not always, but there will be times where your assumptions won’t be valid, and you’ll be wrong. This will not only produce an annoying UX, but can also cause some of the sneakiest bugs you’ll ever have to deal with.

Think about a company signup form. We may think it’s a good idea to ask for their web address, so we can scrape their website, determine their industry, and then show relevant content as soon as they enter like magic (it lowers the barrier to entry, and there’s never an initial empty state!) But now imagine what happens if they mistype their address, don’t want to provide one, or just input a fake address to trial your app.

Stop creating work for yourself and just dumb it down.

Prevent problems, rather than intelligently fixing them

So you’ve stopped making assumptions in your code — but now you have people complaining because you didn’t assume how to fix their mistakes — and they make a ton of mistakes.

Let’s go back to the example of adding logic to filter out articles that have an empty unfinished body text. You say, ok I know this is just an assumption that people will want this, so I won’t filter them out. But what if they do want that? How do you fix this without making assumptions?

You don’t fix it, you prevent it. You can provide control at the root cause of the issue.

In this case it might be a confirmation box that appears when you go to publish a blank article, or publishing is prevented altogether until some body text exists. That’s Dumb Code, and it prevents you from having to write Smart Code.

Dumb Code doesn’t make assumptions, it doesn’t do more work than it’s expected to, and it puts control in the hands of the user. Dumb Code just does exactly what you think it does.

Product Designers and Developers both share the same responsibility for creating and maintaining products. We both love to solve people’s problems, and dream of providing that perfect experience to end users. So why can working together seem so frustrating at times. And how can we fix it?

In the spirit of collaboration I teamed up with my friend Lisa Jacquiot, a talented Product Designer to co-write this article!

If your product development workflow from research, through design to development looks like an assembly line, you’re going to have a bad time

Assembly lines are great for making repeated processes really efficient. The problem is that when we’re developing new things, nothing is a repeated process. Thinking and decision making are not suited to an assembly line robot.

Doing things like a developer handoff where sketch/figma/pdf/paint files are thrown over the fence from designer to developer indicates you might just have an assembly line on your hands.

Here’s why. If your researchers pass data and insights to product managers, who pass specs to designers, who pass designs to developers, then you have a system like the game Telephone.

What’s worse is that you’re also not utilising everyone’s respective skills. Product managers, Designers, and Engineers are all expert problem solvers, but we all come with different perspectives, and think in different ways.

As soon as any one of us start to think we have all the answers, we’re likely going to miss something.

The remedy is as expected: Involve each other at the various stages of the product development process.

Not everyone needs to be a decision maker at every stage — they just need to be involved enough to offer their unique insights, and provide feedback.

Asking for feedback can be hard because it’s time consuming and our solution is obviously the best anyway, so why even bother, right? Also don’t hurt my feelings please.

But realistically feedback can save you from going down the wrong path early, and provide insights and constraints that can spark new, vastly better ideas.

When starting a new project or task, schedule a design-dev (plus anyone relevant with knowledge) meeting, and work on the high level details for what’s possible. Then as a designer, instead of just escaping into that distraction-free, creative, design-utopia, and reappearing with completed designs, organise a few ~30 minute catch ups at different stages of the process.

Explain the thought-process behind your design decisions, and ask where the difficulties in implementing them might be.

As a developer, clarify when there’s unknowns, or when a design is far harder than anticipated and why. There might be an easy design solution.

This helps reduce the discrepancy between designs and the final product and it can build knowledge, and respect for each other’s skillset.

Our tools promote pixel perfection — but in different ways

It’s not just that designers and developers have different methods of thinking, we also have different tools that don’t always play nicely together.

Think about a standard login screen. From a designers perspective this is a single view. From an engineers perspective this is a dynamic assembly of individual components.

Once coded, the screen to designers might look out of alignment, have the wrong font color, or wrong spacing. And you scream in your head — why can’t you just align the text, and make the colors match my designs. It’s so easy!

Designers think in terms of pixel distances between elements, while developers think in terms of margins and padding. That’s the way our tools work.

To the devs, they can look at the design and think: Oh god no, I need to vertically center a div (ok, it’s easy now with flexbox, but just from habit). But what happens when a bigger screen size is used? How about when it’s rotated, or half screen? And there’s an error state missing.

Let’s say as a designer, you want the page to be responsive to screen sizes. If the tool offers a responsive grid to use. It might just be setting you up to fail since it might not be possible to be coded that way. For example…

And here’s how the UserAvatar in the design above might be created using the popular UI library React.

The problem is, although the UserAvatar is inside the LoginScreen component, it doesn’t have access to the grid used by the LoginScreen.

There’s a mismatch in how our tooling makes us think.

The solution? User flows, prototypes, and (again) two-way feedback!

Design for different screen sizes and orientations: create a list of the most common screen cut-off points based on the device breakdown for your product.

And don’t leave it up to the dev to connect the dots between still screens. It takes up their time and is error-prone. Provide them with clear flows mapping and connecting the different screens. For interactions — create a quick prototype showing how a page is supposed to load, or how to navigate your app.

Make a list of different states and produce designs for each state: empty states, first time user states, error states, logged in/out, loading states, partial content.

And for best results, sprinkle more feedback throughout.

Design Systems

The “Design System” is the perfect middle ground. Right? Well…

Yes! If it’s implemented in code. The reason why design systems are great is because it breaks up a product’s interface design into fundamental components, similar to how developers already work. It constrains design components to be consistent

When this system is implemented in code, for example in a UI component library, designers and developers are talking the same language!

Designers can use the fundamental components in their designs knowing the features and constraints of doing so. And developers can use the components directly from their prebuilt UI library in the components they build.

There is a drawback of design systems however. They are a ton of work to create and maintain for both the designers and developers. Seriously, a lot!

However, if you don’t mind not having a fully custom design system, there are a number of open source design systems such as Material Design or Bumbag that have accompanying UI component libraries that promote great design practices and accessibility by default.

That’s it, go forth and build cool stuff together!

Something that is simple to grasp, and easy to use. Something you can pick up with no prior knowledge and be able to utilise to help do whatever you’re trying to get done. Surely everyone wants that! So why on earth are there so few intuitive products?

The answer I’ve come to is this:
I don’t think it’s clear how to design for intuitiveness.

How do you create intuitiveness? Do you just have to remove features? Can only simple products achieve it? Is it just all about a good onboarding? How about a clean UI? And (after creating some monstrosity), is intuitiveness just overrated — users will learn eventually, right?

First let me say, intuitiveness is worth it. In a world of seemingly infinite product choices, the first minute of trial usage is probably the most important for the product’s success. If someone understands how they can solve their immediate problem with it, they’ll continue using it until they have a reason not to.

One thought on intuitiveness is that it equates to minimalism (largely by removing any non-essential features). This might work, but it’s kind of cheating — of course you can stumble upon intuitiveness if there’s only one thing it can do. Too bad it’s also then useless for solving anything but the most simple problems.

Fabricio Teixeira does go further, breaking intuitiveness down into a foundational set of design principles in his practical article What “intuitive” really means. But somehow I still felt like I was missing the underlying why?.

Instead, to answer the question of what makes intuitive products intuitive, you can look to how our brains actually process new things.

What happens in our brains when we come across something new?

If you’ve already read my previous article Clean Code Is All In The Mind, you can skip ahead as I’m just copy-pasting this section.

Let’s say you come across a book on a table written by an author you’ve never heard of before. Do you know how to use the book? Of course you do! If the cover looks interesting you’ll pick it up, and you know if you turn it over to the back side (that you have never seen in your life), there will likely be a blurb for you to read. You know that you can open it and there will be paper pages inside. You know you should start from the first outermost page, and read through it, page by page.

So how do you know so much about how to interact with something that you’ve never even seen before? The answer is Mental Models.

Our brains are exceptionally good at pattern matching, and so when we come across a book, our brains can access an existing mental model based on all the previous experiences we’ve had with books in the past. And it’s this mental model that provides us with a theory on how to interact with the very book in front of us.

It’s this ability for humans to store, pattern match, and retrieving complex mental models better than any other animal, which gives us our relative super intelligence.

Ok, but what is a Mental Model?

We can’t store every detail about every single thing we come across in the world as discrete memories inside our little heads. Plus it wouldn’t help much if every time we came across something slightly new and different (for example a new book) we didn’t know how to interact with it.

Instead, we use mental models. (In the brain these are just a connected set of neurons, and in machine learning these are like a layer of nodes in a neural network — but this isn’t really important). Think of a mental model like a block of knowledge. A theory representing how something in the world works. A small piece of logic.

Here we can identify the mental model by its shape, but in reality, we can identify our mental models not just by how it looks, but by a sound, smell, or any other combination of senses that make it distinctive. When we see a book, or hear the word “book”, our minds immediately go to the index for the mental model we have for books.

On closer inspection, a mental model also contains the related knowledge on each part making it up — mental models within mental models!

If it helps, you can also think of them like folders in your computer, or like Lego bricks stacked into small models.

However, the power of mental models isn’t in how they store our knowledge, but rather how they help us to solve problems. When we have a job to be done, it’s as if we have a hole in our understanding of how to move forward. The job needs to be filled with the knowledge of how we can get it done.

To fill this hole, we can experiment through stacking mental models together in our mind like Lego bricks, until we get something that fills it in an effective way.

Keep in mind, people’s ability to experiment with their mental models varies person to person. If you’re a creative problem solver, this may be easy, but many people may need solutions to be more obvious.

A side note here is the role of marketing. If potential users don’t have a mental model representing your product, then how can they experiment with it in their mind to work out how it could help them solve their problems. Their existing ideas (mental models) on how to complete a job have to be pretty bad for them to realise that maybe they don’t yet know the best solution and to commit to doing more work searching for a better one.

Marketing promoting an accurate mental model for your product can give people an alternative solution to experiment with, and could save them time and effort in finding you or your competitors. Creative, entertaining, and high quality marketing material likely have little to do with it though.

Back to intuitiveness

The thing to remember about mental models is that they’re just your theories on how things work, and they’re often wrong.

Magic, jokes, and optical illusions often play on this in a lighthearted way to trick your brain into initially using the wrong mental model, so that the punchline can surprise you. This can be fun, but since we need to use mental models to solve problems, using the wrong mental models can also breed confusion, and a lack of confidence in using a product.

Because of this, products that either promote an inaccurate mental model, or require a complex set of mental models to fully comprehend will be unintuitive to use.

Intuitiveness can be created by designing every part of a product in reference to a mental model, and then promoting the mental model through the UI and marketing.

In other words, keep the complexity of the mental models required to a minimum, and add affordances in the UI and you’ll have an intuitive product.

For example, if you think of the pre-iPhone smartphones (like the HTC shown above), they required a multitude of mental models to understand. There were various menus, sliding tabs that all had different “fancy” UI, and worst of all, the same functionality was often duplicated in different places with different UI (Windows Mobile contacts, or HTC TouchFLO 3D contacts tab).

I loved the HTC as it was something to explore, but most people don’t like to explore their tech, they just want it to help them.

The iPhone changed this. It didn’t require you to have a mental model for each menu, each UI, and for various similar programs.

It’s was simply a menu of apps — each with their own functionality contained within it. Want to do something, anything at all? It’s always the same. Look for the app that does it, and open that. Even the settings was just an app. Because of this anyone, not just the tech-savvy, could understand how the device could be used to help solve their problems.

All the apps had a similar UI too, and (if you remember skeuomorphic design) they often even looked like how they do in the real world. This helped users retrieve their existing mental models so they could predict how to use the new device.

Another side note. Interesting to see the use of widgets on the iPhone home screen now. Android have had them for a long time with mild success. Just apps no more.

But existing users find it intuitive…

Once you know the mental model for a particular product or feature, no matter how unintuitive it was at first, you’ll believe it’s logical. This can be a problem if you’re familiar with your product.

For example most idioms like “happily ever after” don’t have an intuitive meaning anymore, and so you likely have a mental model just for this phrase (does sadly ever before make much sense?). Those learning english might say it’s unintuitive.

Mental models are literally the logic within our heads, so if it’s in there, you’ll see the logic in it. From the outside however, others will not. Unintuitive mental models are like irregular looking blocks — They don’t fit well with other mental models which makes them harder to remember, and problem-solve with.

If you can recognise the mental models your users require to understand your product, you’re on the right track. If you find that they’re complex, or they’re not consistent with the mental models your UI and marketing promote, you have an opportunity to increase the intuitiveness. Another easy way to know — just ask your new users what they think.

Recognising the complexity of the mental models people require to understand a product is the path to understanding intuitiveness.

Intuitiveness can be created by designing every part of a product in reference to a mental model, and then promoting the mental model throughout the UI and marketing.

What makes intuitive products intuitive? was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

Org charts are hierarchical diagrams usually showing “upper management” at the top and then branching down to their direct reports, and so on. The CEO/boss makes the decisions and the control flows down. Does this sound accurate to you?

While this is accurate, it doesn’t promote a healthy frame of thinking for employees at any level. It promotes the idea that to progress you have to climb on top of others, rather than to support others.

This is where the upside-down organisational chart comes in. It flips the frame of reference. All employees sit above the CEO/boss! With this view it’s also possible to add customers (who sit at the very top), and products into the chart to show the full hierarchy of support.

The upside-down organisation chart promotes the idea of growing strong enough to get behind and support others, rather than climbing up over them.

An example of this in practice is the Australian supermarket giant Coles, that instead of having a ‘Headquarters’, have a ‘Store Support Center’. Everyone’s job in the support center isn’t to control and direct the hundreds of stores, but rather to support the stores, so that each can then better support customers in their grocery shopping.

So, how does it work?

Let’s use a hypothetical. Suppose you’re launching an exciting new company. First there is just you, but you work hard work and you get your first customers!

In this view, you are supporting your customers directly. You’re not working out how to extract value from them, you are working out how to best support them (and then how to share a portion of the extra money you’re helping them make/save!)

Add a Product

Some time later your workload has increased and you have a great idea. Use tech to help support even more customers. And so you introduce a product into the market.

With the upside-down org chart you can see that your product is now supporting many of your customers, and your job is to support your product. You’ve moved down! 👏

Add a Team

Ok, so your customers are really appreciating the support they’ve been receiving in helping to get their jobs done, and business is growing. You decide you need to hire a team!

In this view, you can see that your main concern is not supporting your customers anymore, it’s actually supporting your team! I’ve written about this before in What I’ve learnt after a year founding a tech company.

While this is overly simplistic, it can go on to contain as much detail about people and various departments as is useful.

You don’t have to be in “upper management” to gain a fresh perspective from an upside-down org chart, and it doesn’t have to be an official chart as long as you can visualise how it works.

Great managers at any level are those that support their team, and push them higher! Great contributors also know that it’s their managers responsibility to support them, and communicate how they can be better supported.

To progress down the chart, release direct control, and become stronger in supporting those above you.

Clean Code is code that is easy to understand, easy to use, and easy to modify.

You know when you see clean code because it’s a pleasure to work with, it seems intuitive and straightforward, bugs are easy to spot, and it allows you to develop new features at a fast pace even in a large codebase.

So how can you achieve this holy grail?

There are many books and articles that spew out a whole number of rules to follow to achieve “clean code”. These rules include guidelines for declarative variable naming, small pure functions, DRY (don’t repeat yourself), class length, one class per file, and more. But often these rules can be contradictory, not to mention controversial, and there’s so many that forgetting them is almost inevitable.

So here’s the 1 Rule to rule them all:

Always write code in reference to a mental model.

Awesome, but what’s a mental model?

Let’s say you come across a book on a table written by an author you’ve never heard of before. Do you know how to use the book? Of course you do! If the cover looks interesting you’ll pick it up, and you know if you turn it over to the back side (that you have never seen in your life), there will likely be a blurb for you to read. You know that you can open it and there will be paper pages inside. You know you should start from the first outermost page, and read through it, page by page.

So how do you know so much about how to interact with something that you’ve never even seen before? The answer is Mental Models.

Our brains are exceptionally good at pattern matching, and so when we come across a book, our brains can access an existing mental model based on all the previous experiences we’ve had with books in the past. And it’s this mental model that provides us with a theory on how to interact with the very book in front of us.

It’s this ability for humans to store, pattern match, and retrieving complex mental models better than any other animal, which gives us our relative super intelligence. However this can also lead us astray both in our lives and in our code.

So how does this help in writing clean code?

Bare with me as first we need to take another step back so we can set up the correct mental model for what a mental model is. So meta.

Think of a mental model as a block of knowledge about something. It has a shape, and a name. Both the shape and the name are what we use to index the model directly when we come across it in the world. (In reality the shape may be a sight, sound, smell, or some other sense, but for this model just think of it as a container).

So what is on the inside of the mental model container then? Well, it contains all the knowledge about the parts that make up your understanding of the thing. And since our brain use mental models to represent knowledge, this means each part inside the mental model is also a mental model!

When we come across something new, we take this model and use it as a template for the specific thing in front of us, modifying it as needed.

And when we need to complete a task, we can string these mental models together to produce a new mental model on how to solve it.

There’s two really important points to note however:

1. You can initially be wrong in identifying the right mental model as a template, and you won’t know it until you’re utterly confused by some interaction.

Magic, jokes, and optical illusions often play on this in a lighthearted way to trick your brain into initially using the wrong mental model, so that the punchline can surprise you. This can be fun, but since we need to use mental models to solve problems, using the wrong mental models can also breed confusion, failures, and a lack of confidence when writing code.

2. Once you know the mental model for a particular thing or piece of code, no matter how unintuitive it was at first, you’ll believe it’s logical.

Mental models are literally the logic within out heads, so if it’s in there, you’ll see the logic in it. From the outside however, others will not. Not only are irregular looking shapes unintuitive, they also don’t fit well with other mental models making them harder to remember and problem solve with.

Please just tell me how this relates to my code!?

Ok let’s go back to the rule: Always write code in reference to a mental model. So how do you do that?

Did the mental models shown above seem somewhat familiar? Does this help?

As you can see variables, classes, and functions are mental models! So the idea is to write these as close as we can to our pre-existing mental models.

To kick start you’re thinking, here’s some examples with code!

When creating things

Following the rule of always writing code in reference to a mental model, the first thing to do is decide what mental model to reference. What do you want to represent? A user? A signup? A notification? A book? This inevitably leads to thinking about naming and code structure! Perfect.

Naming

Naming may be the single most important factor in writing clean code.

Remember, we can use the shapes and names of things to identify the right mental model to think about. In code the shape of something like an object, function or a class is often hiding in anther file where it’s defined so we have to rely more heavily on the name alone. (Statically typed languages and a good IDE can help identify the shape more broadly however).

What words encourage the reader to infer what the code is most accurately.

user, buyer, seller, owner, creator, and admin all might be similar in shape, but the name used conveys a (probably important) difference in what the reader will expect the object to contain and be used for.

You may notice sometimes it’s hard to name something or you have an and in the name. This indicates that you might actually have two or more mental models mixed.

Defining code structure

To think about how to structure your code, think about the mental models you want to reference. For example let’s say you’re writing a setupUser function. What would you expect this function to do? Here’s one example.

As you can see, the function creates a user on the server based on some user details, then sets up the browser local storage, sets up notification preferences, and finally returns the user.

Is this what you expected given the name setupUser? What does “setup” mean? A few things could be improved here but the main thing to highlight is it’s unlikely anyone’s initial mental model for a function named setupUser would include creating a user on the server too.

One way to improve this would be to name the function createAndSetupUser, however this means the function is referencing two mental models, not one. A better approach would be to separate it.

While this still may not be perfect, we can see each part of this code is named and structured in a way that references one mental model at a time and won’t mislead the next person that comes across the code.

When Modifying things

More often than not, experienced developers will intuitively write new code in reference to their “clean” mental models. It’s instead when modifying code that all kinds of crimes are committed. This is because it’s often another developer adding a tiny part to it, and it may seem logical at the local level.

To always write code in reference to a mental mode while you’re modifying code, you have to take a minute to understand what the initial mental model was and stay true to it! It may make sense to you to add that one line to that function, but from the outside, that function might now contain a hidden bug waiting to happen.

Here’s an example of a user.

Now let’s say during the users onboarding you need to record whether they have seen and agreed to certain permissions. The easiest thing to do (and maybe even the most performant) is to add this directly to the user model.

Would you guess these new properties would be part of a user if you didn’t already know it?

A better approach would be to consider how they might be part of a new mental model. For example UserPermissions.

Again this can still be improved on depending on the use case, however when you or someone else is looking to find what permissions a user has confirmed, it should be more intuitive where to access the data and code. And if someone were to add more user permissions, there is a clear home for them — no meetings or discussion needed.

Always write code in reference to a mental model and you will be amazed how easy it is to determine what Clean Code is and how to write it.

The Only Rule You Need for Writing Clean Code was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

That was my thought process when starting the tech startup Rulo a year ago (named Curio at the time). I thought I had the product idea that could change the world, and with sheer determination and laser focus on product development my co-founders and I could make it happen.

I could not have been more wrong.

It wasn’t that our idea was bad, or that our product development didn’t meet milestones, the issue was my mindset and where I focused my efforts.

What I came to realise is, a startup is not about your idea, product, or technology, it’s all about people!

Coming from engineering, it took me a long time to realise this and I believe it’s one of the key reasons second+ time founders are far more successful.

Looking back, I should have focused my efforts more like this; team first, customers (controversially) second, and product third. Let me explain.

Team comes first

While most will probably say your customer should come first, I disagree. The reason is subtle but important — Your startups number one focus should be on your customer, but you are not your startup, you are leader within your startup. You should focus on developing the best team environment you can, who together can then focus on your customer.

I’ve seen first hand, the difference between an aligned team, where everyone loves their day to day work and the journey they’re on together, and a team whose goals were mixed, and had members that were uncommitted. The former is close to reaching $100K monthly recurring revenue, the latter is almost dead.

Build the culture you want from day one — even if it’s just you as a sole founder! It is incredibly hard to change behaviour later on. This is not about having bean bags and a table tennis table either (although great). Treat yourself and your team to learning, health and regular achievements. And after that, just have as much fun as possible!

As a side note: I also believe if someone doesn’t fit the culture (and isn’t making efforts to fit) it doesn’t matter if they’re your lead developer, they will bring down your other team members. The right thing to do by everyone is asking them to leave. The product is not as important as the team.

Customers/Market in close second place

A close second is to focus your efforts on those in your target market — your customers.

It’s really easy too! You just have to shut-up and listen to them.

A core human desire is to be understood, as this builds our sense of belonging. When initially talking with customers, you don’t need to try help them or tell about your (probably underwhelming) first solution. You just have to show that you understand them. They will naturally feel a sense of connection and belonging with you and your company and you’ll end up learning a whole lot more about them!

Warning though, to be actively listened to and understood can be so rare that I’ve literally had customers cancel their other meetings to talk on for hours!

When it comes to validating your ideas with customers, the Lean Startup is a great approach, but it’s largely based on trial and error. I’ve more recently found the Jobs-to-be-Done (JTBD) framework can provide a far better, more systematic approach to generating and validating ideas. It can help with framing your user research, identifying holes in the market, pricing, and prioritising user needs. When done right it can also make innovations ridiculously easy to identify.

In short, understand your customers and have them on-board the journey with you. If they’re not, go back and pick them up.

Product/Solution Third

Once you have the right people around you and you understand your customer, start building!

The two most important product development lessons I’ve picked up over the past year are things I had heard and read a thousand times before and yet I still had to fail with before they really sunk in.

Firstly keep the scope of work focused (you’ll never be able to build everything you want), and secondly moving fast is more important than being perfect.

Under the JTBD framework, the product is just something your customer hires to help them get a job done. If it doesn’t help, they will just as easily fire it as their solution and find something else.

This means given limited resources, it’s far more important that you build something that helps a specific customer group achieve a specific job really well rather than a just ok general solution that solves all the problems felt by your target market.

For Rulo that meant helping academic researchers recruit participants for their study, and not trying to solve their problems in report writing and publishing too.

Focus is harder than you think, especially if you and your team are creative and are constantly sharing new ideas. Be critical of the features you invest time into.

Lastly, some of the decisions we made early on that we thought were really important, proved not to be when looking back. React or Angular, AWS or GCP, MySQL or MongoDB — We wasted far too much time deciding on these when we could have been building something and getting feedback.

The reason we all fall into these traps is because they are really important aspects of the product. What we forget however, is that the difference between choices is often small, meaning either choice could suffice.

Even after all the time we spent deciding, we still made mistakes. It simply would have been better starting and changing later if needed.

Thanks for reading! I’m sharing this post as unfortunately this is the end of my journey within Rulo. If only I had known what I do now when I first started things could have been very different. I hope sharing this has triggered some of your own thoughts and will help you and the people around you to grow and have more fun! :)

If you got something out of this post, please share it around.

To follow me with whatever’s next, and to (possibly) get more insights like this one, find me on Twitter @ScottKitchell