We are a small team of developers working on a single multiplatform project (Web, Mobile and PC). One colleague in particular is in "charge" of the mobile application. I quoted that as he is not really in charge but simply the only one working on that project as per the higher ups choice. We have planning sessions at the start of each development cycle and for the sake of this post I will try to describe this as simple as possible.

Out goal is to go from point A(user starting app) to point B(app shows main page with data). But between these points we have a crap load of data to load which is partly grouped. enter image description here enter image description here

I immediately recommend going for partial loading(async) as to speed up the start of the application and improve the user experience.
enter image description here

My colleague starts spitting "facts" about how he can't do that, his dev env doesn't allow multi threaded work on mobile phones and other similar "fact" sounding stuff to our mostly code illiterate superiors. This in fact is just a cover up for the lack of knowledge about asynchronously running code.

This in the end results in us using the synchronous way and getting 10-15 seconds of startup time, which in turn gets the superiors attention and a meeting is scheduled to discuss this problem. He still adamantly states that he cannot do it because his tooling/dev env is limiting him and this really starts pissing the supes off. Eventually he actually starts learning about async code and finally implements it after like 6 months of development. All of a sudden it is a miracle, he basks in the glory of the async knowledge as he claims a new version of his IDE allowed for this to happen.

The problem:
I mostly feel discredited and demotivated by this as it was originally my idea that I could actually implement and shorten the development of this application by a mile. He takes all the credit but based on fiction and deceit.

Should I just keep quiet and let it go or should try to document stuff like this and then point it out to my superiors?

  • He wrote his own code on the mobile platform, right ? and you wrote your own code on the Windows/PC or Web platform, right ? And you gave him the initial suggestion that using async is the best way to go, right ? - Then, you deserve some credits for the initial suggestion to him, and he deserves credits for writing code for mobile. He should have given some credits to you by telling boss about your initial ideas. But, I think you should let it go for now. This is no big deal as the boss knows that the Windows and Web platform already uses Async before the mobile does. Commented Dec 3, 2023 at 10:34
  • There will be more chances to solve more challenging issues and designs in the future. If you consistently perform well on these new tasks, the boss will notice automatically. Commented Dec 3, 2023 at 10:35
  • Any reason why you couldn't have implemented the solution? Was it solely his job? Commented Dec 3, 2023 at 15:35
  • @SybillePeters actually it was his sole job to do this as we were preoccupied with the other platforms.
    – CodeJunkie
    Commented Dec 4, 2023 at 7:21
  • I recommend privately suggesting your superiors that they should fact check what he says with other developers, by googling it, or just by asking on stackexchange (probably softwareengineering.stackexchange.com) . If it's just you they can dismiss it, but if they do any research they'll realize how inept your coworker really is.
    – yeerk
    Commented Dec 8, 2023 at 22:44

4 Answers 4


"A new version of his IDE" gave me a good laugh. That aside, don't do anything. The code issue was solved, your coworker did the research and implementation on his own, and he probably learned at least a small lesson about not trying to show crap to the higher ups and saying it's good.

Now, speaking about how you could have done things better, it sounds like you didn't make your voice heard. If you knew a better way to do something that your superiors were complaining about, you should have been going to your superior and raising that issue. If your coworker is spouting total crap that you know is crap, like "my dev env doesn't allow multithreaded work on phones" or whatever, then you need to be raising that issue as well. You're in an environment where your superiors are relying on you and your coworkers for your specific technical knowledge to make informed decisions. If you don't inform them otherwise, then they're going to take what your coworker says at face value.

The sliver of justice you can get here is that with his attitude, it sounds like your coworker will not do well. Keep improving your skills and expanding your expertise, and you will rise above him in no time. Anyone who is that resistant to learning even basic skills like writing asynchronous code is not going anywhere.

  • I will accept this as an answer as it made me realize it was partly my fault that that kind of structure made it into production in the first place.
    – CodeJunkie
    Commented Dec 3, 2023 at 11:37

Did this have any actual impact on you beyond frustrations that it could have been achieved quicker/easier? In the grand scheme of things this is a major problem for management and the company that just wasted months having a worse user experience and development costs being wasted, but it doesn't sound like it's much of a problem for you unless you make it one. You can make it your problem and choose one of many different ways to change your work environment but all of those changes are going to introduce more active conflicts into your work life than just letting him have his "win" in front of the superiors.

Also if the timeline of him not knowing about async, eventually learning about it and then implementing it is so clear to you, I feel like there would have been a time and place for you to set your foot down and say that it very much is possible on a technical level. It would also go right above the superiors heads, but then it's at least on record that you claimed it's possible. If they don't remember it or it's not documented in writing, it is what it is.

If the only problem is that you didn't get the proper credit for suggesting this idea earlier then your colleague, let it go. Nothing good will come from fighting this in hindsight. Just make your position very clear during the planning sessions and leave it at that. Any other problem is really the superiors problem and not yours (and your colleagues problem because this will not be the last time this happens, and over time they'll notice that things that were claimed to be "impossible" suddenly work)


Let it go, you lost this round. Any action you take in this case will not improve your position. It is better to wait till the next time this person causes problems. At which point...

it is easier to ask for forgiveness than permission.

If you know the technological solution that will make the higher ups happy and your coworker says it is impossible, then make a prototype that demonstrates it is in fact possible (without asking permission). Then take that prototype and present it to a meeting with the higher ups (bonus points if you can conveniently forget to invite coworker to said meeting). At this point the higher ups have two things on their plate: an employee who says it cannot be done and another who has proactively demonstrated and proved it can be done.

At which point rinse and repeat every time coworker throws up roadblocks that are not legitimate. It is important to still listen to your coworker's concerns, they may raise a problem that you did not think of that would render your solution problematic. Assuming the company is not dysfunctional and your coworker keeps creating barriers, eventually the higher ups will conclude where the problem is and remove it.

  • This seems rather hostile towards my colleague and I feel it would probably create a bad atmosphere in the team. IMO everything should always be done transparently
    – CodeJunkie
    Commented Dec 3, 2023 at 11:33
  • @CodeJunkie When someone is acting as a blocker and is not providing any valid reason for said blocking then they are already acting hostile. In such situations not engaging with them and sidestepping them is one of the least hostile actions that can be done.
    – Anketam
    Commented Dec 4, 2023 at 12:01
  • Oh, and your coworker has not been acting transparently up to this point, and by doing so has already created a bad atmosphere in the team.
    – Anketam
    Commented Dec 4, 2023 at 12:04
  • 1
    Even more reason why doing things transparently is the only way to go. There is no need to worsen the situation by going behind everyone's back. This needs to be pointed out in front of everybody so no one attempts/makes the same mistake again.
    – CodeJunkie
    Commented Dec 4, 2023 at 12:15

Is your manager also part of such development cycle alignment meetings? If so, the only thing you can do is to make sure your manager is aware of your suggestions and just keep it as it is.

As long as it has no negative impact on your own work I wouldn't care about it further, if you coworker needs this to feel good about himself then let him be. It's likely you will meet more people that do this in your career and it's up to you to decide how this affects you.

As far as confronting your coworker about this: I doubt you would get any positive effects from calling him out on taking credit for your suggestions, I'd say chances are it may backfire on you (best case it would cause a discussion where it's your word against his).

What you could to is talk to your manager about architectural ideas you have and see if there's merit in creating a lead software developer/architect role in your company. This would not only open up an opportunity for you to grow into a new role, but can also give you mandate in not approving his design/plan to begin with.

Bonus idea: suggest to do code reviews as soon as possible. You don't need to be a lead developer/architect for this. This gives you the platform needed to give feedback and opens up the way for discussion at the right moment. Such a feature wouldn't make it into production because it wouldn't even get through code review, meaning he will not get credits for improving the mess he caused himself.

You must log in to answer this question.

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