6 "bad" tips for the developer

/ photo 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 better not to say to developers and testers . This time we will go from the other side and discuss working moments in which developers themselves are sometimes mistaken.

1. Eat, sleep, code, repeat!

It is known that many developers follow this concept - it has become a kind of mantra, which is repeated by the most dedicated workers. However, it hides a dangerous subtext. If you think about it, this phrase promotes an unhealthy lifestyle, inspiring the idea that programming is everything. Allegedly, in order to succeed in this area, you must devote yourself entirely to development. But in fact, everything is quite the opposite.

There are many other exciting activities besides programming: reading, hiking, gardening, walking with a dog, skiing, motorcycle racing and so on. The list goes on and on.

When you are distracted by other activities, your brain gets the opportunity to “breathe” air away from compilers and compilers. That is what will make youa better developer, will develop mental flexibility and qualities such as creative thinking and patience. They cannot be cultivated by writing code.



The tech industry loves to hyperbolize, they say, how else can you become a programming guru if you don't devote all your waking hours to application development? Yes, enthusiasm can take you to the pinnacle of success, but to stay there and become a really good programmer, reserve a place in your schedule for the entertainment of “mere mortals”.

2. Mitap not needed

Among developers, there is an opinion that applications are delivered on time only if programmers write code, and do not sit on the “flight debriefing”. But you need to understand that in order to create a good product, it is necessary to devote time to these conversations, otherwise the company risks going in the wrong direction.

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

However, mitaps are necessary to organize work. This allows each member of the team to get acquainted with the status of the project. Oddly enough, this is primarily important for management.

Peter Thiel, co-founder of PayPal, once said : “As the 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 abreast and not feel like an outsider.

If you really feel sorry for the time for such a "group therapy", then try to invite management to hold face-to-face meetings or give a general report to the team leader. This frees up valuable development time.

3. UI can be done by yourself ...

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

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

Here he wanted to display some information, so he created this field, of course, with the intention of deleting 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 is this parameter not displayed anywhere? The mess. Add another slider. The result is something like this:



The appearance of the created monster interface becomes so familiar that the development team ceases to notice its “heap”. Later, when it pops out, putting everything in order is quite difficult.

Those who are eager to learn how to design good interfaces should start by exploring this topic on Stack Overflow.

4. ... and test everything yourself

A developer cannot be a tester (of course, there are always exceptions ). This is due to the fact that the developer knows all the details of the software created by him too well, therefore 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 take part 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 for the written code.

Known fact: it is difficult to objectively evaluate your creation. Developers are emotionally attached to their operators and functions.



A good example is children. Parents consider their children ideal (do not notice the flaws) and are 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 “ineffective” ways to use them (what can go wrong?) - switching consciousness in a short period of time is quite problematic.

3) Simplification of complex scenarios

Testers learn to look for complex scenarios of 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 essence, they are looking for ways to complicate a simple process. Developers, on the contrary, break down complex processes into small components that allow them to find a solution.

4) Weak “smell”

Good tester “ smells ”»Bugs and easily reveals that it does not fit into the overall picture of the application. It comes only with great experience.

Most developers do not have a clear idea of ​​how users will use the software. Testers understand exactly how users achieve their goals, and they can "simulate" their work with the application.

5. Be a customer and developer in one bottle

The problem of the developer and the customer in one person is that the developers focus 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 do not want to hear each other.

It is also worth noting that, acting as a developer, the customer limits the rights of the development team, since the last word will always remain with him. Developers will also fail to delegate all the powers. You can’t write code and not express your opinion about the project?

6. "Stealth mode" or "Alone In The Dark"

The code "smells" - this is what they say when a listing shows potential problems and flaws at a glance. Martin Fowler, 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 defining bad code (for example, here , here and here ). Often this problem is associated with excessive complexity, confusion, thoughtless copying, etc.

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



This is because when you work alone, incredible exposure is required so as not to start looking for easy ways. The documentation will be incomplete, the processes will not be optimized, sometimes you can forget about refactoring.

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

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

---

At 1cloud, we believe that you need to talk about development, share experience with friends and colleagues. Good code and services are not born out of nowhere, they become so, being tempered in the fire of criticism. Habr is excellent for this, but we can only quickly respond to any criticism and give maximum information about our IaaS provider.