Yes, that's the title, but I don't remember that particular story. But if Larry told it, you have to take it with a big grain of salt, for he's a habitual embellisher.
the companies around here tend to value experience a great deal.
For devs and architects that's rare in my experience. Maybe analysts and project managers. Try to move into management or quasi-management as you get older. Old coders are rarely welcomed. There are exceptions, but you cannot tell early if you are one. You may get RSI (worn out hands).
but it's also important to have somebody with 40 years of experience who has seen all of the changes in the industry and can offer a different perspective
A young architect convinced the boss, who stopped programming decades ago, that a bastardized MVC stack with lots of "service layers" that don't do anything useful is the way to go. It's a variation of the "magic Legos" fallacy. They couldn't give practical example of future uses, only buzzwords. It increases code size about 4x over what it would normally be.
The older devs realize it's bloated and that the extra layers are unlikely to pay off in the future, but the architect brownoses the boss well and we are stuck with a Rube Goldberg design. The other young devs don't know any different and realize the buzzword parts are good resume padding. It's now a typing contest, and the younglings will probably win it. Our days are numbered. I suspect the architect did it on purpose to control who is on the team, and doesn't really believe his own magic-Legos bullshit.
1. Co's want to match a combo of skills very specific to their company. The product brand combinations a given company uses is purely coincidental and rarely the same for 2 orgs.
2. They don't want to wait for a training curve for some of their products: they want the applicant to hit the ground running. This is not realistic, per #1.
3. They want a tech whiz but also somebody with good people skills. Such are relatively rare and would probably cost a company more to acquire if they are realistic.
4. What HR filters out and what the department of the target employee really want are often out of sync. The right hand is not talking to the left hand of the org; or it's political infighting.
Virtual machines and cloud computing have vastly increased the utilization of the hardware we do have. It's no longer a case of a company having 20,000 servers, and collectively they're idle 85% of the time. Now the same company has perhaps 1,500 powerful physical servers running 20,000 VMs, and the physical hardware is idle only 5% of the time.
People don't buy database hardware for smallish apps, they buy it for big-iron apps that have a lot of transactions and/or data. Small apps with low CPU utilization would typically put on a software-based database (regular server).
The switch to VMs has also put more focus on writing efficient code
If you mean custom/specialty apps, then people costs are usually far more than hardware casts. Machine-efficient code that takes more developer effort to work with is not an economical trade-off for most orgs. A bigger machine is usually cheaper than a bigger dev staff.
Radio stations play all those ads because they can. I usually flip he station when ads come on anyhow. If competition eats away market share, then they may reduce ads. The alternatives to listening to the radio while driving either require a subscription or selecting and preparing material before the drive (unless you like the same songs over and over).
After that, you are increasingly likely to be age discriminated out of a job regardless of how current you keep your skills.
Part of it is that when one is experienced, it's hard to be exuberant about stupid IT fads that PHB's or bullshit artists push on the organization. "Oh boy! Another stupid fad to drain time and money! Weeeee!" Newbies don't know any better: ignorance is bliss, and it's hard to fake bliss in such a workplace. How does one stay enthusiastic about wasteful fads? Take happy-pills after 45?
No, it de-volved. We now do 10x the coding with layers of libraries to get something clunky, error-prone, non-future-proof, and that wastes screen real-estate. Some apps don't have to cater to many device sizes and input methods, and one shouldn't have to pay a multi-size/device complexity tax for them. Internal or specialized applications can potentially sacrifice such flexibility to be quick and simple to develop.
Maybe the industry will fracture into different GUI frameworks for different needs rather than the one-size-fits-all approach now often used.
This was 2001 it was almost impossible to find tech jobs at the time, after about 3 years of unemployment I gave up and took a job at much lower
Amen! I remember those miserable days also. I lived in CA at the time, ground zero of the dot-com crash. I got out-of-state contracts to survive, often leveraging legacy skills that dot-com newbies didn't have. The travel was rough on the family, and often the contract middle-men didn't pay up, creating court hassles. I was looking to bail IT for another career.
There was also a mini-IT bust in the early 1990's that many forgot about. "Glasnost" caused aerospace to cut back, and CA had lot of aerospace companies. This dumped a lot of techies on the market. That slump didn't personally affect my job at the time (other than perhaps reducing my options at other co's), but I have lived through two IT slumps.
There may be another bubble brewing now, one cannot tell. If it smells like a bubble, quacks like a bubble, and pays like a bubble, it's probably a bubble.
The front-end stacks are too fat and I suspect some new technology and/or standard will come along to simplify front-end programming, throwing lots of programmers on the street. It's roughly comparable to what VB did to C++ GUI programming, although GUI programming was expanding rapidly then such that all boats floated higher, even C++ boats. But that may not be the case with web front-end. I just sense a bloat fall-out someday.
But you have lousy Java coders and good Java coders. The language itself is often secondary to issues of good general design/planning, attention to details, and caring about quality. I notice the language I use makes only about a 15% difference in my general productivity. Leverage their strengths and be careful around their weaknesses.
Slashdot Mirror
From a gastronomical standpoint
Yes, that's the title, but I don't remember that particular story. But if Larry told it, you have to take it with a big grain of salt, for he's a habitual embellisher.
Screw healthy, just get plastic surgery.
Simple fix, let's just eat all the cannibals.
I hear it tastes like plastic chicken.
I just read the book about Oracle and Larry by Mike Wilson. Larry is basically a smarter Trump.
WTF are you yammering about? Is this about college speakers and alleged censorship? Diff topic.
If I wanted far-off pontifications from rich egotistical blowhards, I would have voted for Trump.
For devs and architects that's rare in my experience. Maybe analysts and project managers. Try to move into management or quasi-management as you get older. Old coders are rarely welcomed. There are exceptions, but you cannot tell early if you are one. You may get RSI (worn out hands).
A young architect convinced the boss, who stopped programming decades ago, that a bastardized MVC stack with lots of "service layers" that don't do anything useful is the way to go. It's a variation of the "magic Legos" fallacy. They couldn't give practical example of future uses, only buzzwords. It increases code size about 4x over what it would normally be.
The older devs realize it's bloated and that the extra layers are unlikely to pay off in the future, but the architect brownoses the boss well and we are stuck with a Rube Goldberg design. The other young devs don't know any different and realize the buzzword parts are good resume padding. It's now a typing contest, and the younglings will probably win it. Our days are numbered. I suspect the architect did it on purpose to control who is on the team, and doesn't really believe his own magic-Legos bullshit.
I wonder why it didn't go off. Did it land in soft mud or something?
Yah, those beady windows and sloping roads look suspicious.
Because it's doing a face-palm.
1. Co's want to match a combo of skills very specific to their company. The product brand combinations a given company uses is purely coincidental and rarely the same for 2 orgs.
2. They don't want to wait for a training curve for some of their products: they want the applicant to hit the ground running. This is not realistic, per #1.
3. They want a tech whiz but also somebody with good people skills. Such are relatively rare and would probably cost a company more to acquire if they are realistic.
4. What HR filters out and what the department of the target employee really want are often out of sync. The right hand is not talking to the left hand of the org; or it's political infighting.
People don't buy database hardware for smallish apps, they buy it for big-iron apps that have a lot of transactions and/or data. Small apps with low CPU utilization would typically put on a software-based database (regular server).
If you mean custom/specialty apps, then people costs are usually far more than hardware casts. Machine-efficient code that takes more developer effort to work with is not an economical trade-off for most orgs. A bigger machine is usually cheaper than a bigger dev staff.
Just come into work anyhow. Maybe they'll forget they laid you off.
What's next, Procter & Gamble into bot-cars?
I hear ya. I ordered a Galaxy Note 7 for the 4th of July, and the damned thing would not blow up. Goddam fake!
Blindness? Bull! Trump stared directly at the sun without glasses and is perfectly nor.......oh, wait, nevermind.
Radio stations play all those ads because they can. I usually flip he station when ads come on anyhow. If competition eats away market share, then they may reduce ads. The alternatives to listening to the radio while driving either require a subscription or selecting and preparing material before the drive (unless you like the same songs over and over).
You typically have to board a plane to sabotage it. But a 300 mile rail line on the ground cannot be carefully guarded.
Part of it is that when one is experienced, it's hard to be exuberant about stupid IT fads that PHB's or bullshit artists push on the organization. "Oh boy! Another stupid fad to drain time and money! Weeeee!" Newbies don't know any better: ignorance is bliss, and it's hard to fake bliss in such a workplace. How does one stay enthusiastic about wasteful fads? Take happy-pills after 45?
No, it de-volved. We now do 10x the coding with layers of libraries to get something clunky, error-prone, non-future-proof, and that wastes screen real-estate. Some apps don't have to cater to many device sizes and input methods, and one shouldn't have to pay a multi-size/device complexity tax for them. Internal or specialized applications can potentially sacrifice such flexibility to be quick and simple to develop.
Maybe the industry will fracture into different GUI frameworks for different needs rather than the one-size-fits-all approach now often used.
Amen! I remember those miserable days also. I lived in CA at the time, ground zero of the dot-com crash. I got out-of-state contracts to survive, often leveraging legacy skills that dot-com newbies didn't have. The travel was rough on the family, and often the contract middle-men didn't pay up, creating court hassles. I was looking to bail IT for another career.
There was also a mini-IT bust in the early 1990's that many forgot about. "Glasnost" caused aerospace to cut back, and CA had lot of aerospace companies. This dumped a lot of techies on the market. That slump didn't personally affect my job at the time (other than perhaps reducing my options at other co's), but I have lived through two IT slumps.
There may be another bubble brewing now, one cannot tell. If it smells like a bubble, quacks like a bubble, and pays like a bubble, it's probably a bubble.
The front-end stacks are too fat and I suspect some new technology and/or standard will come along to simplify front-end programming, throwing lots of programmers on the street. It's roughly comparable to what VB did to C++ GUI programming, although GUI programming was expanding rapidly then such that all boats floated higher, even C++ boats. But that may not be the case with web front-end. I just sense a bloat fall-out someday.
But you have lousy Java coders and good Java coders. The language itself is often secondary to issues of good general design/planning, attention to details, and caring about quality. I notice the language I use makes only about a 15% difference in my general productivity. Leverage their strengths and be careful around their weaknesses.