6 "harmful" tips to the developer

/ photo by Alexandre Dulaunoy CC

Last week, in our blog on Habré, we discussed the topic of communication within the team. It was about what things are best not to say to developers and testers . This time we will come from the other side and discuss working moments in which developers themselves are sometimes mistaken.
')

1. Eat, sleep, code, repeat!

It is known that this concept is followed by many developers - it has become a kind of mantra, which is repeated by the most dedicated workers. However, it contains a dangerous subtext. If you think about it, this phrase promotes an unhealthy lifestyle, suggesting that programming is everything. Allegedly, to succeed in this area, you must fully devote themselves to the development. But the reality is quite the opposite.

There are many other exciting activities besides programming: reading, hiking, gardening, walking the dog, skiing, racing motorcycles and so on. The list is endless.

When you are distracted by another activity, your brain gets the opportunity to "breathe" the air away from translators and compilers. This is what will make you the best developer, develop the flexibility of the mind and such qualities as creative thinking and patience. They can not be cultivated, engaged only in writing code.



The technical industry likes to hyperbolize, they say, how else would you become a programming guru if you don’t devote all your waking hours to developing applications? Yes, enthusiasm can bring you to the top of success, but in order to stay there and become a really good programmer, reserve a spot in your schedule for the entertainment of "mere mortals."

2. Mitapy not needed

Among developers, there is a perception that applications are delivered on time only if programmers write code, and do not sit on “debriefing”. But you need to understand to create a good product, to devote time to these conversations is necessary, otherwise the company runs the risk of going the wrong way.

Someone considers the meeting a corporate nightmare. Long hours are spent weekly in meetings during which no particularly important decisions are made. Planners are their most popular variety when a dozen people gather to talk about the situation and future projects. Many of their participants are bored and do not pay enough attention to the reports, soaring in the clouds, going down to the ground only when you need to answer the question.

However, mitapy needed to organize work. This allows each team member to become familiar with the status of the project. Oddly enough, first of all it is important for management.

Peter Thiel, co-founder of PayPal, once said : "As a CEO, you are the center of the organization, but sometimes you know the least in the company." Therefore, even small reports lasting 5-7 minutes will allow the boss to keep a finger on the pulse and not feel like an outsider.

If you really feel sorry for the time for such a "group therapy", then try to offer the management to hold meetings one-on-one or give a general report to the leader of the team. This will free up valuable development time.

3. UI can be made and most ...

Deep within each developer is a novice designer. If you let him escape, then you are in trouble. Well, or at least the problems are waiting for users of the application.

There are interfaces that instantly make you smile. You can imagine the flow of thoughts that flashed through the head of the developer at the time of creating this masterpiece. Often this is a bogus dialog box or some utilitarian application.

Here he wanted to display some information, so he created this field, of course, with the intention to delete it later. Here he decided that it would be nice to add a couple more parameters - this is how several new buttons and drop-down lists appeared. So, why this parameter is not displayed anywhere? Disorder. Add another slider. As a result, something like this is born:



The appearance of the monster interface being created becomes so familiar that the development team ceases to notice its “clutter”. Later, when it comes to light, it is quite difficult to put everything in order.

Those who want to learn how to develop good interfaces should start with studying this topic at Stack Overflow.

4. ... and test everything yourself

The developer cannot be a tester (of course, there are always exceptions). This is due to the fact that the developer knows too well all the subtleties of the software created by him, because it is difficult for him to draw any conclusions about the viability of the code - this fact is well known to testers.

Of course, developers can participate in the testing process, especially in the case of Agile, but you need to remember about the "blind spots". Here are a few of them:

1) Parental love of written code

A well-known fact: it's difficult to evaluate your creation objectively. Developers are emotionally attached to the operators and functions written by them.



A good example is children. Parents consider their children ideal (do not notice shortcomings) and get angry if someone scolds their child.

2) Positive thinking

Most of the developer’s efforts are aimed at the effective implementation of functions. In testing, it is necessary to look for "inefficient" ways to use them (what can go wrong?) - switching consciousness in a short period of time is quite problematic.

3) Simplify complex scenarios

Testers learn to search for complex scenarios for using functions, for example, they perform many actions at the same time or repeat the same operation several times to “break” the system and identify bugs. In fact, they are looking for ways to complicate a simple process. Developers, on the contrary, break complex processes into small components that allow them to find a solution.

4) Weak "scent"

A good tester " feels " the bugs and easily reveals that it does not fit into the overall picture of the application. This only comes with more experience.

Most developers do not have a clear idea of ​​how users will handle software. Testers understand how users achieve their goals, and know how to “simulate” their work with the application.

5. To be a customer and developer in one bottle

The problem of the developer and the customer in one person is that the developers focus all their attention on solving problems, and the customer’s task is to find them. It can be difficult to switch from one scenario to another.

The developer focuses on the code and architecture of the product. The customer is thinking about business requirements. Sometimes these two people don't want to hear each other.

It is also worth noting that, speaking as a developer, the customer limits the rights of the development team, since the last word will always remain with him. Delegate all the powers to developers, too, will not succeed. You can not write code and not express your opinion about the project?

6. “Stealth Mode” or “Alone In The Dark”

The code "smells" - so they say, when in the listing at a glance you can see potential problems and flaws. Martin Fowler, the author of several books and articles on software architecture, calls this "smell" an indicator of the problems present in the system. To date, hundreds of articles have been written on the topic of identifying bad code (for example, here , here and here ). Often this problem is associated with excessive complexity, complexity, mindless copying, etc.

However, code written by one person will also "emit an unpleasant smell." This does not mean that it is bad, simply, if you show it to other experts, they will improve it with 100% probability.



This is because when you work alone, you need an incredible endurance, so as not to start looking for easy ways. Documentation will be incomplete, processes will not be optimized, sometimes you can forget about refactoring.

On the other hand, programming "by the light" gives only a positive result. In the process of work, you start to think about trifles, for example, the names of variables, and reviews of other developers will help you grow as a specialist.

Perhaps this is quite an obvious thing, but not every developer is ready to give his work to the court of others. Asking for feedback is not easy - no one likes to hear that he was wrong.

---

We in 1cloud believe that the development needs to be told, to share experience with friends and colleagues. Good code and services are not born out of nowhere, they become so, tempered in the fire of criticism. Habr is great for this, and we can only promptly respond to any criticism and give maximum information about our IaaS provider.