Bsrgvty

I agree with almost all points given in Kate Gregory's answer but would suggest two minor changes:

First, I would not say "make me a lot faster than the rest of the team" (even in case it's true). I would go with "increase my productivity significantly".

Second, I am not the biggest fan of "lunch and learn" (even if it counts as worktime) because many people enjoy talking about things that are not work related during lunch for a change. So I would just suggest a normal meeting during worktime.

However, that is merely nitpicking, I think Kate Gregory's answer is sound advice.

And another aspect: Don't be too disappointed in case some of your colleagues are not as enthusiastic as you might expect: Some people do not appreciate changes in their normal workflow or maybe they have other reasons to not use the suggested tools. So offer them your advice and be supportive but do not pressure them to use your approach.

I would think twice before sharing.

1. For all you know, a lot of people are using these tricks.


2. Does your manager typically appreciate clever things?


3. Is your manager likely to share credit for your innovations with you?

A lot of the people on stackexchange work in places that do reward innovation, automation and teamwork, but not every workplace is like that. You are posting here because you have a doubt that sharing will be beneficial.

It really sucks to share clever innovations, only to make your boss feel stupid and get punished for it.

Kate Gregory gave an excellent answer, but I'd like to expand on it with an additional reason to share: the peer review process. Your tools might "automate some repetitive tasks and improve productivity significantly", but what if there is an error in those tools? What if there are good reasons to do something manually?

Speaking from experience, I did the same thing you did (a long time ago). I wrote some tools that automated the most boring and tedious parts of my job (the data entry portion of a data analytics internship). The tools sped up my productivity, allowing me to process in an afternoon the same workload that it took others weeks to enter by hand. I was proud of my toolset and shared it out with the rest of the team, and good thing I did: there was a critical bug that scrambled data between two fields that would have completely invalidated research results derived from the data. If I had hoarded my tools to myself (and by extension, made myself look like a productive rockstar), I would have caused immense damage to the data sets and forced all data to be extensively rechecked and reviewed for accuracy.

Share your tools, and be prepared for someone to tell you that you did something wrong, or could do something better, or that your tools are not appropriate for your particular tasks.

People will find out. And if a company needs to let go someone, it will be the ones who focussed on looking good at the expense of others and the company. So once your manager finds out, you're in trouble.

Best to publicly make the whole team more productive. But then you didn't mention in which country you work, so it might be different.

The biggest thing you need to weigh in on is,

1. Are you looking to advance the company


2. Are you looking to advance your career.

A lot of these answers are, do what's best for the company, not what's best for yourself. If you keep these tricks to yourself and it gains you 10,000 dollars in a salary bump for being the most productive dev in your company, or if you share it, it could save your company 10,000 in expenses, which do you do.

It depends on your life views, either way is completely fine.

Share them when you have been promoted. Then your team will look good compared to other teams (of course, with time the knowledge will spread).

I don't agree with most other answers. You will get credit for sharing your tricks but it will be forgotten the next day.

What about working gradually? This is what I would do:

I start by sharing one or two tips/tricks to the rest of the team, and check their respnse: someone might say "Hey, that's a neat trick you teached me. Let me teach you something that you didn't know: ...". If you have colleagues like this, you continue sharing your tips/tricks. If, however, they don't share anything in response, you have no reason to share anything in future too.

IMHO, you will have to know your environment and play by ear. I have worked in places where there the atmosphere rewarded sharing ways to make work better and others that, well, didn't. A variation of the later group would be working with someone who will take your trick and then go to your boss and convince him about some "improvements" in a way that your boss puts him as the project manager of your improvement.

Yes, that happened to me before.

So, consider your corporate identity, timing, and your team dynamics. And be mindful of your team. As mentioned above, you might get shot down not out of malice but simply because the team is too stuck in its old ways to try your optimization ideas. I worked with a project manager who thought having a repo (even internal) was witchcraft (I was taught in kitty school to develop, update repo and then deploy from repo), instead filling his local drive with copies of his work. As he outranked me, arguing with him would quickly become a career-ending move.

With all that doom and gloom out, you could test the waters with something simple and see how it goes. You can also clean up (by that I mean make it generic without referring to your work, so others can use it) your tricks and put them in your blog. You would still be helping others but would also be helping yourself. Don't feel ashamed of building your own name.

Here is an argument about sharing: don't be a hero; business should not be run relying on heroes. Making yourself essential for only you can solve some problem may make it harder for you to be promoted.

Another thing you should consider about sharing: whatever knowledge you share is time limited, as in once you do it, move on to new things. Use the tool/techniques and share them if you will, for next week you might come up with something new. Don't rest on past glories. Teach others so you can move on.

I know my reply does not make a good case for either sharing or not sharing, but that is on purpose: there is no absolute right answer. The best answer should cater to your situation.

Say you have a task that takes 12 hours. You spend 20 hours developing automation that reduces this to 5 minutes of work and 4 hours of "monitoring". There is ROI to be considered. It may take 2 hours to train someone else in the use of it.

By all means share, but within a trusted circle, don't let a peer work without knowing about "global updates" for instance. Especially if you are doing something wrong (cloud, outsourcing, pirated software).

There are two ways that this can go down. If your team is semi-autonomous (Agile ?), it is shared within the team and a one pager is written. The client is never told, you accept the maintenance costs and continue to bill 12 hours to the client.

If management becomes aware, and your organisation is anally retentive on the procedural side (CMMI level 5?). Then you will probably be forced to sign it over and spend the next three months documenting the procedure (and making it "compliant") to the point where it now takes 10 hours, plus additional processes to measure the benefit by means of various metrics that another FTE is required to measure and tabulate. Once this desk manual is written, the task can be reduced to a ticket sent to a "shore of convenience".

Oh, and of course if someone else can do harm with your shortcut, where will that leave you when the blame game starts?

I am reminded of the anecdotally recounted discovery of being able to line up and flash the generator magnets (to make them strong again) on the model T Ford. It saved absolute hours, is a method still used today on older cars, but early on the customer was still charged the scheduled fee.

Your customers may not be stupid. They might also expect these improvements to have been obvious, and it won't be pretty if a competitor fingers you for over servicing.

What do you mean by reveal? Are people asking you "how are you so fast?"?

Whatever you do, do NOT impose your productivity tricks on others because it will make people not want to work with you.

My personal productivity tricks involve using my keyboard to quickly navigate my OS and do mundane things like switch windows, close things, open other things, perform complex searches, etc...

Whenever another programmer is standing next to me while I work out a problem they are always impressed and jealous. However, they never ask me to teach them. Trying to copy what I do can prove harmful to them and their productivity so I make a point to never impose and I certainly do not interject when I watch them use their computer "slowly".

Bring up your "tricks" with your manager because it's very possible that your tricks need to be vetted or at least well documented if you expect your team to adopt them with any level of uniformity.

No, you should never reveal your productivity tricks to your peers. But you should reveal them, little by little, to your direct reports.
Your ability is a form of power. Before giving power away in an organisation, first make sure you can trade it with other power. Otherwise, you will just make your own position weaker in the organisation. It's algebra, really.