A few years ago, I was fired from a place, but they asked me to resign instead. At the end of it all, they gave me employment papers that read that I have been fired. Here's most of my resignation letter
For a combination of personal circumstances and professional issues, I am resigning my position....
In my time at [place], I found the following points limited my capacity to succeed in a position with the company:
The documentation for the given projects were almost wholly absent. The example project, Rocky Mountaineering, had a project page listed under “Project Details,” which said only “see Environment page.” In lieu of documentation, the Environment page had page after page of download links to the snapshots of databases and files in the different development environments. Some of those database environments contained data that amounted to chaff, that bloated 50MB archives to be above 650MB in size-- making them almost impossible to manipulate. There was no clear documentation as to what distinguished those environments. In one case, the environment “content stage” was not ready to download for use as of December 3rd, but it was still present and available for use by the developers who would have to rely on the absent documentation to judge as to whether or not the data should be accessed.
The entity relationship diagrams were unavailable for the aforementioned project. I did not get a sense if they were available or if they even existed.
The links to the legacy site were unavailable.
The legacy passwords had to be requested when they needed to be a part of the documentation.
None of the JIRA stories I found contained URLs or paths to parts of the site relevant to a given story.
Comments left in the JIRA stories that referenced other JIRA users were not replied to in the comment stream, nor outside of the JIRA environment; it was as though the developers were unaware of how JIRA actually worked; or the system was not set up to alert those who were referenced.
There were references in the JIRA stories to people in the client team to be contacted as part of the requirements for carrying out stories. The references had no supplemental information (full name, email, phone number, Skype handle, etc.-- none of those were present).
Some of the stories were assigned for action before the business analysis was done.
Little of the code developed contained inline documentation through code commenting.
Contact to other developers in the team went almost wholly unanswered for the most part. With the exception of Jonathan Whang, others in the team who did respond largely waved off engaging in a given topic and referred me to Jonathan or referred me to other team members who themselves would not respond.
Instead of using a small set of tools (ie. modules) to deliver the project, a broad set of tools were used to make the site significantly more resource needy, and less clear to administer and develop for. As per above, documentation and references in the JIRA stories would have gone a long way to clear this up, but that lack of detail in the instructions, or breadcrumbs in the story comments left no mechanism for gaining that information.
Instead of proceeding from an architectural foundation and re-use of elements where possible, the development duplicated functionality repeatedly. That would make for a congested database schema that demonstrated an absence of foresight that would seriously impact the site performance in production where an otherwise well planned schema could have been much leaner and easier to extend.
Some of the design decisions were hard to wholly fathom: for example with all of the division and specialization of elements in the project, Rocky [Project] API call functions are bundled into the same module as the Rocky [Project] import of the CSV files.
An anecdote shared in the Monday session of the Consulting Skills Workshop by Simon [Sales Guy] (ie. to paraphrase, “I promised it to the client, then told the developers what I promised. They got mad at me, then delivered.”) really demonstrated that there are issues with the services available contrasting with the services offered by the sales team. That’s not respectful to the development team, and the approach is likely to impact the company in a profoundly negative fashion.
The development environments were either under-resourced or their code base unstable leaving for lots of incidents where 500 errors were found.
The VPN was inconstant and prone to service outages, so I steered around using it.
The [...]net services (eg. OpenAir, etc.) failed to work with some frequency, usually due to SAML errors and the like.
With the exhaustive coverage in the human resources manual for contingencies, I was disheartened to find that these previous points were the case. They frustrated development. They left “ask a guy” to be the route for information sharing instead of generating adequate documentation and making that available to the team. Lack of documentation in an environment staff where retention is dynamic means that those who do need the information had to wait an unduly long time before finding “a guy” who would have that information and the willingness to share said information.
Last updated date