Of course, after spending quite some time on Friday over the logical approach of a puzzle we were trying to crack, a bit of retrospect and lateral thinking brought us to a solution. It does have side effects, but was consistent and stable with respect to the problem we were trying to solve.
That made a good start to the weekend in general. Friday night was spent watching Television. The whole of Saturday did not turn out to be much too different.
I did watch a good movie, "Bug" which is on quite a difficult subject. The movie was given a "Horror-Movie" tag, while it really is more of a drama with a message that is slightly horrific. It deals with group psychosis, a strange thing that is usually not witnessed with such dramatic outlet as shown in the film. Ashley Judd has again proved herself in the movie in her role.
Further, I am working to find out what is really lacking for an opensource developer while creating embedded application development platforms (the entire Operating System underneath including a kernel, bootloader with the core utilities for a system.) There seems to be a considerable gap being addressed by very few projects like "emdebian" and "openembedded." It would be a good time to give these projects some competition.
Sunday, 30 December 2007
Thursday, 27 December 2007
On Cameras and Pictures
This day at work, my boss was down with fever and I was taking up the weekly status review in his stead. It took half the time which was well spent, attendance being thinner than usual. The rest of the day was spent in finding another (sigh!) anomaly with camera images on something we were working on. By the end of the day, we did find an answer to it, but we had created collateral restrictions working on it.
Another friend debunks from work to take a really long New year weekend vacation. That would leave me hunting down more bugs sitting by myself. I do like doing it, but sometimes it can grow to become quite a weight bearing down on oneself.
Coming back to the main thing, Camera's are odd devices - the modern digital video sensors. The CMOS Sensor Interface originally dismissed as a lower quality (and therefore low cost) alternative has gained popularity with much change in technology. Most sensor companies have decided to put a Application Specific Digital Signal Processor with their Sensors. This actually means that even if a CMOS Sensor is sensing video with less accuracy and sharpness than its cousin, the CCD, we could have "patches" or workarounds that "post-process" the captured image and show it to be of better quality in digital terms.
As these sensors are intended to be integrated in very small designs, they are generally low power consuming. That might seem like a feature to most people, however that means strict restrictions in communicating/programming a CMOS sensor. The major part of the problem that I've been tackling through the day has been on sequencing the program to the DSP paired with the CSI (CMOS Sensor Interface.)
Debugging it seems would occupy a major portion of the timeline of any product development. It is sometimes an interesting exercise if you would discount the human communication aspects at the time of facing a blocker and working through it. Mildly put whenever you encounter major problems in any product/service that on sale would fetch revenue, someone needs to be "accountable" for the "delay" (therefore loss of opportunity) in providing a consistent solution (even a workaround if it were reasonably secure and consistent.)
I do remember Alan Cox's speech on ratio of errors in hardware versus software on which I disagree entirely with his opinion that hardware is relatively much more bug free. I see that hardware is designed in a generic manner to send most of the complexity to "replaceable" and/or "upgradeable" software. This would mean that with higher complexity and offer of features over a generic platform, software would take the bane of being more buggy whenever engineered within strict time-frames with requirements changing along side (on the assumption that software can adapt and incorporate changes much easier than firmware/hardware.) Further, I see that a good number of hardware bugs (including the infamous pentium f00f bug) were worked around in "software."
So whenever a system as a total malfunctions, as most of its features rest in software, so do most of the errors (proportional to the features.) Unfortunately this relationship of software[features:errors] is not normally linear. I would assume that the mathematical non-linear relationship is statistically acceptable in any system that is operational with almost 0 probability of total failure and almost unity probability of being functionally useful for a predetermined set of tasks.
With reliability paradigms existing, like 5 nines or 7 nines, it is reasonable to assume that man-made system in an open environment has a 0 probability of failure (and therefore total perfection.) So engineering time spent in tilting the probability of failure towards 0 for any system grows in an asymptotic non-linear manner as you close in on the 0 but never reach it. That's a nice way of looking at "systems with embedded software" and their failure.
The unfortunate part is that I'm right now having to spend non-linear time in creating these shifts to close the probability towards 0. It does become exciting quite often as you crack the jigsaw puzzle a few pieces at a time.
Another friend debunks from work to take a really long New year weekend vacation. That would leave me hunting down more bugs sitting by myself. I do like doing it, but sometimes it can grow to become quite a weight bearing down on oneself.
Coming back to the main thing, Camera's are odd devices - the modern digital video sensors. The CMOS Sensor Interface originally dismissed as a lower quality (and therefore low cost) alternative has gained popularity with much change in technology. Most sensor companies have decided to put a Application Specific Digital Signal Processor with their Sensors. This actually means that even if a CMOS Sensor is sensing video with less accuracy and sharpness than its cousin, the CCD, we could have "patches" or workarounds that "post-process" the captured image and show it to be of better quality in digital terms.
As these sensors are intended to be integrated in very small designs, they are generally low power consuming. That might seem like a feature to most people, however that means strict restrictions in communicating/programming a CMOS sensor. The major part of the problem that I've been tackling through the day has been on sequencing the program to the DSP paired with the CSI (CMOS Sensor Interface.)
Debugging it seems would occupy a major portion of the timeline of any product development. It is sometimes an interesting exercise if you would discount the human communication aspects at the time of facing a blocker and working through it. Mildly put whenever you encounter major problems in any product/service that on sale would fetch revenue, someone needs to be "accountable" for the "delay" (therefore loss of opportunity) in providing a consistent solution (even a workaround if it were reasonably secure and consistent.)
I do remember Alan Cox's speech on ratio of errors in hardware versus software on which I disagree entirely with his opinion that hardware is relatively much more bug free. I see that hardware is designed in a generic manner to send most of the complexity to "replaceable" and/or "upgradeable" software. This would mean that with higher complexity and offer of features over a generic platform, software would take the bane of being more buggy whenever engineered within strict time-frames with requirements changing along side (on the assumption that software can adapt and incorporate changes much easier than firmware/hardware.) Further, I see that a good number of hardware bugs (including the infamous pentium f00f bug) were worked around in "software."
So whenever a system as a total malfunctions, as most of its features rest in software, so do most of the errors (proportional to the features.) Unfortunately this relationship of software[features:errors] is not normally linear. I would assume that the mathematical non-linear relationship is statistically acceptable in any system that is operational with almost 0 probability of total failure and almost unity probability of being functionally useful for a predetermined set of tasks.
With reliability paradigms existing, like 5 nines or 7 nines, it is reasonable to assume that man-made system in an open environment has a 0 probability of failure (and therefore total perfection.) So engineering time spent in tilting the probability of failure towards 0 for any system grows in an asymptotic non-linear manner as you close in on the 0 but never reach it. That's a nice way of looking at "systems with embedded software" and their failure.
The unfortunate part is that I'm right now having to spend non-linear time in creating these shifts to close the probability towards 0. It does become exciting quite often as you crack the jigsaw puzzle a few pieces at a time.
Labels:
camera,
software. debugging,
work
Wednesday, 26 December 2007
A Good Christmas!
This Christmas, I chose to have a full holiday from Saturday all the way till Tuesday making it a really long weekend. Mom and Dad visited as planned, and we had a good time together. Bangalore, it seems wasn't as cold as Thanjavur at least for these days as a tropical cyclonic formation had rained cats and dogs there making it much colder. The temperature though with lesser humidity did make me feel quite cold.
Christmas was warm and we had food from a good friend. We all watched more than a fair share of Television as moving around Bangalore wasn't really the in-thing to do. On Christmas day we went over to St.Mark's for the service. It was unusually crowded and we were lucky to get seats in the second row to the left. I did enjoy the service, though earlier I was quite lazy to actually leave for church having coded for my pet-project till late night on christmas eve..
A good friend called and wished me and parents. Many relatives got in touch to wish us all a merry Christmas. Mom had brought two cakes made by a friend and that was really nice. I also had a longish phone conversation with my niece, and also wished my Sis and family. They had braved the Delhi cold for the watch-night service which ended shortly after midnight.
Today, Mom and Dad left for home, which due to bad roads and construction work on the way, took almost 10 hours. They left about 7:20am and reached about 5:15pm which was almost the same time they had taken on their trip to Bangalore. The only other person celebrating Christmas at office (people from Goa having returned to their homes) was Natarajan, D-Link's new Marketing head. My Boss was excited about a movie named "Welcome" and was encouraging us all to watch it.
Indeed, it was truly a merry Christmas! I loved it. It helps me prepare myself for my new-year resolutions which would hold quite strong this 2008, as my ever increasing commitment to new-year resolutions is at an all-time high.
Christmas was warm and we had food from a good friend. We all watched more than a fair share of Television as moving around Bangalore wasn't really the in-thing to do. On Christmas day we went over to St.Mark's for the service. It was unusually crowded and we were lucky to get seats in the second row to the left. I did enjoy the service, though earlier I was quite lazy to actually leave for church having coded for my pet-project till late night on christmas eve..
A good friend called and wished me and parents. Many relatives got in touch to wish us all a merry Christmas. Mom had brought two cakes made by a friend and that was really nice. I also had a longish phone conversation with my niece, and also wished my Sis and family. They had braved the Delhi cold for the watch-night service which ended shortly after midnight.
Today, Mom and Dad left for home, which due to bad roads and construction work on the way, took almost 10 hours. They left about 7:20am and reached about 5:15pm which was almost the same time they had taken on their trip to Bangalore. The only other person celebrating Christmas at office (people from Goa having returned to their homes) was Natarajan, D-Link's new Marketing head. My Boss was excited about a movie named "Welcome" and was encouraging us all to watch it.
Indeed, it was truly a merry Christmas! I loved it. It helps me prepare myself for my new-year resolutions which would hold quite strong this 2008, as my ever increasing commitment to new-year resolutions is at an all-time high.
Sunday, 23 December 2007
When Saturn Smiles
Saturday is usually a pretty gloomy day with not much plan on working things out. This Saturday thankfully was different with my parents at home. There was a lot of the usual conversation that goes on at home; the usual Christmas clothes and more of the Christmas spirit than the decorations which is a lone star in the house that ain't attributed to me.
Nothing else was done through the whole day. Parking arrangements were made where possible to accommodate the car over night. Plans of visiting friends are on schedule; except that most schedules haven't been synced.
Nothing else was done through the whole day. Parking arrangements were made where possible to accommodate the car over night. Plans of visiting friends are on schedule; except that most schedules haven't been synced.
Friday, 21 December 2007
Battling the Passe
My whole day was spent in trying to find the source of a many an issue, each of which, if eliminated would make the product I am working on look more polished. The more critical things having been addressed, these are what I term less critical, but necessary finishing touches.
Yet, when you are working on a product where the components are by and large passe and someone has already done it before, probably better; the only way out in software is sometimes fix the symptom of the problem before you find what really causes it. In most cases tracing aetiology of indeterministic and non-repeatable bugs happens by chance.
I believe that the chief architect of a product must anticipate and understand what is necessary rather than what is best. There must be an incentive for providing in short time the necessary ones before closing in on the best solution which would be an end-point. This requires a vision and imagination of a product long before one has even got to the drawing board. This is the one thing I see lacking in completeness.
Christmas season already having arrived, I would like to think of the pleasant things in life and rather cherish the time than crib about bad architects. One can spend hundreds of hours on a badly designed product and achieve nothing much, save wasting precious time. People justify why they "could not" have achieved better once the design imposes constraints that are hard to work around. Last Christmas a prototype of this product was made ready and had a problem no one anticipated, but the architect decided was good enough. The results were of course discontent remarks. The bridge between expectation and realisation wasn't built right. That would entirely be a PR exercise.
Despite the reasons, I am unhappy at being at the same level one year later. There are so many reasons one can attribute it to. Much could have been solved by stronger investment in testing equipment when there was known uncertainty with Silicon components and problems whose source was too difficult to identify with the limited debugging equipment. No one likes to take a risk that could pay off and get things solved. They'd rather waste time than money, as they have no idea that time in today's world is most of the times more precious than money.
If this product does fail in the market, it would be because of archaic architecture and management that is passe. The use of tools and debugging equipment that is not state of the art has added to the uncertainty. Expectation is a license that is free for all, but not by forcing people to slave longer.
Yet, when you are working on a product where the components are by and large passe and someone has already done it before, probably better; the only way out in software is sometimes fix the symptom of the problem before you find what really causes it. In most cases tracing aetiology of indeterministic and non-repeatable bugs happens by chance.
I believe that the chief architect of a product must anticipate and understand what is necessary rather than what is best. There must be an incentive for providing in short time the necessary ones before closing in on the best solution which would be an end-point. This requires a vision and imagination of a product long before one has even got to the drawing board. This is the one thing I see lacking in completeness.
Christmas season already having arrived, I would like to think of the pleasant things in life and rather cherish the time than crib about bad architects. One can spend hundreds of hours on a badly designed product and achieve nothing much, save wasting precious time. People justify why they "could not" have achieved better once the design imposes constraints that are hard to work around. Last Christmas a prototype of this product was made ready and had a problem no one anticipated, but the architect decided was good enough. The results were of course discontent remarks. The bridge between expectation and realisation wasn't built right. That would entirely be a PR exercise.
Despite the reasons, I am unhappy at being at the same level one year later. There are so many reasons one can attribute it to. Much could have been solved by stronger investment in testing equipment when there was known uncertainty with Silicon components and problems whose source was too difficult to identify with the limited debugging equipment. No one likes to take a risk that could pay off and get things solved. They'd rather waste time than money, as they have no idea that time in today's world is most of the times more precious than money.
If this product does fail in the market, it would be because of archaic architecture and management that is passe. The use of tools and debugging equipment that is not state of the art has added to the uncertainty. Expectation is a license that is free for all, but not by forcing people to slave longer.
Labels:
architecture,
passe,
product,
work
Sunday, 16 December 2007
A Weekend that wasn't so gloomy
This weekend, I have been following up with everything that I've been doing over the week in my spare time. I decided to do some real coding and come up with something creative that I could probably deploy even at work. The result is something quite nice where I've pieced together the initial ingredients for what should become a useful toolbox for embedded system/user-space applications. Part of my drive was to create a usable replacement for busybox which almost stands out as the single swiss-army-knife that embedded linux deployments use.
At this stage I haven't started a project page and involved more people, but through the next week that should be possible.
I was also tweaking the iwp3945 drivers as I had quite some trouble getting my custom kernel working on my laptop with wireless access enabled. Pairing with the AP wasn't ever happening. While all this was on, I needed to move a heavy table near my desktops and pulled a muscle and probably tore a ligament in my back. I took some rest finally and feeling much better am just trying to cruise on with the code after reading some interesting articles on anthropology.
It seems that the product I've been working on at office would finally hit the road after one last weekend of stress testing. I haven't heard someone screaming for help which means there is a stable set of system software that should be able to take it without surprises.
On Saturday, I met up with a friend after quite a while having some time to have a long conversation with both of us not too busy. I did experience the horrific traffic on MG Road in Bangalore in an Auto (Driving my Car was out of the question.) This being a Saturday, it was probably amplified thanks to the inching work on the Bangalore metro project.
At this stage I haven't started a project page and involved more people, but through the next week that should be possible.
I was also tweaking the iwp3945 drivers as I had quite some trouble getting my custom kernel working on my laptop with wireless access enabled. Pairing with the AP wasn't ever happening. While all this was on, I needed to move a heavy table near my desktops and pulled a muscle and probably tore a ligament in my back. I took some rest finally and feeling much better am just trying to cruise on with the code after reading some interesting articles on anthropology.
It seems that the product I've been working on at office would finally hit the road after one last weekend of stress testing. I haven't heard someone screaming for help which means there is a stable set of system software that should be able to take it without surprises.
On Saturday, I met up with a friend after quite a while having some time to have a long conversation with both of us not too busy. I did experience the horrific traffic on MG Road in Bangalore in an Auto (Driving my Car was out of the question.) This being a Saturday, it was probably amplified thanks to the inching work on the Bangalore metro project.
Sunday, 9 December 2007
Saturday Lazed out
This Saturday wasn't too different from the many I've spent in the past weeks. I did very little "useful" work. I was watching some movies, playing games, randomly reading kuro5hin, slashdot. I had skipped plans of visiting foss.in on the last day out of partial disinterest. It is bad, I should've gone for a friend's talk at least, but heck what I never made to within 9 km of IISc Bangalore. My chauffer's not in town and with my direction senses I wouldn't take the right diversions (to a straightforward route.) I simply didn't get down to doing it and instead cocooned myself at home.
I was hoping to write an arm related code commentary that went out of the window thanks to movie watching. Then I did some PC maintenance and updated it for vulnerabilities. That should be the only useful thing that went on the whole day. I just lived on chocolates. No noodles, nothing else. (Bad Idea, this too.) Hopefully Sunday would be better as it has been from last week with more personal productivity.
I was hoping to write an arm related code commentary that went out of the window thanks to movie watching. Then I did some PC maintenance and updated it for vulnerabilities. That should be the only useful thing that went on the whole day. I just lived on chocolates. No noodles, nothing else. (Bad Idea, this too.) Hopefully Sunday would be better as it has been from last week with more personal productivity.
Friday, 7 December 2007
A Debugging Day
Today, the early part of the day was spent in the unbiased understanding that out of five of us in our team three were attending a training session. That left me and another teammate in opposite cubicles sitting and feeling more lonely than anything else.
Through the day, I scanned through more CVs and Resumes, shortlisting a few after some careful thought. We also had a trip planned that had to be rescheduled to a prior date necessitating immediate action to book to/fro tickets for 4 (including myself.) My reporting head did a really dedicated job at getting this done.
I went through the next phase of debugging everything in a strange audio driver for one of the products I am working on. I found that "readprofile" gave very low granularity and actually only gave a slight hint on what we should be looking for. It did give some positive results, but we have something that always ends up in a cascade failure. I now need to work my brain on the actual cascade failure to really get the indeterminate problem sorted out.
Finally, the day ended with more than an hour discussing our moving to a new facility, improving some processes and the last item of the agenda scratched out as we ran out of time. Phew! I got back to debugging with another geek and we did build some ground after which we chatted and wasted at least half an hour before I got to exit from office.
Come home, and I had noodles for dinner as that would be the quickest thing to prepare at this time. That done, I didn't have much else to do than to type out into my blog. Ultimately only the debugging thing stays fresh in my mind though I'd actually list today as a very productive one.
Through the day, I scanned through more CVs and Resumes, shortlisting a few after some careful thought. We also had a trip planned that had to be rescheduled to a prior date necessitating immediate action to book to/fro tickets for 4 (including myself.) My reporting head did a really dedicated job at getting this done.
I went through the next phase of debugging everything in a strange audio driver for one of the products I am working on. I found that "readprofile" gave very low granularity and actually only gave a slight hint on what we should be looking for. It did give some positive results, but we have something that always ends up in a cascade failure. I now need to work my brain on the actual cascade failure to really get the indeterminate problem sorted out.
Finally, the day ended with more than an hour discussing our moving to a new facility, improving some processes and the last item of the agenda scratched out as we ran out of time. Phew! I got back to debugging with another geek and we did build some ground after which we chatted and wasted at least half an hour before I got to exit from office.
Come home, and I had noodles for dinner as that would be the quickest thing to prepare at this time. That done, I didn't have much else to do than to type out into my blog. Ultimately only the debugging thing stays fresh in my mind though I'd actually list today as a very productive one.
Thursday, 6 December 2007
Foss.in
Today, I spent time actually listening to people on Free/Libre Open Source Software (FOSS/FLOSS) at the Foss.in Conference. It was a nice experience listening to many of the speakers. I enjoyed Rusty's talk more than anything else. The event had some strange things. The sponsors (including IBM, Sun, Google, ABB, GMI/Trolltech, Redhat and others) were seriously headhunting.
The organisation (of the event) had its share of technical snags. The one thing that did function right was WiFi access to all the delegates. The rest was a bit shabby but better than all the earlier events. I also got to meet a few old friends and acquaintances. In some ways my hacker (MIT sense of the word, wanting to write code that adds features/solve problems in a cool way) side was ignited.
It was also different from a normal day at work which also added up. I am feeling a bit bad that I wouldn't be attending a "want to be there" talk tomorrow by Harald Welte. But hopefully that should be doing something nice at work.
The organisation (of the event) had its share of technical snags. The one thing that did function right was WiFi access to all the delegates. The rest was a bit shabby but better than all the earlier events. I also got to meet a few old friends and acquaintances. In some ways my hacker (MIT sense of the word, wanting to write code that adds features/solve problems in a cool way) side was ignited.
It was also different from a normal day at work which also added up. I am feeling a bit bad that I wouldn't be attending a "want to be there" talk tomorrow by Harald Welte. But hopefully that should be doing something nice at work.
Labels:
event,
foss,
friends,
linux,
recruitment
Sunday, 2 December 2007
Another Saturday!
I usually don't have a "plan" for Saturday. I let it go the way my moods go. This time I decided I'd watch "The Devil Wears Prada." A nice movie indeed. I also got to watch "Zodiac" which was quite another average Hollywood movie. It seemed that that "Zodiac" was more about FBI incompetence than about a serial killer being hunted down by a civilian who just got interested from his boring day job.
Otherwise I didn't do much about eating except some noodles for lunch and chips'n chocolates for dinner. Well, that's the standard. I didn't get out of the house except to return the movies I'd got. That was that.
The rest of the day was trying out configurations on my new phone which was amusing for perhaps an hour. At least three cups of double espressos to keep me going (whew!) My plan (for some time) has been to hack on an opensource project on Saturdays and Sundays. The truth is I do have the time, I just don't get myself to do it. It seems its about time, I did that on Sunday and stop wasting time on movies (being the movie buff I am.)
Strangely there were absolutely no phone calls to me (except from the service provider about some new features for free costing $$$.) It was in that manner quite peaceful. I did not take the time out to call anyone either. I sometimes think I'm building a cocoon around me, but that isn't entirely factual.
Otherwise I didn't do much about eating except some noodles for lunch and chips'n chocolates for dinner. Well, that's the standard. I didn't get out of the house except to return the movies I'd got. That was that.
The rest of the day was trying out configurations on my new phone which was amusing for perhaps an hour. At least three cups of double espressos to keep me going (whew!) My plan (for some time) has been to hack on an opensource project on Saturdays and Sundays. The truth is I do have the time, I just don't get myself to do it. It seems its about time, I did that on Sunday and stop wasting time on movies (being the movie buff I am.)
Strangely there were absolutely no phone calls to me (except from the service provider about some new features for free costing $$$.) It was in that manner quite peaceful. I did not take the time out to call anyone either. I sometimes think I'm building a cocoon around me, but that isn't entirely factual.
Saturday, 1 December 2007
The Carrot and the Stick
Before a "Grand Inauguration" of a new facility, at least my teammates were expecting their performance Bonus. Processing for the same and scoring was already done and the figures had already been presented on paper to the team. But like all efficient organizations and with the assistance of an absolutely insensitive clod of a reporting head (who ain't bothered coz he's got no financial deficit right now) this wasn't credited.
That meant a lot of people were unhappy. I had a bitter taste too after having detailed all the necessary information, nothing was working out.
I am probably very impatient in many ways. This of course helps me in more ways than it can harm me as I get things done on the double.
I am not very happy either at the end. I might end up not visiting the Grand Inauguration even if I could, just for saving a few bucks on transport (fuel) and spending some quality time playing around with the linux kernel.
There were other precipitating factors like the inability to recruit new people because the company's offer of salary is too disagreeable to anyone whom we select. Market correction of the salary is a long way down the line. I am sure more people will quit before they realize. The point is the management think they have the Carrot and the Stick. It looks to me like the Stick is with the people who actually create it. If you don't invest you get nothing out of people or bricks. The Truth being, today's world does call people "Human Resources" and are more interested in "Capital Assets" and "Human Resources" like other resources are a liability.
(Yeah these are the words of a disgruntled employee in part.) That doesn't change what's what at the end. You give everything you have when you want to get more than what you have; that's the personal loyalty sense of today. Otherwise it has a negative effect that you stop giving everything you can give, that makes you dull. You'd rather switch and do more rather than stay back unhappy and do less. That seems to be a valid argument to me.
The unfortunate part is, no matter where you go, you're still a brick. There are those who are Dogs in the manger (managers) who'd rather never give up for a horse.
There's just the watermark of what you get that gets adjusted. When you reach it, you get unhappy all over again and switch. So where do you stop this all? One way, is to start on your own with your dreams and put yourself and everything you have at risk to get much more than what anyone else can offer. The other way is to learn to change the place you're already in to think differently. The former being easier (although too risky), the latter being much more difficult (although it looks less risky.)
That meant a lot of people were unhappy. I had a bitter taste too after having detailed all the necessary information, nothing was working out.
I am probably very impatient in many ways. This of course helps me in more ways than it can harm me as I get things done on the double.
I am not very happy either at the end. I might end up not visiting the Grand Inauguration even if I could, just for saving a few bucks on transport (fuel) and spending some quality time playing around with the linux kernel.
There were other precipitating factors like the inability to recruit new people because the company's offer of salary is too disagreeable to anyone whom we select. Market correction of the salary is a long way down the line. I am sure more people will quit before they realize. The point is the management think they have the Carrot and the Stick. It looks to me like the Stick is with the people who actually create it. If you don't invest you get nothing out of people or bricks. The Truth being, today's world does call people "Human Resources" and are more interested in "Capital Assets" and "Human Resources" like other resources are a liability.
(Yeah these are the words of a disgruntled employee in part.) That doesn't change what's what at the end. You give everything you have when you want to get more than what you have; that's the personal loyalty sense of today. Otherwise it has a negative effect that you stop giving everything you can give, that makes you dull. You'd rather switch and do more rather than stay back unhappy and do less. That seems to be a valid argument to me.
The unfortunate part is, no matter where you go, you're still a brick. There are those who are Dogs in the manger (managers) who'd rather never give up for a horse.
There's just the watermark of what you get that gets adjusted. When you reach it, you get unhappy all over again and switch. So where do you stop this all? One way, is to start on your own with your dreams and put yourself and everything you have at risk to get much more than what anyone else can offer. The other way is to learn to change the place you're already in to think differently. The former being easier (although too risky), the latter being much more difficult (although it looks less risky.)
Labels:
company,
management,
personal,
work
Subscribe to:
Posts (Atom)