Editors Note: During our work on the webinar series, we came across a lot of quality content that can help engineers become more productive.We are always excited about productivity. We wanted not only to share the content with our audience but also to celebrate the brilliant minds. Today's post is from Michael Shpilt, Lead Software Engineer at OzCode. Enjoy!
In software, one developer can make a big difference. This is why hiring great engineers is so hard, and why programmer salaries are sky-rocketing. A high-performance software developer is an incredible asset in a team. A company is willing to pay them top dollar, and the competition to hire them is fierce.
An efficient high-performance developer is a professional that gets the job done fast and effectively. Someone who has incredible productivity with high quality. Someone who you just can’t understand how they can get so much done.
I was able to become such a developer and was very rewarded as a result. This is reflected in great performance reviews, yearly bonuses, salary raises, and promotions. I was able to achieve this with experience, proper motivation and by optimizing myself. In this article, I’ll show you 11 tips to become a highly-productive, effective, and performant software engineer.
Before listing any of the tips, the most important thing is to want to become an efficient, high-performance developer. A high-performance developer comes to his place of work with the intention to achieve as much as possible on that day. This is the prime directive and what you need to keep in mind while working.
Being high-performant comes with a lot of rewards. Career wise, a productive developer is a huge asset. You will get more raises, promotions and better feedback. In addition, high productivity turns into a game at some point. Completing tasks is fun, simple as that. Another advantage is work experience. If you are doing twice more tasks in a single day, then you also have doubled your work experience.
One of the most effective productivity tools is a simple To-Do list of your daily goals. Write down at the beginning of your day what you want to get done. Then, as you go on with your work?—?Cross items from the list. It’s as simple as that, but the effect is amazing.
The simple act of crossing items off your to-do list is very satisfying. In fact, it’s hard-wired into our brain. When we succeed in something, our body releases dopamine, which immediately causes us pleasure. This, in turn, causes us to want to repeat that pleasure and do even more work. In other words?—?lists will make you more productive and work more enjoyable.
Before coding, debugging, or even touching the keyboard?—?take a moment to think. How are you going to approach your task? What classes are you going to create? Where are you going to set breakpoints? What technical obstacles can you encounter?
You should ask yourself all these questions before anything else. Once you build an approach plan in your head (or even better, on paper), you can plan your steps exactly. This results in an organized and efficient workflow. It will focus you on your task and prevent needless adventures that have no benefit. As a result, your productivity will sky-rocket.
Programming can be a lot of fun, but it also can be hard and frustrating. In some tasks, you might not even know how to begin. Sometimes you evaluate a task will take 2 hours, and it ends up taking 2 days. Or you might be dealing with deadlines and context-switches.
Programming can be stressful indeed, but the solution is simple?—?Keep Calm. Getting angry and frustrated will cloud your mind and you’ll end up spending even more time on the task or adding bugs. Keeping calm is easier said than done. Everyone has their own techniques for that. For me, just keeping in mind that I should be calm usually does the trick.
There are several reasons why taking breaks helps with productivity. For me, it breaks down to two reasons.
In many tasks, you might have some sort of technological bottleneck that you don’t know how you’re going to solve. The rest of it might be straightforward stuff that you’ve done a hundred times, but this one thing you don’t know how to deal with.
My advice is to start with the hardest part. One reason is that once you’ve solved it, you will be much more confident about the rest. Another reason is that while dealing with this part you might realize the task can’t be completed the way you planned and you’ve just saved yourself a lot of time.
A very powerful technique to high-performance development is to check for similar solution before starting your tasks. Whatever feature you are working on, there’s a good chance you have something similar done in your own project. Instead of re-inventing the wheel, find that place (maybe ask other developers) and see how they got it to work.
You might want to copy-paste the solution as is, create a reusable component or just use the basic idea. Whatever you choose, you’ve just saved yourself a whole lot of work.
No one can deny that asking for help is effective. Whether you’re starting in a new place, working on unfamiliar code or just looking for advice, it’s extremely useful.
The thing about help though is that when someone else explains something, you understand less than if you’d figure it out by yourself. When you decipher the code yourself, you get an intimate understanding of it. All the logical pieces fall together and you will be able to tackle any problem in that code later on. When someone else explains it, you will understand some part of the equation, but the rest will remain a mystery until the next time you’ll ask for help.
It’s a fine balance between asking for help or not. On one hand, you might be stuck for a very long time without help. On the other hand, asking for help for everything will result in you learning the least. My advice is to try to figure out anything by yourself for at least a little while before asking for help. This way, even when you eventually do ask for help, you will understand their answer much better.
Whatever company you are working with, you probably use a set of technologies. It might be a programming language, a few fram eworks and a few tools. If it’s something you constantly use, it’s worth it to learn in depth the core of your technology.
I’m suggesting more than just learn-while-working approach. Take some kind of course to learn the technology. It can be an online Pluralsight course, a book or something else. It will take a long time, but consider this as a long-term investment.
To become a high-performance developer, you should always improve and optimize yourself. This means several things. On the technical side, you should always keep learning. As programmers, we are in a profession where we can learn something new every single day, which is awesome.
On another aspect, you should strive to optimize your work process. After each completed task you can ask yourself: Did I do it as efficiently as I could? Could I have done this better or faster? How would I approach the same problem again? These questions are key to endless improvement and becoming the best professional you can be.
You might be a ninja efficient developer, but it’s also important to know when not to finish a task. These are usually tasks where you recognize that completing them will take much longer than it’s worth, or tasks that increase complexity too much.
For example, you might be working on functionality that causes a deadlock when triggered in a certain time. It’s hard to reproduce and when you do succeed, you just can’t solve the deadlock. Instead of solving it, you might be able to disable the scenario in that specific time in the first place.
A second example might be some refactor you started, but after a week you realize that the new refactor will take much more time than intended and can break the system in a whole bunch of places. As developers, we have to be realistic about these things. We are developing a product, not striving to code perfection. Perhaps this refactor just isn’t worth it.
Originally published at Michael Shpilt's blog.
Photo by Austin Distel on Unsplash