What I wanted to know at the beginning of my development career. Part 1

When you start your career anywhere, you probably expect a lot, but you don’t know what to expect. Is it worth it not to lean out and do what is said or aim only at ambitious projects? This is what I learned during my work as a software developer.



Let me make a few assumptions based on my experience and observations. This list is not complete - because it cannot be. Your experience will be unique.

This is a translation of the response article on Quora.com, an illustration from LifeHacker.com .

1. Do not be afraid to study at work.Unfortunately, the bookshelves of most jobs are just there. You rarely see anyone reading a book, much less during working hours. Still, you can read the documentation and most books from a computer or e-book. So do it. It is unlikely that you will learn much if you do only what is said and said. You also will not advance anywhere if you require more work and get a routine. Stop, think, do things right and learn the basics. How do people become experts in areas like machine learning? Learn a little every day.

2. Manage your career intensively.Take control of your training and your progress. One out of ten (at best) finds a mentor who shows the beaten track and pulls the strings so that their student receives a promotion and a good project. If you are among nine others (and you will be among them most of the time) and work alone, reconcile yourself to the fact that no one cares about you. So take care of yourself. Do not ask another person for a job until you are sure that you trust this person and he will give you a better job than the one you are currently working on. Whenever possible, do as little work as possible that does not advance you on the career ladder or does not teach you anything; if this work does not matter for your career, then most likely people do not care that you do the work somehow. After three years, if you are not given tasks more or more difficult,

3. Learn to recognize flaws and processing, as well as avoid them.There are many lazy developers working for years. This is a good strategy if you get settled, but I would not fall like that. By the way, people who do so little work that they create work for the rest are usually fired for a flaw. Deficiencies who do not protrude do not usually make enemies. Beware of recycling at the same time. This is not a university in which you can get five for the fact that you arguably argued over your professor. Processors often create work for their colleagues and superiors and attract unnecessary attention, as well as have more chances to be fired under the item “performance of official duties” than underworkers. I do not mean that you should not try, do a good job and study as much as possible - it’s just not processing. In my experience, recycling is perhaps increased ambitiousness is much more dangerous than a flaw, because it will lead to your dismissal much faster. If you have to choose from two evils, lean toward a flaw.

4. Never ask permission unless it is dangerous to ask.Want to spend a week researching on your own initiative? Do not ask permission. You will not receive it. It is likely that you will not do a favor to your superiors by asking permission; from their point of view, you throw responsibility on them if you fail. In addition, in any case, he may give up your liability later, because he is above you. As you can see, there are no good sides to these requests. Of course, if you run the risk of causing serious damage to the business, or you just need to ask permission, then you must do it. If the losses are small, and the risks correspond to your level in the company (and you should not get a job for a programmer who is not trusted in weeks of your own time) - then do not ask permission. Just do it, and do it well.

5. Never apologize for being independent or using your own time. You can acknowledge that your project or your investigation did not work out as intended. although it’s better to imagine this as an attempt to research, but you should not apologize for the failed third-party project. This sets a precedent for you as a subordinate, on which more supervision is needed. After describing something that was done on your initiative, do not tell the boss: "Do not worry, I did it outside of working hours." If your company does not allow you to work on your projects during the hours of your work, then you should not try for their sake for any reason. Respect your time - otherwise no one will.

6 Learn to communicate.Learn the norms of communication once and forget about it. Do not study, and they will haunt you all your life. As we grow older, we begin to see value in portable and general abilities: functional programming instead of Spring / Hibernate, algorithms instead of the quirks of Java 1.4 legacy. Yes, communication skills within the norms are not pleasant, but it is applicable in the industry much better than any programming language. I'm not saying that you should forget about programming and become a polite gossip, because it will end badly, but you should know the norms and be able to communicate, because they are in everything that we do. It is good to start studying people and their actions as early as possible, even if you are not going to flirt with them (and in your youth you should not often flirt with your colleagues). Have you been given a cluster to solve your problem? Stop adding features to the project, so you can fix bugs? Have you been given a good project? This is all your communication skill. Good or bad, but this is your main tool, and in fact, you better use it, and not fall under its action. As soon as you learn to communicate within the framework of norms, you will get time to catch your breath, forget about it and just do a good job. If you do not learn, then your career will be shaped by those who use it better.

7. Do not be idealistic and do not try to prove that your bosses are not right.When young engineers feel that their ideas are better than those proposed by the boss, but do not find support, as a rule they sharply increase the rate and risks and spend many hours. “Let's prove that the boss is wrong ... by sacrificing your own time for what they will own!” Sorry, but if you had to throw a couple of days off (apart from rare cases like the “last jerk”) to complete the project, then your bosses not much cares about him. Otherwise, you would have time and resources, and also there was no patience for idealism. Instead of making a hat-trick a broken club, just let this game happen. The boss does not like when people who doubted him make a fool out of him. You will not receive a promotion or bonus. The authorities will find a way to prove their bad impression (and your sincere empathy with the success of the “bad” project will leave a mark on you) and even if you succeed, you will fail. There will always be room for: "He did a good job, but was distracted from the assigned work and I cannot trust him / we cannot allow him to set a precedent / it was my idea."

UPD: 6 point rewritten.

Also popular now: