
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 all this can be learned.
Here is my list of what is needed for developing software projects that really sell well and work well:
Learn how to create a product for people.
Creating a product for people is the same skill as many others, and it can be learned. I do not mean visual design (although this is also part of the process). I’m talking more about recognizing the problem and understanding how to ensure human-computer interaction, which guarantees the user a successful solution of problems without any difficulty, instead of simply creating the standard CRUD application to work 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 with the help of these programs, and what you need to do to solve them. For example, how many mouse clicks do I need to do in an e-mail program in order to write an answer? How many tags do I need to read? How often do I need to switch between the mouse and the keyboard? Does this help me in solving common problems? How about finding all the attachments from emails from a specific person - you will be surprised at how difficult it is to do with software!
Learn and use several languages.
If another language (or other development environment) is the best solution or gives you great advantages, then use it. Often, mastering the next tool is not worth the extra effort.
Do not underestimate the value of something new for the working environment: all new items must be tested, involved, protected, control must be made - and this can take years.
Do not get fooled by advertising
Use what is best for you. If your productivity is high for PHP, then work with PHP. Of course, sometimes technologies are actually capable of increasing productivity or providing other significant benefits, but I’m not exaggerating if I say that this is a huge rarity - this happens, perhaps, once or twice a decade.
Do not fall for the hook, believing that the basic idea is good only because there are many variations of a particular technology. In fact, this may indicate that people are desperately looking for a technological solution for the wrong approach.
For example, client-side MVC for almost any type of web application functionality adds overhead (because with more layers, more interfaces are needed between them), it reduces productivity (you need to write more code, and layers complicate the process of eliminating errors) and does not improve user experience.
User interface design is hard work, and using client-side MVC will not do the magic for you.
Stick to one style
Together with languages, frameworks, libraries, the way you use a language changes like seasons. One month you used closure with might and main, and in the next you will find out that this is already obsolete.
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 a minimally viable solution
With this you can not overdo it: while writing code, do not write anything that the code does not really need for normal operation. Do not think in advance about how you can expand it in the future. All the same, everything will be as you did not expect. Focus on the code that works, and write tests better, rather than waste time on abstract assumptions.
And do not forget: the code is not set in stone. It's easy to reorganize or rewrite later, when you really need to change or expand it, and when you know the real requirements.
Avoid difficulties
I do not use CSS or HTML preprocessors such as HAML or Sass (if you are comfortable with them, 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 much easier for me to mess around with code at a lower level (for example, simply 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 write JavaScript completely. There are not enough advantages for me in the form of a slightly cleaner syntax and better language capabilities, in order to deal with additional compilation steps, more complex settings and an additional level of abstraction when debugging.
All these difficulties are relative. What seems terribly complicated to me, you can perceive 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 uncomfortable with using this or that tool, then you probably should not try to adapt it to your work style. Just find what suits you best.
Coding> Configuration
It’s easy to get into trouble by relying too much on code written by other people. Should be (as you believe), if many people use this code, then it should be of high quality. After all the truth? By the way, this is why most people use Windows. This is what is called "reasonable sufficiency" (satisficing), or the desire for something that seems 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 well known Not Invented Here syndrome?
Choosing a ready-made component is almost always not the most optimal way to solve a problem. Such tools will solve your problem by 80%. And then suddenly it turns out that for this seemingly simple thing that looked so simple, there is no possibility of configuration. And now you need to reorganize the source code and fix errors in the selected library, and ultimately make the code branching. After that, you need to understand how to properly perform the tests, and here it suddenly turns out that the possibility of conducting tests is simply not available. And then ... And all in the same spirit.
Do not forget that you are a programmer, not a configurator
Try to track time and exactly what you do during programming. These include: thinking about how to implement a specific feature, developing man-machine interfaces and ensuring interaction, creating plans and task lists for implementing a specific function, choosing tools and libraries that facilitate work, creating prototypes, writing the code itself, testing and performing iterations for searching errors and ensure proper functionality.
You will be surprised at how little time you spent writing the code itself compared to how much it took to choose and configure the 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 problem area, makes me think about borderline cases. Nothing like this would ever happen if I chose a ready-made library that does all the work for me.
Never stop learning
Perhaps the best way to be always in the subject, from time to time to perform various side-projects. This is a great option to enjoy new things without introducing “technological clutter” into your work design.
For example, write an open source microbibliography (or even two) and use it to share with other people the things you learned to use in your work.
Experiment and remake certain elements in order not to lose the joy of programming - creating various things from nothing.