Get Yourself a Reputation at Work
For most of us, as programmers, we are a pretty lucky bunch. We get
paid handsomely (or at least nicely) for doing something which we enjoy,
will never go out of fashion and provides a great deal of benefit to
the companies we do it for, if not the world at large. While we may not
be working in the IT fields we want to be working in or for the
companies we want to be working for, we still get to enjoy the process
of writing code on a daily basis for a living.
Programmers that love to program can get this positive feedback effect
where pursuing our own interests by writing great code, solving
difficult problems and completing tasks or projects leads to an increase
in our productivity for our clients or employers. In turn this
increases our value to them and if you are lucky, is reciprocated back
in some way.
The game is afoot
Sites like Stack Overflow incorporate gamification
so you can build up reputation points and earn awards as a record of
your status within the site in order to keep the users engaged and
coming back. While nobody is handing out points at work, you can do the
same thing by building up your reputation as someone who is
knowledgeable and able to get things done.
Now obviously, everyone wants to get involved with a new project, its
like a newborn that has been untainted by horrific decisions, bad design
and sloppy coding. However, from over 15 years experience, when
something unexpected goes wrong, usually they are just waiting for
someone to pick the ball up and run with it. That is the opportunity to
step in and find out what you are made of.
Work hard enough and you’ll hit that sweet spot where you become the go-to guy for certain topics. Sometimes the problems can be difficult, but treat these things as a puzzle, as a challenge to be met just like an athlete rises to the challenge of that additional mile or extra weight.
Do it well enough and people will notice, do it long enough and you’ll get a reputation.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
Balázs Bessenyei replied on Tue, 2012/05/01 - 8:48am
A very good article and advices.
However there is one addition I have to make. Make sure to avoid the situation where you are the only specialist on a given field and trying to live from that (unless you are the DBA). A narrow specialization on a topic allows you to sit back and relax while forgetting how to evolve and to learn new things.
I`m working on a projects with 160+ developers and testers, organized into 12+ SCRUM/Kanban teams (by feature groups and functional areas) over 4 geographically distributed locations.
Recently the company had to get rid of 2 colleagues each of them over 20+ years of experience, because of this.
Which was a sad day, but a good learning experience that attempting to survive leaning on narrow fields specialization only works for a limited time. Till the knowledge stays relevant or (forced to) move to a new company/project.
In one of the above mentioned cases, moving partially from SQL (iBatis) to NoSQL (Lucene, Casandra) and thread-safe, highly concurrent programing was the cause of his downfall. Even the iBatis based DB layer remained virtually untouched in the last few years.
In the other case, he was obsessed with catching up with new technologies, that he ignored most project related responsibilities. In a project structure where even the architect, and his SCRUM team, codes as well (new generic components), proved to be a suicide.
In short have a few fields where you are the expert, but do not stay there; evolve continuously with the languages you are using and with new technologies. If the daily work does not provide enough opportunities then either switch or spend free time. Since wasting project time on self development can hazardous on long term employment.
Mohammad Haq replied on Tue, 2012/05/01 - 4:29pm