Software engineers spend a lot of time practicing leet code questions and perfecting their resumes to get better interview chances. Once they are eventually hired by Google, Amazon or elsewhere, they may find that the skills they used to get the job don’t match the skills they need in their everyday jobs.
Our team was inspired by the seven Skills for effective Programmers created by TechLead. We want to offer our own perspective on the topic. Here are the seven skills we’ve identified as effective programmers.
- Learning how to read other people’s code
Everyone’s code is crap except you, right? In fact, being able to work on other people’s code is a great skill with multiple benefits.
No matter how messed up or ill-conceived the previous engineer’s code was, you still need to be able to extend it. After all, it’s your job. And that “former engineer” could be you from a year ago.
This skill will benefit you in two ways. First, being able to read other people’s code is a great opportunity to learn what bad design is. When you look at someone else’s code, you know what works and what doesn’t. More importantly, you can learn what types of code are easy to extend for other engineers, and what types of code are hard to extend.
Make sure you find out as many problems as you can when reading other people’s code. That way, other engineers will know what a good engineer you are. Make sure you make a point about the importance of maintainable code and good comments. This further demonstrates your strength in programming.
Your code should be designed so well that you don’t need any documentation. In fact, if you’re a good programmer, you don’t need any documentation to explain any of your code. It’s a waste of time when coding and meetings are more important.
Being able to read other people’s messy code also makes it easier to update when needed. This sometimes means updating code that you have little experience with. For example, we once updated a script from Powershell to Python to Perl. Our experience with Perl is limited, but we still have enough background knowledge to figure out exactly what this script does and make the necessary changes.
It all comes from a good understanding of all the code and being able to read past code. Reading other people’s code makes you valuable, because this skill can even allow you to take over overengineered systems that embarrass others.
- Feelings about bad projects
There are many skills that take time to learn. One of the skills we think is worth knowing is understanding what projects aren’t worth doing and what projects are clearly dead.
Big companies have lots and lots of projects going on (bosses don’t even know how many), some of which may never get done and may not benefit the company if they do. Some may not make any business sense per se (at least not to you), and some may be poorly managed. This is not to say that when you don’t approve of a project, you should reject it out of hand. It’s best to see how the stakeholders feel about the project. If they can’t explain themselves correctly what they expect the end result of the project to be, then the project probably isn’t worth doing.
Also, some projects may be so focused on technology rather than solutions that it’s clear from the start that there won’t be much impact. This skill requires you to do a lot of bad projects before you know what a bad project really is. So don’t spend too much time trying to identify each item too early.
At some point in your career, you will have good intuition and awareness.
- Avoid unnecessary meetings
Whether you’re a software engineer or a data scientist, meetings are essential because you need to be able to reach consensus with project managers, end users, and customers. However, there is also a tendency for meetings to suddenly take over your entire schedule. That’s why it’s important to learn how to avoid unnecessary meetings.
Perhaps a better word would be to manage rather than avoid. The goal here is to make sure you spend your time in meetings that drive decisions and help your team move forward.
The most common way to do this is to set aside two hours a day, which is an ongoing meeting. In general, most people have regular meetings when they find it useful. They use this time to catch up on their development work.
Another way to avoid meetings in order to get work done is to show up before someone else. Personally, we like to be early because, generally speaking, the office is quiet. Most people who show up early are just like you, just trying to get work done so no one bothers you.
This is important for individual contributors because our work requires our attention time and we don’t talk to other people. Yes, there may be times when you need to solve problems and you may want to work with other people. But once you’ve solved the blocking problem, you just need to code. It’s about getting into that zone where you constantly have a lot of complex ideas in your head about the work you’re doing. If you keep stopping, it’s hard to pick up where you left off.
- Use the Git
Some computer science students start using Git the day they start out. They don’t need professional guidance to understand every command and parameter. Others experience GitHub for the first time in their first jobs. To them, Github is a hellish place, full of chaotic commands and processes. They’re never 100% sure what they’re doing (memos are popular for a reason).
No matter what warehouse system your company uses, it can be useful if you use it correctly, or a hindrance if you use it incorrectly. A simple commit or push can take hours to untangle a hodgepodge of branch merges. In addition, if you often forget to use the latest version of the repository, you will also be dealing with less fun merge conflicts.
If you need a Git command cheat sheet, do it. Anything to make your life easier.
- Write simple, maintainable code
Young engineers may have a tendency to try to incorporate everything they know into one solution. There is a desire to incorporate your understanding of object-oriented programming, data structures, design patterns, and new technologies into every piece of code you write. Then, you’re likely to create unnecessary complexity, because it’s easy to over-attach yourself to solutions or design patterns that you’ve used in the past.
Strike a balance between complex design concepts and simple code. Design patterns and object-oriented design should simplify the code in the macro plan as much as possible. The more abstracted, encapsulated, and black-boxed a process is, the harder it becomes to debug and maintain.
- Learn to say no and prioritize
This applies to any role on the team, whether you’re a financial analyst or a software engineer. But for technical roles it seems that everyone needs to learn this more. If you’re a data engineer, you’ll probably be asked to do more of the same. Some teams need data extraction, others need dashboards, and others need new data analytics docking.
Prioritizing and saying no are two different skills, but they are closely intertwined. Prioritizing means that you only spend your time on things that have a big impact on the company. However, saying no sometimes just means avoiding work that should be handled by another team. For all characters, they often come together.
This can be a difficult skill to acquire, as you will always want to have your way with every request. Especially when you’re fresh out of college. You want to avoid letting anyone down, and you always get plenty of work. However, in large companies there is always an endless amount of work to do, so be sure to grasp the key: only take on what you can do.
There are many skills that can’t be tested and verified in an interview or even taught in college. More often than not, this is more about environmental limitations than a lack of desire to expose students to the real world to develop and grow.
- Contextualized thinking
One skill that’s hard to test in an interview, and hard to replicate in college, is thinking about how end users might use your software incorrectly. We often refer to this as contextualized operational thinking.
Since most programming is maintainable, it usually means changing code that is highly coupled to other code. Even simple changes need to keep track of every possible reference to objects, methods, and apis. Otherwise, it’s easy to accidentally break module connections that you’re not aware of. Even if you just change the data type in the database.
It also involves thinking through edge cases and integrated high-level design before moving into development.
For scenarios where you’re developing new modules or microservices, it’s even more complex, and it’s important to take the time to think about the operational scenarios you’re building. Think about how future users might need to use your new module, how they might use it incorrectly, what parameters might be required, and whether future programmers might need your code differently.
Simple coding and programming is only part of the problem. It’s easy to create software that works well on your computer. But there are many ways deployment code can go wrong. Once in production, it’s hard to say how the code will be used and what other code will be attached to the original code. Five years from now, future programmers may be frustrated by the limitations of your code.
— — — — — — — —
Copyright notice: This article is an original article by CSDN blogger “Programape DD”
The original link: blog.csdn.net/dyc87112/ar…