“The more that you read, the more things you will know. The more that you learn, the more places you'll go.”
- Dr. Seuss
1. Turning Problems into Learning Opportunities
Look at the things you can change, calculate the odds and analyze your chances. Accept the situation the way it is without exaggerating it and making the problem bigger than it actually is. Don’t try to fix the whole problem, try to transform it (breaking it into smaller ones) and turn it into a source of new possibilities. Concentrate on the possible outcomes of the specific situation, not on the problem by itself. The problem has nothing to give you, but the way of finding a solution for it can open many doors of possibilities in front of you.
Create a list with all the possible moves you can do and choose one or more of these options. It is important to stay active and to create an action plan. Whatever the situation is, it is important to be able to move on and continue your journey.
Commit messages are a way of communication between team members. Let’s say there’s a bug in the application which was not there before. To find out what caused the problem, reading the commit messages could be handy. The proper commit message can save a great deal of time finding the recent changes related to a bug.
If we fix a bug or add a feature we will probably completely forget about it a month or two later. It’s not a good idea to think that if it’s not clear for others, they can ask us about it. Instead, we should provide proper commit messages for people to use as a resource in their daily work.
The perfect commit message should have certain qualities:
2. Writing a good and clean commit message
If we fix a bug or add a feature we will probably completely forget about it a month or two later. It’s not a good idea to think that if it’s not clear for others, they can ask us about it. Instead, we should provide proper commit messages for people to use as a resource in their daily work.
The perfect commit message should have certain qualities:
- It should be understandable (by any person and not just your teammate) even by seeing only the header of the message.
- It should be just enough with to the point information, and not too detailed.
- It should be unambiguous.
3. How to Share Just Enough Information
As Albert Einstein once said, “If you can’t explain it simply, you don’t understand it well enough.” Being able to target, identify, and express a pain point or issue is essential to solving it in a way that is ultimately successful.In these 3 years of my career, I learned how to share just enough information considering the end person with whom you are going to share it. This information can vary depending on the end person because the information which your co-developer wants is not useful to your manager and as soon as this hierarchy goes upwards (till the CEO) you need to provide a more crisp version of your base information. Let’s say you have provided information with 10-12 lines to your co-developer. The same information should get crisper in 5-6 lines to your manager. We always need to think about the end person who is going to read your information and need to write that accordingly.
Early in my career, I would often declare work finished too early. I recall several occasions where, after letting my team lead know I was finished with a feature, they would review it and immediately find issues. Even if the code worked well enough, my pull request would still be appeared with comments. Situations like this often result from poor attention to detail.
A few strategies I’ve used that have helped me develop quality code while ensuring strong attention to detail include:
Sometimes we may be required to work with people whose ideas and philosophies we don’t agree with. Other times, misunderstandings arise and can threaten us and our team’s deadline but we should be comfortable working closely with others, compromising and innovating as needed.
4. Attention to details
Developers who pay attention to detail tend to write higher-quality code. Computers only do what you tell them to do. If a code does not compile or a product has a bug, it’s not the computer’s fault. Exercising the ability to think through corner cases and writing codes that will handle various use cases allow for a much easier development process.
Early in my career, I would often declare work finished too early. I recall several occasions where, after letting my team lead know I was finished with a feature, they would review it and immediately find issues. Even if the code worked well enough, my pull request would still be appeared with comments. Situations like this often result from poor attention to detail.
A few strategies I’ve used that have helped me develop quality code while ensuring strong attention to detail include:
- Testing: One way to make sure your code works for the full domain of inputs is to test it. Usually, this means unit tests., and perhaps even writing test-driven code.
- Self Code Review: The first person to review my code is me—often, more than once. I usually open a pull request just for myself. I make sure all of the changes make sense. Then I make sure my code is consistent with the existing code.
- Feature Review: I always make sure to review the story or feature I’m working on to make sure my code satisfies all of the requirements and acceptance criteria. There have been several occasions when I thought I was done, only to realize there was another requirement of the story I hadn’t addressed.
- Take Notes: I try to document decisions I made while working on any code, along with their rationale. It’s easy to make a decision in the moment, only to forget it later when someone asks you why you implemented something the way you did.
5. Teamwork
As a software engineer, we must still be able to communicate regularly with other people and teams. As an engineer, we should be able to articulate project needs, as well as be able to discuss any challenges or problems that arise. We will routinely work with a number of other teams and departments at once, while also managing a team/resource of our own.
Sometimes we may be required to work with people whose ideas and philosophies we don’t agree with. Other times, misunderstandings arise and can threaten us and our team’s deadline but we should be comfortable working closely with others, compromising and innovating as needed.
That's all for this blog. I hope this will help you in your career as a software developer. Thank you!!
Nice blog.. Thanks for sharing.. 😊
ReplyDeleteGood one! Will be helpful for new joiners.
ReplyDelete