Disclaimer: I am not the best developer but I appreciate and reason the differences which make some developers stand out from the rest. Photo by on Joshua Earle Unsplash 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 definedif (data === undefined) {valid = false;} // check if email is well formedif (!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 listthis.users.append(response.userid);}).catch((error) => {// show errors.});} else {showValidationError();}} So the method 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 will be difficult and messy. You can break it into multiple methods and test each method separately for e.g. postData postData function postData(data) {return http.post(`example.com/user/create`, data);} function validate(data) {// check if data is definedif (data === undefined) {return false;} // check if email is well formedif (!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 lose 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 on rawpixel 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. 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 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 ⭐️ developer Lower your ego Don’t let your ego and your job title come in between the way of your learning/improvement. Care less about who you are and more about what you are becoming every day. An architect in a 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. xyz 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 docs site. Even when I am looking at this very basic example I am trying to reason out the below things in my head: vue.js Why a keyword for creating the component ? Why don’t they have a factory pattern for creating objects ? new Seems like property takes the of the element and why does it uses ? Does that mean I can add other element selectors as well such as attribute and class ? el id # seems like a very generic property name of the object, what is it trying to represent exactly? data vue 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 , , and . hackerrank leetcode topcoder 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 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. programming 🙂 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 If you liked the post do not forget to 👏 and share with other developers 🙂. Hope it was useful! Technical careers at Adyen We are on the lookout for talented engineers and technical people to help us build the infrastructure of global commerce! If you are interested in finding out more, check out , or see our page. Developer vacancies Careers
