How to be a better software developer?

Part 1: actively seek feedback.

When you write code you go to the lowest level of detail of what you are trying to achieve with the program. Therefore, this phase can often surprise you no matter how much you spend time discussing and planning prior to coding. When you do feel like you are "at a cross road" having to make a choice that you didn't realize to discuss with the team beforehand, don't wait for a step in the process to discuss which way to go, but start the discussion as soon as possible.

Examples:

- Your team had a plan where to write the new code but it turned out the code got more complex and you don't feel good about the plan anymore. Instead of waiting for a pull request code review or a daily stand-up meeting, pick a team member who is familiar with the area you are working on and start a discussion. Often talking with one person already helps but if it doesn't, involve the whole development team.

- You thought you understood what the product owner was asking for during a sprint planning or a backlog grooming meeting but during the implementation you come up with questions that are not answered in the user story and you don't remember discussing it. Instead of guessing and waiting for a sprint review, go find the product owner or the service designer and discuss the issue. Perhaps they also didn't think of all the details or they failed to communicate all their thoughts.

In both of these cases, the sooner you start a discussion, the sooner you find the right road to follow and the less backtracking you need to do if you chose wrong.

Keep in mind though that you shouldn't interrupt other people all the time because interruptions cost more time to the other people than the time it took to discuss "your issue". So prepare for the discussion and try to be efficient.

Programming is about handling complexity. Handling complexity is about reducing visibility and dependencies. A class should model one thing and a method should do one thing and everything should be named logically. If you can't name something then it's a code smell. Don't document strange code, rewrite it. If you have a complete test set covering everything, your code can still be a nightmare to refactor if the above criteria is not met

To view or add a comment, sign in

More articles by Ville Henriksson

  • The Expanding Reach of a Hungry Software Developer

    When a software developer joins a new team, there's plenty of things to learn. The team members and their skills and…

    2 Comments
  • Putin's Russia

    Finland and Sweden have recently applied for NATO membership. Russia's response to that has been mild, almost…

  • How to be a better software developer? Part 3

    Create modules with a maximum of one external dependency. Here an external dependency is something that you cannot…

    2 Comments
  • How to be a better software developer? Part 2

    Be honest. People with professional pride want to show that they are good at their job.

    2 Comments
  • Complex organizations create bad quality software

    Recently I came across a blog post that summarized an older study made by Microsoft that concluded that organizational…

    1 Comment

Others also viewed

Explore content categories