Category: Careers

To be a professional programmer, there’re many things that we’ve to do to be a good one.

In this article, we’ll look at how we make commitments, and why we shouldn’t code when we’re tired.

Saying Yes

It’s possible to do everything, so we can’t say yes all the time. There are also plenty of situations where we run into issues with software projects.

Therefore, we got to think twice before committing to anything. There are 3 parts to making a commitment.

First, we say that we’ll do it. Second, we mean what we way. Finally, we actually do what we say we’ll do. There are some people that mean what they say and get it done.

There are some that say they mean them but don’t get it done.

There are even more people that promise things that they don’t mean to do.

We just can’t trust people that don’t mean what they do.

Recognizing Noncommitment

There are things that people say that can identify noncommitment.

Any sentence with ‘need’ like ‘we need to get this done’ is one sign of no commitment.

‘Hope’ or ‘wish’ in a sentence also signals noncommitment.

Also, “let’s” is also the same thing as the other 2.

Once we look for these words, we’ll catch noncommitment easily.

Recognizing Commitment

Commitment can be spotted by saying something will be done by a concrete date.

If it’s said so concretely, then we know that it’ll either be done or not. We can do things that we have full control of. If it depends on others, then we can’t commit to it.

We can, however, commit to other actions to meet our target. We can coordinate with other people that will help us get what we need to be done by communicating with them.

If something can’t be done, then we can still promise something that will bring us closer to the target. We can do actions that bring us closer to done.

Sometimes we just can’t make the date that we set to get something done. We got to tell the stakeholder if we can’t make the timeline that we promised.

If we run into unexpected technical issues, then we can communicate that and decide on the course of action.

How to Say Yes

Using the word ‘try’ signifies that maybe we’ll get something done.

To commit to something fully, we would have a more concrete timeline.

Coding

Coding is a challenging and exhausting activity. It requires a level of concentration and focuses that few other disciplines require. This is because we’ve to juggle many competing things at once.

Our code must work. We got to understand what problems we’re solving and understand how to solve it, We also have to ensure that our code is a faithful representation of the solution.

Also, we’ve to ensure that the solution is consistent with the language, platform, architecture, and all the other bits of the current system. The code must also solve the problems for the customer.

We got to check with the customer to see if the solution is actually solving the problems that they need solving. The code also must fit well within the existing system.

The rigidity, fragility, or opacity of the system. It must also be well-managed.

The code must be readable by other programmers. It must be crafted in a way that reveals the intent. It’s hard to do and a difficult thing to master.

Dealing with all these things is hard. They are the necessary concentration and focus for a long period of time. The problems and distractions of working in a team or organization make thins even harder.

If we can’t concentrate sufficiently, then the code will be wrong and have bugs. We shouldn’t code when we’re tired.

Coding When Tired

When we’re tired, we shouldn’t code.

The code we write wouldn’t be good. We probably won’t catch a lot of issues that we can if we have more energy. We might think something works but it might be a fluke since we’re so tired that we missed stuff.

The code quality will probably be poor since we can’t think straight. It’ll just bite us later when we have issues with the code even though it may work.

To be a professional programmer, there’re many things that we’ve to do to be a good one.

In this article, we’ll look at the most basic requirement to be a good programmer, which is to clean up after ourselves by naming things better.

Writing Clean Code

Boy scouts are always told to leave their campground cleaner than they’ve found it.

We can apply the same principle to code. We leave them cleaner than we found it.

This way, we’ll always have a clean code that is pleasant to read and work with.

Naming is the start of writing code that’s easy to work with.

Using Intention-Revealing Names

We can start cleaning up code by naming things in an intention-revealing manner. Names should be descriptive enough that we can understand it by reading its name.

For instance, instead of writing:

let x;

We write:

let elapsedTimeInMinutes;

There’s a big difference in both names.

We know what elapsedTimeInMinutes means right away, but we’ve no clue with x means.

Therefore, we should name things in ways that we understand. The code should tell us what it’s doing explicitly rather than doing everything implicitly.

We don’t know what x so we don’t know what it holds.

Likewise, if we have a function like:

const getItems = () => {
  const list = [];
  for (const a of arr) {
    if (a % 2 === 0){
      list.push(arr)
     }
  }
  return list;
}

We don’t know what list and arr have.

Therefore, we just don’t know what it’s trying to do, even though the spacing and indentation are good.

No Disinformation

We should never leave false clues with our names. For instance, we should only prefix our variables with num if it’s actually a number.

Also, we should keep our spelling consistent so that there’s no chance that we can mislead people.

Meaningful Distinctions

We should name our things in our programs so that we can distinguish between them. Otherwise, we’ll be confused by things with similar names but act differently.

For instance, if we have 2 variable names called productInfo and productData , then they’re too similar. If they’re different, then they should have more distinguishable names.

Use Pronounceable Names

Pronounceable names should be used so that we can actually remember them and talk about them.

If we can’t pronounce the names, then it’s hard for us to discuss them.

Use Searchable Names

Names should be searchable so that we can find them later. Therefore, we should use descriptive names as we mentioned before.

Also, we should avoid magic values and assign them to named constants. This way, we can find them easily and only have to change them in one place.

Member Prefixes

We don’t need member prefixes since we can tell that they’re members of a class or object by their location.

For instance, instead of writing:

const obj = {
  mName: 'joe',
  //...
};

We can just write:

const obj = {
  name: 'joe',
  //...
};

Mental Mapping

We shouldn’t make our brains more work when we don’t have to.

Therefore, we should just write out everything clearly so that we don’t have to map them with our brains.

Class Names

Class names should be noun phrases like Car or Dog .

Method Names

Method names should be a verb or verb phrases like save or speak.

One Word per Concept

We should have one word per concept instead of having synonyms.

For instance, we can use fetch instead of using fetch , retrieve or get .

Context

We should add some context to our names so that we can understand why they’re named the way they are.

For instance, if something is part of the address, then we should prefix them with something that indicates that it’s so.

So instead of writing state, we can write addrState so we’re sure that we refer to the state in the address instead of some other state.

Conclusion

We can make our code clearer by naming things properly.

Names should be descriptive, easy to pronounce, and consistent.

Also, we should give some context in the names so that we won’t be confused by them.

Disinformation should be corrected also to avoid confusion.

To be a professional programmer, there’re many things that we’ve to do to be a good one.

In this article, we’ll look at the most basic requirement to be a good programmer, which is writing clean code.

Clean Code

Code is what we have to write to make things that businesses want.

Therefore, we’ll have to live with them for a long time.

This means that we’ve to write code that we can change and read easily.

Otherwise, we’re making our lives difficult.

Writing clean code is a way to make them clear and easy to change.

We just got to strive to write clean code.

Code is the way that we express requirements, so we should make them self explanatory so that we or other people can know what the code means.

Bad Code

Bad code is just code that we can’t live with.

Bad code includes code that has bad naming, messy logic, bad organization, and many more things that make reading and changing it difficult.

Bad code may be faster to make when we’re writing them, but we’ll pay dearly later.

This is because one will understand what we write when we go back to look at it.

Everything is so confusing that making even simple changes would be very difficult.

Therefore, we should always clean up our code after we got something working.

If we leave it, then it’ll haunt us later.

We should clean it up immediately. Otherwise, we’ll never clean it up.

Costs of Messy Code

Since changing bad code is so hard and time-consuming, it’ll definitely cost us more money.

Also, if we make changes, we may break other parts easily.

This isn’t good at all since we customers will notice if the bad parts are released.

Productivity decreases and customer complaints increase with bad code.

There’s just no way that bad code can be good for anyone.

The more change we make to bad code, the messier it gets, and productivity decreases more.

Redesign

Eventually, the code is so messy that making changes is impossible and the code has to be rewritten from scratch.

This takes lots of time since we’ve to replicate all the parts of the existing software.

There are many cases and boundary conditions that we have to worry about.

We always encounter issues when writing code, especially if it’s such a big rewrite.

Therefore, it just takes longer to rewrite the code.

Something that takes minute would take hours, and something take hours would take days.

Changes to one module may lead to changes in 10 or more other modules.

It’s tough to rewrite code.

Therefore, we should always leave time for cleaning up our code from the get-go.

We should give ourselves generous estimates so that we can clean up after ourselves.

And then we won’t run into all the problems that we’ll encounter later on with bad code.

The business probably wants good code so that we can work on them faster.

Therefore, we should think about that when we make estimates.

Making messes to meet deadlines just isn’t a good idea.

The moment we finish writing the messy code, we’ll be confused by them immediately.

Meeting deadlines means that we should write our code cleanly.

Clean Code is an Art

Writing clean code is an art.

We’ve to use lots of little techniques in a disciplined manner to create clean code.

We’ve to acquire the sense of writing clean code.

There are many definitions of clean code. Some may say it’s elegant.

According to Mac’s built-in dictionary app, elegant means ‘pleasingly graceful and stylish in appearance or manner; pleasingly ingenious and simple.’

It’s supposed to be pleasing.

Clean code should be pleasing to read.

We shouldn’t be tempted to turn our code into a mess.

Error handling should be complete. Also, broken bits should be fided.

Clean code does one thing well.

Conclusion

The cost of messy code is just too high.

Therefore, we should write code that is clean and well organized, and easy to read and change.

Clean code makes us work faster and messy code will slow us down to a point where working with the code is almost impossible.