How to Stand Out at Work: 10 Tips for Programmers (Bonus Part)

This is a bonus part of the article in which I’m sharing a list of simple tips that, in my opinion, can help programmers succeed at their current workplace. You can read the first two parts here:

As I was writing these 2 articles, I came up with a few more tips that I decided to present to you separately. Here they are:

A) Invest in yourself

We have chosen a difficult profession. While people of many different occupations have the luxury of working 8 hours per day and forgetting about their work just after leaving for the day, it’s not the case for programmers. We often have to think about our job while commuting, in the evenings and on weekends. In addition to doing our job well we should also follow the new trends in our industry and keep learning during all of our live. Otherwise, when the project we’ve been working on for a couple of years finishes, we might realize that we’re stuck with the technologies that became less popular and it’s not that easy to quickly catch up with the market.

Luckily, there are a lot of great online resources we can use for keeping up with the newest technologies. Let me name a few of them:

Attending technical conferences and user groups is another great opportunity to learn new things. I was surprised to find out that some programmers grudge spending a couple of hundred dollars on a conference or an on-line training. First of all, you can always try to ask your manager to sponsor you, since the things you’ll learn might come in handy for the company. But even if the company doesn’t do it – go ahead and pay by yourself, it’s worth it!

B) Deliver

A couple of months ago I came across a photo of a poster located in the Facebook office that read: "Done is better than perfect". Great phrase! Indeed, many developers suffer from a so called "perfectionism issue". Such people will rather postpone the production deploy than let a couple of minuscule issues sneak into production environment. The problem is that “perfect” is something unreachable. There’s always some room for improvement, so it’s important to be able to say to yourself at some point: that’s it, that’s enough. A different issue is that some developers loose enthusiasm when the feature they are working on doesn’t meet the deadline and gets postponed. They mistakenly think that it becomes less important for the company and switch to a different task, which is of course wrong.

Sometimes, when modifying or extending some functionality, you might come across an unexpected existing bug. If this is the case, be sure to create a separate ticket for it instead of fixing it along the way. Remember that fixing other issues takes your precious time and might affect the delivery date of the main functionality.

Finally, documenting your functionality helps to avoid misunderstandings regarding what features it includes and how the business flow should look like in different use cases.

C) Go an extra mile in terms of quality

I’ve already stressed out the importance of testing the developed functionality on your local environment as a user as well as with the help of unit and integration tests. Here are a couple of more quality-related suggestions that will help you to go even a bit further.

First of all, as it was mentioned in the previous paragraph, when noticing a bug in the existing functionality be sure to take a couple of minutes and file it in you bug tracking system. This seems obvious, but I noticed that some programmers don’t do this because they think it’s the QA job to find and report bugs. Others just inform their colleagues about the found bug in the chat room and their message quickly gets lost.

Besides, some people, when unable to reproduce the issue on the local or testing environment, simply move the ticket back to Ready (which means anyone else can pick it up). Instead of doing like this, first, spend a few minutes and consult the person who created this ticket or at least leave a comment saying that you weren’t able to reproduce it, so that the next person who picks it up reads your message before repeating the steps you’ve already done.

Sometimes the problem might be related to a third party API your application is using. For instance, I don’t want to blame Facebook, but their Graph API is just buggy. Every now and then some of its functionalities either stop working or start returning unexpected results. So, in such cases be sure to go to their support page and report a bug if no one has done it yet.

D) If possible, delegate part of your work

If you’ve been working in the same company for a couple of years and your team continues to grow, there’s a chance that one day your manager will ask you to introduce your new colleague to the project and to be the first point of contact for him during the first few months. Many developers don’t really like it, because such help usually takes time and it becomes harder for them to meet the deadlines with their own tasks. In many cases they ask this new person to spend too much time reading the documentation and fixing some very simple bugs, so that they aren’t distracted that often. But, in fact, this discourages the new person and slows down his familiarization with the project.

In fact, I’d suggest considering this a good opportunity to delegate part of your work to this person and to quickly involve him into the real project live. This is especially handy when you’ve got too much on your plate. Some developers think that no one else in the world is able to cope with their tasks, which is not true, of course. Moreover, this is an opportunity to develop your management and communication skills, since this person will be reporting to you and asking for your consultations and suggestions.

Recently I have experienced such situation: a new developer started working for our company and I was asked to give him a few first tasks and provide some assistance. I had a lot of work on my plate, so I just introduced him into what I was doing and started delegating some work to him. In a few months he was already able to work on almost all tasks related to this module.

E) KISS (Keep it simple, stupid)

The KISS principle is in fact applicable to many real life aspects. In this paragraph I’d like to outline how to adjust your behavior according to this principle.

Whenever you ask one of your colleagues for a suggestion, consultation or help, be sure to mention that his opinion is very important to you. Besides, don’t feel uncomfortable admitting that you don’t know something. Remember that no one is perfect. I experienced such situations many times in my life. Once I was given a Big Data-related task, which involved Hadoop and Pig Latin technologies I knew nothing about. I asked one of our Big Data experts for a consultation and the first question he asked me was whether I used these technologies before. I didn’t know what to answer. On the one hand, I was afraid that if I say that I don’t have any experience with these technologies, he’ll suggest my manager to ask someone else to do this task. On the other hand, I didn’t want to lie. So, after a short hesitation, I admitted that I didn’t have any experience with these technologies. To my surprise, he just said that this is not a problem and along with the consultation provided me with a few links to a good documentation and best practices on these technologies.

Finally, remember that it’s ok to hesitate before making a decision. Intelligent people often hesitate, since they understand that they might have not taken into consideration some better approach or solution. So, it’s not a weakness to ask your colleagues’ opinion or advise before making a decision.

That’s it! I hope you found these 3 articles useful and you now know what to do to stand out at work!