Occupational Post-Mortem

I recently gave notice at the place I've called "work" for the last four years. I'll miss it dearly. I'll miss the personalities, the small-team dynamic, and some of the complex projects. I was brought in as a regular schmo software engineer and became senior a few years later. Initially, I was asked to work on the core Silver-light project with WPF Setup and then transitioned to custom (client) work, various small modules relating to html5 and other types of services and applications.

I enjoyed the initial team in which I was placed. We were a cohesive unit, and we were very fast. After a few hires, I noticed some alarming trends. 1) The quality of the developers that we were picking up was lacking. 2) The architect decided to slowly implement certain bureaucratic bottlenecks and procedures. We lost several developers during my first few years, and they were mostly replaced with inadequate counterfeits. The quality of our work declined, and the architect decided to put his foot on the gas with regard to the red tape.

At first, code-reviews became mandatory and then architecture-reviews became mandatory. You've been coding for 8 years? Doesn't matter, send your code in for inspection. Know the module better than anyone? Doesn't matter, send it in for inspection. Found a project you're not even remotely working on? Doesn't matter, we're going to stick you in a meeting and force you to listen to how a developer is going to pseudo-code his/her unrelated feature. Then came the mandatory technical document. This gem known as the tech doc started out simply enough by noting the changes that have occurred with regard to an existing feature, then it morphed into a base document for the entire feature and any possible offshoots. So now, the developer is writing documentation. This is not a good idea for several reasons: 1) Time per feature goes way up. Remember, clients are getting billed many hours for this madness.  If it takes 10 hours to code a feature, it takes 5 to write the document. 2) Redundancy. You're writing code, and then describing the code. Ever heard of self-documenting code? Also, there are many xml scrapers such as SandCastle that provide the description of each method to the client. 3) Most developers do not have a business degree and as such are practically incapable of stringing two sentences together in a way that a business representative could read. The architect would argue that only developers are the primary readers, but that isn't true as the technical documentation has been sold as "value-added."

In my final discussion with the Director of Development, I couldn't stress enough the problems that I was having with the department being inefficient. We were a joke, and our clients were beginning to recognize it. There were other aspects of the meeting that I won't discuss, but I was left with an inadequate feeling and that my concerns would not be addressed. I sought council from a few different folks from a few different backgrounds, and one played devil's advocate. I settled on the realization that nothing would change. I am scared about the decision that I have made, but I am comforted in the fact that I can fall back on my laurels.

I will miss the company, not for what they became, but for what they were. It was a great place, and I have many fond memories. I established many relationships, and I learned a great many things. 

“To say goodbye is to die a little.”