Habr is full of forecasts and advice on what to do next year - what languages to learn, what areas to turn into, how to deal with your health. Sounds inspiring! But every coin has two sides, and we stumble not only in something new, but mostly in what we do every day. “Well, why didn’t anyone warn me!” We exclaim in annoyance, usually referring to ourselves. Let's call the fire on ourselves - we have compiled a list of things NOT to do in 2020 (and maybe always) for you.
Gravity was never asked
We'd love to put the anti-recommendations in order, from most important to least important. But they are so common, equivalent and familiar to almost everyone that we will write out of order. Well, let's check the list, shall we?
No need to go to IT if everything is fine
Don't learn new technology to change careers or start from scratch. Our time is wonderful because you can study, change jobs, radically change the field - and so at least until retirement. It's cool, seductive stuff. But if you are over 28-30, you should not give up everything in order to enter IT or leave for a new stack (for example, you write highly loaded systems in Java and suddenly decide to go into neural networks in Python). The reason is simple: you will not be easy. Firstly, there is high competition from specialists who have been sitting on this stack since the beginning of their careers, secondly, you will have to become a junior with a low salary again, and thirdly, it will be morally difficult for you to become a subordinate of the lowest level of the hierarchy. Therefore, if you want to move in the other direction, try to do it either in line with the current work and current tasks, or develop new knowledge as a hobby, file a pet project in order to come to a new job no longer as a junior.
Stack to stack to change - only time to lose
Don't jump between technology stacks for your development. If you are writing a project in one language, using a certain framework and libraries, you should not throw everything to hell and rewrite it in Dart just because it seemed interesting to you. Make it a rule to find a justification for changing technology - not only at the “want-I can’t” level, but also at the financial and engineering levels.
No need to stand your ground and bronze
Sticking to one language or technology and not learning new things is as extreme as changing the stack with each new technology. Be sure to study new libraries and frameworks, do not be stubborn in the mind that everything is better thought up before you and finished only by you. Updates are constantly being released for almost every language, which can sometimes greatly improve your project. Do not be lazy to follow the dynamics of your stack and, as soon as you find something cool and useful, feel free to drag it into the project!
Your head is good, always good
Do not think with other people's heads, your own is better. Alas, some developers sit and wait for the task to code from the previous error to the end, without trying to bring something of their own into the project, develop a new feature, test it and offer it to production. Why bother when there is a head of a team leader or a company leader who will decide everything on their own? If you recognize yourself, then we have bad news: a passive position will not help either in your career or in development. You have a chance to try your hand as a development engineer rather than a coder in a real combat project and understand where to go, what is missing, but you prefer to spend your time on something else and do exactly “from here to now”. Such in modern IT survive worse and worse, get out of suspended animation.
Users are terrible people
Don't overestimate the users of your software: if you're not writing for programmers, expect the program to run into impenetrable misunderstandings. For the first few days or weeks, the user will hate your software because "the old one wasn't so dumb." To avoid this, make cool documentation and tutorials. When installing or buying, very intrusively hint that the manuals should be read before starting to work with the program, and not after the crash of the database, loss of the password and self-control.
Users should not be underestimated either: they are smarter, smarter and more curious than you think. If you think that that bug with the variable format and the exception on the 138th press of Enter with an interval of a second will not pop up, you are mistaken - they will pop up and affect the operation of your application in the most bizarre way. The amateur rule works: it is he who copes with testing best of all. But for some reason, users do not like to find bugs in production - there is no IT solidarity in them. In general, the more confident you are in your software, the better. After all, it's better to delay the release of certain features than to add them to a running application and make it suddenly raw.
Stop googling!
Stop relying on Google alone. We won’t even argue - in the field of development, you can find a lot with a direct request to a search engine. The deeper you dig in search of information, the more "lateral" data you will receive and learn more, because you will learn something new that is not related to your query, but probably necessary in the future. Refer to full-fledged materials, books, articles, etc. Languages and libraries have specifications, communities, how to, and thus you get the most reliable way to develop programming skills - just read the documentation, and not look for other people's local solutions and code snippets. What if your solution will be better, faster and cooler?
Trust, but verify
Do not use libraries and frameworks created by third-party developers without checking the code and adapting it to suit your purposes. You have no reason to unconditionally trust this author of a code that you do not know at all. Yes, various deliberate malicious elements in third-party code are not so common and you should not suffer from paranoia, but blindly copying ready-made parts of software into your project can lead to unpredictable consequences. Therefore, be sure to read and analyze the code before use and conduct testing after the implementation of the code.
Make backups!
Stop not making backups or keeping them on the same third party servers where your project is hosted. Do you think this is ridiculous and useless advice? But more than 700 Telegram chat participants who got into a recent unpleasant situation with the shutdown of one well-known data center did not think so - everything was there: from pet projects to large state sites. bodies and corporate databases 1C and billing. A significant part - without backups or with backups in the same place. So distribute the risks and store the backup at least on the main hosting, on some reliable VDS and on your local server. It will end up being much cheaper.
Stop bringing your own to the detriment of the project
Do not do what you want in the working project, but do what the clients need. Yes, it’s incredibly interesting and cool to create your own neural network, train it and implement it in your software, but if your clients need a simple contact manager, this will be a costly overkill. See how the project works, read the documentation, read the feedback and requests from customers, and implement what will add business value to the project. If you want to create something scientific or super complex, start with your own project.
Not a code, but a bundle of nerves
Do not write unreadable and undocumented code. We are familiar with this trick: the developer writes the code as God puts it on his soul, deliberately confusing it a little so that none of his colleagues could understand what was written - such a kind of preventive revenge before something happened. However, you are not only putting the company (which pays you money for the work) at risk, but also yourself: it is likely that you yourself will not remember what you wanted to say with this unintentional obfuscation. The same with undocumented code: relying on your variable and function naming logic and good memory, in a couple of years you may not remember why you chose this particular loop, method, pattern, etc. Documenting your code and structure it well is a great service to your colleagues, your employer, and most of all, yourself.
Keep it simple, stupid
Keep your code, solutions, and projects simple. There is no need to fence a complex structure and produce entities without special significance. The more complex your code, the more you become its hostage - it will be as difficult as possible for you to maintain and develop it. Of course, the famous KISS principle (“Keep it simple, stupid”) is not always suitable, but it was created for a reason: the simplicity and elegance of the code is the key to its successful application and reuse.
protect yourself
Do not ignore security - in 2020 it is literally criminal. Even if your company, development, and you are not of interest to attackers, you may be affected by problems associated with the defeat of some network segment, hosting provider, with an attack on the data center, with the theft of mail passwords and with the unsafe behavior of employees who can steal data from the company, steal customers or the program code of the entire project. If this is within your power and falls within your area of expertise, try to protect the projects you work on. Well, observe information security yourself, this has not bothered anyone yet.
Don't spit in the well
Don't bullshit your employer. To date, communications have reached such a level that, for example, all HRs of the city are familiar with each other in absentia and can exchange any information in chats and closed groups (how to help find a job, and write “Vasily Ivanov, system architect, killed everything before leaving accounts, erased backups and disconnected the network, the recovery took 3 days. Do not take him to work"). Thus, your behavior will play exclusively against you - and sometimes even relocation to another city or capital will not help. Even if you leave with a grudge, there is no better revenge than to become a useful and cool employee of a competitor 🙂 And most importantly, with complete impunity.
It's not worth doing that either. But, as experience shows, we will not stop
In general, friends, read the advice, but do what seems best to you - after all, real discoveries are made when we doubt already discovered truths. We congratulate you on the New Year, may your projects be successful, your career not boring, your colleagues and leaders adequate, and life in general is good. In general, for the New Year and for the new code!
With love,
RegionSoft Developer Studio team
In the new year, we will continue to work for you and develop a powerful desktop CRM system and a simple and convenient helpdesk and ticket system .
Source: habr.com