On jianshu, the platform I use to write my tech blog, I see a lot of workplace posts written every day by so-called professionals in various industries. But I find that programmers, as a large group, rarely write about it. Looking back on my career, DURING my ten years as a programmer or architect, I rarely think about or summarize the lessons I learned in the workplace. Most young programmers, like me, are so focused on technology that they are oblivious to the rules of the workplace.
In the past few years, when I started working in IT management, I have had more time to look back at myself and see and experience some things from more young programmers around me, and I think IT would be helpful for more programmers to learn these things as early as possible in their careers.
Your salary has nothing to do with your workload
This first one might make you feel a little bit depressed, but is it a universal truth? When you graduate from college and enter a company, you work very hard every day and often work overtime, while some older members of the same team seem to be not busy at all, and even worse, they may earn several times more than you. At this point, your heart will have a little imbalance, even heart dissatisfaction?
Your salary actually depends on many factors, such as technical skills, experience, amount of work, etc. But the bottom line is whether you are important to the company, in other words, whether you are easily replaceable. It’s easy to find a new graduate, but it’s more costly or risky to replace an older employee who’s familiar with the company’s products and plays a key role.
So, might as well straighten out the state of mind, correctly recognize their position in the company, and strive to practice internal skills, so that they become more and more important, I believe that your salary will also be increased.
Do one thing as consistently as possible
Since your value to the company comes from your irreplaceability, how can you increase it? My advice is to keep doing one thing as long as possible. This refers to both the accumulation of skills and the ability to work on the same project or product for a full or extended period of time. While there may be times when the work you do is beyond your control, you still need to be conscious and proactive about opportunities that will allow you to continue to gain technical or project experience.
I often hear from young programmers who feel that the technology they are working on is too old and ask if they should switch to another technology or even a career. Or to the company to do the project is not interested, feel no future, should change jobs and so on. I always encourage them to learn more different things, such as new technologies, frameworks, and even the UI design, but I will remind them at the same time, the technical depth as well as the importance of complete project experience, if you always follow the new technology and the framework, it is hard to to achieve the ideal of a certain technical depth, likewise, in a company, It’s hard to add value if you’re constantly changing projects. One project is better than 10 projects. Doing something consistently means doing everything well, not just skimming through it.
The only constant is change itself
In more than a decade of work, the only thing I’ve seen constant is change itself. The technology we use changes, the software practices change, the projects we work on change, the organizational structure of the company changes, our own positions and roles change, and of course our bosses change.
How should we, as programmers, respond to these changes? I mean, it’s hard to change your environment, or to stop the tide of change. What you can do is develop your ability to keep learning. In my previous posts, I’ve talked a lot about the 10,000-hour rule — it takes more than 10,000 hours to become an expert in a field. For programmers, the 100-hour rule is just as important — it takes 100 hours to learn or hone a new skill, and you can often beat the average person by a mile. You need to develop your ability to learn quickly, and the more you learn, the faster you tend to learn because there’s always a correlation. Over time, you’ll find that you’re very comfortable with the changes that are constantly coming your way. You’ll even be able to anticipate trends in advance and always be the one prepared for opportunities when they come your way.
Your reputation is very important
Reputation is very important to a programmer. The best programmers I see all have one thing in common: they have a good reputation on their team and within their company, and this has helped them grow their careers iteration after iteration. Those who lack a reputation, on the other hand, tend to fall into a vicious cycle, struggle to advance within the company, and often end up moving elsewhere.
Reputation itself is associated with many things, but for a young programmer or new graduate, besides the usual talk of honesty, conscientiousness, and so on, one thing in particular is rigor. It is often the factor that determines whether a programmer has good potential or not. Careful programmers who understand what they’re assigned and scrutinize their output can greatly reduce the chance of errors and make a good impression on the rest of the team or company. It can take a long time to build a reputation, and one careless mistake can cost it all. Develop rigorous habits that will benefit you.
Understand the meaning of communication
When I first started as a programmer, I thought technology was everything, and I felt a sense of satisfaction as long as I could develop high-quality programs quickly. As a result, I was reluctant to communicate with users and was perfunctory about requirements discussions in order to get into development as quickly as possible. However, this often backfired. Users did not recognize my design of the system, and I was often required to rework, which made my work efficiency very low and my mood very low.
The change came from my reunderstanding of the meaning of communication, and the fact that everything we built was designed to solve some problem or provide a specific tool for the user. When we do not have a deep understanding of the problem, it is very difficult to write correct procedure, so we need to users for advice modestly, to really understand what they want to solve the problem, in the same way, if we have is an expert in a particular aspect, we also have the responsibility to guide the end user accept our professional solution or design is put forward. I think that’s why we need to communicate better with users and other related parties.
Your left brain will be the key to your success
In one of my previous posts about what every programmer should know, speaking of what we think of as highly successful technology gurus, IT executives surprisingly cite non-technical skills as key to their success, such as the ability to write a document or a powerpoint presentation, the ability to make a presentation, the ability to convince others, etc. I don’t entirely agree that the best programmers don’t write code, but I do believe that your left brain is the key to your success.
The last big improvement I’ve felt has come from self-taught design. Is not to say that my design ability to what degree, but when I learn to a designer’s point of view to analyze and solve problems, my train of thought is extended, which makes me can use right brain to come up with the technical proposal, the left brain can also be used to provide users with more human chat and have a good user experience design.
You may ask, I’m a programmer, how do I exercise my left brain? Does it have to be design or a musical instrument? Not at all. There are plenty of ways to improve your left brain skills at work. For example, when you write a document or powerpoint, can you think about fonts and typography in addition to content to make it easier to read? When you discuss requirements with users, can you try to think from a programmer’s point of view to a user’s point of view? In the internal team meeting, can you do some preparation in advance, strive for the opportunity to present in front of the group? As you keep doing this, you’ll find yourself getting better at everything, including your programming skills. Because they are always interacting and promoting in places where you can’t see them.
Don’t say easy or impossible
Young programmers who are just starting out tend to be careless about how they express themselves, which is certainly a sign of frankness, but can sometimes be a minus for you. I remember that this was 2008, the company recruited a group of fresh graduates through school recruitment, among which 10 were assigned to my department. One boy stood out from the rest because of his quick learning and cheerful disposition, and we all agreed that he was the most talented of the group of fresh graduates. In a department meeting, the department leader consciously asked everyone for suggestions and opinions on some system transformation, while the boy repeatedly used such expressions as “XXXX is easy” and “XXXX is impossible”. Although we all knew that he didn’t mean any harm, it was clear that his seemingly hasty answers were inappropriate, which greatly reduced his impression score with the department leaders, leading to some unnecessary trouble later on.
Me the above example is not hope you become very sophisticated, but remind young programmers should not be taken lightly those too absolute judgment, as far as possible to use the scientific method to analysis and argument, and then use the way is not easy to be misunderstood effectively express, in this way can you put forward arguments that everyone was convinced.
You shouldn’t be a lone Wolf
Many programmers complain about how bad product managers, PMS, designers, users, and even other programmers are, and how working with them is like fighting a bunch of mosquitoes in a room. When you’re a beginner programmer, your job is probably pretty straightforward — programming. However, as you grow in ability and position, you will be given more important roles on the team, such as architect, team leader, project manager, etc.
If you really want to make an impact, it’s hard to do it on your own. You have to work with different people in different roles on the team, sometimes you have to convince people, sometimes you have to be convinced, and during that time, you can be frustrated by being rejected, which can be frustrating for programmers, but it’s an opportunity for you to grow. Instead of being a lone Wolf, learn to work as a team and surround yourself with great people as possible, which will expand your range and make you stronger.
Your ability is obvious
When I worked as an architect at my previous company, I was often involved in the company’s recruitment and year-end personnel skills assessment. I won’t go into detail on how to hire a good programmer before, but as for personal skills, I’d like to say that your skills are obvious and come entirely from your own efforts.
From easily solving technical problems, to coming up with a consensus solution in a meeting, to the elegant, polished code they write, these are the things that make them stand out, as if they were born good programmers. But I would say that they are actually people who try and do it the right way. The programmer’s ability comes from a lot of coding practice, as well as the ability to keep learning and the habit of thinking hard. Any smart-aleck, know-it-all, or opportunistic attempt will appear to the discerning eye to be a case of monkey business.
These are some of the things I felt and wrote about today, some of which you may find enlightening, others not. But I believe that in the process of reading, you will think and get your own answers, believe in what you believe, and you will become better and better.
Jane book signed by: technical craftsman, welcome to share the above content to circle of friends/micro blog, etc.