4 Tips To Be Highly Efficient Developer
Tags: softwaredeelopment, career, leadership, productivity
Published: 2023-08-17 17:29:32

---
title: 4 Tips To Be Highly Efficient Developer
published: true
date: 2023-08-17 12:00:42 UTC
tags: softwareDeelopment,careers,leadership,productivity
canonical_url: https://pathtosenior.substack.com/p/4-tips-to-be-highly-efficient-developer
---

![man sitting on chair](https://images.unsplash.com/photo-1553484771-047a44eee27a?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3wzMDAzMzh8MHwxfHNlYXJjaHwxMTd8fGVmZmljaWVudHxlbnwwfHx8fDE2OTE4NjQ5NTF8MA&ixlib=rb-4.0.3&q=80&w=1080 "man sitting on chair")
<svg xmlns="http://www.w3.org/2000/svg" width="16" height="16" viewbox="0 0 24 24" fill="none" stroke="#FFFFFF" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><polyline points="15 3 21 3 21 9"></polyline><polyline points="9 21 3 21 3 15"></polyline><line x1="21" x2="14" y1="3" y2="10"></line><line x1="3" x2="10" y1="21" y2="14"></line></svg>


_Time is money._

This may be an overused phrase, but we're all trading our most treasured asset - time.

Seriously, all software engineers should keep this phrase on their wallpaper- it's pure gold! Because, dear software engineers, time is your most prized asset, even over your LeetCode problem-solving skills.

Joking aside - the difference between a top-tier developer and a regular developer is their efficiency in finishing their project. By being efficient, I mean someone with incredible productivity to produce high-quality outcomes quickly. 

Someone, who you question, "How can they get so much done in a short amount of time?"

In this article, I want to share four tips I have used to help complete my work faster. Using these tips, I have received positive feedback from my manager on how fast I can onboard into a new project and make a huge impact. Without further ado, let's get started.

## Solve the Hardest Task First

"If you got a list of tasks on your board, which would you choose first?"

The answer is you should solve the hardest task first. 

Productivity gurus like to quote Mark Twain's famous advice towards productivity: to "eat the frog" or perform your hardest task immediately. This advice holds water in both behavioral research and anecdotal observation.

[Research](https://insight.kellogg.northwestern.edu/article/easy-or-hard-tasks-first) shows that people who execute their most difficult tasks first are generally more productive and high achieving than those who start easy and work their way up. 

If you're short on time or motivation, it's generally easier to put off or delegate smaller tasks rather than larger ones. We all have a limited amount of energy each week, so it's important to consider whether those small tasks are necessary before jumping into them. Trying to tackle multiple small tasks at once can lead to unproductive multitasking. Completing smaller tasks first can hinder productivity. Instead, tackling the hardest task first is better, as this increases the likelihood of completing it. Keep in mind that willpower can only last so long before running out.

When designing software, the path to resistance is good for everyone. For productivity, the path of least resistance is not the right path to productivity because our human brain is wired to feel positive about short-term rewards, so we are more included t take actions that result in gaining those short-term rewards.

Not only should you solve the hardest task first, but you should also break your time and prioritize the top heaviest work. This is how the Olympic trains. According to [the power of Full Engagement](https://www.amazon.com/Power-Full-Engagement-Managing-Performance/dp/0743226755), Olympic athletes don't train nonstop. They do intense exercise and deep relaxation. 

This means we need to work on things that are more weight at the beginning than at the end. In the context of a project and task, you should work most work in the early of the timeline and less on the deadline.

## Learn the Programming Language That You Use For Your Project

Efficiency is bred from repetition. 

People think that language is not important. Overall, big tech companies don't test on what language you know but your problem-solving skills.

Little people know that to be really good at problem-solving, you need to be really good at leveraging your tools, which is getting really good at the language being used in your company. Therefore, to be good at problem-solving, you will need to be good at understanding the language so that you can put a lot of your focus on the problem-solving portion.

A Senior Engineer always asks me questions about how to do things in the code base. Each time I helped him, he would make a note saying, "Man, I don't know why all the Android code is wrapped in Scala. I would have finished this by now if this was in Kotlin." This seasoned senior engineer with 10+ years of experience solving real-world engineering problems has difficulty creating a button nav bar in the IOS app because he doesn't know the programming language. 

Master the minimum technology everyone uses in your company and achieve 90% of the desired outcome. 

## Apply the Pareto Principle

This is also called the 80/20 rule and can be applied to software engineering practices. This states that 80% of the problems encountered with building applications can be attributed to just 20% of the causes. This is, of course, an approximation and not an absolute figure.

What this means is working on the highest priority task first. Any bug tickets that you get assigned that are not a priority can be done sometime in the future, or sometimes you do not even need to do them at all because it is not important.

Do the assignment that impacts the team and the business the most. This way, you can showcase your work by illustrating the impact that you have done.

## Before You Write Any Code, Check Where it Has Done Before

A powerful high-performance development technique is checking for similar solutions before starting your tasks. Whatever feature you are working on, there's a good chance you have something similar done in your project. Instead of reinventing 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 use the basic idea. Whatever you choose, you've just saved yourself a lot of work.

I know I have experienced this before when working on a new task. I was assigned to write projects, and it always took me some time to finish them because I often like to find ways to do it differently and more efficiently. Thinking that the future developer working on the task will see my solution, they will choose mine over others else because the solution is more elegant.

Well, all those imaginations are wishful thinking. The truth is, no matter how elegant you write your code, the most important thing you do is provide business value. 

Instead of spending hours or even days trying to reinvent the client wrapper to call service B, you can check another codebase with the logic you want to emulate. Do yourself a huge favor by referencing that way of doing things. There are a couple of benefits to this:

- Your new way of doing things may not be the preferred way. Thus, if you push the new way as a code review, it may cause some pushback, extending the duration of your project.

- The code that has already push to production has survived various battles on the battlefield. Therefore, reusing the same logic will make it easier to justify in code review and push your project faster.

You can significantly enhance your development process by leveraging existing solutions and reusing proven code. Don't waste time reinventing the wheel; instead, tap into your project's wealth of knowledge and experience or reach out to other developers for guidance.

## Conclusion

To maximize productivity and deliver high-quality outcomes in shorter timeframes, we can follow a few key principles:

1. Tackling the hardest task first allows us to utilize our energy more efficiently.

2. Being good at using the tools that you have for your project is essential for efficient problem-solving. Applying Pareto Principle helps us work on the most impactful task first. This concept is similar to my first point, where we need to be mindful of how to distribute our mental energy efficiently.

3. If you can copy, delegate or eliminate, do all of the above.

Safe your mental power to solve problems important for your team's success.

In the fast-paced world of software engineering, optimizing our efficiency and delivering value swiftly is paramount. By incorporating these tips into our workflow, we can become more productive, make a substantial impact, and ultimately become high-performing software engineers. 

## 💡 Want more actionable advice about Software engineering?
I’m Edward. I started writing as a Software Engineer at Disney Streaming Service, trying to document my learnings as I step into a Senior role. I write about functional programming, Scala, distributed systems, and careers-development.

Subscribe to the FREE newsletter to get actionable advice every week and topics about Scala, Functional Programming, and Distributed Systems: https://pathtosenior.substack.com/