|
1000X this! My organization is in the process of shifting to a security model where:
- 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.
|
|
|
|
|
You're on a new project starting today, but you've to support your current project for all time to come, working beyond office hours if needed.
|
|
|
|
|
For me "Now that you're done I'm handing the system over to the other team" it's the best thing they can announce. No longer my problem, sunshines!
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
|
|
|
|
|
Anything that is unrelated to elephants is irrelephant Anonymous
- The problem with quotes on the internet is that you can never tell if they're genuine Winston Churchill, 1944
- Never argue with a fool. Onlookers may not be able to tell the difference. Mark Twain
|
|
|
|
|
That's why I never share my phone # with my direct manager. Especially as it's a cell phone, and they don't pay for it...
|
|
|
|
|
All my phones are strangely malfunctioning, doesn't matter the brand, age... I am not receiving any call, who knew it.
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
|
|
|
|
|
I have been known to tell people in the past that I only ever answer calls coming from people in my phonebook. Funnily enough, it's only a few seconds later that I often need to decline the offer of their number.
I think Dale Carnegie may have written about that technique..
|
|
|
|
|
We're get used to manager, C level, or customer related things, they're part of the job, unfortunately. We can't control everything. I can understand that.
But...
What do you mean we're out of coffee?
|
|
|
|
|
When there is no money for office supplies (e.g. coffee), next week there will be no money for payroll. It's a deathnail.
|
|
|
|
|
I once was employed by a software firm like that. Every week they would cater a huge lunch for staff. Then after lunch announce how they would be short on payroll...
It especially ranked when they made sure the co-op students were paid (otherwise the universities they came from would have yanked them out).
When I started, I made it clear if I didn't get paid I was out of there, so I lasted for quite some time. But eventually it happened. I also happened to hang onto the Macbook pro they gave me to work with, until they finally settled and paid me...
|
|
|
|
|
When there is no coffee, the likelihood of violence skyrockets. Always bad for development.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|