I have been asking myself questions for a long time and I myself am looking for answers to them: what is the “ideal” IT company? For the developer, for the manager, for the owner, for clients? What is a “good” IT company, what should it be and what should not it? As a result, for myself, I formed such a list, such a quintessence of wishes and my own experience. It can be useful to any developer, manager, CEO. Perhaps this is somewhat naive, in many respects - more typical for companies “not IT”, but nevertheless ... The principles of an “ideal” IT company in my view. In simple words and a little childish.

')
Make systems interesting, and things - quality ("good things")You can produce a bunch of low-quality products and in the short term to have more money from it. But in the long run - you lose at the same time. Remember, where are the notorious "flea market" now? .. Whoever didn’t have time to grow out of them - was gone. In programming, everything is the same.
Always be one step aheadDo not be afraid to use something new. Try it. Search. Always be on the crest. Sooner or later it will “take out” you to something very interesting and promising.
Synergy. People firstThen - technology, processes, advertising, contracts, partners, money, promotions and other rubbish. If you do not believe people, and people do not believe you, working for money and only for money - you have no future. See the article Two types of entrepreneurs
Look for the best and create an atmosphere in the team.Look for the best. Or grow the best. And pay programmers more than the market average. Come up with other "holding" bonuses - invent. Create your own unique atmosphere in which people would like to be. In which they would be comfortable. Never keep "bad" people near you: gray mice, snitches, swept and other riffraff - sooner or later it will bury both your company and yourself.
Create comfortable working conditionsJust believe: a programmer sitting in a warehouse among the boxes and shelves in a reeling chair will leave you at the first opportunity. Unless, of course, he needs at least something in life.
Invest in specialist educationTrain on your own, send to trainings, courses, conferences. If at the same time you are afraid that the specialist will leave, “having picked up skills” at trainings means that there are deeper problems in your company. Solve them, but do not save on training. And do not be greedy!
Avoid direct monetary competition between specialists.Monetary competition among specialists is an incontestable, absolute evil. Monetary competition between employees leads to a disunity of the team. If Vasya knows that he can “discourage” the task of Petya and earn 5000 more money next month - most likely, he will do it. Maybe Petya will not even be offended ... But they will never be friends and work as a team. Competition can be "indirect" - in knowledge, in responsibility, in mentoring - but not in money. This is very bad. In this case, "leveling" also should not be.
Throw out the old stuff. Mercilessly Refactor and remove the "bad" codeOld furniture, servers and code hamper the space around. Do not give to breathe. Do general cleaning regularly - and it will be light in your house.
Do not go on about the users (customers)Tons of literature have already been written about this, it makes no sense to repeat. In the IT client is not always right. Moreover, he doesn't even always know what he wants.
Do not let the system "freeze", the development stop, and programmers - relaxDo not be afraid of change. Change and change. Shake up your programmers - otherwise, sooner or later, they will relax, dry out and ossify with their beer - and at some point will not be able to do anything new and interesting.
Never do "in a quick way." This will then respond to you!The temptation is always great. But the problems from this - even more. You can't even imagine what ...
If you do, correct it “as normal” as soon as possible!
Programming is not languages!Programming is technologies, development environments, APIs, frameworks. Programming is people, their knowledge and dreams. Their ideas and aspirations. Programming languages as an entity are secondary.
SQL: do not write complex stored procedures. Simplify your data better and use ORMOne of the most typical and gross architectural errors. See “Never do it in a quick way.”
Bring algorithms to application servers, do not lay the algorithms in SQLSQL SQL'yu discord. See “Never do“ in a quick way ”.
Get rid of complex branches and conditions in the code. Use templates... otherwise you will not know where you have what. If there are too many conditions and branches, this is a sure call that there is something “wrong” in the system, that architectural errors are made, or the system simply “outgrown” itself, and it is time to change something radically.
Maximize the code by logical and physical entitiesIf in your code it is not clear what the object is responsible for and from which it is inherited - a priori, you yourself do not know what you are writing and what you generally do. The question is: what for then? .. After all, in fact, we get the picture as in the famous fable:
Simplify applications. Forget about editing values in gridsAnother ineradicable evil, sometimes leading to very significant problems in the system. Every time, sitting down to write a desktop application - imagine that you do not have it, but there is only a web-interface. Imagine how you will be doing there “editing the image in the cell of the grid of the grid, which is the cell of another grid under the condition of such and such” - and be terrified. Instead of having all this hemorrhoids - just make a separate editor. And do not worry yourself and the customer brain.
Don't reinvent bicycles: use standard solutions (Best Practices, frameworks and APIs)Write your search algorithm for substrings in the string - of course, interesting. Maybe it will even be faster than the standard one - if you are a good programmer. The problem is that in most cases this algorithm is absolutely not needed. Much better is to use standard solutions, taking a well-known framework, rather than getting bogged down in the invention of bicycles.
Do not mix different functionality in one pile. Design (inter) interchangeability of components (and customers)Developers are always tempted to do everything in one application - it is often easier. But in the future - get a monster. Especially if the system is large and complex.
Do not attempt to impose performance problems on iron.Super modern server is great. But if the software is crooked and eats all the memory that is available - no server will help. Iron still fails.
Write in modern programming languages and use modern technology.Of course, I admit that it seems to someone that writing in Delphi, Visual Basic or some other strange or ancient dialect is cool. But this is not cool at all, believe me. And there will be a lot of problems in the future.
Do not overload interfaces. Only minimalistic and modern design.Try to make a second Apple. Most likely, you will not succeed. But still strive.

The list can be supplemented - the ideal IT-company is not limited to anything!