As we progress in our careers as developers, we learn that certain skills are more valuable than others. Valuable skills are those that will make you more efficient, adaptable and relevant.
These might not necessarily be the skills that you’ll see in a job description but they are the skills that will make you valuable to any employer. Here are six valuable skills that will make you effective as a developer.
- Able to Read Other Programmers’ Code
Your code makes perfect sense to you. Their code makes perfect sense to them. We hate to read other programmers code, but we have to. Plus, you can’t get too annoyed, that poorly written code was probably you at some point… maybe it still is.
Undoubtedly, you will have to read and make sense of poorly written code. Being able to process someone else’s code, no matter how bad, is a great skill to have.
Why is this skill so valuable?
Reading bad code means you are learning what not to write yourself, how not to design things. You can identify what was really easy to read and what wasn’t? Was something that was hard to follow similar to your own code? Good to know, it might be time to change some things yourself. If there’s anything that was easy to follow that you could use, even better.
Remember, the skill we’re discussing is being able to read other programmers’ code, not your ability to criticize, critique and give specific advice to a co-programmer. Even if a piece of code isn’t easy to follow, it might be like that for a reason. Also, remember that previously written code isn’t necessarily representative of a developer’s current code. If upskilling is needed, politely bring it up and proceed from there.
You might be the developer to have replaced the old one, so it might be on you to make the code more maintainable and add any necessary documentation (hopefully not too much).
- Knowing When a Project Isn’t Worth it
This is a skill that takes a long time to actualize. Why? Because you have to do a lot of unnecessary projects to know when a project may be either pointless or doomed from the start. This skill also assumes that you’re in a workplace and position that gives you the freedom to suggest a project won’t be worthwhile. A cancelled project is likely to be internal, if all your work is external for clients, a cancelled project is more a reflection of a client who seems shady or too unsure of what they want.
Sometimes projects will be too focused on the technology involved, but not have a clear purpose or end value. If there is no identifiable long-term benefit that can justify investing time and energy into a project, then maybe it needs to be put on hold until the purpose becomes a bit more clear.
- Optimizing Meeting Times
Meetings are essential, they’re necessary to drive decisions, provide direction and become familiar with the progress of other team members. But, meetings also have a tendency to go too long, become off-track and be scheduled inefficiently.
Therefore, it’s important to know how to optimize your meetings and, when appropriate, completely avoid meetings. The idea is to only be in meetings that do actually drive decisions or provide direction.
There are a few ways you can optimize your meetings.
The first method is to simply ask: “What’s this meeting about? Am I actually needed? If I am needed, am I only needed for a certain part of the meeting?” If you’re only needed for a certain section, can the leader of the meeting call you in just for that part?
Another common option is to set a recurring meeting time every day (or whatever suits) which allows all parties to update themselves. But, what recurring timeslot should you dedicate? It’s contextual. Many people don’t like morning meetings, and would rather take care of many important to-do’s. It’s recommended you choose a time that allows you to have two decent sized blocks of time for you to do your own work. For example: Your own work between 9am–12pm, meeting from 12pm–2pm, hour break, own work again from 3–5pm.
If your workplace isn’t flexible with meeting times, then your final option is to come in earlier. Many programmers prefer to come in earlier to minimize distractions and take advantage of a larger dedicated chunk of time where you can stay immersed in your work.
Many programmers are now moving to coworking spaces. Why? Because such spaces give programmers the option of working in a private office or desk, an open desk while still having access to a functional meeting space whenever it’s needed. More programmers are realising that coworking spaces accomodate all personality types, no matter if you prefer a more private or social setting.
- Be Honest With Yourself, How Well Do You Know Github?
Some programmers are very familiar with Git and have all commands ingrained in their brain. Other programmers will have next to no experience with Git. Using Git is extremely useful for recording and collaboration when used properly, and a timesuck when used wrong. A couple of wrong commands by an inexperienced programmer and you’ll find yourself stuck in a web without any way of knowing how to untangle yourself.
The solution: keep a Git cheat sheet—always.
- Keep Code as Simple as Possible
Many junior programmers will use everything they know to come up with one solution. They take everything they’ve learnt about data patterns, object oriented programming, data structures and stuff it into one solution, and the next one… and the next one. This isn’t bad if you’re a junior: it’s just how you learn. It becomes a problem over time though, and is something you should work on as you become more experienced.
Don’t become rigid in the way you find solutions, relying on the same pattern for most solutions means you’re not considering simpler forms of finding a solution. Although design patterns serve to make code more maintainable, they can still make things more complex if they’re unnecessary.
Always keep in mind that every time a piece of code is abstracted or black-boxed, the more complex debugging becomes.
- Ability to See Your Code from a Future User’s Perspective
Whenever you’re writing any code or editing any code, you need to be able to foresee what users are likely to also use this code. This is called imagining operational scenarios and it refers to imagining how any future user might use or perceive your code. This relates back to why it’s so important to be able to read others code and understand what they did wrong in theirs.
For example, if you’re developing a module, you want to be able to:
- Imagine the different ways a user might need to use your module
- Imagine how a user might use your module incorrectly
- Imagine and implement any parameters future users might need
- Imagine how any future programmers might want to repurpose your code
This is a great skill to have and gives all of your work longevity. Yet, nobody is expecting you to be a magic genie. You can only foresee so much and once code is deployed anything might happen to it. In a few years, a future programmer is likely to find your code annoying. That’s just the way it is, software architecture is always changing and code quickly becomes outdated. Thankfully, the qualities we’ve outlined in this article won’t.
If you’re an adept programmer looking to take your career to the next level, the global development company CodeClouds is always looking to hire expert developers from India and the US (Fort Wayne, Indiana).
