4 ms·

We were explicitly barred from using tools that were not published by Microsoft. Even if Microsoft didn't make a tool to solve the problem. Instead, we were e

by MrFoof 17y ago

We were explicitly barred from using tools that were not published by Microsoft. Even if Microsoft didn't make a tool to solve the problem. Instead, we were encouraged to create our own, on our own time, outside of regular business hours. The same place barred the use of code generators, the use of snippet macros, and they barred admins from creating automated scripts/utilities to automate gruntwork. They likened it to taking a math test without a calculator -- you should be able to do it by hand if you can supposedly do the job. The same place also required that comments were not to be made in source code files. They should only be made in source control check-in comments. The same place felt refactoring was an unproductive activity unless it corrected a specific "bug". Scalability and performance issues weren't considered valid bugs - it was fast before, so why would it ever be slow now? Blame would be put on the hardware until network ops bit back. Then you would be lambasted for your application not scaling 4 orders of magnitude on the same hardware when that wasn't part of the original requirements. One place I worked for did not allow developers to use the bug-tracking system. Instead, someone from QA would place printout of open bugs in a bin. You were required to take the bug from the bin, back to your desk, and when completed, fill in a form by hand detailing the explanation and attach the appropriate colored paper strips in the right order so it could be triaged appropriately. The same place migrated customer data to their product by hand. Using Excel. We jokingly referred to this process as "electronic handcrafting". The reason was because it was faster and resulted in fewer reported defects after deployment. Someone in that department got fed up, so she had me create ETL processes for the four most common competitor products. Time-to-install went from 4 weeks to 4 days and the error rate dropped 98%. It won over the COO and some staff, but made me enemies with plenty of others. At the same place a sales manager convinced the COO that RAID1 should be considered a viable backup and disaster recovery solution. We were tasked with making it so RAID controllers would not back up certain types of files. Another place I worked for as a contractor insisted that their web app was written in ColdFusion. Despite not having any other contractors past or present, and the market not having any ColdFusion developers. The reason ended up being is it because it "sounded cool". Needless to say, they have an app still running on ColdFusion 4. I've worked in too many places that are adamant that "backups" are all the database version control they need. I've worked at a place that would expect me to develop APIs for certain products and systems we had, yet refused to allow for a requirements gathering phase. I was actually fired trying to explain that I can't build something when I don't know what I was building. Reason was so the new CIO could bring on a contracting firm run by a friend of his. Three other people have since quit in response.

erlanger 17y ago
How did you find so many bad jobs (they sound horrendous)? More importantly, why did you take them, let alone keep them?
- MrFoof 17y ago
  Inexperience, and a tendency to be a "saver". I've since learned how to read between the lines, ask a lot of questions hiring managers aren't expecting to be asked, and to request interviews with team members if it isn't offered (and refusing the position if my request is refused). Additionally, you'll hear enough horror stories if you talk to those who work in IT departments in regular companies that aren't doing anything interesting because no one's been able to present a solid business case as to why IT can add value or affect the bottom line. Though sometimes the works is simply gummed up by political battles and everyone's afraid to go to HR or to make an attempt to knock down those walls in fear of losing their job. What you read about on HN is what you'll see at the right-end of the bell curve, and often isn't representative of your average company. Most of these issues were driven by politics. In a lot of situations (electronic hand-crafting, manual bug-tracking) I was able to drive change from within. Granted, they took months. However people were afraid of opposing the head of QA because A) she was a lifelong friend of the founder's life B) she was predisposed to think all developers were idiots C) they weren't equipped to traverse that delicate political minefield without at least losing a leg in the process. The scalability/performance issue one? This was at a private sales-oriented company with a billion dollars in annual revenue. Again, mired in politics. Their entire e-commerce system was built by guys who were completely green at the time, and they hacked it together. He was best buds with the CIO, and was... a pretty passionate guy, and very defensive. The average person with a spouse and kids to support didn't feel it was worth risking their job to improve the architecture if they couldn't present a decent argument and it came across as hurting his feelings. Me? I spent far too many lunches talking with developers, guys in network ops and analysts to come up with ways to cache data and partition functionality so the thing could handle the existing load and scale in the future. It took buy-in from stubborn developers who normally pointed the fingers at the database or the servers, network ops guys who pointed fingers at the developers, and a testy data architect who had a serious row with the development manager. I've learned a lot from those experiences, especially the social problems that can exist in team-based development, and how to present solutions where even the most stubborn-minded individual can "get it". I've also learned that these problems exist nearly everywhere, just more so in some environments than others, and when you can solve these problems and when it's instead best to learn and move on.

by MrFoof 17y ago

erlanger 17y ago

How did you find so many bad jobs (they sound horrendous)? More importantly, why did you take them, let alone keep them?

MrFoof 17y ago
Inexperience, and a tendency to be a "saver". I've since learned how to read between the lines, ask a lot of questions hiring managers aren't expecting to be asked, and to request interviews with team members if it isn't offered (and refusing the position if my request is refused). Additionally, you'll hear enough horror stories if you talk to those who work in IT departments in regular companies that aren't doing anything interesting because no one's been able to present a solid business case as to why IT can add value or affect the bottom line. Though sometimes the works is simply gummed up by political battles and everyone's afraid to go to HR or to make an attempt to knock down those walls in fear of losing their job. What you read about on HN is what you'll see at the right-end of the bell curve, and often isn't representative of your average company. Most of these issues were driven by politics. In a lot of situations (electronic hand-crafting, manual bug-tracking) I was able to drive change from within. Granted, they took months. However people were afraid of opposing the head of QA because A) she was a lifelong friend of the founder's life B) she was predisposed to think all developers were idiots C) they weren't equipped to traverse that delicate political minefield without at least losing a leg in the process. The scalability/performance issue one? This was at a private sales-oriented company with a billion dollars in annual revenue. Again, mired in politics. Their entire e-commerce system was built by guys who were completely green at the time, and they hacked it together. He was best buds with the CIO, and was... a pretty passionate guy, and very defensive. The average person with a spouse and kids to support didn't feel it was worth risking their job to improve the architecture if they couldn't present a decent argument and it came across as hurting his feelings. Me? I spent far too many lunches talking with developers, guys in network ops and analysts to come up with ways to cache data and partition functionality so the thing could handle the existing load and scale in the future. It took buy-in from stubborn developers who normally pointed the fingers at the database or the servers, network ops guys who pointed fingers at the developers, and a testy data architect who had a serious row with the development manager. I've learned a lot from those experiences, especially the social problems that can exist in team-based development, and how to present solutions where even the most stubborn-minded individual can "get it". I've also learned that these problems exist nearly everywhere, just more so in some environments than others, and when you can solve these problems and when it's instead best to learn and move on.