good developer

Overview

A 'good developer' is too vague. It could be a developer who knows how to properly apply TDD in practice, a developer with the performance to create a huge amount of code in an instant or a developer equipped with software craftsmanship to the core.

Neither one is wrong, nor one can be said to be right. I think it would be best if I looked at various types of developers and made my own 'good developers' by imitating the strengths of those people.

your own standards

The 7 criteria I set for a good developer at the beginning of 2022 are:

• high productivity
• reliably solve a given problem
• good at collaboration
• general, domain knowledge
• write stable code
• write clean code
• good at the software design

Once you have set a standard, you should be able to achieve it. But how?

To be more productive

High productivity means that the number of tasks processed per unit time is large.

So, first of all, you need to manage your time well. I personally use the Pomodoro technique.

Second, the work I've done has to be useful. In order to do that, you must first know how to answer the Why. Knowing why you are doing this will show you what you need to do, and if you know what you need to do, you will be able to think about how to secure it. If I get out of this Why - How - What cycle and do things in the reverse order or in the wrong order, my hard work turns into a piece of tissue paper or I have to make major revisions from time to time.

If I can manage my time well and always do only the important things, the rest is my own competence. In other words, you need to be good at coding. This requires an absolute amount of time, so the more you dig and the more you dig, the more productive you should be.

Personally, in development, I have experienced that the more I get used to modeling the code, the higher my productivity. Modeling the code means that the program runs freely in your head without running a separate compilation. The great developers I've worked with would sometimes shout, 'Oh, I see what's wrong,' when a bug occurs, and find the cause right away without running the program. As I watch them, how are they different from me? This modeling is what I discovered while thinking about it.

To reliably solve a given problem

This is a difficult question. You must also have the ability to solve problems, and also have the ability to predict and prepare for various variables in solving the problem. The meticulous attention to detail here is an added bonus.

Since problem-solving ability is a comprehensively required ability at various levels such as the code level and the decision-making level within the team, it is necessary to have quick judgment and experience. As you gain experience, you will be able to make some predictions about what will happen in the future if something similar happens.

In other words, this question turns into how to get a lot of experiences that help growth in a short time and how to handle things with meticulous care. Getting a lot of experience in a short amount of time always puts me in an uncomfortable zone. If something is repetitive, you should automate it and always crave something new.

I am not a meticulous person by nature, so I worked hard to be meticulous. Self-review of the code I've written, or check it out by deploying it instead of finishing testing locally. When combined with Pomodoro, when I think about what I am currently doing during my break time, I can recall the parts I missed.

To collaborate well

In order to collaborate well, communication skills are essential. I should always be on the lookout for inefficiencies when communicating my intentions clearly and discussing them without hurting the other person's feelings.

A good example of being wary of inefficiencies is ubiquitous language. By defining a common domain language between domain experts and developers, the inefficiency of word choices and explanations is blocked in the first place.

In general, domain knowledge

Domain knowledge is the understanding of your domain. Be it product, software, technologies, or the business to which you are contributing.

First, in order to increase general knowledge, you should actively do several projects for proof of concept. Many won’t agree but this is what has been worked out for me.

To write stable code

Stable code is, after all, bug-free code. In fact, it is impossible to completely eliminate the bug. This is because unexpected bugs pop up even if you test for all the assumed cases. Our goal is to make it bug-free in every case we assume.

The best way is to do TDD. If you do TDD, you have no choice but to make the module easier to test, and the code becomes simpler when dependencies are organized, making it easier to follow the KISS principle.

To write clean code

The definition of clean code is as diverse as the number of developers. However, as a rule, the clean code I define here is Uncle Bob's Clean code.

This book is a lot to read, a lot to follow, and a lot to experience. I've read this book two times since I was an undergraduate, but every time I look at it, something new catches my eye. In the past, the content that said, 'What is it?' It means that the moment of 'Wow...' will come. Uncle Bob is in a far-off state, and every time I leveled up, I was only able to get what I could see from my height, step by step.

To be good at the software design

A good software design is one that delays decision-making as much as possible. A decision made after getting as much information as possible is always better than a decision not made.

To be good at this, you need to be good at an abstract painting, which you learned in college. By distinguishing which domains and non-domains are, it should be possible to abstract all non-domains and invert dependencies. However, it is difficult to distinguish between domains and non-domains. At this time, if you have a lot of general knowledge, you can get more help.