Software Engineering Fundamentals
By: Kevin Meldau
Tags: Programming, Front End Development, Software Development, Full Stack Developer, Web Development

You submit your first pull request. The head developer takes a look at your code and starts sweating and going into melt-down mode. He’s 20 seconds into reviewing your work and has seen some basic rookie errors. Not a great look!

Don’t panic, all is not lost. Here are a few things you can do to impress the senior developers on your team:

No Comments

Comments can sometimes be misleading, they don’t always do a great job of explaining behavior. A better option would be to improve naming so that your code explains itself. If your code has the correct naming, comments are no longer needed.

David Heinemeier Hansson, the creator of Ruby on Rails, had this to say about the importance of naming:

“One of the real delights of programming is picking great variable, method, and class names. But an even greater treat is when you can name pairs, or even whole narratives, that fit right.”

No Inline Styles

You should not be using any inline styling. Here are a few reasons why it’s such a rookie move to add inline styling:

Maintainability — It makes your code hard to maintain. You will not remember why you wrote your CSS inline 2 months from now. Even if you’re working solo and think you know the project well. Modular Design — It’s good practice to separate your markup and presentation. It makes the design easier to maintain. It also allows various developers to work on the same design without too much overlap. Shareable Code — It’s easier to share the styling rules on a project. It’s harder to track down code when it’s used in another area. And worse, you may not remember that it’s used elsewhere. Easier to Understand — This is especially true if you’re not looking at code you wrote. A new developer will find it easier to understand if it is not inlined all over the place. Specificity Issues — Tracking down specificity issues becomes so much harder. You’ll have to check a few different places to see why your changes are not getting implemented.

Proper Indentation

Indentation helps to convey a better structure of a program to the readers. Indentation is especially important when using Haml in Ruby. There are no closing tags, div wrapping is all based on indentation.

Proper code indentation will give you a lot of ‘brownie points’ with senior developers. It will also make your code easier to read, understand, and maintain.

Proper use of semantic HTML tags

Semantic markup HTML tags tell browsers something about the contents of the element. In semantic markup, tags are not only a way to get content shown on a site in a human-readable format. The tags themselves become a way to tell the browser something about the meaning of the content.

Properly Sized Commit Messages

Git has recommended that you keep your commit messages to 72 characters. This will ensure there is room to indent text and keep everything under 80 characters.

Thoughtful Commit Messages

Effective commit messages help “future you” understand why certain changes were made. They also simplify the debugging process. You don’t have to review hundreds of commits to discover where a problem is.

Close Unused Programs

It removes distractions and reduced cognitive load. It’s setting the stage for you to do your best work. It’s also better for the performance of your computer.

Limit Your Time

Limit the time you spend on a problem. Rather than dumping endless hours into it, set an amount of time you’ll continue trying. If you have still not found a solution, take a step back.