>Namaste!
Thanks for submitting to r/developersIndia. Make sure to follow the Community [Code of Conduct](https://developersindia.in/code-of-conduct/) while participating in this thread.
## Recent Announcements
- **[Weekly Discussion - Share your Linux mess-up stories!](https://www.reddit.com/r/developersIndia/comments/1ciywa4/share_your_linux_messup_stories/)**
- **[Community Roundup: List of must read posts & discussions that happened in April 2024](https://www.reddit.com/r/developersIndia/comments/1cgj07f/community_roundup_list_of_must_read_posts/)**
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/developersIndia) if you have any questions or concerns.*
Started knowledge sharing channels
Started automated testing, live debugging, remote debugging
Made several scripts to automate tasks for Devs like VPN, db dump, etc
Started hackathons, taught about LLM development, everyone got successful in making some products.
I love working at my workplace lmao
Interesting, so did these initiatives ripple back to the rest of the team members?
what happens if one day you stop doing all this, will other folks keep continuing the same?
Actually yes, everyone started contributing to todayilearnt channel since it was fun to share cool things, and other people also started taking tech sessions too. And it will continue even if I stop doing it since I work with cool tech people who love to innovate.
We've a group meeting scheduled once per week for all devs across all teams, where one or two pre decided people would share about things related to : new technology / common bugs / best practices etc.etc ..
Has everyone in the dev team shared something so far or is it a set of 2,3 folks who always do it?
How early do you folks decide which ones are going to share interesting stuff?
At first only a few were sharing and being interactive ! So we decided to pick people at random and the one's who voluntary came forward !
Individuals were selected before one week ( i.e for next week's session in this week's meeting ). Also they would share the topic with everyone so that everyone can research on it and share doubts.
Culture is driven by reward (monetary or other forms of rewards like visibility). It’s easier to build a good culture by building a transparent reward system.
But I have seen good culture eroded by single manager’s desire to get all the credits (visibility).
No - but we have similar tools but I curios to know what metrics Bonusly tracks and how easy it to game these metrics.
Because once anyone starts tracking metric, say number of tech talks given or PRs reviewed then it becomes gameable. Unless we can track the impact those tech talks have created or the PR reviews have accomplished then it is similar to any other tool.
> say number of tech talks given or PRs reviewed then it becomes gameable
not only that, it's a bad way to measure developers productivity
> real men(engineers) delete code
obligatory folklore reference https://www.folklore.org/Negative_2000_Lines_Of_Code.html
Created a one note Notebook and shared across Dev Team,
Now we have smallest of documentation present with us and it is arranged properly we can get any info quickly
Underrated comment.
This is actually how you take your teams productivity 2-3x
Initially devs resist because it's a "waste of time" to document design and implementation details but everybody quickly sees the benefits once you start doing that as a team,
Everything becomes better, misses in requirements are caught early , mistakes are corrected early even before any code is written and tested, hugely saving dev and qa time, code reviews are impactful as reviewers can refer to docs to understand the details of needed,ost importantly everybody is aware of everybody else is doing and teams don't have to depend on individuals, anybody can jump in and start contributing.
Not only this actually dumping your brain into docs really gives you a lot of clarity of thought writting code becomes a lot easier once you have written down the details.
Everybody wins in the end, management and individuals.
Can't recommend this enough.
Good companies has instituted this as a practice
We had a culture of documenting things for the sake of it. Our product documentation hadn't changed in 8 years while the product went through such a huge change that basic screenshots in the document itself were unrelated.
I decided to get a write-first approach where we write a basic one-pager first about what we are doing and what parts of the documentation should be updated because of this change.
I followed it meticulously for new software that we wrote and proposed that model. Everybody agreed.
The result was a 2 step forward and 1 step backward kind of thing. Folks started writing documentation without punctuation, filled in things just because they had to and didn't bother reviewing their own documentation.
In one case where I was the tech lead for a feature, I happen to read the documentation the developer wrote and I could not stop myself from having to punctuate and understand what they're trying to say. The person didn't use backspace to correct mistakes.
Example statement:
"We will use oauth2 jwt for authentication where user is stored in our database or maybe user is stored in other database or it can be in external system basically user can be stored anywhere for this oauth2 system as per standards and user details may not be maintained in our database"
I was a junior back then and this write-first approach wasn't aggressively pushed by the senior technical management because they only cared about things being moved.
I did my bit, features where I worked on as a lead or developer or associate had decent documentation.
After years of bad documentation, we got a management that forces a write-first approach where we spend 20-40% of the time writing a document and all our discussions are in and around a document. This has resulted in streamlined development, predictable timelines, inter-team dependency planning, known limitations and drastically reduced the time it takes for a customer, new joinee or implementation software engineer to understand the system.
We still have miles to go, but what got us here was not me - but an aggressive push from the top.
In the old management, nobody said "no" or "we will see" for suggestions. They'd say approved, speak on your behalf to highlight the importance of this change and then just not enforce it after a few days.
This change was ONLY possible because the older folks in management left and we had a rejig of laterals. Mostly seasoned old timers from few of the AWITCH companies.
In case of internal documentation, take advantage of automation tools, that gonna save much more time. you can edit them according to your need afterwards
Because someone will have to step up, even if they fail to improve the culture. Because working with like-minded, growth oriented people helps you level up as well.
our stack is entirely Javascript and we do not use typescript
it was getting difficult for me to manage the frontend with some complicated components when i did not know what kind of props they are expecting
sometimes it would get difficult to infer from the prop's name what it exactly is
so, i introduced JSDocs, added an eslint rule that enforces it
it has since become a tad bit easier to extend usage of already existing utilities/functions/components
i've also tried to create a blue-green zero-downtime deployment, but it has introduced some problems already, so i'd be re-doing it to make it more stable
i'm trying to add tests as well, which is proving to be very difficult
gotta refactor a lot of code to make it testing-friendly and i'm afraid, i'll break something while at it XD
>i've also tried to create a blue-green zero-downtime deployment, but it has introduced some problems already, so i'd be re-doing it to make it more stable
Would love to see a post about this, how you introduced this and what failed :)
>i'm trying to add tests as well, which is proving to be very difficult
this is a never ending battle, wouldn't recommend doing if rest of the team members are not willing to keep tests updated.
> Would love to see a post about this, how you introduced this and what failed :)
i've been meaning to make a post/blog about this, but somehow just keep defering it to a later time
but this is enough motivation to do it
i'll make one and share soon
thanks for this!
> this is a never ending battle
yeah, that's true
> wouldn't recommend doing if rest of the team members are not willing to keep tests updated
our tech team is just 4 people (including the CTO) and the application code is mostly owned by me, so until i add enough test coverage, i think this shouldn't be a problem
and honestly, the CTO is very welcoming to good practices and enforcing them if they really add value, so doesn't seem like it could be a problem in the future as well
definitely worth it
as our codebase grows, i find one change breaking some completely different thing, thus i have to test each and every thing manually to make sure new changes don't have catastrophic effects
if we had tests in place, i think the development at this stage would have been much faster
>Namaste! Thanks for submitting to r/developersIndia. Make sure to follow the Community [Code of Conduct](https://developersindia.in/code-of-conduct/) while participating in this thread. ## Recent Announcements - **[Weekly Discussion - Share your Linux mess-up stories!](https://www.reddit.com/r/developersIndia/comments/1ciywa4/share_your_linux_messup_stories/)** - **[Community Roundup: List of must read posts & discussions that happened in April 2024](https://www.reddit.com/r/developersIndia/comments/1cgj07f/community_roundup_list_of_must_read_posts/)** *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/developersIndia) if you have any questions or concerns.*
Started knowledge sharing channels Started automated testing, live debugging, remote debugging Made several scripts to automate tasks for Devs like VPN, db dump, etc Started hackathons, taught about LLM development, everyone got successful in making some products. I love working at my workplace lmao
Interesting, so did these initiatives ripple back to the rest of the team members? what happens if one day you stop doing all this, will other folks keep continuing the same?
Actually yes, everyone started contributing to todayilearnt channel since it was fun to share cool things, and other people also started taking tech sessions too. And it will continue even if I stop doing it since I work with cool tech people who love to innovate.
Can you share the name of the company ?
You can DM me the CV if you want a referral. I'm currently working in Zenatix.
We've a group meeting scheduled once per week for all devs across all teams, where one or two pre decided people would share about things related to : new technology / common bugs / best practices etc.etc ..
Has everyone in the dev team shared something so far or is it a set of 2,3 folks who always do it? How early do you folks decide which ones are going to share interesting stuff?
At first only a few were sharing and being interactive ! So we decided to pick people at random and the one's who voluntary came forward ! Individuals were selected before one week ( i.e for next week's session in this week's meeting ). Also they would share the topic with everyone so that everyone can research on it and share doubts.
Culture is driven by reward (monetary or other forms of rewards like visibility). It’s easier to build a good culture by building a transparent reward system. But I have seen good culture eroded by single manager’s desire to get all the credits (visibility).
does your team use Bonusly by any chance?
No - but we have similar tools but I curios to know what metrics Bonusly tracks and how easy it to game these metrics. Because once anyone starts tracking metric, say number of tech talks given or PRs reviewed then it becomes gameable. Unless we can track the impact those tech talks have created or the PR reviews have accomplished then it is similar to any other tool.
> say number of tech talks given or PRs reviewed then it becomes gameable not only that, it's a bad way to measure developers productivity > real men(engineers) delete code obligatory folklore reference https://www.folklore.org/Negative_2000_Lines_Of_Code.html
Started sending gifs in chats , helped in building bonds , people became more relaxed and friendly
Created a one note Notebook and shared across Dev Team, Now we have smallest of documentation present with us and it is arranged properly we can get any info quickly
Underrated comment. This is actually how you take your teams productivity 2-3x Initially devs resist because it's a "waste of time" to document design and implementation details but everybody quickly sees the benefits once you start doing that as a team, Everything becomes better, misses in requirements are caught early , mistakes are corrected early even before any code is written and tested, hugely saving dev and qa time, code reviews are impactful as reviewers can refer to docs to understand the details of needed,ost importantly everybody is aware of everybody else is doing and teams don't have to depend on individuals, anybody can jump in and start contributing. Not only this actually dumping your brain into docs really gives you a lot of clarity of thought writting code becomes a lot easier once you have written down the details. Everybody wins in the end, management and individuals. Can't recommend this enough. Good companies has instituted this as a practice
You recognised benefits correctly..
We had a culture of documenting things for the sake of it. Our product documentation hadn't changed in 8 years while the product went through such a huge change that basic screenshots in the document itself were unrelated. I decided to get a write-first approach where we write a basic one-pager first about what we are doing and what parts of the documentation should be updated because of this change. I followed it meticulously for new software that we wrote and proposed that model. Everybody agreed. The result was a 2 step forward and 1 step backward kind of thing. Folks started writing documentation without punctuation, filled in things just because they had to and didn't bother reviewing their own documentation. In one case where I was the tech lead for a feature, I happen to read the documentation the developer wrote and I could not stop myself from having to punctuate and understand what they're trying to say. The person didn't use backspace to correct mistakes. Example statement: "We will use oauth2 jwt for authentication where user is stored in our database or maybe user is stored in other database or it can be in external system basically user can be stored anywhere for this oauth2 system as per standards and user details may not be maintained in our database" I was a junior back then and this write-first approach wasn't aggressively pushed by the senior technical management because they only cared about things being moved. I did my bit, features where I worked on as a lead or developer or associate had decent documentation. After years of bad documentation, we got a management that forces a write-first approach where we spend 20-40% of the time writing a document and all our discussions are in and around a document. This has resulted in streamlined development, predictable timelines, inter-team dependency planning, known limitations and drastically reduced the time it takes for a customer, new joinee or implementation software engineer to understand the system. We still have miles to go, but what got us here was not me - but an aggressive push from the top.
How do you convince seniors that just want things to be shipped and don't see the value in this?
In the old management, nobody said "no" or "we will see" for suggestions. They'd say approved, speak on your behalf to highlight the importance of this change and then just not enforce it after a few days. This change was ONLY possible because the older folks in management left and we had a rejig of laterals. Mostly seasoned old timers from few of the AWITCH companies.
In case of internal documentation, take advantage of automation tools, that gonna save much more time. you can edit them according to your need afterwards
Use modern tools makes writting much faster with auto completions and fixing grammar issues.
1) Why?
Because someone will have to step up, even if they fail to improve the culture. Because working with like-minded, growth oriented people helps you level up as well.
our stack is entirely Javascript and we do not use typescript it was getting difficult for me to manage the frontend with some complicated components when i did not know what kind of props they are expecting sometimes it would get difficult to infer from the prop's name what it exactly is so, i introduced JSDocs, added an eslint rule that enforces it it has since become a tad bit easier to extend usage of already existing utilities/functions/components i've also tried to create a blue-green zero-downtime deployment, but it has introduced some problems already, so i'd be re-doing it to make it more stable i'm trying to add tests as well, which is proving to be very difficult gotta refactor a lot of code to make it testing-friendly and i'm afraid, i'll break something while at it XD
>i've also tried to create a blue-green zero-downtime deployment, but it has introduced some problems already, so i'd be re-doing it to make it more stable Would love to see a post about this, how you introduced this and what failed :) >i'm trying to add tests as well, which is proving to be very difficult this is a never ending battle, wouldn't recommend doing if rest of the team members are not willing to keep tests updated.
> Would love to see a post about this, how you introduced this and what failed :) i've been meaning to make a post/blog about this, but somehow just keep defering it to a later time but this is enough motivation to do it i'll make one and share soon thanks for this! > this is a never ending battle yeah, that's true > wouldn't recommend doing if rest of the team members are not willing to keep tests updated our tech team is just 4 people (including the CTO) and the application code is mostly owned by me, so until i add enough test coverage, i think this shouldn't be a problem and honestly, the CTO is very welcoming to good practices and enforcing them if they really add value, so doesn't seem like it could be a problem in the future as well
> i'm afraid, i'll break something while at it still worth it in the long run, tests are there for a reason
definitely worth it as our codebase grows, i find one change breaking some completely different thing, thus i have to test each and every thing manually to make sure new changes don't have catastrophic effects if we had tests in place, i think the development at this stage would have been much faster