September 23, 2013 at 12:32The rules of a “good” IT company
I have been asking myself questions for a long time and I myself am looking for answers to them: what is an “ideal” IT company? For the developer, for the manager, for the owner, for customers? What is a “good” IT company, what should be in it and what should not? As a result, for myself, I formed such a list here, 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 ways - more characteristic of non-IT companies, but nonetheless ... The principles of an “ideal” IT company in my view. In simple words and a little childish.
Make systems interesting and things good (“good things”)
You can produce a bunch of low-quality products and in the near future have more money from this. But in the long run, you will lose. Remember, where are the notorious "flecks"? .. Who did not have time to grow out of them is gone. In programming, everything is the same.
Always be one step ahead.
Don't be afraid to use something new. Give it a try. Search. Always be on the crest. Sooner or later it will “take” you to something very interesting and promising.
Synergy. People - first of all
Then - technologies, processes, advertising, contracts, partners, money, stocks 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 article Two types of entrepreneurs
Look for the best and create an atmosphere in a team
Look for the best. Or grow the best. And pay programmers more than the market average. Think up 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, informers, sweeping the other riffraff - sooner or later it will bury both your company and yourself.
Create comfortable working conditions
Just believe: a programmer sitting in a warehouse among boxes and shelving in a staggering chair will leave you at the earliest opportunity. Unless, of course, he needs at least something in life.
Invest in specialist training
Educate yourself, send to trainings, courses, conferences. If at the same time you are afraid that the specialist will leave by “gaining skills” at the trainings, it means that your company has deeper problems. Solve them, not save on training. And do not be greedy!
Avoid direct money competition between professionals
Monetary competition between specialists is an undeniable, absolute evil. Monetary competition between employees leads to disunity of the team. If Vasya knows that he can “beat off” the task from Petya and earn 5000 more 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, “egalitarianism” also should not be.
Throw away the junk. Ruthlessly. Do refactoring and remove the “bad” code from thegovnokod .
Old furniture, servers, and the code restrict the space around. Do not let breathe. Do regular cleaning - and it will become light in your house.
Do not follow up with users (customers).
Tons of literature has already been written about this, it makes no sense to repeat. In IT, the client is not always right. Moreover - he does not always know what he wants.
Do not let the system freeze, the development to stop, and programmers to relax
Do not be afraid of change. Change and change. “Shake” your programmers - otherwise sooner or later they will relax, dry out and become stiff with their beer - and at some point they will not be able to do anything new and interesting.
Never do it fast. Then it will still respond to you!
The temptation is always great. But the problems from this are even greater. You can’t even imagine which ones ...
If you do, fix it as normal 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 ORM.
One of the most typical and gross architectural errors. See “Never do it fast.”
Take the algorithms to the application server, do not lay the algorithms in SQL
SQL SQL'yu discord. See “Never Do It Quickly”.
Get rid of complex branches and conditions in the code. Use patterns
... otherwise, you yourself will not know where you have what. If there are too many conditions and branches, this is a sure bell that there is something “wrong” in the system, that there are architectural errors or that the system has simply “outgrown” itself, and it’s time to change something radically.
Separate the code as
much as possible by logical and physical entities If it is not clear in your code what object is responsible for and what it is inherited from - a priori you yourself do not know what you are writing and what you are doing at all. The question is: what for then? .. After all, in fact, we get the picture as in a famous fable:
Simplify applications. Forget about editing values in grids.
Another ineradicable evil, sometimes leading to very significant problems in the system. Each time, sitting down to write a desktop application - imagine that you do not have it, but only the web-interface. Imagine how you will do “editing the picture in the cell of the grid column, which is a cell of another grid under the condition of such and such” - and be horrified. Instead of having all this hemorrhoids - just make a separate editor. And do not worry yourself and the customer’s brain.
Do not reinvent the wheel: use standard solutions (Best Practices, frameworks and APIs)
To write your own substring search algorithm in a string is, 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 unnecessary. It is much more optimal to use standard solutions using a well-known framework than to get bogged down in the invention of bicycles.
Do not mix different functionalities in one heap. Design (mutually) interchangeability of components (and clients)
. Developers are always tempted to do everything in one application - often it's easier. But in the long run - get a monster. Especially if the system is large and complex.
Do not try to blame performance problems on hardware
An ultra-modern server is great. But if the software is crooked and eats all the memory that is available - no server will help. Iron still let you down.
Write in modern programming languages and use modern technologies.
I, of course, 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 a 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!
Make systems interesting and things good (“good things”)
You can produce a bunch of low-quality products and in the near future have more money from this. But in the long run, you will lose. Remember, where are the notorious "flecks"? .. Who did not have time to grow out of them is gone. In programming, everything is the same.
Always be one step ahead.
Don't be afraid to use something new. Give it a try. Search. Always be on the crest. Sooner or later it will “take” you to something very interesting and promising.
Synergy. People - first of all
Then - technologies, processes, advertising, contracts, partners, money, stocks 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 article Two types of entrepreneurs
Look for the best and create an atmosphere in a team
Look for the best. Or grow the best. And pay programmers more than the market average. Think up 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, informers, sweeping the other riffraff - sooner or later it will bury both your company and yourself.
Create comfortable working conditions
Just believe: a programmer sitting in a warehouse among boxes and shelving in a staggering chair will leave you at the earliest opportunity. Unless, of course, he needs at least something in life.
Invest in specialist training
Educate yourself, send to trainings, courses, conferences. If at the same time you are afraid that the specialist will leave by “gaining skills” at the trainings, it means that your company has deeper problems. Solve them, not save on training. And do not be greedy!
Avoid direct money competition between professionals
Monetary competition between specialists is an undeniable, absolute evil. Monetary competition between employees leads to disunity of the team. If Vasya knows that he can “beat off” the task from Petya and earn 5000 more 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, “egalitarianism” also should not be.
Throw away the junk. Ruthlessly. Do refactoring and remove the “bad” code from the
Old furniture, servers, and the code restrict the space around. Do not let breathe. Do regular cleaning - and it will become light in your house.
Do not follow up with users (customers).
Tons of literature has already been written about this, it makes no sense to repeat. In IT, the client is not always right. Moreover - he does not always know what he wants.
Do not let the system freeze, the development to stop, and programmers to relax
Do not be afraid of change. Change and change. “Shake” your programmers - otherwise sooner or later they will relax, dry out and become stiff with their beer - and at some point they will not be able to do anything new and interesting.
Never do it fast. Then it will still respond to you!
The temptation is always great. But the problems from this are even greater. You can’t even imagine which ones ...
If you do, fix it as normal 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 ORM.
One of the most typical and gross architectural errors. See “Never do it fast.”
Take the algorithms to the application server, do not lay the algorithms in SQL
SQL SQL'yu discord. See “Never Do It Quickly”.
Get rid of complex branches and conditions in the code. Use patterns
... otherwise, you yourself will not know where you have what. If there are too many conditions and branches, this is a sure bell that there is something “wrong” in the system, that there are architectural errors or that the system has simply “outgrown” itself, and it’s time to change something radically.
Separate the code as
much as possible by logical and physical entities If it is not clear in your code what object is responsible for and what it is inherited from - a priori you yourself do not know what you are writing and what you are doing at all. The question is: what for then? .. After all, in fact, we get the picture as in a famous fable:
Simplify applications. Forget about editing values in grids.
Another ineradicable evil, sometimes leading to very significant problems in the system. Each time, sitting down to write a desktop application - imagine that you do not have it, but only the web-interface. Imagine how you will do “editing the picture in the cell of the grid column, which is a cell of another grid under the condition of such and such” - and be horrified. Instead of having all this hemorrhoids - just make a separate editor. And do not worry yourself and the customer’s brain.
Do not reinvent the wheel: use standard solutions (Best Practices, frameworks and APIs)
To write your own substring search algorithm in a string is, 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 unnecessary. It is much more optimal to use standard solutions using a well-known framework than to get bogged down in the invention of bicycles.
Do not mix different functionalities in one heap. Design (mutually) interchangeability of components (and clients)
. Developers are always tempted to do everything in one application - often it's easier. But in the long run - get a monster. Especially if the system is large and complex.
Do not try to blame performance problems on hardware
An ultra-modern server is great. But if the software is crooked and eats all the memory that is available - no server will help. Iron still let you down.
Write in modern programming languages and use modern technologies.
I, of course, 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 a 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!