I am working as a Software Engineer and working with team on one of the products.

While working I have developed some productivity tools and tricks which can automate some repetitive tasks and improve productivity significantly.

Now I am confused, whether I should reveal these things to peers or should I keep them secret and show my productivity higher than others?

I don't have a problem to reveal it but it will be short term recognition whereas if I keep it secret then I can continuously perform well - better than the others.


11 Answers 11


If you reveal it publicly (that is, everyone knows you have trained your peers) not only will you be more productive, but your whole team will be, and management will know why. By advancing the interests of the team and the company, you will be seen as someone making an important contribution. You're more likely to be promoted (for example, to team lead) or to be given the tricky and important projects. Your generosity will have positive consequences.

If you tell just one or two people who you happen to like, management may notice a productivity difference within the team, but their guess about why may not land in your favour. They might think some of you are just taking the easier work, or hiding your mistakes and making others deal with them, or other things that would work against a future promotion for you. What's more, the people you don't share tricks with may discover what's going on and begin to dislike you, or refuse to help you when you need it.

If you tell no-one and you're just the best programmer on your team, you may feel important and successful, but you're achieving less than you could. The true 10x programmer gets to that level by helping others to be better, by lifting the whole team.

Another thing to consider: perhaps your peers have some tips and automation they could share, to lift your skills and speed even higher than they are.

My suggestion: go to your boss and say "I have automated a few things and developed some skills with our tools that make me a lot faster than the rest of the team. I'd like to share these. Can I set up a lunch and learn and invite people to learn my tips and share their own?" This shows that you care, that you are generous, that you take the initiative.

  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Neo
    Commented Sep 30, 2019 at 12:29
  • 14
    This relies critically on the way management thinks and recognizes the sharing, but does not address that (optimistic) assumption.
    – FooBar
    Commented Oct 1, 2019 at 13:31

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.

  • 5
    If you do want to convince people that your way is better, you'll need data to back it up. People respond to that.
    – Derek
    Commented Sep 30, 2019 at 6:56
  • 10
    @Derek In my experience that's wishful thinking. There's a nontrivial amount of people who have been using the same tools for years and just won't invest the effort required to get up to date with a new tool even if there's more than enough data to show that it's objectively better. But then not really your problem in this case (in others you'll just have to deal with the resistence).
    – Voo
    Commented Sep 30, 2019 at 7:29
  • 4
    @Derek Oh I agree, my point was mostly that there's an emotional aspect here that should not be disregarded. People grow fond of their tools. It's more a problem for people having to onboard people when making bigger infrastructure changes thought (e.g. changing source control from TFSVC to Git).
    – Voo
    Commented Sep 30, 2019 at 10:04
  • 3
    @Derek I agree with Voo. For example, I HATE autocompletion (to a certain extent). It does make writting code a lot faster and is objectivelly better in that regard (automatically closing an HTML tag, closing a string, opening and formatting brackets). But I would hate to work with it and would be banging my head just to stop closing the string/tag myself. I would be extremelly disatisfied if autocompletion was mandatory from now on. Commented Sep 30, 2019 at 15:55
  • 1
    @Derek, and some people just want to do everything manually, since they don't trust automation, even though they are in the business of automation. I've gotten push back from several scripts/utilities I've written to make things faster and more accurate/reliable, simply because they've "always done" it manually. Also, autocomplete has it's place. If it gets better at placing the end tag/bracket/etc then it'll become a lot more usable. Commented Sep 30, 2019 at 16:44

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.

  • 4
    good point, and I have seen (and heard about from reliable sources) multiple times the case where a team member thinks up some innovation that will make things easier, shares it, and promptly has it shut down by someone senior. Mostly I've found this happened when the innovation 'should' have been done already by another team but wasn't, resulting in a "stay in your lane!" rebuff to the person proposing it. And you can guess what are the chances that that person, or anyone else who knows about that, will propose any more innovations... Commented Sep 30, 2019 at 18:06
  • 5
    ... in one case, the person was particularly resilient and came up with numerous suggestions for improvement/innovation which were all shot down and not spoken of again. What do you know, a few years later when they had been downsized and outsourced, most of those 'innovations' were imposed from outside consultants and then accepted! Commented Sep 30, 2019 at 18:08
  • 3
    Oof, those kinds of places are so stifling. If you're working somewhere like that, I recommend looking for a new job if you're in a position to do so. In case you need another reason: IME those kinds of places also tend to be very layoff-happy, because they treat software developers like commodities (YMMV of course). Commented Oct 1, 2019 at 6:36

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.

  • I've yet to see any example where humans don't introduce much, much more error than tools over the long run, particularly for monotone tasks. And more importantly: Tools you only have to fix once and can write tests to validate the results, for humans you just have to accept the fact that there will be a nontrivial amount of errors (and it will be the same errors over and over). And if there's need for a creative check over the data you should integrate it into the process and not throw the baby out with the bathwater.
    – Voo
    Commented Oct 1, 2019 at 15:56
  • 1
    @Voo agreed, in general. My point is that tools which have not been examined and verified to produce correct outputs can cause more problems than they solve.
    – asgallant
    Commented Oct 1, 2019 at 16:06
  • Ah I misunderstood you then, I absolutely I agree with your point there.
    – Voo
    Commented Oct 1, 2019 at 16:08

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.

  • 5
    That depends greatly on the management style -- they way well choose to keep the "top performers" without caring why they are that. Classic Wall Street management.
    – KlaymenDK
    Commented Sep 29, 2019 at 11:19
  • Or they find out and ask you to automate someone else's job into oblivion (keeping you, the expert and talented programmer around). Commented Sep 29, 2019 at 21:10
  • 1
    This is an over-generalization: have you not had co-workers that only sought to obtain your knowledge without sharing theirs? They might be the buddies of the manager. They are not going to be the ones let go first if the company hits hard times. Commented Sep 29, 2019 at 23:14
  • 4
    People will find out what? that you have some ideas that make you productive? so what? what is wrong with that, as long as you are legit & are not cheating? I agree with sharing knowledge but not for the reason given that people will find out & you would be fired... Commented Sep 30, 2019 at 12:32
  • 2
    This works in healthy workplaces, but a toxic workplace will get rid of people who are "making trouble". This could be someone who constantly "complains" about the workload, work flow, and anything else by offering suggestions and improvements all the time, "as if they don't trust mgmt to know best". Offering suggestions can "undermine" the managers "authority" at some places, so knowing your office culture is key to answering this question, as I've learned the hard way. Commented Sep 30, 2019 at 16:49

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.

  • This is a very selfish answer and can lead to the toxic workplace where sharing is not rewarded. I agree that you need to watch out for yourself, but making your co-workers more productive can get you the promotion and raise you deserve/need, as well as getting you better paying jobs later, which works in your favor better. Keeping improvements secret really only works best when sharing them is actively bad for you. Commented Sep 30, 2019 at 16:55
  • 1
    @computercarguy It is a selfish answer indeed, but many workplaces are already toxic and many people are already selfish. I can imagine situations where keeping your cards close to your chest is the best course of action. Readers in situations such as OP must judge wisely.
    – Agent_L
    Commented Sep 30, 2019 at 17:18
  • @Agent_L, yes, I agree and have said the same in comments on other answers. However, this answer doesn't make a claim on whether it is in response to an already toxic workplace, it just sets the advice out for use at anytime, presumably regardless if the workplace is toxic or healthy. That lack of stating to use this only in toxic environments is why I commented. Commented Sep 30, 2019 at 17:24
  • Being selfish will help you immediately but being generous will earn you more in long term. After all, we learn from others and let us give back something.
    – Gopi
    Commented Oct 1, 2019 at 7:44

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .