Author: John Au-Yeung

Building software requires some basic tools. To build software, we’ll have to use source control and debuggers to track our changes and debuggers to help us step through our code to debug them.

In this article, we’ll look at why and how we should use source control and debuggers.

Source Code Control

We need to check in our code to source control systems so that code change history can be tracked.

This makes reverting our code easy if anything goes wrong.

It’s also very good for letting people review our code since people can see what we changed and compare them.

Also, we can use it to merge people’s code together easily. There’s just no alternative way to merge different people’s code together in a systematic way if there are no source control systems to control the merges.

It’s also great since we know who worked on which piece of the code so we can get help on that part of the code from that person if needed.

Furthermore, source control systems let people branch code so that different people can work on different copies of the same code base and apply their own changes.

Once they’re done, then they can merge their changes in after it’s been reviewed.

Always Use Source Control

With all the benefits that source control systems brings, we should definitely use them whether we work by ourselves or within a team.

If we’re working by ourselves, we can track our own change history and revert code to a previous state from the change history if needed.

If we work on a team, then we use the undo feature plus, we can merge things from different branches in an easy, systematic way.

When 2 branches have code that conflicts with each other, then we can fix them with the built-in programs to diff and merge changes by fixing them ourselves.

Another good thing about source control systems is that some systems like Git are distributed.

This means that one copy of the repository is stored remotely in some server outside our computed, mostly remotely, and the other is stored locally.

It a repository is stored in a remote Git host, then we can treat that as a backup.

Source Control and Builds

Source control systems create the possibility to create automatic and repeatable builds.

A computer can automatically check out the code and then build it with an automated system of some kind.

Also, we can run regression tests automatically on that computer to make sure that our code didn’t break anything.

It’s repeatable because we can always check out the code and rebuild the code to create a new build artifact.

Therefore, it’s time to use control. There’s just no excuse not to use them for any sized project.

Debugging

To make our lives easier when we run into issues with our code, we should use a debugger to see what’s wrong.

With a debugger, we can run each line of the code with the debugger and check the values of the variables that are in each step.

Then we can easily see what’s going on in each line of the code.

With that, we’ll see what happens to our code in no time.

In the end, debugging is just problem solving, so we should attack it as such.

It’s not good to blame people. Instead, we should help each other instead of blaming others.

It’s easy to panic if we’re rushed or have a nervous boss or client breathing down our necks.,

However, panicking is just going to make matters worse. We just got to calm down and ignore everyone.

We shouldn’t eliminate any possibility until they can be proven that they can be eliminated.

This way, we won’t ignore anything. For instance, the error that takes the longest to fix may be a simple typo because we have overlooked it when we’re debugging.

Conclusion

Source code control is a must so that we can revert code easily. Also, it lets us work from a branch of the code instead of working on the code itself.

Also, we should use a debugger to debug, don’t panic and don’t eliminate any possibility when we’re trying to find the cause of a bug.

It’s easy for developers to make mistakes, but we can prevent them if we know them beforehand.

In this article, we’ll look at mistakes that newbie front end developers make that we can all avoid.

Relying Too Much on Frameworks

Front end frameworks are great. But we shouldn’t rely too much on it. We should still be able to do things on our own if we aren’t using the frameworks that we’re used to using.

Also, we should only learn frameworks once we’re proficient with plain JavaScript constructs and DOM manipulation.

Otherwise, we don’t know why everything works.

Using Bootstrap For Layout

Bootstrap was great when flexbox and grid were releases or when it wasn’t widely available in browsers.

Now we can use both to create layouts for our pages. Even Bootstrap itself uses flexbox and grid for layouts.

Therefore, we should use flexbox and grid for layouts instead of Bootstrap. Relying on Bootstrap too much doesn’t help us too much. And we’ll forget about the fundamentals.

Instead, we should just stick with the flexbox and grid, which makes the layout very easy.

Putting Our Code All in One Place

JavaScript had modules as a standard for a few years, so there’s no reason to have long scripts anymore.

Instead, we should use modules to divide up our code into manageable pieces.

Also, we shouldn’t have global variables anymore. Instead, we have variables we want to export in modules.

If we want to package everything together into a custom component, we can use the web components API to do that. This way, we can use them anywhere.

Projects created with framework all divide our code into modules. They encourage best practices by dividing things into modules.

Not Optimising Images

Many people don’t have fast Internet connections. Even though many parts of the Earth have broadband, they may not be the best quality.

Therefore, we should make sure that we compress images and shrink them so that their file size won’t be too big.

We can’t have many images that are megabytes in size. They’ll still take a long time to download with slower broadband connections.

To test out the performance on slower connections, we can simulate loading our website or app with a slower connection on the Network tab of the Chrome console.

We can choose from 3G, 4G, and a regular connection.

Using Inline Styles

Inline-styles are bad since they clutter up our page. Instead, we should clean them up by moving them to a CSS file.

This way, we won’t clutter up our page with styles and we can reuse the same style in multiple places.

Not Using Heading Tags for Styling Purposes

Heading tags are great for styling and tell us that they’re headings. Suitable headings have an impact on SEO.

Therefore, we should change headings to h1, h2,…, h6 tags if they’re actually headings.

Photo by Alvan Nee on Unsplash

Not Removing Redundant Styles

Redundant styles are a pain. There are things like having 100% width in block elements like divs that are redundant.

We don’t need to set a width of a div to 100% since the default width is to take 100% of the width of the parent.

Chrome often tells us which styles are redundant so that we can remove them if we see that warning in our console.

Embedding Fonts in a Wrong Way

@font-face is for specifying the font name for fonts that have to be imported.

However, we can also specify the weight of the font within the @font-face block to control the font-weight of the font and keep the same name in both the block for the regular font and the one with a different font-weight.

For instance, instead of writing the following:

@font-face {
  font-family: 'Open Sans';
  src: url('opensans.woff2');
}

@font-face {
  font-family: 'Open Sans Bold';
  font-weight: bold;
  src: url('opensans-bold.woff2');
}

We should write:

@font-face {
  font-family: 'Open Sans';
  src: url('opensans.woff2');
}

@font-face {
  font-family: 'Open Sans';
  src: url('opensans-bold.woff2');
}

Then we can just set the font-weight in our style and then the right font will be picked from the font with the right font-weight or other styles on the list.

For instance, we can use Open Sans as follows:

.foo {
  font-family: 'Open Sans';
  font-weight: bold;
}

Then the browser will pick the Open Sans font face that has font-weight set to bold.

Conclusion

Inline-styles are bad, we should move them to a CSS file so we can reuse them.

Also, we should embed fonts properly by putting the styles in the @font-face block.

Finally, we should think about users with slower connections and optimize our assets.

To be a good programmer, we should follow some easy to adopt habits to keep our programming career long-lasting.

In this article, we’ll look at the best practices to apply to make us better developers.

Duplication is Bad

If we have to write the same thing 3 or more times, then we should definitely consolidate them into one place and reference that one place only.

Duplicating things men’s that we have maintained the same thing in different places.

This means more work for us at the end just by copying and pasting in one place.

When we have to perform maintenance, we’ve to find and change things.

If we duplicate things, then we have a maintenance nightmare.

It starts before whatever code we have is shipped.

Therefore, we should stick to the do not repeat yourself, or DRY, principle.

Instead of having the same thing in 3 or more places, we should consolidate them into one place.

2 of the same thing isn’t quite enough for them to be needed to be consolidated since we don’t if we need them again.

If we know that they’re needed a 3rd time, then it makes sense to move them out into their own component.

This doesn’t only apply to code. It includes any kind of duplication.

There’re a few kinds of duplication. They include imposed duplication from environments that makes us keep duplicating things because we’re forced to.

Also, we may be inadvertently duplicating things because we may not that something like what we have already existed for example.

We can also duplicate because we just didn’t both to abstract out things that are duplicated.

Duplication may seem easier at the beginning but it’ll make our lives difficult later.

Interdeveloper duplication may also occur if multiple people on one or more teams duplicate something.

Imposed Duplication

We may be forced to top duplicate something because of requirements and.

Programming languages may require certain structures to be duplicated.

Multiple representations of something may occur if we have to create the same thing in different languages for example.

This kind of duplication is hard to avoid since whatever we need to implement is needed in 2 different programming languages, so we can’t just apply the DRY principle straight up.

Instead, we may have to stick with duplication if it’s a one-off change or we can make a code generator to create the code for us if we have to change the same thing multiple times.

Documentation in Code

Documentation in code may duplicate what we have in our code.

Since our code is supposed to be mostly self-documenting, we don’t need to put in comments in addition to having our code in most cases.

Unless something really needs explaining like if it’s not completely obvious why we’re writing a piece of code to do something, then we need to comment on it.

Otherwise, we just make sure that our variable and function names are clear and following the usually clean code principles like dividing our code into small pieces.

Comments are easily ignored and become out of date, so that’s another reason not to have so many comments that are duplicate of what we convey in our code.

Documentation Outside Of Our Code

We may also be writing documentation outside of our code.

We can also remove most of those if they’re only for internal documentation and let our code explain themselves.

Also, we also have tests to document our code to tell us what the business requirements are, so that’s also great documentation.

Therefore, we really only need documentation for external users of our API or app so that they’ll know how to use it.

This is because they are the only people that can’t read our stuff. There’s no way that they can access our code in most cases and even if they can, it’s not practical for them to read every line of code to understand how to use our API.

Therefore, we need documentation for them.

Language Issues

Programming languages may be making us duplicate things. We may have the same method in different objects or namespaces for example.

This is a form of duplication that we can’t avoid, but since it’s namespaced, we won’t get confused so easily.

Conclusion

Duplication is something that may come in different forms. We may be forced to duplicate something, we may not know that we’re duplication something, or we may be doing it on purpose.

Duplication doesn’t only apply to code, it may also apply to other things like documentation and anything else that can be duplicated.

Writing software is hard. Therefore, there’re many ways that we can mess up.

However, if we’re aware of them, then we may think twice before doing the wrong thing.

In this article, we’ll look at some mistakes that many developers have made before.

Committing Code in the Wrong Branch

Committing code to the wrong branch is something that’s been done a lot.

Since we’re supposed to make a new branch for even making the smallest changes, we may do this a lot.

Worse yet, we force pushed the wrong branch and overwrite the commit history of a branch that we shouldn’t.

We definitely let that happen.

We can protect our branches that we can’t mess up on so that we won’t accidentally commit the wrong things to them.

Hacky Code

Hacks will bite us in the long run. Unless our code ios total throwaway code, we should think about the long term consequences of our hacks.

We may write crappy codes that are hard to read so that others can’t work on it.

Also, we may run into problems later when we try to change our code or when new change requests come in.

We shouldn’t write a hacky code for anything that is used for years.

This way, we won’t run into problems later on.

Code That’s Way Too Fancy

Code that’s too fancy is also a problem.

Anything over-engineered is bad. If we should make our code easy to changes, but we don’t have to incorporate everything in the get-go.

If we can keep our code simple, then we should keep them simple.

No code is a lot better than code that we don’t need.

Also, we don’t want to write code that’d overly clever. This way, we don’t have to make others read code that are hard to understand.

Hard to understand code is definitely not pleasant for anyone to read or work with.

Underestimating the Workload

We should always give generous estimates that give us plenty of time to do the work.

Therefore, we shouldn’t underestimate the workload that something takes to be complete.

If we underestimate, then we’ll disappoint people that are looking forward to our stuff after a short time.

We’ll also be under pressure to rush out our code, which isn’t good.

Assuming we Don’t Need to Test Your Code

Any small change can break something.

Therefore, we should make sure that we test our code no matter what we change.

Changes never end up like what we expect.

Therefore, we should always test our code so that they do what we expect.

We should write automated tests so that we can test faster.

Reinventing the Wheel

Reinventing the wheel isn’t good. It’ll slow us down and create duplicate code.

We don’t want that. If we can reuse something that’s already there, then we should do that.

This way, we work faster and we don’t have to write everything from scratch.

For instance, JavaScript arrays have lots of methods to make manipulating arrays easy.

Therefore, we should use them to manipulate arrays instead of using loops.

Reinventing the wheel is often because of ignorance.

Therefore, we should know the language, libraries, and frameworks well so that we won’t implement the same thing that are already available somewhere else.

Committing the Wrong Files

Committing the wrong files can also happen.

It happens easier if we don’t see what we’re committing graphically like when we commit our code with the command line.

Therefore, it may be a good idea to visualize what we’re committing by using a graphical client for the version control systems that we’re using so that we can see what we’re committing clearer.

Code is Never Self-Documenting

Some code may need explaining. Even if we know the workflow from the code, we can still use comments to justify decisions and tell people why something is done the way it is.

Writing comments that explain why will help everyone know the code better.

As long as we aren’t just repeating the code what the code says in our comments, we should leave some comments.

Conclusion

To avoid mistakes, we should learn more so that we don’t reinvent the wheel.

We can avoid branching and commit mistakes by protecting branches and using a graphical version control client.

Hacky code will always come back to bite us later. Unless we write throwaway code, we should think about that.

Finally, we may want to leave some comments to explain our decisions in our code.

To be a good programmer, we should follow some easy to adopt habits to keep our programming career long-lasting.

In this article, we’ll look at better ways to communicate as a developer.

Choose a Style

We should adjust our communication to the audience. Not everyone wants to take in information the same way.

Some people want lots of detail and some want to stick to the point.

People want to read long reports and some want simple memos.

Therefore, we should adjust to their style so that people listening to us and reading our things will have a better time to understand our information.

Present Our Message Nicely

We have to present our message nicely so that we can convey them to our audience in a way that they’re happy with.

We shouldn’t only focus on written communication. Verbal communication is also important.

If we’re writing written documents, we should make the nicely formatted.

If we can’t make them nice ourselves, we can use templates to help us make them look nicer.

Also, we have to check the spelling and grammar of our work before presenting it to our audience. This way, we won’t embarrass ourselves with such mistakes.

Involve Our Audience

When we’re presenting something, we should engage our audience by getting feedback and pick their brains so that we can improve on our work.

This way, we can produce a better document than if we just write the whole thing ourselves without consulting anyone.

Be a Listener

We got to listen to people so that we can get their views on things.

Also, if we listen to people, then they’ll listen to us.

Therefore, we should encourage people to talk by asking questions or have them summarize what we tell them to make sure that they got what we said.

This will make getting our point across more effectively and learn something.

Reply to People

When we get a message, we should reply to them. It’s impolite to make people wait a long for an answer and it’s even worse if we just ignore them.

Therefore, we should always respond to messages and emails and check our notifications often.

Email Communication

Being careful with our email communication will save us. We should proofread before we send so that we won’t send out messages with typos or wrong information.

Also, we should check the recipient to see if it’s the right person or people before sending it.

This is especially important if the email has sensitive information.

Also, we should check the spelling of our emails to make sure that everything is right.

The formatting should be simple so that people with any email client can read them clearly.

If we use rich text or HTML emails, then we should make sure that all recipients can read them properly.

Quoting things should be kept to a minimum so that we won’t have to read everyone’s quotes.

If we do quote, then we should attribute the quote to the person that wrote the quote.

Flaming is always wrong. We should be polite even if we’re sending emails.

Also, we should organize our emails so that we only see the important stuff. The rest can be archived.

Sketch Boards and Storyboards

Diagrams are always good. We can put them on whiteboards, documents, messages, etc to convey what we want other people to know.

A picture is worth a thousand words, so one diagram can replace a thousand words.

Most people just understand diagrams better than a wall of text.

We can draw stuff with markers on whiteboards or we can do the same with virtual whiteboards and make things nice.

This way, everyone can explore ideas and make discussions easier than just talking and writing out words.

Flowcharts

To discuss workflow related things, flowcharts are always great. We can draw them or we can use a program to create them.

There’re many programs that let us create flowcharts to outline the workflows of our programs.

The symbols on a flowchart are standard so many people will know what they mean.

Therefore we should use them and save us from taking lots of time explaining things.

Conclusion

When we communicate with email, we should think about who to send it to and check for typos.

Also, we should draw diagrams instead of writing out lots of words to explain something.

It just saves us lots of time from doing things that we don’t have do to communicate the same thing.