Author: John Au-Yeung

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 to continuously improve ourselves.

Continuous Learning

In the software development world, things change a lot in quick succession.

However, like with anything else, software development is maturing with the accumulation of knowledge.

Many things that need improvement have improved thanks to decades of knowledge accumulation.

Therefore, learning now shouldn’t be hard work.

We can learn from videos, blogs, conferences, forums, books, and more.

The more we learn, the more useful we are.

Practice

Another important thing to do is to practice.

We got to keep our skills sharp and ready.

It’s hard to internalize programming knowledge without practice.

Like with anything else we want to master, we just got to practice it.

There are many things that we can do to practice.

We can do simple programming exercises from LeetCode or Project Euler.

Also, we can build apps and other programs that we want to use.

We can pick some technologies we want to use and write apps with them.

There are lots of things we can do to maintain our skills.

Collaboration

Collaborating with other people is another great way to learn.

We can make a special effort to practice programming with other people.

It’s sometimes more fun than working alone all the time, and we can exchange knowledge easily.

Teaching

Teaching is also a great way to learn.

If we can teach what we learned, then we know we learned it well.

We can bring people into a group and present what we learned.

Professionals take responsibility for learning people less experienced than them.

They won’t let them go unsupervised.

Know Our Domain

We got to understand the domain of the solutions we’re programming.

This means that we got to know the business requirements well.

Otherwise, we probably build things that don’t create the right results for the users.

For instance, if we’re building a payroll system, then we got to know about income taxes and accounting.

We probably want to read some books on these topics.

It’s bad to code from a specification without knowing if they make sense to the business.

We should know enough about the domain to be able to recognize and challenge specification errors.

Identifying with Customers

We got to know what’s bugging our customers.

Otherwise, we build things that they won’t be happy with, and then we got to do it again.

That’s definitely not ideal.

Humility

Programmers should be humble.

Risks are taken in a calculated way based on our confidence.

This means that we should be aware that sometimes we’ll fail.

Risk calculations can be wrong, our abilities may fall short of what’s required.

It means that we should never be arrogant and ridicule others.

Saying No

Sometimes, we just got to say no.

There’s no way that everything can be done nicely and quickly.

Also, there’s no way that many features can be implemented in a short timeline.

It’s just unfortunate that the ideal situation won’t happen.

There are always issues that we run into that slow us down/

Being a Team Player

Team players communicate frequently.

We also keep an eye on our teammates.

It’s not someone that says yes all the time.

People that advocate for the team are team players.

Trying

If we have any reservations about our commitments, then we shouldn’t commit to something 100%.

We can only commit to what we know can be done within our timeline.

There are always issues that we run into when writing software and we’ll disappoint people if we promise too much and deliver something less than that.

If there is any uncertainty, then we should communicate that.

If things are looking better, then we can communicate that.

If something is slowing us down, then we should update people on that.

The Cost of Saying Yes

We can’t always say yes to everything.

If we do, we won’t have time to do everything that’s promised.

This means that we’ll be stressed and we never get enough done.

Also, if we rush, then we make mistakes and we deliver something crappy.

The code that we write also probably won’t be the best quality.

Conclusion

We should think twice before saying yes to everything.

There is no way that we can do everything. Otherwise, we’ll have problems because we rush our work.

Also, we should learn and practice to keep our knowledge up to date.

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 when we should code.

Worry Code

If we feel bad, then we shouldn’t be coding.

Stress distracts us from doing the hard task of coding.

We can’t maintain focus or concentration.

Also, we get tired and we get stuck with problems that we may able to solve faster if we feel good.

We just got to know how to shut down these bad feelings and get on with coding.

Coding is also a good distraction from all the bad things that are happening in life.

We should also find a quiet place to write code if it distracts us.

Flow

Flow is when we’re in a productive state,

Some programmers also call it ‘the zone’.

It’s when we’re in a focused, tunnel-vision state of consciousness that programmers can get into while they write code.

It’s when we’re feeling productivity.

When we’re in the zone, we’ll write more code.

We’ll add more features and refactoring them more quickly.

However, we may lose some of the pictures when we’re in the zone, so we may make decisions that we’ll have to go back later and reverse.

Therefore, we may want to walk away and take a break as we go into the zone.

Pair programming also prevents us from going into the zone.

The zone is an uncommunicative state.

Pairing requires intense and constant communication.

Music

Music may be distracting to us when we go into code.

Therefore, we may want to turn it off when we code.

Not everybody can code well with music on.

So if it distracts us, then we can turn them off.

Interruptions

Another bad thing that happens when we go into the zone is that we get mad when interruptions happen that take us out of the zone.

We may snap at people that take us out of the zone.

However, sometimes we’re stuck on some hard problem that needs concentration.

This may also lead to us being mad at people that interrupt us.

Pairing can help with solving hard problems.

Our pair partner can hold the context of the problem while we deal with the interruption.

When we return to pair programming, then we can reconstruct the context before the interruption.

Test-driven development also helps us with holding context.

The context are in the test. If we have a failing test, then we have a problem.

Writer’s Block

Sometimes we get stuck when we write code.

Often we find other work to do when we’re stuck, we surf the web or check the email for example.

The lack of sleep may slow our brain down so that we get stuck.

Other things like worry, fear, and depressions are also factors.

This is where a pair partner can help again.

They can help get us unstuck in whatever we’re doing.

Creative Input

Reading things also give us some ideas on how to solve our problems.

Creative input gives us the inspiration to make output.

Books, websites, TV, movies, music, etc. all may help.

Debugging

Debugging is definitely part of coding.

It probably takes more time than writing the code.

Debugging is just as expensive as coding time.

With test-driven development, we can spend less time debugging since we can catch them with the tests.

Ideally, we should spend no time debugging, and we should try to reduce it as much as we can.

Pacing Ourselves

Software development isn’t a race.

There will also be things to do and there’s no finish line.

When we’re tired, we can’t solve the problems that we can probably solve quickly if we’re energetic.

When we’re stuck or tired, we should stop for a while.

We should pace ourselves so that we won’t be working when we’re tired.

When we’re driving, we should also disengage from problems at work so we can concentrate.

Taking a shower is a great time to think about problems. Lots of solutions may come to our brains when we’re taking a shower.

Conclusion

We shouldn’t be coding when we’re tired.

Also, pair programming is useful when we need to get back to work faster after interruptions.

Pair partners also help when we’re stuck.

We should also minimize the time we need for debugging.

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 being professional.

Being Professional

Being professional is hard. We got to clean up the mess that we leave, and we got to take responsibility for our work.

We got to look out for issues and respond to them.

There are many things that we’ve to look out for.

We can mess up any existing functionality, we can lose any data, and we’ve got to minimize emergencies that may come up.

This way, we can the systems running so that customers can do use the software that we’ve built.

We got to make sure that everything is functioning.

Software is hard to create without bugs, so we got to think and test them out before we work on them.

If there are any imperfections, then they’ve to be fixed.

QA Finds Nothing

The ideal scenario is that QA just finds no issues and we move on.

They are there to catch issues that developers may have missed.

QA will probably find bugs. There are too many cases in any software.

It’s too easy to miss things and hopefully, QA will find those issues before the software is released.

We got to test our stuff to make sure they work.

Ideally, we have comprehensive test coverage so that we don’t have to test ourselves.

To make sure that everything works, we got to test it.

We can design our code so that it’s easy to test. If we do that, then testing wouldn’t be too hard.

Automated QA

Automated QA reduces the burden of manual testing, so we should make sure that we have automated testing.

If we have them, at least we know that we didn’t break anything existing when we worked on the code.

Software Structure

We got to make sure that the software we work on is easy to change.

If we make them hard, then we’ll have problems working on it later.

Too many projects become a mess once people worked on it.

Tasks that used to be quick take longer and longer to complete.

More developers won’t help since the code is so messy that no one can navigate through it.

If they work on it, then it’ll just get messier.

Therefore, we should make sure that our code is flexible and maintainable.

To prove that our software is easy to change, the only way to find out is to make changes to it.

We want changes to be easily made all the time.

Every time we look at a module, we should make small changes to improve its structure.

We keep adjusting the structure to keep it easy to change.

If we have tests, then we shouldn’t be afraid of breaking code.

If we break it, we would know right away.

Tests can be run on a whim so that we can check if we broke anything.

If there are changes we want to make, we wouldn’t be afraid to make them.

Our Career

We should keep learning on and off the job.

Some employers may provide us with resources to learn, but that’s a bonus.

It’s up to us to learn things and keep our knowledge up to date.

We can definitely learn on our free time.

Even a little bit of time each day can add up to a lot.

The spare time is for learning and having fun during the process.

Photo by Anthony DELANOIX on Unsplash

Know Our Field

Technologies, ideas, disciplines, all have to learn.

Everything is moving at a ferocious pace. So we got to incrementally update our knowledge.

A lot is different, but a lot of things stay the same.

Many things like waterfall development have been pushed aside but we can still learn what it is.

There are things that developers should be knowledgable on at the minimum.

They include things like design patterns, design principles, and some development methods like waterfall and agile.

Also, we should know things like test-driven development, object-oriented development, and how to draw designs on UML diagrams and charts.

Conclusion

Developers should know some minimal items.

Also, we should make our code maintainable and flexible.

Testing our code is also important.

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.