DevOps Zone is brought to you in partnership with:

Grails Developer Yuriy has posted 3 posts at DZone. You can read more from them at their website. View Full User Profile

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

05.10.2013
| 58303 views |
  • submit to reddit

I’ve been in the IT industry for almost 8 years working in 4 different companies. During this time I had a chance to work with a couple of dozens of programmers. They were different. I observed some of them successfully developing their career; some were satisfied with their position and continued working many years for the same company performing similar tasks; a few have been fired. Based on my observations I came up with a list of tips, which, in my opinion, can help programmers to succeed at their current workplace. Here it is:


1) Don't Hesitate to Ask Questions

I noticed that some programmers hesitate to ask for help from the very first days in the company, e.g. when they encounter problems with the project environment set up or when they work on a task but don’t fully understand the business flow behind it. It’s not a big deal – just ask for assistance or clarification. Otherwise you’ll waste a lot of time struggling with a typical project-related problem or guessing what should be the correct application behavior in this or that particular case.

Another problem is hesitation to ask questions even when you’re expected to do so. For example, last year a lead developer and a manager of our company were visiting our regional office to get to know us (developers) in person and to give a few presentations. They asked us to prepare a list of topics and questions we’d like them to present and clarify to us. I was surprised to see that only a few people contributed to this list, although the range of possible questions was unlimited, from “why are we using a NoSQL database in that particular module” to “what features of the application are the most popular among our clients”. Don’t be afraid to ask questions, especially in such cases.


2) Search for a Niche

It often happens that several company projects or project modules lack resources. This means that either when you just start working for a company or finish your current project, there’s a chance that you’ll be able to choose or at least let your manager know about your preference project- and task-wise. Many people tend to join the newest project or feature. Some prefer to join a team, where a few of their close colleagues already work.

In my opinion, it’s better to do the opposite – choose a project or a feature that’s not known by many other fellow developers. When I had such choice, I’ve chosen a task from a module only 1 person specialized on. Initially I had to spend more time getting familiar with the business flow and existing code. But later, when I already knew the module well enough, it turned out there’s a lot of new stuff to be implemented in it. More and more new features have been requested by the managers. Not surprisingly, I was asked to implement many of them as well as was one of the first points of contact for developers, who started getting involved in this module after me.


3) Get Familiar with the “Big Picture” of the Application

Nowadays almost all of the enterprise applications are fairly complex and consist of many modules that might be using completely different technologies. For instance, the current application I work on consists of 3 parts:

  • a module that interacts with social networks and collects data;
  • a module that processes all the collected data;
  • a UI module

Each of the modules is developed and maintained by a separate team of developers. The modules are different technology-wise but related business-wise. This means that whenever a new feature is introduced, it affects in most cases all the 3 modules.

There aren’t that many people, though, who understand the whole business flow. So, whenever a new feature is discussed, the managers tend to involve people who can make a top level assessment of changes that will be required in each of the modules. So, if you know the big picture, you have a better chance to get involved in such discussions.

Besides, when you know the big picture, you understand the kind and complexity of tasks that are being performed in each of the modules. Thus, there’s a chance that some tasks and technologies, used in one of the modules, will become particularly interesting for you. Remember that it’s much easier to switch to a new technology within the company where you’re already considered a senior developer, than to start searching for a new job.


4) Do What You Need to Do, Not What You Like to Do

Some very talented programmers suffer from a serious issue – they have a specific field of interests and whenever they’re asked to do something different, they show poor performance and quality, because they can’t concentrate on the stuff they don’t like to do. For instance, people might love experimenting with Scala, but have to deal with Hibernate or native SQL; they might love concurrency, but have to assist with the front end-related work.

If you’re one of such programmers and have to permanently deal with the technologies that you can’t stand – you probably need to change the job. Otherwise, if you just temporarily need to help other developers in the areas you don’t really like – you have to show the professionalism and do a good job anyway. Just remind your managers about your preferences, so that they don’t ask you to work on that stuff too often.

The same is applicable to the tasks with different priorities. It might sound obvious, but remember: you have to pick up the one with the higher priority, even though the one with the lower priority looks way more interesting to you. Be a professional!


5) Share Your Knowledge and Help Your Colleagues

Have you ever encountered colleagues who are way more productive when working alone? This might be an indicator of poor communication skills. Sometimes it gets even worse – believe it or not, some developers don’t really want to share their knowledge. Kind of a selfish attitude, eh? Such people wish either to be irreplaceable or to make sure their colleagues face all the issues they had to face to make their life as hard as their own. No wonder that such behavior gets noticed fairly quickly by fellow developers and managers and doesn’t give any credit to such “lone wolfs”.

Moreover, when you’re working in a regional office, remember: if one of your colleagues doesn’t do his job well, the whole office suffers in terms of reputation. So, if you can help your colleague – just do it, it’s a win-win solution.


This was the first part of the blog. In the next part I’ll describe another 5 tips that can help you to stand out at work. Stay tuned!

Published at DZone with permission of its author, Yuriy Lopotun.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Andreas Schilling replied on Fri, 2013/05/10 - 12:57am

Nice lineup.

I'd say if you do 3), 4) and 5) correctly (and probably more or less in that order...) than you soon reach the state where you don't need 1) anymore (or only rarely) and can focus on important things and 2) :-)

Vishal Jain replied on Fri, 2013/05/10 - 8:12am

Nice tips !!!

Keuller Magalhães replied on Fri, 2013/05/10 - 11:30am

 I agree. Developers should follow these tips!

Lund Wolfe replied on Sat, 2013/05/11 - 6:44am

Not asking questions is an extremely common problem.  I think it is mostly because programmers are proud and afraid to admit ignorance (an upfront failure) in any form, even though this is how we learn and grow.  Asking questions is often just being efficient/expedient and reducing risk and others are usually glad to help.  Questions are often less about technical knowledge and more about company specific environment, process, or apps/infrastructure, so pride has nothing to do with it anyway.  There is definitely no excuse for not getting the correct project requirements or digging to find out where you can get them.

There is also the distrust issue.  If I don't know a tool or framework I'll learn it on my own: online, from a book, or from experimentation.  This is very understandable, since other programmers who have knowledge and experience with a subject often don't know it well and are a poor source of advice to someone learning the fundamentals and core best practices.

Lion Libaax replied on Wed, 2013/06/05 - 1:56pm

Nice points, but there is also the company culture and racism.  I have seen some people who always do all those points and more, but  they have never been recognized for their contribution and commitment.   In my observation, know your company culture and your manager  very well  and act accordingly.  Just know that we are equal but not equal

Raffi Basmajian replied on Thu, 2013/06/06 - 10:07am

If you're clever, you can take #4 and make it work in your favor while benefiting your company at the same time. For instance, lets say you enjoy playing with mongodb, but your company isn't doing big data and doesn't seem interested in it. Develop a value justification and present it to your team on why they should use mongo and how the firm could benefit from its use. If they go for it, it's a win-win for all; if they don't, at least you'll be viewed amongst your colleagues as someone takes initiative and promotes new ideas, and that's a good quality to have in any regard, not just in the office.

David Altenhoff replied on Fri, 2013/06/21 - 5:19pm

 #1 often tends to be frustrating because so few IT people are any good at #5. Only a few IT people are any good at explaining new concepts to others. Some perhaps just assume that you know more than what you do. Some don't want to take the time. Some are protective of "their" area. My experience is that you are likely to get more good information out of non-techies than techies. <br/><br/>

When asking questions of techies, my strategy is to learn as much as I can about the concepts/technologies first. Then hit them with as many *specific* questions as possible. That way they can't tell you, "Um, you can just look at the code and kind of see what's going on."

Mike Miller replied on Mon, 2013/07/22 - 11:57am

 Good comments.  I struggle with #4 all the time!

Mono Polos replied on Thu, 2013/11/07 - 5:25am

Yes I am totally agree  with you to improve company and human productivity


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.