What should an IT person avoid doing in 2020?

Habr is full of predictions and advice on what to do in the coming year—what languages to learn, which fields to shift towards, and how to handle our health. It sounds inspiring! But any coin has two sides, and we stumble not only in something new but mostly in what we do every day. "Why didn't anyone warn me!" we exclaim irritably, often addressing ourselves. We call the fire upon ourselves—we have gathered for you a list of things NOT to do in 2020 (or perhaps always). 

And gravity was not asked

We would love to organize anti-recommendations in order, from the most important to the least significant. But they are so widespread, equivalent, and familiar to almost everyone that we will write them haphazardly. So, shall we check the list?

Don't go into IT if everything is fine

Don't study a new technology to change professions or start from scratch. Our times are great in that you can learn, change jobs, fundamentally change fields—and do so until retirement. It's an enticing and cool thing. But if you are over 28-30, it's not advisable to drop everything to enter IT or switch to a new stack (for instance, if you are writing high-load systems in Java and suddenly decide to switch to neural networks in Python). The reason is simple: it will be difficult for you. Firstly, there is high competition from specialists who have been in that stack since the beginning of their careers, secondly, you'll have to become a junior again with a low salary, and thirdly, it will be psychologically challenging to become the subordinate at the lowest level of the hierarchy. Therefore, if you want to move in a different direction, try to do it either within the scope of your current job and current tasks or develop new knowledge as a hobby—work on a pet project so that you can come to a new job not as a junior. 

Switching stacks is just wasting time

Don't jump between technology stacks for your development. If you are writing a project in one language, using a specific framework and libraries, don't just throw everything away and rewrite it in Dart just because it seems interesting to you. Make it a rule to find justification for changing technology—not only at the level of "I want to, I can't," but also on financial and engineering levels. 

There's no need to stand your ground and turn to bronze.

Sticking to one language or technology and not exploring new ones is just as extreme as switching tech stacks with every new technology. It’s essential to learn new libraries and frameworks; don’t be stubborn, believing that everything has already been invented by others and polished solely by you. Almost every programming language regularly releases updates that can greatly enhance your project. Don’t be lazy about keeping track of your stack's evolution, and as soon as you find something cool and useful, confidently integrate it into your project!

Your own mind is good, it's always good.

Don’t think with others' minds; your own is better. Unfortunately, some developers sit and wait for tasks, coding from the previous error to the end, without attempting to contribute something of their own to the project, develop a new feature, test it, and propose it for production. Why burden yourself when there’s a team lead or manager who will make all the decisions? If this sounds like you, we’ve got bad news: a passive stance won’t help either your career or your growth. You have a chance to try your hand as an engineer-developer, not just a coder in a real project, and understand where to go and what is lacking; yet you prefer to spend your time on something else, doing only the bare minimum. Those who take such an approach in modern IT are surviving less and less; it’s time to come out of hibernation. 

Users are strange creatures.

Don’t overestimate the users of your software: if you're not writing for programmers, expect that the program will face incomprehensible challenges. For the first few days or weeks, users may hate your software because 'the old one wasn’t this stupid.' To avoid this, create great documentation and training materials. When installing or purchasing, strongly hint that manuals should be read before starting work with the software, not after a database crash, password loss, and self-control breakdown.

Don’t underestimate users either: they are smarter, more cunning, and more curious than you think. If you believe that the bug with the variable format and the exception on pressing Enter at the 138th time with a one-second interval won’t come up, you’re mistaken — it will, and it will affect the operation of your application in the most peculiar ways. There's a rule of thumb: it is often the amateur who does the best testing. However, for some reason, users don’t like finding bugs in production — there’s no IT solidarity in that. In summary, 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 functioning application and make it suddenly unstable.

Stop Googling!

Stop relying solely on Google. There's no debate here — in the development sphere, you can find a lot with a direct query to a search engine. The deeper you dig for information, the more 'side' data you’ll uncover, and you’ll learn more because you’ll encounter new information that may not directly relate to your query but could be useful in the future. Refer to complete materials, books, articles, etc. Languages and libraries have specifications, communities, how-to guides, and thus you get the most reliable way to develop your skills as a programmer — simply by reading documentation instead of searching for someone else's local solutions and code snippets. What if your solution is more optimal, faster, and better? 

Trust, but verify

Do not use libraries and frameworks created by third-party developers without checking the code and adapting it to your goals. You have no reason to unconditionally trust the author of the code you don’t even know. Yes, various intentional malicious elements in third-party code don’t occur that often, and you shouldn’t suffer from paranoia, but blindly copying ready-made software parts into your project can lead to unpredictable consequences. Therefore, always read and analyze the code before usage and conduct testing after code implementation. 

Make backups!

Stop neglecting backups or keeping them on the same third-party servers where your project is hosted. Think this is a funny and unnecessary piece of advice? Over 700 members of a Telegram chat who recently faced an unpleasant situation with a well-known data center shutdown didn't think so — there were everything from pet projects to major government websites and corporate 1C databases and billing systems involved. A significant number lacked backups or had backups stored on the same servers. So distribute your risks and keep a backup at least on your main hosting, on a reliable VDS, and on your local server. In the end, it will be much cheaper. 

Stop bringing your own issues at the expense of the project

Don't do in a working project what you want; do what your clients need. Yes, it's incredibly interesting and great to create your own neural network, train it, and implement it in your software, but if your clients need a simple contact manager, that's an unnecessary extravagance. Look at how the project works, read the documentation, go through client reviews and requests, and implement what will add business value to the project. If you want to create something scientific or overly complex, start with your own project.

Not code, but a bundle of nerves

Don't write unreadable and undocumented code. We're familiar with this trick: a developer writes code as they see fit, intentionally making it somewhat confusing so that no one else can figure it out — a sort of preventive revenge before anything happens. However, you're putting not only the company (which pays you for your work) at risk but yourself as well: it's quite possible that you won't remember what you meant by this unintentional obfuscation. The same goes for undocumented code: relying on your variable and function naming logic and good memory, in a couple of years, you might not recall why you chose that particular loop, method, pattern, etc. Documenting code and structuring it well is a fantastic service to your colleagues, employer, and primarily to yourself. 

Keep it simple, stupid

Don't complicate code, solutions, and projects. There’s no need to build复杂结构 and create entities without significant meaning. The more complex your code, the more you become its hostage — it will be extremely difficult to maintain and develop. Of course, the well-known KISS principle ('Keep it simple, stupid') doesn’t always apply, but it exists for a reason: simplicity and elegance of code are key to its successful implementation and reuse.

Stay protected

Don’t ignore security — in 2020, this is literally criminal. Even if your company, development, and you are not interesting to malicious actors, problems related to the compromise of some segment of the network, a hosting provider, an attack on a data center, password theft from email, and unsafe employee behavior, who may steal data from the company, take customers, or the entire project’s source code, can affect you. If it's within your power and falls under your area of expertise, try to protect the projects you work on. And also maintain information security yourself; it has never hurt anyone. 

Don't spit in the well

Don't disrespect your employer. Nowadays, communication has reached such a level that, for example, all HRs in the city are virtually familiar with each other and can exchange any information in chats and closed groups (such as how to help find employment, or write 'Vasily Ivanov, system architect, deleted all accounts before leaving, erased backups, and disabled the network; recovery took 3 days. Don’t hire him.'). Therefore, your behavior will play against you — and sometimes relocation to another city or capital won’t help. Even if you leave in anger, there’s no better revenge than being a valuable and cool employee of a competitor 🙂 Above all, completely without consequence.

It's also not a good idea to do that. But, as experience shows, we won't stop.

Anyway, friends, read the advice but do what seems best to you — after all, true discoveries are made when we question established truths. We congratulate you on the New Year; may your projects be successful, your career be interesting, your colleagues and leaders be reasonable, and life, in general, be rewarding. Cheers to the New Year and new code! 

With love,
the RegionSoft Developer Studio team

In the new year, we will continue to work for you and develop a powerful desktop CRM system. RegionSoft CRM and a simple and convenient helpdesk and ticket system. ZEDLine Support.

Source: habr.com