By following the rules
below who knows, you might end up being the favourite of your boss and the
centre of attraction in your organization.
1) Don't hesitate to ask questions
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 behaviour in this or that
particular case.
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.
It’s better
to do the opposite – choose a project or a feature that’s not known by many
other fellow developers. Spend more time getting familiar with the business
flow and existing code. And later on, when you know the module well enough, it
turns out that 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 you can
be asked to implement many of them as well.
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, assume the following application modules:
1.
a module that interacts with social networks and collects data;
2.
a module that processes all the collected data;
3.
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 behaviour
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.