How to Stand Out at Work: 10 Tips for Programmers (Part 2)
This is the second 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 part here: How to Stand Out at Work: 10 Tips for Programmers (Part 1).
We’ve already reviewed 5 items, so let’s continue with the number 6:
6) Try to give realistic estimates
Giving too optimistic estimates is a common problem for many programmers. In my opinion, there are two main reasons for this:
a) We often forget to take into consideration the time that we’ll have to spend:
- dealing with some unexpected issues during the implementation phase;
- testing the implemented functionality on the development environment;
- writing unit and integration tests;
- distracting to other high priority tasks that show up every now and then.
Just remember about these things when giving an estimate.
b) Sometimes we’re kind of uncomfortable giving a true estimate, because we think it might look a bit scary to the manager. In such case I usually divide the feature into a few sub tasks so that the total estimate doesn’t look so scary.
Too optimistic estimates in most cases have the same sad result: you have to move the task to QA in a buggy state, justifying it to yourself by thinking: “normally the QAs return the first version of any developed functionality with a list of their remarks back to the developers, so I’ll still have a chance to fix all those bugs”. But it won’t be like this in the case of a realistic estimate.
7) Test, test, test!
While many programmers are forced to move the developed functionality to QA in a buggy state because of wrong estimates, some other developers, surprisingly, close their tasks way before the deadline, when they aren’t rushed to do so. They wish to demonstrate their high performance, which is a good intention, but, unfortunately, which doesn’t often give them much credit in such cases. Remember that it’s better to test the code more thoroughly but only once rather than come back to it several times, each time reviewing the same methods to recall the business logic behind them.
Moreover, the Continuous Integration methodology, which implies deploying the code to production up to several times a week, is quite popular nowadays. If it’s used in your company and you commit buggy code, in the best case QAs find your bugs, return the story back to you and start rushing you, since your buggy commit blocks the production deployment; in the worst case your buggy code is deployed to production.
Let me also stress out the importance of unit and integration tests. They are the first indicator of a regression: a change that breaks some existing functionality. Unfortunately, some people write tests for the only purpose – to avoid the blame for dropping code coverage. It results in tests with, believe it or not, no asserts at all or with a “slacker’s” favorite assert: assertNotNull. Such code needs to be caught and rejected during code review, which is another good method for increasing code quality.
8) Remember that all of us make mistakes
Do you enjoy working alongside programmers who search for a person to blame rather than for a solution (and sometimes point their finger at you) when a problem occurs? Me neither. But unfortunately, sometimes we look like them, even though we don’t realize it. Here are a couple of suggestions for avoiding such situations:
- If you work on some functionality with your colleague and there’s a delay on his side, instead of blaming him in front of your manager, try to help him out, or at least go together to your manager and ask for help. Remember that it’s your problem as well, since both of you are responsible for the whole functionality to be delivered in time.
- When you’re fixing a bug and discover that it’s, say, John’s code change that caused it, it doesn’t mean that you have to mention this in the company skype channel to all of your colleagues. Remember that all of us make mistakes and this might happen to you as well. Sometimes you might come across a block of “ugly code”. Same here – there’s no reason to let everyone know about its author.
- If you’ve developed a bad opinion of one of your colleagues, it doesn’t mean that you need to share it with your colleagues and especially managers, unless you’re asked to. Be sure – your manager knows perfectly well the strong and weak sides of each developer he’s managing and he doesn’t need your suggestions.
In contrary, if you think that one of your colleagues did a great job – try to find a way to inform your manager and colleagues about it. For example, a few weeks ago one of my colleagues had to drive to the office at 7am to temporarily run one of our production application modules from his laptop. Of course, he deserved at least a few grateful words from us in the company skype channel.
9) Promote strengths of your company in social networks
Nowadays every programmer uses social networks. Ok, almost every. In fact, believe it or not, I know at least two talented developers who ignore all kinds of social networks. While I can understand them not using Facebook, since it’s considered a personal life-related network, I don’t see any reasons to not have accounts in the business-oriented networks like LinkedIn and Twitter. Many new career opportunities, lots of technology- and business-related stuff pass you by if you’re not there.
Take a closer look at your company: sometimes it probably organizes technical seminars, sponsors conferences, participates in business summits, publishes blogs, searches for new developers etc. Why not tell about it in your social networks? It doesn’t mean, of course, that you have to spam in your networks by liking and retwitting all the news that your company publishes – share just the ones that you indeed like. Besides, there’re many web sites where developers post reviews of the companies they work for. Why not write one about your company? You don’t have to lie, of course. Highlight the things you do like in your company.
By the way, did you know that one of the easiest ways to talk to a company CTO or CEO nowadays is via Twitter? :)
10) Small tips and tricks
Finally, here are a few small tips & tricks that can help you deserve a good word from your managers and colleagues:
a) Adjust to your employer’s time zone
Lots of programmers from Europe and India work remotely for US companies with most of their management stuff and many senior developers located onsite, in their US headquarters. In such case, those programmers who reserve at least 1 hour of their evening time for a discussion of current issues with their US colleagues have better chances to do their job well than those who leave for the day at 5pm their local time.
b) If asked, help your company on weekends and holidays
Let me give you an example here. Our production system is monitored 24/7, because a problem might occur at any time of the day or night and there should be a person who can take care of it. Normally our regional office programmers are asked for assistance only during our working hours. But last year we were asked to be on duty during the New Year holidays. I had to take December 31 – not the best day for resolving production issues, eh? Of course, I could have said no, but I agreed. Luckily, there were no alerts that night so no one called me and I had a chance to celebrate the New Year in a normal atmosphere. So, in fact, I did nothing work-related that day, but still deserved credit for being ready to help.
c) Participate in job interviews, conducted by your company
If you have a chance to participate as one of the interviewers in a job interview, be sure to utilize this opportunity, because it’s an invaluable experience. First of all, you develop your communication skills – a thing many programmers lack. Moreover, if there’re several interviewers – it’s always interesting to listen to your colleagues’ questions. Finally, your opinion on the interviewee will be taken into consideration, which is especially important if this person is going to work in your team.
That’s it for the second part of the article. In fact, as I was writing these 2 articles, I came up with a few more tips that can be added to this list. So, I decided to include them into the 3rd “bonus” article. Thus, stay tuned!
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)