These actions are being taken in response to real threats that really killed real people.
Real threats by people they already knew were potential terrorists and yet they failed to stop them from carrying them out. In other words, they had all the intel they could have wished for and it didn't help. This push for more intel/less privacy has bugger all to do with stopping terrorists.
And we get the job done where those young whippersnappers just give up and throw their toys out of the pram.
The converse was true were I've worked. I've seen more older people walk out on jobs than young people. The young people kept throwing themselves at practically impossible tasks until they burned themselves out. The older people warned three or four times and then quit when their warnings went unheeded.
The interesting thing is that both approaches have their place: in nearly all cases the older engineers were right in the long-term and the project they left ended up being a very expensive failure. In some of the young people's cases they ended up against all odds finding a solution to the problem. I'd estimate that 9/10 times the old guys were right, 1/10 times the young ones were right, but the company got blinded by the success of that 1/10, ignoring the many people that had been lost along the way.
These companies are missing the flip side of the coin, that the over-50s are highly motivated (saving for retirement!,) often highly skilled, and generally have done that before, several times.
I'll add one: I've always enjoyed working with the few "older" engineers in the places I've worked. They were never stingy with advice or stories and generally had less "me against the world" attitude - they knew their value and were past their own insecurities.
Though they do command the big salaries.
And that's wrong. The job and how good a person is at it should dictate the salary, not the person's age or "years of experience". As we get older we MUST let go of the idea that our income evolution can only be in one direction.
You can fix the room without drilling holes in anything.
The really cheap ghetto solution is to buy bales or rolls of rock wool, just leave them in the plastic, and stack them in the corners of the room. Ugly, smells a bit funny, and not everyone likes the idea of being in the proximity of bare rock wool, but it works.
More expensively you might get something like Auralex Promax stands and put them in the corners.
It kind of sounds like you might all be on the same side of the microphone, or at least have that option by moving where you stand or moving the microphone. In that case you could get one of the Reflexion Filters (e.g. the Fame Reflexion Screen Premium for a cheap option) to screen off half of the room. I've used one, and they work surprisingly well.
This, of course, depends significantly on whether by "average" you mean the mode, median, or mean, which in a non-bellcurve distribution such as a programmers or software engineers can be very different.
It's assuming spherical software engineers in a frictionless vacuum, durr.
There may be a better pattern, but in a few cases, I found Goto a lot easier to read than 20 layers of nested If statements..
That's a straw-man argument: no-one would seriously argue that having 20 layers of nested conditionals is good code so even shops that religiously avoid goto would rewrite that code to something that doesn't suck.
A contract won't save you from IR35 compliance issues: it's specifically designed to catch people who are for all intents and purposes employees even if they're on a contract. Though of course the lawyers and accountants will tell you if you'll get on the wrong side of IR35 by sticking to it.
I know, but the companies I have worked with have all been very understanding of the IR35-specific clauses and how important it is that we actually *work* this way. The contract's only one piece of the story, but it is a good way to get the story across to companies that aren't familiar with IR35 and start off thinking they can treat you like "just an employee".
IR35 is a mess. No-one can actually tell you for sure what'll happen.
Your anecdotes don't contradict what I said - your client reviewed your commits and requested further changes for actual compliance before acceptance. The grandparent post implied that you paid the freelancer, they disappeared off the face of the earth, and only then the client would realize compliance issues. That has never been how it works in my experience, and clearly not in yours either.
About the contract:
The framework contract/service agreement I work with is about 6 pages of actual text. It's my own text, it has already been reviewed thoroughly (by two sets of lawyers and several accountants specialized in UK contracting), so in case of new agreements it's usually only a few amendments that need review.
Part of the reason it's so long is because of the UK's IR35 regulation - the way I work makes it very important that my contracts are iron-clad in case of a review. Another reason is that I do quite a bit of work for US multinationals in software that has to achieve FDA approval. I'm sure that for a lot of work you could get away with less. I think that's because US companies are more aware of the damage potential of legal issues more so than in other countries. One of the big ones I work with has been involved in IP/patent battles and critical subcontractors declaring bankruptcy unexpectedly in the middle of a project - they needed me to cover those eventualities.
To avoid the issues of having to review long contracts and the cost of review, I use my own framework agreement for clients. If a client wants to use their contract that's fine, but they get a notice that the cost of having to review their contract will be added to the cost of my work.
Though I guess that in all of the above we're not talking about "freelancing" as in the article - a $150 piece of work wouldn't open anyone up to any great liability (one of my contract clauses stipulates that liability can never be more than the amount paid for the work).
Further more, out of experience, especially for bigger projects, taking in freelancers is a very bad idea :
- You lose the knowledge about the project :
- in case of evolution you need to find the same freelancer hoping he/she will be able and have the time to do the job
Only if the hiring party is being cheap and/or is relying on "wishful thinking" documentation (what if one of your in-house devs with a lot of knowledge gets hit by a bus?). A well-run project will have documentation requirements that the freelancer has to implement.
- If there's a problem,
- your own developpers will be pulling out their hair because it's not compliant to their way of working (or worse unreadable spaghetti code)
Why would you pay a freelancer to develop code that isn't compliant to in-house standards?
- no garantees, you've already validated and payed the freelancer, yer on yer own.
need to go on?
And again - why would you hire a freelancer under a contract with no warranty if you feel that is important to your business (because you don't trust your initial validation and acceptance)?
I actually work as a software contractor. My contracts have all kinds of stipulations for the situations mentioned - including an arbitrage and jurisdiction clause. Having a good contract is great for both sides. Don't skimp on it. Clients can be a little intimidated at first (it's not a short document even in draft form) but when they read it they realise that everything that's in there is in there for a reason, and it's really not just to cover my own arse.
If you're company is willing to pay for it, you can get something like Coverity. On the free(as in beer) side there is CppCheck and clang.
Coverity is expensive, slow, and failed to successfully compile any of our large real-world projects ("large" here meaning tens of thousands of files). This was with their own consultants / sales people on-site to babysit the process. They couldn't do it and couldn't figure out why it wasn't working. From their explanations it also seemed that on a properly large code-base you'd have to spend a long time tweaking the output to rid yourself of spurious messages/warnings.
From experience, the best way to clean up a large project is to not actually mess it up in the first place. If you think it's messed up anyway, then the first thing you need to do is to think long and hard about cost/benefit. A large, specialized company like Coverity can't actually make a specialized compiler/linker that works for all possible correct C++ programs. C++ is notoriously hard to handle "automatically" unless you follow certain strict rules, and if the project is already that messy it's unlikely that any automatic tool is going to make that much of it.
Where do you want to go with this project? Is it actually working fine now? Does it need changes? Can you afford these changes? If the answers to all of these are "yes" then I think your best bet is good old elbow grease. Start adding unit tests for the code, and then manually start cleaning up the code. Just the act of adding unit tests will teach you a lot about the dependencies of the code.
It is a perceived safety issue and I don't buy the arguments in favor of mandating noise pollution. If it really were a problem we should expect to see cars that are quieter than average involved in proportionally more collisions that cars that are more noisy. I've not seen one speck of evidence that quiet cars get in more accidents due to their sound levels. It is to my mind a completely nonsensical argument with no evidence to support it.
Studies have been done and have confirmed that quiet cars get in more accidents at lower speeds due to their sound levels.
I think you're on the mark, but that would mean the projections cannot be solid as the video portrays.
It can be if the transparency of the glasses can also be locally controlled, a bit like the 3D shutterglass technology but at a much higher resolution than left eye/right eye.
As a BT Customer, I can assure you that it stands for "Bloody Terrible", and the buyout is only feasible because the telecomms regulator is as toothless as a wet cabbage.
My friends who use it, assure me that EE stands for "Extremely Expensive".
As an EE user I have to disagree. It actually stands for "Eencredibly Eencompetent."
As I discovered when they contacted me to suggest I go from Pay-As-You-Go to Pay-Monthly, on a plan that was actually financially advantageous.
Only to find out the next time I was abroad, a week later, that there was no roaming activated on Pay-Monthly. I spent a week attempting to get through to customer service with no success ("We estimate we'll be with you in 1m", for an hour and a half). When I finally managed to get through to them back in the UK, they gleefully told me that roaming could only be activated on pay-monthly if you'd been with them for over a year (W... T.... F.....).
I calmly explained that it was *them* that had contacted me to switch plans, when I'd been using the roaming facility on my PAYG for a week out of every month in the past year, so could they kindly get their thumbs out of their arses and fix it or cancel my plan entirely. And suddenly it wasn't so much of a problem to instantly activate my roaming.
Why am I still with them? Best coverage in the UK and abroad, and best prices for my (very non-average, admittedly) usage pattern. But holy shit, are they ever incompetent.
That's how you argue with a crazy person - with more crazy. He, and his followers, don't give a single fuck about the truth. So take them down within their own framework, not from your own.
No, no no. Never argue with an idiot. First they drag you down to their level and then they beat you with experience.
Warning: the following reply may be somewhat acerbic due to real-world experience on both ends of the interviewing table.
That's only because those who haven't been through a PhD program are ignorant as to the amount of intense work, self-motivation, and ingenuity a PhD requires.
As someone who's been through a PhD program and dropped out in disgust, and has subsequently interviewed quite a few PhDs for industry jobs: baloney, it's pretty much as the GP describes in a great number of places. It's a highly-politicised who-do-you-know academic circlejerk. And PhD work is usually nowhere near as "intense" as proper high-level real-world work anyway (something a lot of them learn to their detriment in the first few months on the job).
Many PhDs have already worked extensively in industry.
Whoa, hold on there, now we're not just talking about PhDs, we're talking about PhDs with actual real world experience. That's a much smaller subset than you imply, and quite a few of that subset had *failed* real world experience that made them go back to PhDs. Someone with a PhD who's made it work in the real world is extremely valuable, because at that point you actually have evidence that you really have found that smart, motivated, ingenuous person with serious specialization who can be forgiven for naively believing the academic fairy-story that a PhD would actually be valuable outside of the world of academia.
The less you know, the less you realize how much you don't know.
I have also seen/heard of circumstances where "doing the minimum to keep the thing working" is allowed but actually improving the code is not because improving the code counts as "new work" and comes from a different budget than maintenance.
Seems stupid but that's how some shops operate.
"The minimum to keep the thing working" nearly always implies improving the code. All developers need to realize this and stop this silly false dichotomy between "maintenance" and "refactoring".
A small number of dysfunctional shops like that has virtually always existed.
90% is a small number, right?
I'm joking, I've never had to work in a truly dysfunctional shop, and yet "fear-driven development" tends to make an appearance whenever stress levels get higher. Pressure makes people take funny decisions that they think are "safe", such as not touching a legacy code base for another 5 years because "it works and we don't want to break it", until it finally collapses under its own weight and technological advancement (in the case I'm thinking of it was the lack of multithreading and 64bit support).
Often its the fear of other people's reactions if you stick your neck out and get it wrong that will doom you to inaction. It helps to remind yourself and others constantly that you cannot have improvement without change, and the only way to do nothing wrong is to do nothing. Build up trust at detecting and *recovering* from mistakes is at least as important as having a process that avoids mistakes. Mistakes happen. Learn to deal with them instead of expending inordinate amounts of time trying to avoid them.
Slashdot Mirror
These actions are being taken in response to real threats that really killed real people.
Real threats by people they already knew were potential terrorists and yet they failed to stop them from carrying them out. In other words, they had all the intel they could have wished for and it didn't help. This push for more intel/less privacy has bugger all to do with stopping terrorists.
And we get the job done where those young whippersnappers just give up and throw their toys out of the pram.
The converse was true were I've worked. I've seen more older people walk out on jobs than young people. The young people kept throwing themselves at practically impossible tasks until they burned themselves out. The older people warned three or four times and then quit when their warnings went unheeded.
The interesting thing is that both approaches have their place: in nearly all cases the older engineers were right in the long-term and the project they left ended up being a very expensive failure. In some of the young people's cases they ended up against all odds finding a solution to the problem. I'd estimate that 9/10 times the old guys were right, 1/10 times the young ones were right, but the company got blinded by the success of that 1/10, ignoring the many people that had been lost along the way.
These companies are missing the flip side of the coin, that the over-50s are highly motivated (saving for retirement!,) often highly skilled, and generally have done that before, several times.
I'll add one: I've always enjoyed working with the few "older" engineers in the places I've worked. They were never stingy with advice or stories and generally had less "me against the world" attitude - they knew their value and were past their own insecurities.
Though they do command the big salaries.
And that's wrong. The job and how good a person is at it should dictate the salary, not the person's age or "years of experience". As we get older we MUST let go of the idea that our income evolution can only be in one direction.
Or to explain it with a car analogy: Chevy Nova.
You can fix the room without drilling holes in anything.
The really cheap ghetto solution is to buy bales or rolls of rock wool, just leave them in the plastic, and stack them in the corners of the room. Ugly, smells a bit funny, and not everyone likes the idea of being in the proximity of bare rock wool, but it works.
More expensively you might get something like Auralex Promax stands and put them in the corners.
It kind of sounds like you might all be on the same side of the microphone, or at least have that option by moving where you stand or moving the microphone. In that case you could get one of the Reflexion Filters (e.g. the Fame Reflexion Screen Premium for a cheap option) to screen off half of the room. I've used one, and they work surprisingly well.
How about just tell them to be in the room when you do the standup? This solution is simple and costs absolutely nothing.
Kinda difficult when that person isn't even in the same country.
This, of course, depends significantly on whether by "average" you mean the mode, median, or mean, which in a non-bellcurve distribution such as a programmers or software engineers can be very different.
It's assuming spherical software engineers in a frictionless vacuum, durr.
There may be a better pattern, but in a few cases, I found Goto a lot easier to read than 20 layers of nested If statements..
That's a straw-man argument: no-one would seriously argue that having 20 layers of nested conditionals is good code so even shops that religiously avoid goto would rewrite that code to something that doesn't suck.
A contract won't save you from IR35 compliance issues: it's specifically designed to catch people who are for all intents and purposes employees even if they're on a contract. Though of course the lawyers and accountants will tell you if you'll get on the wrong side of IR35 by sticking to it.
I know, but the companies I have worked with have all been very understanding of the IR35-specific clauses and how important it is that we actually *work* this way. The contract's only one piece of the story, but it is a good way to get the story across to companies that aren't familiar with IR35 and start off thinking they can treat you like "just an employee".
IR35 is a mess. No-one can actually tell you for sure what'll happen.
Your anecdotes don't contradict what I said - your client reviewed your commits and requested further changes for actual compliance before acceptance. The grandparent post implied that you paid the freelancer, they disappeared off the face of the earth, and only then the client would realize compliance issues. That has never been how it works in my experience, and clearly not in yours either.
About the contract:
The framework contract/service agreement I work with is about 6 pages of actual text. It's my own text, it has already been reviewed thoroughly (by two sets of lawyers and several accountants specialized in UK contracting), so in case of new agreements it's usually only a few amendments that need review.
Part of the reason it's so long is because of the UK's IR35 regulation - the way I work makes it very important that my contracts are iron-clad in case of a review. Another reason is that I do quite a bit of work for US multinationals in software that has to achieve FDA approval. I'm sure that for a lot of work you could get away with less. I think that's because US companies are more aware of the damage potential of legal issues more so than in other countries. One of the big ones I work with has been involved in IP/patent battles and critical subcontractors declaring bankruptcy unexpectedly in the middle of a project - they needed me to cover those eventualities.
To avoid the issues of having to review long contracts and the cost of review, I use my own framework agreement for clients. If a client wants to use their contract that's fine, but they get a notice that the cost of having to review their contract will be added to the cost of my work.
Though I guess that in all of the above we're not talking about "freelancing" as in the article - a $150 piece of work wouldn't open anyone up to any great liability (one of my contract clauses stipulates that liability can never be more than the amount paid for the work).
Further more, out of experience, especially for bigger projects, taking in freelancers is a very bad idea : - You lose the knowledge about the project : - in case of evolution you need to find the same freelancer hoping he/she will be able and have the time to do the job
Only if the hiring party is being cheap and/or is relying on "wishful thinking" documentation (what if one of your in-house devs with a lot of knowledge gets hit by a bus?). A well-run project will have documentation requirements that the freelancer has to implement.
- If there's a problem, - your own developpers will be pulling out their hair because it's not compliant to their way of working (or worse unreadable spaghetti code)
Why would you pay a freelancer to develop code that isn't compliant to in-house standards?
- no garantees, you've already validated and payed the freelancer, yer on yer own.
need to go on?
And again - why would you hire a freelancer under a contract with no warranty if you feel that is important to your business (because you don't trust your initial validation and acceptance)?
I actually work as a software contractor. My contracts have all kinds of stipulations for the situations mentioned - including an arbitrage and jurisdiction clause. Having a good contract is great for both sides. Don't skimp on it. Clients can be a little intimidated at first (it's not a short document even in draft form) but when they read it they realise that everything that's in there is in there for a reason, and it's really not just to cover my own arse.
If you're company is willing to pay for it, you can get something like Coverity. On the free(as in beer) side there is CppCheck and clang.
Coverity is expensive, slow, and failed to successfully compile any of our large real-world projects ("large" here meaning tens of thousands of files). This was with their own consultants / sales people on-site to babysit the process. They couldn't do it and couldn't figure out why it wasn't working. From their explanations it also seemed that on a properly large code-base you'd have to spend a long time tweaking the output to rid yourself of spurious messages/warnings.
From experience, the best way to clean up a large project is to not actually mess it up in the first place. If you think it's messed up anyway, then the first thing you need to do is to think long and hard about cost/benefit. A large, specialized company like Coverity can't actually make a specialized compiler/linker that works for all possible correct C++ programs. C++ is notoriously hard to handle "automatically" unless you follow certain strict rules, and if the project is already that messy it's unlikely that any automatic tool is going to make that much of it.
Where do you want to go with this project? Is it actually working fine now? Does it need changes? Can you afford these changes? If the answers to all of these are "yes" then I think your best bet is good old elbow grease. Start adding unit tests for the code, and then manually start cleaning up the code. Just the act of adding unit tests will teach you a lot about the dependencies of the code.
it appears the devs are doing it right, and will release when it is ready, and no earlier.
That's what 3DRealms kept saying about Duke Nukem Forever, and we all know how that ended up.
They really do not. That's like saying Mercedes Benz faces competition from Smart Cars.
Theoretically, both a Smart Car and an S class have four wheels, but nobody who is shopping for one is seriously considering the other.
Likewise, nobody shopping for cable Internet is shopping for DSL.
Not-so-theoretically, Smart are actually owned by Mercedes Benz.
That mandated noise IS entirely a safety issue
It is a perceived safety issue and I don't buy the arguments in favor of mandating noise pollution. If it really were a problem we should expect to see cars that are quieter than average involved in proportionally more collisions that cars that are more noisy. I've not seen one speck of evidence that quiet cars get in more accidents due to their sound levels. It is to my mind a completely nonsensical argument with no evidence to support it.
Studies have been done and have confirmed that quiet cars get in more accidents at lower speeds due to their sound levels.
I've seen a firm where they still use a Tolkien Ring. It's their most prized possession.
I'm sure you meant to say their most precious possession.
I think you're on the mark, but that would mean the projections cannot be solid as the video portrays.
It can be if the transparency of the glasses can also be locally controlled, a bit like the 3D shutterglass technology but at a much higher resolution than left eye/right eye.
Man, I'd be a better driver with my wanker removed. "Distractuious" women have caused most of my near misses.
Could have been worse - could have been complete mrs.
As a BT Customer, I can assure you that it stands for "Bloody Terrible", and the buyout is only feasible because the telecomms regulator is as toothless as a wet cabbage.
My friends who use it, assure me that EE stands for "Extremely Expensive".
As an EE user I have to disagree. It actually stands for "Eencredibly Eencompetent."
As I discovered when they contacted me to suggest I go from Pay-As-You-Go to Pay-Monthly, on a plan that was actually financially advantageous. Only to find out the next time I was abroad, a week later, that there was no roaming activated on Pay-Monthly. I spent a week attempting to get through to customer service with no success ("We estimate we'll be with you in 1m", for an hour and a half). When I finally managed to get through to them back in the UK, they gleefully told me that roaming could only be activated on pay-monthly if you'd been with them for over a year (W... T.... F.....).
I calmly explained that it was *them* that had contacted me to switch plans, when I'd been using the roaming facility on my PAYG for a week out of every month in the past year, so could they kindly get their thumbs out of their arses and fix it or cancel my plan entirely. And suddenly it wasn't so much of a problem to instantly activate my roaming.
Why am I still with them? Best coverage in the UK and abroad, and best prices for my (very non-average, admittedly) usage pattern. But holy shit, are they ever incompetent.
Don't worry, they'll get better eventually
Just hope you won't be there during one of the Mass Extinction Events.
That's how you argue with a crazy person - with more crazy. He, and his followers, don't give a single fuck about the truth. So take them down within their own framework, not from your own.
No, no no. Never argue with an idiot. First they drag you down to their level and then they beat you with experience.
Don't leave your keys in the obvious places, including the spare keys.
I'm really good at this! Most of the time even *I* can't find my keys.
That's only because those who haven't been through a PhD program are ignorant as to the amount of intense work, self-motivation, and ingenuity a PhD requires.
As someone who's been through a PhD program and dropped out in disgust, and has subsequently interviewed quite a few PhDs for industry jobs: baloney, it's pretty much as the GP describes in a great number of places. It's a highly-politicised who-do-you-know academic circlejerk. And PhD work is usually nowhere near as "intense" as proper high-level real-world work anyway (something a lot of them learn to their detriment in the first few months on the job).
Many PhDs have already worked extensively in industry.
Whoa, hold on there, now we're not just talking about PhDs, we're talking about PhDs with actual real world experience. That's a much smaller subset than you imply, and quite a few of that subset had *failed* real world experience that made them go back to PhDs. Someone with a PhD who's made it work in the real world is extremely valuable, because at that point you actually have evidence that you really have found that smart, motivated, ingenuous person with serious specialization who can be forgiven for naively believing the academic fairy-story that a PhD would actually be valuable outside of the world of academia.
The less you know, the less you realize how much you don't know.
Indeed.
I have also seen/heard of circumstances where "doing the minimum to keep the thing working" is allowed but actually improving the code is not because improving the code counts as "new work" and comes from a different budget than maintenance. Seems stupid but that's how some shops operate.
"The minimum to keep the thing working" nearly always implies improving the code. All developers need to realize this and stop this silly false dichotomy between "maintenance" and "refactoring".
A small number of dysfunctional shops like that has virtually always existed.
90% is a small number, right?
I'm joking, I've never had to work in a truly dysfunctional shop, and yet "fear-driven development" tends to make an appearance whenever stress levels get higher. Pressure makes people take funny decisions that they think are "safe", such as not touching a legacy code base for another 5 years because "it works and we don't want to break it", until it finally collapses under its own weight and technological advancement (in the case I'm thinking of it was the lack of multithreading and 64bit support).
Often its the fear of other people's reactions if you stick your neck out and get it wrong that will doom you to inaction. It helps to remind yourself and others constantly that you cannot have improvement without change, and the only way to do nothing wrong is to do nothing. Build up trust at detecting and *recovering* from mistakes is at least as important as having a process that avoids mistakes. Mistakes happen. Learn to deal with them instead of expending inordinate amounts of time trying to avoid them.