How to create software that really works?

Do you really think that you have everything to create cool software? I will tell you one secret: it is not easy and requires a lot of effort, but you can learn all this.

Here is my list of what is needed to develop software projects that sells really well and works well:

Learn how to create a product for people.

Creating a product for people is the same skill as many others, and you can learn it. I do not mean visual design (although this is also part of the process). I’m rather talking about recognizing a problem and understanding how to ensure that a person interacts with a computer that guarantees the user a successful solution to problems without any difficulties, instead of just creating the most standard CRUD application for working with Databases, which includes several typical UI components.

To do this, at first you can do the following: analyze the software of other developers and what tasks you need to solve using these programs, and what you need to do to solve them. For example, how many mouse clicks do I need to make in an email program in order to write an answer? How many tags do I need to read? How often do I need to switch between mouse and keyboard? Does this help me in solving well-known problems. How about finding all the attachments from letters from a certain person - you will be surprised at how difficult it is to do this using software!

Learn and use several languages

If another language (or another development environment) is the best solution or gives you great benefits, then use it. Often, mastering the next tool is not worth the extra effort.

Do not underestimate the importance of something new for the work environment: all new products must be checked, involved, protected, and control must be done - and this can take years.

Do not get fooled by ads

Use what is best for you. If your productivity is high in PHP, then work with PHP. Of course, sometimes technologies can actually increase productivity or provide other significant advantages, but I will not exaggerate if I say that this is a huge rarity - this is, perhaps, once or twice a decade.

Do not fall for the hook, believing that the main idea is good only because there are many variations of a particular technology. In fact, this may indicate that people are desperate for a technological solution for the wrong approach.

For example, client-side MVC for almost any type of web application functionality adds an overhead (because with more layers and more interfaces between them), it reduces productivity (you need to write more code, and layers complicate the process of eliminating errors) and in fact does not improve user experience.

UI design is hard work, and using MVC on the client side will not do the magic for you.

Stick to one style

Along with languages, frameworks, libraries, the way you use the language is changing - like the seasons. For one month you have been using closures with might and main, and in the next you will find out that this is already out of date.

Try to reduce cognitive stress while writing code and debugging so that you can calmly think about solving problems that you really need to solve.

Implement the smallest viable solution

You can’t overdo it: when writing code, do not write anything that the code actually does not need for normal operation. Do not think in advance about how you can expand it in the future. All the same, everything will be the way you did not expect. Focus on code that works and write tests better than wasting time on abstract assumptions.

And don't forget: the code is not carved in stone. It is easy to reorganize or rewrite it later, when you really need to change or expand it, and when you know the real requirements.

Avoid the difficulties

I don’t use CSS or HTML preprocessors such as HAML or Sass (if it’s convenient for you to work with them, then use them for health and increase your productivity!) - my style of writing code and polishing applications requires a lot of fuss and rework, and for it's a lot easier for me to mess around with code at a lower level (for example, just copying and pasting styles and working with development tools in the browser directly in the CSS file).

And although I really like CoffeeScript, it's still easier for me to just completely write JavaScript. The advantages in the form of a slightly cleaner syntactic construction and better language features are not enough for me to then deal with additional compilation steps, more complex settings and an additional level of abstraction during debugging.

All these difficulties are relative. What seems terribly complicated to me can be perceived as simple and natural. It will take time to understand which types of work are best for you.
Be honest with yourself - if you feel inconvenient in using this or that tool, then perhaps you should not try to adapt this to your style of work. Just find what suits you best.

Coding> Configuration

It's easy to get it wrong, relying too much on code written by other people. It should be (as you believe), if many use this code, then it should be of high quality. Is it true? By the way, that’s why most people use Windows. This is what is called “satisficing,” or the pursuit of something that seems to be sufficient for a person.

Your brain is always trying to find the easiest solution. He will tell you to forget about any component or library, and most programmers will agree with this. Why reinvent the wheel and suffer from the famous Not Invented Here syndrome?

Choosing a ready-made component is almost always not the best way to solve a problem. Similar tools will solve your problem by 80%. And then suddenly it turns out that for this simple, it would seem, thing that looked so simple, there is no possibility of configuration. And now you need to do the reorganization of the source code and correct errors in the selected library, and ultimately make the code fork. After that, you need to understand how to run the tests correctly, and here it suddenly turns out that the ability to conduct tests is simply absent. And then ... And all in the same vein.

Do not forget that you are a programmer, not a configurator

Try keeping track of time and what exactly you do during programming. These include: thinking about how to implement a specific feature, developing human-machine interfaces and ensuring interaction, creating plans and task lists for implementing a specific function, choosing tools and libraries to facilitate work, creating prototypes, writing code itself, testing and iterating to search bugs and ensure proper functionality.

You will be surprised at how little time you spent writing code in comparison with how much it took to select and configure libraries.

You could save a lot of time if you just write code from scratch. I found out that writing code often helps me better understand the area of ​​the problem, making me think about borderline cases. Nothing of the kind would ever happen if I chose a pre-made library that does all the work for me.

Never stop learning

Perhaps the best way to stay on top of this is to do various side projects from time to time. This is a great option to enjoy getting to know new things without introducing “technological mess” into your work project.
For example, write an open source micro-library (or even two) and use it to share with other people things that you have learned to use in your work.

Experiment and remodel certain elements in order not to lose the joy of programming - creating various things from nothing.