What I wanted to know at the beginning of my development career. Part 1
When you start a career anywhere, you probably hope for a lot, but don’t know what to expect. Should we not stick out and do what has been said or aim only at ambitious projects? This is what I learned during my time as a software developer.
Let me make a few assumptions based on my experience and observations. This list is not complete - because it can not be. Your experience will be unique.
This is a translation of the article-answer on the resource Quora.com, illustration from the site LifeHacker.com .
')
1. Do not be afraid to learn at work. Unfortunately, the bookshelves of most jobs are just there. You rarely see anyone reading a book, especially during business hours. Still, you can read documentation and most books from a computer or e-book. So do it. It is unlikely that you will learn a lot if you do only what is said and how it is said. You also will not get anywhere if you demand 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? They study every day little by little.
2. Manage your career intensively. Take your training and your progress into your own hands. One out of ten (at best) finds a mentor who shows the beaten track and pulls the strings so that their student gets 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, accept the fact that nobody 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 job better than the one you are doing now. When possible, do as little work as possible that does not move you up the career ladder or teach you something; if this job doesn’t matter for your career, then most likely people don’t care that you do the work somehow. After three years, if you are not given more tasks or more difficult than at the beginning of your career, an “outdoor boost” (read: a job change) is usually a good way out.
3. Learn to recognize flaws and recycling, as well as avoid them. There are many lazy developers working for years. This is a good strategy if you are settled, but I would not fall that way. By the way, for the flaw usually fired people who do so little work that they create work for others. Flaws who do not protrude, usually do not make enemies. At the same time, beware of recycling. This is not a university where you can get a five for arguing that you argued your professor. Processors often create jobs for their colleagues and bosses and draw unnecessary attention, as well as being more likely to be dismissed under the item “job fulfillment” than non-workers. I don’t mean that you don’t have to try, do a good job and learn as much as possible - it’s just not recycling. In my experience, recycling - perhaps increased ambition - is much more dangerous than flaws, because it will lead you to dismissal much faster. If you have to choose from two evils, lean towards the flaw.
4. Never ask permission, unless asking is dangerous. Want to spend a week on research on their own initiative? Do not ask permission. You will not get it. It is likely that you will not do a favor to your superiors by asking for permission; from their point of view, you throw responsibility at them if you fail. In addition, in any case, he can refuse your responsibility later, because he is taller than you. As you can see, there are no good sides in these requests. Of course, if you risk serious damage to a business, or you are simply asked 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 you don’t trust in your own time in weeks), then don’t ask permission. Just do it, and do it well.
5. Never apologize for being independent or using your own time. You can admit that your project or your investigation did not work out as intended. Although it is better to present it as an attempt to research, but you should not apologize for the failed third-party project. This creates a precedent for you as a subordinate, over which more observation is needed. After describing something done on your initiative, do not tell the boss: "Do not worry, I did it outside working hours." If your company does not allow you to work on your projects during your work hours, then you should not try for any reason for them. Respect your time - otherwise no one will.
6 Learn to communicate. Learn the norms of communication once and forget about it. Do not learn, and they will haunt you for life. When we grow up, we begin to see the value of transferable and common abilities: functional programming instead of Spring / Hibernate, algorithms instead of Java 1.4 legacy fads. Yes, the skill of communicating within the norms is not a pleasant one, 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 must know the rules and be able to communicate, because they are in everything we do. It’s good to start learning about people and their actions as early as possible, even if you are not going to flirt with them (and in your youth you shouldn’t often flirt with colleagues). Have you been given a cluster to solve your problem? Stop adding features to your project so you can fix bugs? Have you been given a good project? This is all your communication skills. Good or bad, but it is - your main tool, and in fact you better use it, and not fall under its action. Once you learn to communicate within the norm, you 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 formed by those who use it better.
7. Do not be an idealist and do not try to prove that your boss is 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 dramatically increase the rate and risks and spend many hours. “Let's prove that the boss is not right ... by donating his own time to what they will own!” Sorry, but if you had to throw out a couple of weekends (not counting rare cases like the “last spurt”), to complete the project, it means your boss not much care about him. Otherwise, you would have time and resources, and you also had no patience for idealism. Instead of making a hat-trick with a broken stick, just let this game happen. The boss does not like when people who have doubted him make a fool out of him. You will not receive a promotion or bonus. The bosses will find a way to prove their bad impression (and your sincere empathy for the success of a “bad” project will put a mark on you) and, even if you succeed, you will fail. There will always be room for: “He did a good job, but he was distracted from the assigned work and I cannot trust him / we cannot allow him to create a precedent / it was my idea”.
UPD: 6 item rewritten.
Let me make a few assumptions based on my experience and observations. This list is not complete - because it can not be. Your experience will be unique.
This is a translation of the article-answer on the resource Quora.com, illustration from the site LifeHacker.com .
')
1. Do not be afraid to learn at work. Unfortunately, the bookshelves of most jobs are just there. You rarely see anyone reading a book, especially during business hours. Still, you can read documentation and most books from a computer or e-book. So do it. It is unlikely that you will learn a lot if you do only what is said and how it is said. You also will not get anywhere if you demand 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? They study every day little by little.
2. Manage your career intensively. Take your training and your progress into your own hands. One out of ten (at best) finds a mentor who shows the beaten track and pulls the strings so that their student gets 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, accept the fact that nobody 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 job better than the one you are doing now. When possible, do as little work as possible that does not move you up the career ladder or teach you something; if this job doesn’t matter for your career, then most likely people don’t care that you do the work somehow. After three years, if you are not given more tasks or more difficult than at the beginning of your career, an “outdoor boost” (read: a job change) is usually a good way out.
3. Learn to recognize flaws and recycling, as well as avoid them. There are many lazy developers working for years. This is a good strategy if you are settled, but I would not fall that way. By the way, for the flaw usually fired people who do so little work that they create work for others. Flaws who do not protrude, usually do not make enemies. At the same time, beware of recycling. This is not a university where you can get a five for arguing that you argued your professor. Processors often create jobs for their colleagues and bosses and draw unnecessary attention, as well as being more likely to be dismissed under the item “job fulfillment” than non-workers. I don’t mean that you don’t have to try, do a good job and learn as much as possible - it’s just not recycling. In my experience, recycling - perhaps increased ambition - is much more dangerous than flaws, because it will lead you to dismissal much faster. If you have to choose from two evils, lean towards the flaw.
4. Never ask permission, unless asking is dangerous. Want to spend a week on research on their own initiative? Do not ask permission. You will not get it. It is likely that you will not do a favor to your superiors by asking for permission; from their point of view, you throw responsibility at them if you fail. In addition, in any case, he can refuse your responsibility later, because he is taller than you. As you can see, there are no good sides in these requests. Of course, if you risk serious damage to a business, or you are simply asked 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 you don’t trust in your own time in weeks), then don’t ask permission. Just do it, and do it well.
5. Never apologize for being independent or using your own time. You can admit that your project or your investigation did not work out as intended. Although it is better to present it as an attempt to research, but you should not apologize for the failed third-party project. This creates a precedent for you as a subordinate, over which more observation is needed. After describing something done on your initiative, do not tell the boss: "Do not worry, I did it outside working hours." If your company does not allow you to work on your projects during your work hours, then you should not try for any reason for them. Respect your time - otherwise no one will.
6 Learn to communicate. Learn the norms of communication once and forget about it. Do not learn, and they will haunt you for life. When we grow up, we begin to see the value of transferable and common abilities: functional programming instead of Spring / Hibernate, algorithms instead of Java 1.4 legacy fads. Yes, the skill of communicating within the norms is not a pleasant one, 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 must know the rules and be able to communicate, because they are in everything we do. It’s good to start learning about people and their actions as early as possible, even if you are not going to flirt with them (and in your youth you shouldn’t often flirt with colleagues). Have you been given a cluster to solve your problem? Stop adding features to your project so you can fix bugs? Have you been given a good project? This is all your communication skills. Good or bad, but it is - your main tool, and in fact you better use it, and not fall under its action. Once you learn to communicate within the norm, you 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 formed by those who use it better.
7. Do not be an idealist and do not try to prove that your boss is 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 dramatically increase the rate and risks and spend many hours. “Let's prove that the boss is not right ... by donating his own time to what they will own!” Sorry, but if you had to throw out a couple of weekends (not counting rare cases like the “last spurt”), to complete the project, it means your boss not much care about him. Otherwise, you would have time and resources, and you also had no patience for idealism. Instead of making a hat-trick with a broken stick, just let this game happen. The boss does not like when people who have doubted him make a fool out of him. You will not receive a promotion or bonus. The bosses will find a way to prove their bad impression (and your sincere empathy for the success of a “bad” project will put a mark on you) and, even if you succeed, you will fail. There will always be room for: “He did a good job, but he was distracted from the assigned work and I cannot trust him / we cannot allow him to create a precedent / it was my idea”.
UPD: 6 item rewritten.
Source: https://habr.com/ru/post/248841/
All Articles