Answer the question
In order to leave comments, you need to log in
How to increase development speed and attentiveness?
Hello everyone
Such a question: a new month has begun, the employer invited me to "summing up". It turned out that there are two snags: the speed of work and attentiveness. I understand that the questions are very trivial, but maybe you can give at least some advice?
I have about half a year of front-end development experience behind me, I have been working for two months now.
I would be grateful for any advice
Answer the question
In order to leave comments, you need to log in
It turned out that there are two snags: the speed of work and attentiveness.
Do not be distracted by extraneous things, such as social networks and a toaster
Make two files hosts.closed and hosts.opened
Schedule them to copy over hosts so that everything is closed only during working hours
The speed of work is a muddy and ambiguous thing. It has long been established as a fact that the brain can simultaneously store 7+-2 objects in consciousness, i.e. 5 to 9, depending on a bunch of factors. Anything more than that, you need to somehow cleverly organize, otherwise you get porridge. And only advanced Jedi can productively strain the brain for more than 4-5 hours a day...
Any work of any programmer begins with building a model of an application/module that needs to be worked on. In this process, an important link is the modeling of incoming and outgoing data flows.
When the model is more or less built, it is necessary to work out the architecture of the application, what is the foundation, what are the walls, what is the roof, what are the communications, and what is the decoration (cosmetics), and how it all fits in with other aggregated technologies.
In the process of building an architecture, all related technologies emerge at the same time, and it is possible to repeatedly revise both the model and the architecture, because these things are interconnected.
When the model and architecture are more or less settled, you can begin to plan something in terms of implementation, usually starting from the foundation.
An important factor is that both the model and the architecture must be kept in the head as a whole, with all the details, and load this stuff into the head, and settle there, sometimes it takes a decent amount of time.
Further, in the process of implementation, a manager with new breakthrough ideas will definitely resort, and broadcast that this is a trifle, nonsense and in general. In fact, such a manager is an amateur, and the project is threatened with a drain (failure to meet deadlines, budget, etc.), and the responsible developer will be to blame ...
However, life is a dynamic thing, and a lively and long-term business is always in resonance with life, so the same dynamic, and on the bolt twirled excuses and excuses of lazy progers. Therefore, the manager is essentially right, but this does not make it easier for anyone.
Jun is usually given something, on the one hand, non-urgent and not key, on the other hand, on which he can learn. It is clear that the junior does not have all these intricacies in his head and he rushes like a chicken with a written bag with his module / class.
The first advice to a jun is to torture the elder with prejudice regarding all the slightest nuances of his task, because due to the lack of experience, there is a very high probability of misunderstanding the task, doing a lot of time in the wrong direction and in the wrong place, for which you will later rake, although at the same time broadening your horizons.
The second recommendation is to realize that a jun is such a journeyman artisan who makes bricks with his hands, usually slowly and crookedly.
Half a year is very little, especially if you haven’t been involved in development before. To fully master the contexts and develop an initial level of skill, you need to gain at least a couple of thousand hours of furious debugging - the most valuable layer of knowledge about how not to do it. :) Then you will already feel in your gut where bugs could hide, where to dig and in general. At the dawn of my journey, I remember, once for 20 hours I couldn’t understand that I didn’t put one single comma ...
The third recommendation is to write the code concisely so that the functions / methods fit entirely into one screen. Moreover, write functions / methods with a single responsibility, and try to make as many of them as clean (no global variables and states, only arguments). Such code is much easier to read / understand, and to test and debug.
The fourth recommendation is to constantly upgrade your skills, read the docks a lot, delve into, ask a lot of questions and look for answers to them, and try everything in practice. The criterion of truth is practice.
The fact that the jun is not very fast is normal, up to 70% of the time the jun should study the docks, from the remaining 30%, up to 95% of the time is debugging. :) So, there is not much time left for a real maid, 0.3 * 0.05 ...
It is clear that ideally a jun should do this not only during work, but also in his free time. When I dug into the basics, I could maniac for 12-16 hours a day, without holidays, weekends and vacations. Luckily, circumstances allowed...
And, most importantly, patience + perseverance. This path is not easy, not easy, you will have to constantly learn, and they will constantly criticize what could be more precise, faster, more and cheaper .... :)
Apparently you work in a hurry and make mistakes. Slow down, double-check - follow the proverb: "Measure seven times, cut once." Better long and high quality than fast and tyap-blunder.
Perhaps you were taken as ambitious. But you dig a lot in the documentation and you have to finish it for you. When they finish it for you, it's bad. You mow a lot.
Speed: To get more done in the same amount of time, you first need to understand how it is spent. Time it for a few days. There are a lot of services for this, but for a beginner, a piece of paper with a pen is best. The log should contain 2 columns: time, what did. Write everything down to going to the toilet, otherwise there will be a distorted picture. Also write the work not in one piece, but for example: understood the task, figured out how to do it, coded, debugged, merged, etc. Then sum up and figure out what activities take how much time. There you will understand where the fact diverges from expectations and how to optimize. BUT compare yourself with other developers of your level so that it doesn’t turn out that they are trying to turn you into a robot that doesn’t eat, doesn’t drink, but only codes.
Attentiveness:If the problem is not a lack of qualifications, but namely attentiveness, train concentration. You need to be able to get rid of extraneous thoughts while busy with business. This exercise is called meditation. Find the technique in Google, discarding the esoteric.
the employer invited to "summing up". It turned out that there are two snags: the speed of work and attentiveness.to send on nah this smart guy. not satisfied - let him look for another. respect yourself.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question