Knowledgebase

Disclaimer: I am not the best developer but I appreciate and reason the differences which make some developers stand out from the rest.

Write more code

If you want to get better at something then you have to spend time doing that thing, there is no other way sadly. No matter how many articles you read, how many times you read the docs, you will not improve unless you put your hands and mind in action. That design pattern which seemed hard to implement at the start will seem like a cake walk after you have practiced it’s use in multiple contexts.

Incorporate tests

When I first started writing tests for my own code, I was amazed to see the mindset I was lacking for writing good tests. Writing tests will enable you to look at your code the way you did not imagine at first because when coming up with tests you have to think about how can this thing break and you realise you were doing too many things in that function you wrote and it might be better to split into multiple functions because it’s hard to come up with a test for a function which does multiple things.

Let see an example below

function postData(data) {
 boolean valid = true;
 // check if data is defined
 if (data === undefined) {
   valid = false;
 }

// check if email is well formed
 if (!regex(data['email']) {
   valid = false;
 }

// check if password is atleast 8 chars.
 if (data['password'].length < 8) {
   valid = false;
 }

if (valid) {
  http
   .post(`example.com/user/create`, data)
   .then((response) => {
    //append to the list
    this.users.append(response.userid);
   })
   .catch((error) => {
    // show errors.
   });
 } else {
   showValidationError();
 }
}

So the method postData is doing multiple things such as validating the data, appending to the users list when the promise is resolved and handling errors. Writing unit test for postData will be difficult and messy. You can break it into multiple methods and test each method separately for e.g.

function postData(data) {
 return http
   .post(`example.com/user/create`, data);
}

function validate(data) {
 // check if data is defined
 if (data === undefined) {
   return false;
 }

// check if email is well formed
 if (!regex(data['email']) {
   return false;
 }

// check if password is atleast 8 chars.
 if (data['password'].length >= 8) {
   return false;
 }

  return true;
}

function appendUsers(userId) {
  this.users.append(response.userid);
}

function main() {
 if (validate(data)) {
  postData(data)
   .then(data => appendToList(data.userId))
   .catch(error => handleError(error))
 } else {
  showValidationError();
 }
}

You can already see why writing tests leads to a better quality code, you had to split your long method into multiple smaller units and each single unit can be tested atomically.

Be honest

Be honest about what you know thoroughly and what you don’t. Pretending that you know the in’s and out’s of an API will never help you improve and infact you might loose face in a discussion if you happen to say something stupid because of your lack of knowledge about an API or a topic.

Contribute to open source

Contributing to open source can expose you to scenarios which might never occur at work and thus limiting your horizons. You can learn what it takes to run a project in a distributed scenario, introducing non breaking changes and other new open source tools etc, the benefits are endless and we all know how open source has changed everyone’s lives directly and indirectly.

by rawpixel on Unsplash

Be open to help

Helping others for something you know makes you a “goto” person for that concept/feature/API and thus stemming your value and importance in the team. Be open to help for stuff you might not be the best at, you might end up learning something valuable from the experience.

Don’t be this guy

Pick a personal project

Personal project’s are a great way to learn new frameworks and technologies which you might not experience at work. With your personal project you are the product manager, you are the developer and the architect, so you can imagine the amount of decision making you will have to do. You can use the experience from your project and suggest new frameworks and tools at work or in your community and shine like a ⭐️

hardworking penguin

Lower your ego

Don’t let your ego and your job title come in between the way of your learning/improvement. An architect in a xyz organisation might be a software developer in some other organisation. Always be open to new and different ways of doing the thing you think you are great at. You might loose on a more efficient algorithm or a better design for a feature.

don’t be the kanye in your team

Understand the “why”

Before accepting and stemming your belief in a new framework or a pattern or an API try understanding that “why” does it exists at first place. Try getting to the intuition of the very existence of a concept.

var app = new Vue({
  el: '#app',
  data: {
    message: 'Hello Vue!'
  }
})

Above is the first code example you come across on the vue.js docs site. Even when I am looking at this very basic example I am trying to reason out the below things in my head:

• Why a new keyword for creating the component ? Why don’t they have a factory pattern for creating objects ?
• Seems like el property takes the id of the element and why does it uses # ? Does that mean I can add other element selectors as well such as attribute and class ?
• data seems like a very generic property name of the vue object, what is it trying to represent exactly?

Not saying that you should be critical to this extent for everything but developing this habit helps understand the philosophy of things better and thus improving your understanding.

Don’t be lazy

Laziness can come in your way to showcase your skills or the things you care about for e.g. if you believe a refactor will improve the performance then go ahead and do it, add comments to save other developers’ time, document the new API you have built. Time added by you in your code is equal to time saved for the other developer who is trying to make sense of what you have written.

Solve coding challenges

Solving coding challenges forces you to think about stuff which we take for granted in our routine. I am talking about space and time complexity of our code. Some people argue that it’s not practical to solve challenges since most of the things are abstracted and you are just gonna use the API.

But I disagree! Not only does it help you look at the code critically but also it enables you with the confidence of coming up with the best possible code in terms of performance and another benefit is that you will always be prepared for that interview ????

Some of the sites for solving challenges are hackerrank, leetcode, topcoderand spoj.

Encourage the good stuff

If you have liked your colleague’s commit then don’t hesitate to drop a message and appreciate or upvote that answer that helped you on stackoverflow or clap for the article on medium which gave you free wisdom or star that interesting project you checked out on github. Encouraging others helps bring the best out of them and eventually you also.

Do not hide behind the layer

You found an issue with the API which you are consuming in your view but you cannot fix it because you are a “front-end developer”. It is a bad attitude to have in my opinion. The basic principles of programming such as keeping the code DRY, using abstractions if you see multiple use-cases for your classes, catching exceptions for all flow control paths, etc. apply to almost every layer of the stack. Keeping the basic principles in mind, it might help you solve issues which you thought you cannot touch because you don’t work on that part of the codebase.

Conclusion: As I said above, reading this guide will help you realise the things which you haven’t been doing yet but to make the cut above you will have to put in effort and discipline

@Credits: Hackernoon