|
"I know that's the kind of challenge we will all grow by taking on"
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
... do you expect to earn anything more for that?
|
|
|
|
|
The title says everything.
|
|
|
|
|
Who ever had a bonus?
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
In US it's a kind of yearly thing.
|
|
|
|
|
I've been one of the "consultants to speed things up" - actually worse, to "rescue projects."
It's soul crushing. Half the time you're not even there to fix things. You're there because the management wants to scrub the entire project - and with it the development team whose morale is already destroyed - and they'd rather not do the laying off themselves or at the very least you're there as something they feel they can rationalize it with. Basically it's a fait accompli by the time you arrive.
 
It paid well in raw figures, but they can never pay me enough to do it again. It's a horrible job.
Real programmers use butterflies
|
|
|
|
|
|
I've been in that situation once (or actually it was that my contract wouldn't be renewed) and I had to hide excessive joy.
Basically, my customer had a contract with my employer and the customer decided to let me go.
Since I was still employed by my employer, you'd think that wouldn't hit me financially, but it did because of the type of relation we had.
My employer even tried to get the contract renewed, but I asked begged them not to 
Soon after that I quit and started my own business, so far with some success 
|
|
|
|
|
I got the most percent item 2 & 3.
it seems that most people don't like managers as such style...
diligent hands rule....
|
|
|
|
|
|
Fool me once, shame on you.
Fool me twice, shame on me.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
|
|
|
|
|
Exactly - I pushed back and stopped working weekends. Made a huge difference.
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music."
-- Marcus Brigstocke, British Comedian
|
|
|
|
|
Yup. I'll work extra occasionally in an emergency. But your [customer/manager/coworker] chronic failure to plan is not my emergency. And if you show a pattern of saying something asap is a critical need and then acting in a way that says otherwise, your emergency declarations lose any relevance to me beyond "what do I work on next".
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
|
|
|
|
|
Erik Burd wrote: 3) Tells me "cancel your weekend - we need this implemented by first thing for the demo at 8am Monday morning!"
4) gets a lawsuit for breaking work laws, loses job
FTFY
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
|
It is vitally important not to work out-with contracted hours unless you are paid money or you get time back (in both cases more than the time you use). You can, if you have a sensible manager, play come and go with your hours. They take a relaxed attitude to you nipping out to attend to personal business during office hours but in return you work a bit later or be on call at the weekend, that helps your employer in two ways, you are a happier employee with a better work-life balance, and they get you out of hours to do work that needs done then. BUT extra working must not become routine and where possible no-one should be expected to work weekends or evenings without notice and definitely not without compensation.
Older employees need to stand up for this as an example for younger employees. Younger employees: no-one gets credit for working stupid hours ever, and hardly anyone gets fired for not doing that. Keep your hours under control and if they do fire you, they did you a favour, go find a better employer and do a job for them.
|
|
|
|
|
as to the above; although I guess some of the above would be more of a blessing than a curse!!!
|
|
|
|
|
I'm going on vacation, it's all yours.
The less you need, the more you have.
Even a blind squirrel gets a nut...occasionally.
JaxCoder.com
|
|
|
|
|
Boss: We also needs feature XYZ.
Me: WTF? Why didn't you told me before? XYZ requires a completely different architecture ...
Boss: Nah, that's just a small difference ...
Me: rewrites the lot
Boss: By the way -- we need it tomorrow morning ...
Repeat and rinse ...
|
|
|
|
|
"We're moving the highly complex app you've been working on to a low/no code environment. It should be easy, and we expect you to assist with the transition, after which you will be fired. You're still held to the delivery schedule."
"The security guys have determined that nobody should be able to use the browser's dev console. Ever. You're still held to the delivery schedule."
"You have new training assigned to cover the latest woke panic situation might be. It only takes two hours, so you're still being held to the delivery schedule."
"It has been determined that the devs cannot have even read access to the test, qa, or production databases to assist in forensic debugging of live data, even if the bug doesn't exist on the dev environment. You're still being held to the delivery schedule."
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
- dev tools are locked down to only access the dev environment
- dev tools can only be run in a remote VM (and a rather underpowered one at that)
- only a prescribed set of dev tools can be used (you can try to get a new tool approved after some red tape, but forget about it if it's not commercially-supported, available as an admin-only installer package, and the company is willing to pay the license)
- websites on the dev VM are blacklisted by default, and getting a host whitelisted is like pulling teeth
- the dev VM is subject to 90-day password expiration policy
- internet and email has to be accessed from a separate VM, using a separate login, which is also subject to the 90-day password expiration policy
- the physical machine from which we access the dev and internet VMs uses yet another login, also subject to the password expiration policy. We are literally unable to do anything on this machine apart from connecting to VMs
- any kind of production access (databases, file systems, etc.) requires yet another VM with yet another login (with password expiration), and it is extremely locked-down
- the physical machine and the internet VM both need to be connected to VPN, requiring yet another password to be remembered (fortunately we only need to reconnect to VPN every couple of days)
- the physical machine, as well as all of the VMs, lock their screen after 5 minutes of idle time
As a consequence of all of this, my day consists mainly of switching back and forth between VMs and trying to remember the passwords. And if someone messages or emails me, the notifications only go to the internet VM (which I may or may not have visible/unlocked), so I might log onto the internet VM after a long stint on the dev VM only to find that people have been furiously messaging me for the last hour wondering why I'm "slacking off" (because I didn't reply to them quickly enough). In order to prevent this, I have to interrupt my work frequently to switch VMs just to check if the sky is falling down. And yet I'm still held to the same delivery schedule. It's madness!
|
|
|
|
|
Back in the day, deadlines that kept moving or something they've never mentioned before.
I laughed at "The customer requested a new feature and I said yes. I'm sure that's OK, right?"
I work in custom software, so what I write, I write for the customer and if they want a new feature they're going to get it!
In fact, my manager sold "no" in the past and that ticks me off more.
Customer is king and all, guess I'm just customer oriented that way.
If we're selling no, for whatever reason, we're not doing a good job (either planning or, worse, because we just can't integrate it in the mess we call software)!
Now, if you're working on software that's used by multiple customers (maybe even thousands) and you have to write a new feature for one specific customer... That's a different story
|
|
|
|
|
I once got told to use an existing reporting engine (internal) to create a report much larger than any we ran at that point. Existing reports were typically 2 pages at most, but this whopper would have been 14-50 pages.
We'd already seen exponential growth in the times reports took to run, depending on the size of the report.
It took me half a day to write a proof that by the time the report ran, the person requesting it would be dead, on current hardware at the time.
I got a raise for that one, on the basis of saving time and effort.
Sometimes the correct answer is no, but you need to able to justify it.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Rob Grainger wrote: Sometimes the correct answer is no, but you need to able to justify it.
Sander Rossel wrote: If we're selling no, for whatever reason, we're not doing a good job (either planning or, worse, because we just can't integrate it in the mess we call software)!
I don't know, but if you can't report on your data, even just 14 to 50 pages, something seems off to me...
What did you do with that data if not report it?
Maybe you had to aggregate the data up-front so reporting would've been easier?
I know what you're saying, since I've seen it many times before, but every time the problem was the software and the way we stored data, not the customer's request.
|
|
|
|
|
Just happend a couple of years ago:
* Do me a favour and write a program for problem xyz. It's really simple...
* Please handle customer support problem.
* Please check quality of produced devices xyz.
* Your parcel acceptance was not acceptable. Please fill out form xyz. Under xyz you will find any documentation.
* What is the current status of xyz? -> Ok I didn't know I should handle it!
* When is software xyz ready? -> When I got time to work for software! -> Ok when is software ready?
All at the same time...
This typically happens before fairs and other meetings. Therefore I hate fairs because everbody gets nervous, most errors will be found in this time, you will be overloaded with work, interruption level is always high (> 3) and sometimes you will be drawn into pointless discussions like talking about implementation / micro optimisations when you haven't already understood software requirements.
Thats burn out conditions. But afterwards everything returns to normal level.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
