Web Ethics has so much depth and it is difficult to take one idea and have it cover what it really means to be ethical in building and shipping for the web.
Ethics is the "defending and recommending concepts of right and wrong conduct."1
I like this part of the definition because we can write a topic on web ethics that we feel strongly about.
Web Ethics breaks down into2:
- Web applications should work for everyone
- Web applications should work everywhere
- Web applications should respect a user's privacy and security
- Web developers should be considerate of their peers
There are many events in my life as a web developer I felt strongly about in each of these areas and with experience you begin to understand how important each of these are in how you approach building and shipping for the web.
"Am I leaving these people or this project in a better place than when I first started? Did I make an impact?"
I've always asked myself with any engagement, "Am I leaving these people or this project in a better place than when I first started? Did I make an impact?" Source control has always been one of those areas I've felt strongly about. This area I've focused on to grow in and how I serve my peer developers in leaving them in a better place.
Source Control is just one of those things you just can't do without. If you don't have one, start one. Source control allows you to document how the software has changed over time. It is one way you can serve your peers and yourself to have some track record especially when issues show up.
Source Control facilitates good workflow for development
Source control should facilitate a good workflow for promoting and isolating units of work. If you are working on a fire and need to quickly shift gears, you need a good way to isolate that work from any hotfixes you may have to do.
Branching and merging should be painless.
If your source control is hindering you from branching and merging, it is time to find a different source control. I didn't realize how much a disservice I was providing my team when we were using TFS version control (this was prior to TFS supporting Git). And I had accepted that branching and merging was something you try to avoid. A few years ago at the Rocky Mountain Tech Trifecta conference in Denver, I remember a speaker in his session talk about source control and TFS stating "Avoid branching and merging whenever possible". This was easy to believe why he would say this because TFS branching and merging took a lot of effort and pain.
Git was a breath of fresh air. My productivity as a developer increased when I was introduced to feature branching with Gitflow. Branching and merging with Git became painless and really provided great control in delivering features through QA to production.
Understand what you are committing to source control.
I always run a
git diff to understand what I've changed especially if the team is working on one branch. Is there something in my commit that I didn't intend? Feature branching has always helped isolate work. Before the branch can integrated into a develop branch, a good code review process will help reduce conflicts for the entire team. Github has a great concept for review with pull requests. I've been on teams when everyone is working on one branch. One developer would check in their major change and it would blow up my local sandbox to do work. Here you have to get creative to stay productive. This is where I feel strongly about feature branches and a good review process before it gets introduced to the entire team. Also, having someone else review your work and pulling your branch to validate that it works on another machine will provide a good check to make sure you have checked in everything to make your feature functional.
Get latest and commit often.
It is important to stay in sync with the develop branch. I would always bring changes from develop back to my feature branch before I would think to propose it to be merged with the develop branch.
Try to think atomically with changes you are introducing with source control. A great article to read on atomic commits is Atomic Commits with Git
Provide meaningful commit messages
Find a standard in documenting your commits. Another great read is Semantic Commit Messages. When it comes to reviewing work or investigating issues, providing a great commit message and that is consistent throughout source control will really help the team.