Saving fish by writing code! Applications developer in fisheries, specializing in webapps and moving 'enterprise-y' legacy systems to modern agile systems - Email or tweet me if you want to talk!
Those certainly have similar roles and overlap in a lot of ways. The principal places where I see differences are in two areas - the potentially adversarial workplace, and personal opinions you don't necessarily want to share.
All the things you mentioned are geared towards collaboration and sharing. They are typically public (inside the company public, anyhow), or at least accessible by your boss and/or your companies HR department and legal team.
In the case of the adversarial workplace, that means anything you write on a company system, and potentially anything you transmit over company wires (hello Firepower) is readable by an entity with more people, more money and more time than you. Why give them a leg up, if you don't have to?
In the case of the personal opinion you don't necessarily want to share, here's an example. I sit on a board that votes on who gets the employee of the month award at my regional line office. There's a defined procedure for submitting applications, and then the board votes on the pool of applicants and picks one.
An individual attended our meeting because they were very upset we had not selected their nominee. They had a lot to say, much of quite heated and not at all complimentary. We record meeting minutes in a wiki. I put a respectful, formal, high level overview of the complaint in the minutes. I did not minute a complete description of my impression (they weren't listening they were aggressive, they started repeating themselves louder and louder, etc.) You can bet I wrote down my impressions of what went on in my personal notebook, because I have no intention of catching any more grief for giving a dang award out.
In my view, wikis, issue trackers and chats are for actually getting project based coding work done, and keeping a record of how the work was done. The memo comes into play in that gray area, where non-project based, not necessarily coding work is done. They are useful in the political, human side of work that inevitably crops up in large organizations.
I will say that not all workplaces are adversarial, and it's possible to work somewhere that nothing ever comes up that you wouldn't share publicly. The benefits of personal memos are greatly lessened in those environments, however I contend they are still useful for preparing an end of the year summary of what you did. They are also a useful hedge against nice environments turning bad - it's often only a supervisor change/merger/team swap away.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Those certainly have similar roles and overlap in a lot of ways. The principal places where I see differences are in two areas - the potentially adversarial workplace, and personal opinions you don't necessarily want to share.
All the things you mentioned are geared towards collaboration and sharing. They are typically public (inside the company public, anyhow), or at least accessible by your boss and/or your companies HR department and legal team.
In the case of the adversarial workplace, that means anything you write on a company system, and potentially anything you transmit over company wires (hello Firepower) is readable by an entity with more people, more money and more time than you. Why give them a leg up, if you don't have to?
In the case of the personal opinion you don't necessarily want to share, here's an example. I sit on a board that votes on who gets the employee of the month award at my regional line office. There's a defined procedure for submitting applications, and then the board votes on the pool of applicants and picks one.
An individual attended our meeting because they were very upset we had not selected their nominee. They had a lot to say, much of quite heated and not at all complimentary. We record meeting minutes in a wiki. I put a respectful, formal, high level overview of the complaint in the minutes. I did not minute a complete description of my impression (they weren't listening they were aggressive, they started repeating themselves louder and louder, etc.) You can bet I wrote down my impressions of what went on in my personal notebook, because I have no intention of catching any more grief for giving a dang award out.
In my view, wikis, issue trackers and chats are for actually getting project based coding work done, and keeping a record of how the work was done. The memo comes into play in that gray area, where non-project based, not necessarily coding work is done. They are useful in the political, human side of work that inevitably crops up in large organizations.
I will say that not all workplaces are adversarial, and it's possible to work somewhere that nothing ever comes up that you wouldn't share publicly. The benefits of personal memos are greatly lessened in those environments, however I contend they are still useful for preparing an end of the year summary of what you did. They are also a useful hedge against nice environments turning bad - it's often only a supervisor change/merger/team swap away.