5 Mistakes That Junior Programmers Make

As a young developer, I had the opportunity to make mistakes, some costly and some not so much. And I have no doubt I will continue to have many more opportunities in the future.

Here are my top five rookies mistakes that I’ve made in the past half a year.

  1.  Not being decisive with my code. As a rookie on the team, it’s nerve recking to display your work. It’s similar to practicing violin for hours after hours (8th grade until I graduated high school), but still being afraid to perform in front of the teacher. I try to delay it as long as possible. This was not a good idea. I ended having longer review cycles. The problems in my code would have surfaced sooner, if I reached out to my tech lead sooner. Advice: get a second eye on your code as soon as possible
  2. Working only within the boundary. I tried to fit my code within the models and controllers that are available. Having to work with the Accounts service, I wanted to fit this aspect in the closest javascript file. This led me to the application.js (the all knowing) file. However, talking with other programmers it made sense to create it’s own accounts.js file. I handicapped myself by creating an imaginary boundary line. Advice: talk to another developer and get feedback on your implementation
  3. Git issue. Merging Conflicts. As my first programming job, I wasn’t too familiar using git with in a team. I made awful decisions of pushing without pulling, pushing without running the full test suite, and creating merging conflicts. Those are the worst. Advice: after you commit. Git pull –rebase origin master. Run tests, then push. By rebasing you’re putting your newest commit on top of the latest master. 
  4. Not specifying order of commit. I created two separate pull requests in two different services. I did not specify that PR 1 is contingent to PR 2. Then PR 1 was reviewed first and got merged in. This created issues as the PR 1 tried to make ajax requests that PR 2 was suppose to create. Advice: Always notify in the PR if it needs another PR to be merged in before hand. 
  5. Lack of defensive code. First time Redis user. I didn’t think that Redis would ever go down. Didn’t put in a rescue clause when Redis service goes down. This caused my app to break. Advice: Get in the habit of writing defensive code against potential issues.  

Let me know what mistakes that helped you grow as a developer!
John

Standard

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s