|
Sounds like a friend who got acquihired there was lucky to get out when he did. He's a mysql guru; and at his prior company mostly helped customers who were murdering their DB performance with badly designed queries/lack of indexing. Rackspace decided he was too expensive to be client facing and then derped around trying to use him internally on projects that never actually went anywhere. He said it felt like they had no real idea what to do with someone with his skillset/abilities. 
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
|
|
|
|
|
UK celebrates 25 years of wasteful, 'underperforming' government IT projects • The Register[^]
Seriously? The ROOT cause of under-performing government IT projects is the "lowest bid" contracting system.Here's how it usually goes:
0) Government asks for bids on a new project.
1) Since the project is new, there is no current incumbent entity from which to gauge salaries, so bids come in at a reasonable (?) pay scale for the devs.
2) Two years later (or whatever the re-compete time frame might be), the incumbent re-bids, and competitors undercut the incumbent with their bids, thus winning the contract.
3) The new contractor company now has to find a way to keep the existing devs, usually be negotiating lower salaries, reduced benefits, or both. Of course, this causes a number of the experienced devs to leave (pissed off no doubt), and the new contractor company will fill those empty seats with devs that will take less money (and that means devs with less experience).
4) Every re-compete cycle, repeat steps 2 and 3, until the result is such a severe reduction of expertise on the dev team that there is nobody left that can actually do the work.
5) Fingers are pointed, the project is abandoned, and chalked up to a "lack of experience" on the part of the devs. Because management couldn't possible be the f*ckin problem.
I'm not a bitter old man, but I did stay at a Holiday Inn Express last night.
".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
modified 24-Jul-21 7:13am.
|
|
|
|
|
Only 25 years? Government projects have been underperforming since IT was a thing!
|
|
|
|
|
|
"No, darling, it's the Washington Post - Honest!"
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Seems more like Washington's Post.
"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
|
|
|
|
|
I saw a video of a KFC somewhere. Some bugger had hacked their self-serve ordering computers.
Same deal - porn..
|
|
|
|
|
I believe there may be a straightforward yes/no answer to this. I just want to find out if my way of thinking (being "hell no") is outdated.
There is a surprisingly low amount of information on this topic, the most relevant thing I could find is 11 years old, and back then the person who asked for a screen recording solution in order to keep track of a hired coder has received a lot of negative response and was advised to give it up, but that was 11 years ago. remote desktop - I have a programming contractor - how do I record their screen remotely? - Server Fault[^]
I've been a remote developer under various arrangements (employee, freelance..) for about 15 years now, and was always able to find work despite refusing to install any sort of screen capture / work hour tracking software. But my last application didn't go well as the employer insisted on screen capture. And while I know why I refused, that got me thinking, does one still has solid chance of acquiring a decently paid contract or a full employment these days without screen track? Is it that employer who is clueless or me? Has the situation changed with the new generations, new reality and all?
Rather than opinions (we all probably still know that capturing a coder's screen is counter productive (I think?)) I'd like some information from those with insight in this area, thanks.
|
|
|
|
|
"Hell no" would be very polite compared to what I'd tell them.
Their outlook is cretinous. You should be paid for what you produce, not for how many hours it takes. This assumes, of course, that the requirements don't change. The acceptance testing also needs to be fairly clear from the outset. After that, they leave you alone except for status reports and whatever ongoing discussions are required.
|
|
|
|
|
Greg Utas wrote: You should be paid for what you produce, not for how many hours it takes.
I'm working as a contractor right now and I would never knowingly agree to screen capture.
However, you *are* being paid for how many hours it takes, if you're being paid by the hour. The only time it works that you are paid by what you produce is if you are being paid a lump sum for the project.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I would never agree to that, and if someone wanted that of me it would be a huge red flag.
If you can't trust me, don't hire me. It's that simple. I'll find someone who can.
And if you don't trust *anyone* you have no business supervising people, and I want no part of that circus you're running.
That's my $0.02 as politely as I can bring myself to put it.
Real programmers use butterflies
|
|
|
|
|
I have been on both sides of the fence as a contractor and one who employs them and I have never used anything resembling that. As far as I am concerned, if you can't trust your contractor enough to be productive then you hired the wrong person.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
Rick York wrote: if you can't trust your contractor enough to be productive then you hired the wrong person.
Or you are the one having a problem
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Why trust an employer who doesn't trust you?
|
|
|
|
|
I have occasionally done contracting work outside my normal employment.
I would never accept any kind of work monitoring or screen recording software from a client. That tells me they're going to be a bastard about paying me, regardless of the quality or timeliness of the work I do.
Software Zen: delete this;
|
|
|
|
|
If they want visual entertainment in addition to engineering work, charge an extra fee, per hour, paid in advance, for each hour they want that entertainment 
Jokes aside, I think other people hit the nail on the head. It indicates a lack of trust, probably obsessive micromanagement, and potentially future payment disputes (you aren't doing it like I think you should, despite me not knowing anything about software engineering).
|
|
|
|
|
I very much agree with what everyone wrote and am glad to see that all is well at the moment. I guess I should have mentioned in the original question that I ponder about the near future as well.
During the googling that I mentioned, where queries were variations of "should remote coder accept screen recording", I managed to find only one hit with some sort of discussion about this practice applied on coders, multiple pages of remaining hits were exclusively advertisements for existing screen tracking solutions and articles about how to most efficiently track screens of your employees and contractors, only that one hit was about moral issues and anti productivity of this idea.
Looking back, when the business world adopts some unpopular and impractical method to the point that it becomes a norm (in most environments), you are not able to oppose by relying on statements such as "you must trust me", "I will never agree to this", "you are asking me to do it for your own amusement", "you are only looking for ways to pay me less", and "you are a control freak" or "you have mental problems". Not even the "I get less work done that way" would help to talk them into allowing you to breach the company's own policy. And the next thing you know, your only comfort is the assumption that your employer doesn't actually spend hours staring intensely into your screen. They don't really want to monitor you anyway, that screen recorder is just a necessary part of this hot new tool for developers that intends to really bring people closer together. At least the tool is a massive help when you code, can't live with it, can't live without it. And why would you worry if you have nothing to hide, right? So if such a hypothetical near future is possible, I guess we should be looking for the most solid arguments to prevent it from taking off.
Not to appear a hater, I do think that screen sharing could work well in a very limited number of cases, for example when a tiny team of equally dedicated developers wishes to create an atmosphere of everyone sitting in the same room, where they would be able to see each other's screens anyway and reap productivity benefits from that.
|
|
|
|
|
Kr4ft3r wrote: for example when a tiny team of equally dedicated developers wishes to create an atmosphere of everyone sitting in the same room, where they would be able to see each other's screens anyway and reap productivity benefits from that.
That's the stupidest thing I've read in a long time.
I turned down a 6-figure job back in the 80's because all of the devs were in a big auditoruium sized room with 8 devs sitting around big round tables. The noise was deafening. I don't know any devs that would enjoy or feel like the would benefit from such an environment.
".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
|
|
|
|
|
Because you have read it in the stupidest way that you could imagine. But I guess I wasn't clear enough, that tiny team would be 2-4 developers who are equally dedicated to a single project and therefore wouldn't mind sharing a room/screens and would even have benefits from that since everyone would be busy with their own work and only look at screens of others when they need to. Not the chicken coop that you described.
|
|
|
|
|
Kr4ft3r wrote: Looking back, when the business world adopts some unpopular and impractical method to the point that it becomes a norm (in most environments), you are not able to oppose by relying on statements such as "you must trust me", "I will never agree to this", "you are asking me to do it for your own amusement", "you are only looking for ways to pay me less", and "you are a control freak" or "you have mental problems". Not even the "I get less work done that way" would help to talk them into allowing you to breach the company's own policy.
It depends. If one is an employee then what you say is correct (although of course one can still withdraw one's labour and go elsewhere or never work there in the first place) but as a contractor it is different. A contractor has no requirement to adhere to "the company's own policy"; he or she has his or her own policies!
Also, even as an employee, it's not necessarily so clear cut. Companies cannot necessarily just do what they want. Whilst it might seem like it sometimes, not all companies just do whatever they want and ride roughshod over the feelings and thoughts of their employees; some actually do listen and do what works best for all.
And, of course, strikes sometimes happen over issues like this. I'm not in favour of strike action in general but if negotiation has been attempted and it was met with intransigence then temporary withdrawal of labour might be justified. (Although I expect I'd be resigning at that stage rather than going on strike).
Kr4ft3r wrote: I do think that screen sharing could work well in a very limited number of cases, for example when a tiny team of equally dedicated developers wishes to create an atmosphere of everyone sitting in the same room, where they would be able to see each other's screens anyway and reap productivity benefits from that.
Good grief, what benefits? Unless someone is walking around all the time looking at other people's screens (which means that he or she isn't doing their own coding work!) then they would not normally be able to see other people's screen anyway. I can see no benefits to be drawn from this scenario.
(Edited because I misread the initial message).
|
|
|
|
|
markrlondon wrote: It depends. If one is an employee then what you say is correct (although of course one can still withdraw one's labour and go elsewhere or never work there in the first place) but as a contractor it is different. A contractor has no requirement to adhere to "the company's own policy"; he or she has his or her own policies!
Well yes, a contractor has his own policies, but one of those policies should be that he must adopt the policies (policies towards contractors) of a client company he agrees to work for, in order to get hired in the first place. Only by offering an amazing amount of value can one get their clients to give in. But there is no point in throwing exceptions into the equation, I am not worried about the 1% who are either extremely well recognized as experts or are extremely crafty in negotiations, but your average independent developer.
markrlondon wrote: Also, even as an employee, it's not necessarily so clear cut. Companies cannot necessarily just do what they want. Whilst it might seem like it sometimes, not all companies just do whatever they want and ride roughshod over the feelings and thoughts of their employees; some actually do listen and do what works best for all.
Yes, and the best examples are software development companies that are owned and managed by people who are coders themselves and who understand how developers should be treated. But these are not a majority nor do they have an infinite capacity to hire.
markrlondon wrote: Although I expect I'd be resigning at that stage rather than going on strike
But go where? To some guy who is looking to hire a freelancer and who has read in some blog article in 2023 that he shouldn't hire a coder who doesn't agree to have his screen monitored? Or wait out a few years until one of the good companies (that are becoming a minority in this scenario) decides that they should hire you out of all people? Again, I am assuming that this hypothetical coder I am talking about is not widely recognized as an exceptional talent who can make demands.
All I am implying is I believe in the future there may be an attempt to steer towards such direction, and we should come up with really good arguments against it, rather than just refuse out of principle.
markrlondon wrote: Good grief, what benefits?
I don't think it should be so hard to imagine cases where this could be productive, as few as there are. If you imagine some negative atmosphere then that is simply not an example of what I meant. Of course, not a single case involves a boss figure who has nothing better to do himself but to check up on everyone.
Some years ago I worked in the same room with two coders who were junior by comparison, and there was nothing but benefits from being able to see each other's screens since I could guide them, or correct them, or they could see some good example on my screen, all of which they enjoyed. Or just to cross-reference parts of how the system works without having to wait until the documentation is published/updated, hold meetings or write long letters to each other.
|
|
|
|
|
There are cases when sharing a screen with another developer can be useful, but the choice should be the developer's. With the exception of presentations, I cannot think of a single case where sharing a screen with management is useful - for the developer or for the manager.
If the manager can't trust his/her developers, he/she shouldn't have hired them in the first place.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Then you found an example of how "screen sharing could work well in a very limited number of cases". I just wanted to point out that my disagreement with having screen recorded by an employer/manager is not due to hating on the whole concept of screen sharing but that there is some proper reasoning behind this stand.
If at some point in future they manage to generalize the opponents to this idea as "haters of screen sharing" that's when they'll be able to slap this onto us as a norm.
|
|
|
|
|
When applying for jobs, software developers often take great care to emphasize their technical skills. However, when it comes to actually landing the position, your “soft skills” (such as empathy and communication) can matter just as much, if not more. Fingers crossed that it's "belly". I'll be so employable!
|
|
|
|
|
"Problem Solving", "Troubleshooting".....
Err.. these are not a "soft skills", they are the essence of what we do!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
