Coffee break #83. What character traits distinguish outstanding programmers. Simple Programming Guide: Functions and Methods

What character traits distinguish outstanding programmers?

Source: Hackernoon What separates great programmers from good ones? I discovered two character traits that great programmers share: they were consistent and persistent. These traits in themselves are not signs of genius, and if desired, anyone can develop these traits and then apply them in their work.

1. Be consistent

Good programmers don't program occasionally. Rather, they have a specific schedule to improve their knowledge and skills during their free time: before or after work and on weekends. For example, a programmer I know spends the first two hours of his day—six days a week—on personal study projects or tasks. This is not to say that such people write code around the clock. They, like all of us, have time for their personal lives, obligations and interests. But they are consistent: programming has become their habit. How can you become consistent? This is what many of us are trying to achieve. I've found that there are several ways to do this. First, determine the number of hours per week you can spend programming. This number is your weekly “program mileage.” As a former distance runner, I ran a certain number of miles each week. This was my weekly run. Now I have my programming experience: this is the number of hours I spend programming each week. Most people neglect this stage. They jump straight to the project they want to complete or the topic they want to study, without thinking about how they will find the time to do it. As a result, they work at night or 16 hours a day. There's a problem with this approach: it's not sustainable in the long term. Honing your skills as a programmer isn't something you do over the course of a busy week or two. Instead, you have to continually work at it for a long time. This is why it is so important to identify your programming experience. To do this, consider using a time log to see where and how you spend your time. Take a piece of paper and write down everything you do every day and how long you do it, including checking social media or email for five minutes. This will make it easier for you to find open slots in your schedule. You might even be able to get a little extra time to do housework or watch TV. You can then create a programming training plan that you need to stick to. A training plan is one of the most effective ways to be consistent. It allows you to distribute all the details in advance. All you have to do is put this plan into action every single day. My running training plans outlined how many miles I needed to run each day and how fast I needed to run them. Now I create programming workout plans that serve the same purpose: they tell me what I need to do each day. At the end of the day, I open Evernote on my computer and make a schedule for the next day. Here's an example: I follow this process throughout my workday: I designate the amount of time I will spend on a task and what I want to accomplish in that time. I also create a monthly training plan. In it, I include three things that I want to accomplish, learn, or complete in the coming month. I used to make quarterly plans. But then I discovered that too much can change in three months. A monthly plan allows enough time to make significant steps in your training.

2. Be persistent

The second trait of good programmers is persistence. They work through all the options for solving the problem and find the answer. This seems to be the secret. The great programmers I've met have an uncanny ability to break down problems and come up with different solutions or solutions to a difficult situation. In short, they had a system for solving problems. I never had a solution system in high school. Whenever I was given a problem in math class, I would dive straight into it at full speed. Then I continued to do this when I started programming. No plan. There is no system. No time to think. No analysis. Unsurprisingly, in both cases I was spinning my wheels unnecessarily and constantly running into obstacles. I now have a problem-solving system that helps me break down a problem to find different options. For example, the first step in my problem-solving process is to state the problem. This is the first. Once I understand the problem, I focus on each of the following steps.

• Analysis of input data and expected results.
• Creation of an action algorithm.
• Writing pseudocode.
• Solving a simplified version of the problem.

Hope you get the idea. The stages may not be easy, but they are manageable. By solving a difficult problem, we become better people. It also instills confidence. Once we solve one difficult problem, we are ready for new ones.

3. Attitude to problems?

On the path to becoming better programmers, there's something else we need to consider: attitude. You must have a fresh approach to problems and ambiguities. One day I asked a senior developer some questions about a problem I was stuck on. I was puzzled and disappointed. At first, the developer was also puzzled. However, his answer shocked me. “Wow, that’s a cool problem,” he said. His interest was piqued by the details he discovered. That's not to say that great programmers don't get stuck in some problem, too. They get stuck. But the difference is in attitude. The lesson I learned that day was this: good programmers are not afraid to venture into the unknown. They understand that they will definitely learn something new by studying this problem. We can learn a lot by studying other programmers. But ultimately the responsibility lies with us: we need to get to work every day and take action.

Simple Programming Guide: Functions and Methods

Source: DZone What makes a good function or method? This requires a combination of factors, each of which matters. Let's look at four of the most important ones.

Meaningful name

Functions should have names that describe their purpose or functionality. When a function has a meaningful name, it is easy to read and understand its purpose. For example, if the purpose of the function is to find a customer by ID, a good name might be findCustomerById(id: String) . Another option could be findCustomer(id: String) . Here the function signature implies that the buyer is found by his ID. The word “find” also implies that the buyer may or may not be found. If the function name is changed to getCustomer(id: String) then its meaning changes because it now implies no rollback; the client is either found or the function fails and possibly throws an exception. Both names are valid names for a function, but have different meanings, and so their implementations must also be different.

As few parameters as possible

I like to follow the rule of three. This means that the function must have three or fewer parameters. When a function requires more than three parameters, it should be rewritten and the parameters placed in a data holder, such as its class, data class, JavaScript object, and so on. This is an easy way to reduce the number of parameters and organize data within an application. Let's take for example a function that has identical behavior but different signatures:

fun addCustomer(
  firstname: String,
  lastname: String,
  streetAddress: String,
  city: String,
  zipCode: String
)

Here's another option:

data class Address(
  val street: String,
  val city: String,
  val zipCode: String,
  val streetNumber: String
)

data class Customer(
  val firstname: String,
  val lastname: String,
  val address: Address
)

fun addCustomer(customer: Customer)

The function does what is expected

A function must do what is expected of it. No more, no less. If the function is named findAddress(latitude, longitude) then it should find the address at the given coordinates, or, if the address cannot be converted to coordinates, return None , null , Empty or whatever is the appropriate type for the given language . The function shouldn't do anything else, such as look up nearby addresses or build coordinate records. A function may have side effects such as logging or analytics, but these are invisible to input and output.

The function can be tested

Features must be designed so that they can be tested. In the previous code example, I defined the addCustomer function , but I didn't define any return type, so its testability is questionable. Of course it can be tested using mocks or spies depending on what the internal implementation is like, this can be achieved by simply providing the return type:

fun addCustomer(customer: Customer): Customer

With this function signature, we can return the added client entity to the called component. We can also check if the function does what it is supposed to do with this client object (that is, assign it a unique identifier).