How Do I Work?
Whenever I join an already established software development team, I ask for which conventions that are in place regarding code style or quality. I'll follow the conventions if they are there and if not, I'll make sure that something gets established. Code conventions such as code style is a subjective matter but isn't something to be religious about. Have a discussion about which conventions to follow and stick to them. That will bring consistency to the code base which will benefit all developers.
Caring like it's your own project
Whenever working on a project, I like to put myself in the shoes of the business or clients. Consider the business goals, not just the technical requirements. I find that if you think about the project like it's your own, you'll start taking more ownership and responsibility. You'll see that you start delivering work of higher quality. You'll avoid any shortcuts in your work. Overall, by delivering more than what's expected of you, the project will more likely succeed which you get to see the fruits of.
Doing code reviews is non-negotiable in my book. No developer is able to write flawless code every time. No matter how many years of experiences you have, everybody makes mistakes and no code should go in the codebase without going through an extra pair of eyes. Here's a few points about code reviews:
- Code reviews are great for sharing knowledge in the team about what's being added to the code base. No single individual will be familiar with some piece of code and it will help team members find their way around a constantly changing code base.
- Learn from the feedback you're receiving. Be open-minded to suggestions and don't take critique of the code personally. I always appreciate getting feedback from reviews - I get to learn from experiences of others and improve my code.
- You should keep the code changes to review to an absolute minimum. I much rather split up a huge PR in multiple, smaller PR's that are easier to digest for the reviewer. We all have only limited memory capacity and focus, so bugs will easily be overlooked if we overwhelm the reviewer.
Learning as part of your daily routine
Wanting to learn should be rooted in all developers. Don't get stuck in the things you already know, or else you'll not advance. What I do is that I incorporate learning in my daily routing. I set aside time every day to touch upon new technologies that I'm interested in. I get to work around 6:30 AM, and I spend the first 30-60 minutes of the day either reading blog posts or watching videos on stuff that I'd like to learn more about. For a couple of weeks, I went through the best WWDC sessions, one session a day. If it's relevant for the tasks on your daily to-do list, that's even better! You'll be surprised to see how much you'll advance if you do this for a few months or even a few weeks.
These are some of the things that have improved my efficiency as a developer the most. I strongly recommend that you take these points into consideration, if they are new to you. Also, I'd love you hear what makes you efficient as a developer (especially if you have some different points than mine).
Share this post
You may also like
RxSwift provides plenty of options for joining your observable sequences together. Let’s go over the 5 most important combining operators you’ll likely use the most.
Transforming operators in RxSwift serve the purpose of preparing data coming from observables before it reaches the subscribers. Let’s cover this type of operators and look at 3 operators you will be using all the time.
Defect management should not be a phase in the lifecycle of an app, but instead a fundamental part of an agile process. Here is my recommendation of processes to enforce defect management into your team’s daily workflow.