I've been looking for a job for a month now, and it seems that it's going to be tough. The job market is really bad. I have a rather stellar CV, and it doesn't seem to matter much. Being fired from my last job seems to be a show-stopper for some of the places that could be very nice to work in. If the only jobs available will be little startups that treat people like cannon fodder, I think I'll go work the doors. That's a job that can't be outsourced and something I'd also be good at.
A thing that I cannot understand is that if good people are available because they were fired, why being fired is seen as a shooting offense? That doesn't make much sense to me, but I guess the managers now better. We'll see. In the meantime, I think I'll learn to play keyboard (piano) which I stopped doing when I was 13. It seems to make me happy, which is very good when the whole world is going to shit along w/the economy.
2009-03-28
2009-02-20
What did the managers learn?
This is a true story about a company and the way they handle their employee relationships. Last year I worked for a company that has one blanket solutions for all problems. They fire people. I will give you a few examples how well this tends to work.
Case #1: They hired a new employee to build a a certain application. Let's call her Jane. Jane was a semi-solid developer, but not exactly familiar w/the libraries that the application was based on. In fact, neither was the developer before her, who had had no time to learn the ropes and had to do what little she could to build the application. Well, Jane started working with the application, and fixed a few bugs. Fixing these bugs uncovered more bugs. Jane continued to fix the new bugs, ending up in a situation where new bugs arose about at the same pace old ones got fixed. Jane received no help from senior developers, because they were too busy. After two months, and with little results, someone had to pay: Jane was fired.
What was never revealed to Jane was that this had already happened before in the organization. They hired people to do things with no time to learn the ropes, and they then fired them just when they were getting up to speed. The application did not get much better, and Jane had to sell her apartment. The company wasted money, and got nothing and Jane got hurt.
But what did the managers learn?
Case #2: Another developer at the same company had nearly finished a new application. However, they way she had worked had not pleased the managers. She was too independent. She resisted the culture of fear, so she had to go.
As it happens, she was fired in the middle of a database update, rendering the application useless. The managers had a problem, and they turned to another developer, who they had mistreated previously. Karma is a bitch, and this developer who could have helped them just told the managers that she didn't know anything about the application. Of course, this was not true. She could have easily helped the managers, had she wanted to.
So, again the company fired a competent employee, and ended up with a project that crashed and burnt in the last few yards.
But what did the managers learn?
Case #3: The same company had a part-time developer work with a certain component of an application. They did not have much work other than that to give that person at that moment, so after completing the project they fired him. A few months past and they reused the workstation that had the expensive development tools for the application.
Some six months later, they noticed that they had no-one to update the software when there were new features that they had otherwise completed. They asked another developer in the company if she'd be willing to learn the new development tools to create the missing components. It was karma time again, as the other developer bluntly told them that she didn't know the technology. The reason she did this was not because she was unable to learn the new tools. She just had seen enough of blaming people for things they couldn't have done any better. So again they had no-one to fix their application.
The story continued so that they tried to get the person to fix the application they had previously fired. It doesn't take a rocket scientist to guess how this person responded. Karma time, again.
So as you can see, there are consequences. You can do a lot of things, but they will lead to certain other things. It would behoove one to try to act so that these things are rather good than outright nasty.
Maybe some managers just never learn.
Case #1: They hired a new employee to build a a certain application. Let's call her Jane. Jane was a semi-solid developer, but not exactly familiar w/the libraries that the application was based on. In fact, neither was the developer before her, who had had no time to learn the ropes and had to do what little she could to build the application. Well, Jane started working with the application, and fixed a few bugs. Fixing these bugs uncovered more bugs. Jane continued to fix the new bugs, ending up in a situation where new bugs arose about at the same pace old ones got fixed. Jane received no help from senior developers, because they were too busy. After two months, and with little results, someone had to pay: Jane was fired.
What was never revealed to Jane was that this had already happened before in the organization. They hired people to do things with no time to learn the ropes, and they then fired them just when they were getting up to speed. The application did not get much better, and Jane had to sell her apartment. The company wasted money, and got nothing and Jane got hurt.
But what did the managers learn?
Case #2: Another developer at the same company had nearly finished a new application. However, they way she had worked had not pleased the managers. She was too independent. She resisted the culture of fear, so she had to go.
As it happens, she was fired in the middle of a database update, rendering the application useless. The managers had a problem, and they turned to another developer, who they had mistreated previously. Karma is a bitch, and this developer who could have helped them just told the managers that she didn't know anything about the application. Of course, this was not true. She could have easily helped the managers, had she wanted to.
So, again the company fired a competent employee, and ended up with a project that crashed and burnt in the last few yards.
But what did the managers learn?
Case #3: The same company had a part-time developer work with a certain component of an application. They did not have much work other than that to give that person at that moment, so after completing the project they fired him. A few months past and they reused the workstation that had the expensive development tools for the application.
Some six months later, they noticed that they had no-one to update the software when there were new features that they had otherwise completed. They asked another developer in the company if she'd be willing to learn the new development tools to create the missing components. It was karma time again, as the other developer bluntly told them that she didn't know the technology. The reason she did this was not because she was unable to learn the new tools. She just had seen enough of blaming people for things they couldn't have done any better. So again they had no-one to fix their application.
The story continued so that they tried to get the person to fix the application they had previously fired. It doesn't take a rocket scientist to guess how this person responded. Karma time, again.
So as you can see, there are consequences. You can do a lot of things, but they will lead to certain other things. It would behoove one to try to act so that these things are rather good than outright nasty.
Maybe some managers just never learn.
2009-02-19
Buying software
Years ago, as a junior developer, I used to think that there's totally no point in buying software projects. I thought that it's simply the best to build in in-house. At a certain point of my career, I understood that there are situations when it can make sense, money-wise. At that point, I had not worked in customer projects myself. Now I have. I can assure you that buying software projects is a risky business. So don't do it, if you can find a way around it. If you can build it in-house, just do it. The reason for this is the way the companies are run that do the projects. It'd horrid. It's a mix of worse sides of waterfall and scrum. Effectively they're simply cowboy coding. No planning, no documentation, no refactoring. Just hack it together. The budget is tight, and the project managers make sure that you spend 1/3rd less time than the budget would allow for. The quality is simply horrendous. You will end up w/a system that barely works, is glued together and is completely unmaintainable. Who the hell wants a project like that ? It seems that quite a few companies. They just don't know any better. They're happy when they're provided w/documentation that is copy/pasted from somewhere else. The documentation is almost always basically completely useless, and most oft there's lot of this paper. It doesn't solve any real problems, there's no engineering or planning done to create it. It's just put together at the pace of 30 pages a day.
So, you see - buying software through projects equates to buying complete crap. In addition, it's expensive. So what's the point?
So, you see - buying software through projects equates to buying complete crap. In addition, it's expensive. So what's the point?
First post
Because I'm active in work life, I cannot really write the things to my own blog that I'd like to. Hence, this blog. I will rant and rave and speak all the honest truths right here. It's great, if someone ends up reading this blog, but mostly this is for my own entertainment and especially - therapy. On the other hand, this is here so I can speak the truth. I'm really tired of being unable to speak my mind anywhere these days, because doing so could look bad on my resume.
Subscribe to:
Posts (Atom)