25 Feb 2020

Knowing your users

History / Edit / PDF / EPUB / BIB / 2 min read (~314 words)

What should I know about my users if I want to build appropriate software for them?

If you are building technical software for your users, you need to know what their level of expertise and experience is. If you can use a job title to describe their position, that is a great start.

You should define the users' strengths and weaknesses, that is, what you expect them to excel at and where they will require more of your assistance to succeed at their task.

Define the scenarios in which your users use the software you will build. What information do they have available? Which information do they need to gather? What kind of decisions do they need to make? Which decisions can be automated for them? Do they need to run the software in a specific environment? Do they need access to data to do their task? How is this data made available to them? When do they use the software? How frequently do they use the software? How much of their time is spent on the task they are solving using the software you're building?

Define what the users' goals are. You might be creating a text editor, if your users' goal is to transmit information between companies, they may not care at all about making the text fancy but they might appreciate your editor helping them correct grammatical mistakes.

You want to be as specific as possible when describing your users so that your decisions are guided by this persona you're creating. What kind of company are they working in? Startups, PME, large enterprises? Do they have multiple responsibilities or are specialized?

With all this information about your users you should be able to make more judicious decisions. This will help you scope your work.

24 Feb 2020

The definition of value in business

History / Edit / PDF / EPUB / BIB / 1 min read (~126 words)

How is value defined in a business context?

For a solution to be valuable it must solve an actual problem.

If a need exist for the solution, then the solution must do one or many of the following:

  • Reduce costs/time: reduce human resources needed to produce the same results
  • Increase quality: Increase accuracy/repeatability of a process
  • Solve a problem that could not be solved previously
  • Have a significant impact on costs for improving an already solved problem
  • Offer the ability to scale the process without having to scale the necessary human support linearly with the growth of the process
  • Help with identifying the most important pieces of the business in order to follow the 80/20 principle
23 Feb 2020

Writing good documentation

History / Edit / PDF / EPUB / BIB / 2 min read (~213 words)

What do you need to know to write good documentation?

You need to know who your audience is. You need to know what they should know so that you can make assumptions about their knowledge. You should also be able to tell what they won't know. It is mainly this lack of knowledge that you need to fill when you write your documentation.

Once you have established who your audience is, you should state it clearly. This way, readers will be able to determine if they identify or not with the target audience, which can help them better frame how to read the documentation.

The purpose of documentation should be clear. Is it to describe a specific use case, provide a getting started guide, answer specific questions regarding functionalities?

You need to state explicitly what you will cover and not cover in the documentation. Readers may start reading your document which contains assumptions about their knowledge, but if they do not have this knowledge, they should know where to acquire it.

It should be easy for readers to know where to reach the author of the documentation or people knowledgeable enough to guide them to the right people.

22 Feb 2020

Onboarding users on your library

History / Edit / PDF / EPUB / BIB / 2 min read (~338 words)

How can you onboard users to use your library as fast as possible?

You need to make it as frictionless as possible for them to use your library.

First, they need to know the value proposition of the library. They need to know why they should use your library and not find another one available online. It needs to be convincing and to touch on the tasks they need to accomplish. The closer your vocabulary is to theirs, the easier it will be.

Second, the installation process needs to be as painless as possible. If you use a language with a package manager, give instructions on how to install your package using the package manager. If there are multiple popular package managers for the language in which the package was written, make sure to cover the most used ones.

Third, when users do not understand how to do certain tasks using your library (when it is in its early stage of development), take note of those questions, especially the wording. You want to capture what they were trying to do, how they described what they wanted to do, and why they were trying to do it. With this information in hand it should be easy for you to determine whether your library supports (or should support) the use case they tried to accomplish. If your library is not going to support the use case, make sure to indicate it early in the documentation so that users do not have the wrong expectation that your library will help them with this use case.

Finally, try to learn as much from your users as possible. Try to understand what it is they are trying to accomplish and whether it is valuable to most of them if you were to support new use cases. If you can document the most common use cases so that they can read the steps they'll have to go through, it will be simpler for them to evaluate the process before going through it.

21 Feb 2020

Ways to measure intelligence

History / Edit / PDF / EPUB / BIB / 1 min read (~163 words)

What are the different ways to measure intelligence?

We can measure intelligence as:

  • the number of CPU cycles necessary to solve a problem. Less is better.
  • the amount of energy spent by a system to solve a problem. Less is better.
  • the time necessary to solve a problem. Less is better.
  • the space (memory, RAM, atoms) necessary to solve a problem. Less is better.

The benefit of all those measurements is that they are scalar and thus ordinal, creating an order between the different agents that can successfully solve the problem.

Those values can be taken separately as one axis of intelligence. Taken together, they become a complex measurement of intelligence where there's no clear ordering between the different approaches. The agent with the "highest intelligence" is defined by the requirements of the environment: if energy sources are abundant in the environment, then using little energy is less important than using less time or space.