How to Stand Out at Work: 10 Tips for Programmers (Part 1)
How to Stand Out at Work: 10 Tips for Programmers (Part 1)
Join the DZone community and get the full member experience.Join For Free
Is the concept of adopting a continuous everything model a daunting task for your fast moving business? Read this whitepaper to break down and understand one of the key pillars of this model in Continuous Governance: The Guardrails for Continuous Everything.
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!
Opinions expressed by DZone contributors are their own.