I can see most LCD monitors at work mostly fine with my polarized sun glasses. Only a rare few are nearly pitch black and that goes away if I tilt my head at all. Even at home I have to rotate my glasses 45 degrees to make it dark enough to not easily read. Even the slightest misalignment and I can read my screen.
In my very limited experience, I've seen many different polarization orientations. There's no way a polarization based filter will universally work.
That's only in the case where you assume to have installed the CA from the proxy. If all you did was indicate that you "trust" the proxy, then the proxy could be trusted for only the matter of privacy, but still require the content be signed by the site.
Encryption in this case provides two benefits: 1) Privacy, knowing that you're only talking to the one site 2) Signing, knowing that the data you got was unaltered from the site
What if they made it so the MITM HTTPS proxies only broke #1 and could just pass through the content. Then the client could at least know that the content was unaltered. Assuming the proxy is decently implemented and validates the site, the proxy could now become responsible for making sure that the connection is secure and the client can assume that the proxy is handling this.
By some definition of "thinking logically". That's the issue. Humans are currently the highest form of intelligence that we can compare anything against. Yet for certain categories of "thinking logically", ability is distributed on a power curve. If you take the smartest human at a particular form of reasoning, nearly all other humans would be considered retarded.
Ever hear the "10,000 hours to master". That is a general rule of thumb, but the time required to master a particular skill varies wildly per person. For skill domains where repetition is important, like physically training your muscles, the range is +-1 magnitude. Some people can master in 1,000 hours, others will take 100,000 hours, but the median works out to around 10,000. For mental related domains, it's about +-2 magnitudes. One person may take 100 hours and another 1,000,000 hours. That's already a 10,000x difference between the high and low humans.
Imagine if a substantial portion of the human population found themselves reliably reproducing those humans who learn 100x+ faster than the current median. One may easily consider them almost like a separate species in the way that a sudden large population of 100x+ smarter humans, albeit at a limited scope of skills.
In summary, humans have a ridiculous std-dev when it comes to obtaining mastery. A typical human is already only a fraction of a percent as smart as the best humans. There is no reason to assume another species couldn't reliably create our best reliably even within the limitations of current human biology.
Level 3 was saying some years ago that bandwdith has become a commodity. Low margin and constantly changing. The only way to compete in the long run is with services. Even right now, we have a multi trillion dollar set of businesses running on top of a messily $150 bil worth of world wide network equipment. The value of the services running on top of the network is growing exponentially and the network itself is mostly a one-time sunk cost with some upkeep and maintenance.
Upgrading endpoints is easy and cheap, and most of the trenching has already been done. A small amount of physical growth. Most of the improvements in network speed are from an increase in technology, not capital expenditure.
It's not surprise that these service providers are wanting to just peer and have free bandwidth. The administrative overhead to manage the nickle-and-diming is more than the cost of the bandwidth. Not to mention the opportunity costs of long negotiations. Cut out the middle-man, make it free and compete with services.
Very true. But there's always a middle ground. We can have anti-social specific geniuses destroying a team of skilled workers. But we shouldn't be keeping out those who have a rare ability because they can't weave baskets as well as a typical human. I'm using basket weaving as an example of the mostly arbitrary "requirements" that many places have.
While this isn't the best example, it is an example. At work, I overheard that there were about 10 of our most senior programmers, system administrators, and support-contract specialists trying to figure out a problem with a $500,000 3rd-party appliance that was dragging on for 2 days. The problem go so bad they paid to fly in additional specialists. They had zero leads, just trying out different settings.
At this point, I was fresh out of college with 1-2 weeks of programming time under my belt. I was interested in what kind of "difficult" problem could have so many of what many would consider "very smart" veterans of their trade. I caught one of them on their way to lunch and asked if I could get a description of the issue. They forwarded the original email that the customer sent in. Not the head of the email chain, so I have no information of any discussions or findings. 15 minutes later I had a theory, another 15 minutes later my co-worker helped me prove the theory. One hour later the problem was fixed.
Remember, this was a 3rd-party custom appliance to which I had no prior experience or knowledge of. All I did was hit wiki to find out what this company specialized in, read some sales brochures about what features the device had, made some assumptions about how a sane person could have implemented those features, and thought about different ways those different implementations could interact with other systems in a way that could manifest the issues the customer described.
At this point my my carrier I suddenly went from thinking these experience programmers were solving hard problems to having great disdain for their their lack of ability. After these many years, I have mellowed out. I have realized how important working as a team is, but that doesn't excuse such incompetence being acceptable in technical positions.
My team very much recognizes my ability to do certain things infinitely better. Problems they could never solve in a life-time, I can slap together. But many day-to-day things I am absolutely horrible at. I am very forgetful of anything fact related, am very stress sensitive, no concentration for anything "boring", burn out quickly when task switching, among other deficiencies. But in my strengths, I can debug systems without having seen the code, notice even the smallest nuance of difference in semantics, breeze over code and catch bugs that hundreds of other programmers over the years have looked at but never noticed, think of corner cases so well that most of the systems I have designed have NEVER had an undefined case.
I'm like soup-spoon when trying to eat soup. Not very good for anything else, but I got soup eating down. In a land where most people eat steak, a fork and knife seem like the standard to compare all eating utensils against. But is seems quite spiteful to say a soup-spoon is not very useful for eating when you'd dealing with mainly soup.
What actually happens is that coding transforms a somewhat to very abstract description into a concrete
That's called design. Coding is literally the act of write code. Code is how human currently communicate with computers and potentially other humans. "Designing" code is taking an idea and thinking of a way to express it in code. Design is something rarely done. Most people just get to working pumping out code.
"FOR US HUMANS" may even be an over generalization. My main point has been that society tried to shoe-horn everyone into some bell-curve that doesn't represent anything except a bell-curve. And in order to do "harder" stuff, you need to be at the top of the curve. Some people are inverted. What 99.999% of people consider hard, they consider easy, and what other people consider easy, they consider hard. Those people seem to be all over the place, yet are not involved with the "hard" problems.
Seems the only time you hear of these people is when they get a lucky break and someone with connections takes them under their wing to get them in touch with people who have influence.
I propose that the issue isn't "humanity's inability", it's humanity's refusal to acknowledge those with talent by filtering them out by making them jump through hoops. People exceptionally smart in one area seem to trade abilities in other areas. When you look at them as a whole, they seem mediocre, but if you focus on the very limited area that they excel in, they make everyone else look stupid.
Coding is just a transcription process. There's a fundamental issue that in order to make a system that can code for you, that you need a way to unambiguously tell that system what you want it to do. Guess what coding is. Telling a system in an unambiguous way what you want it to do. What we really want is a way to further divorce programmers from the nitty-gritty details that consume most of our coding time.
Languages up to this point have done a decent job of just that by hiding ASM from the coder, but we've hit a brick wall. We keep creating new specialized languages, but each has a trade-off and most of the time they're specialized in order to deal with specific back-ends or front-ends, not so much as general purpose.
I personally think the first effective usage of AI to enhancing coding is better refactoring tooling. It can be a time-consuming operation, especially in large systems. Imagine instead of refactoring bits at a time, you can do the entire system in one step and have it ready for the next release. Could be done by assigning attributes to methods and variables and specify guarantees required. You still have an architectural and design issue that you have to specify the correct attributes, but even if you miss one, it could be as easy and adding the missing or changing an incorrect one and letting the AI restructure the system.
You do point out the issue of current systems and there's no hardware silver-bullet that wouldn't changes to algorithms and datastructures of existing currency logic. But cache-coherency is not a requirement, but does have certain trade-offs when it comes to concurrency like latency, and execution units within a CPU do not require being in sync. There are async CPU designs that can clock very high, but they're much more complex, few people are able to designing them, almost no tooling to design them, and have thus far been more difficult than just throwing more transistors at the problem. I'm not sure what performance trade-offs there would be.
The answer to the problem is to let people who can do concurrency well, have a say in the architecture and design of systems. The problem is this whole top-down management style. It needs to be bi-directional. Most of your talent is in the trenches and it's a recipe for disaster to tell your talent how to do their job when they see the flaws in the designs. No one person can both be technically fluent and have the communication skills required to be the perfect lead.
Programming is a huge industry. People saying "concurrency is hard" is akin to a typical person saying calculus is hard. Some people find it easy. But don't expect people who find calculus easy to find communication easy.
The fact of the matter is that for many important classes of algorithms, using more cores slows things down and that is a hard, theoretical fact
While you are technically correct, there are trade-offs that can be made. Many programmers limit themselves to preserving ordering and never losing data. There are cases where a lossy or non-order preserving alternative algorithm can have near perfect linear scaling, but you need to make sure you system is designed and can fundamentally accept this trade-off.
A simple example that I've done. I wrote a high concurrency library that had an estimated time to completion. The way it did that was to update the average rate of work units processed and the remaining. When I did proper locking, the fine grained work units were causing high contention, resulting a maximum of 80-90% utilization on a quad core HT CPU. I removed the locks and just optimistically checked a variable padded to its own cache-line. If the data-structure was in use, just don't update and discard the timing results of the current work unit, and if it wasn't in use, then flag it in use and update. If a race condition occurred and two updates happened at the same time, it didn't matter because the the values were designed to not be accumulative and would approach correct.
In the end, there was an ever so slight increase of variability in the presented ETC, but it was still capable of predicting what time it would finish within 1% of error within the first few minutes of a multi-hour run, and now it was able to scale to 99% CPU on a 32core HT server. Not that the increased variability mattered much because there was already a natural amount of minor variability due to available computational resources. In short, the increased variability was measurably different, but within the std-dev of existing uncontrollable fluctuations.
Moral of this store. In concurrency, perfect can be the enemy of good.
As long as we understand that "X is difficult" has an implied "X is difficult to me or most others". I find a lot of things difficult that are considered simple to most. I really dislike how society tries to force everyone into some bell-curve of ability. I'm lucky enough to have the confidence in the very narrow band of what I'm great at and a team to back me up. The important part is I'm part of a team. Each with our own strengths. I just so happen to be exceptionally good at what most of them find difficult or impossible, yet I have extreme difficulty dealing with every day problems.
I very much get the feeling that humanity would be much further if we didn't artificially restrict people by requiring them to have skills orthogonal to the problem at hand. Referencing back at the "You can't do arithmetic so you can't enter high end physics classes". I have a similar issue. I am horrible at math in my head, even though I understand it very well. I am good at manipulating symbols and found out too late that I excel at higher maths, but they were not my passion. Just because I can't do something does not mean I do not understand it. Computers are great at math, but have zero understanding.
The world is filled with broken, insecure code written by people who treated Bruce Schneier's "Applied Cryptography" book like a howto-cookbook instead of a very, very old & out of date high-level overview.
Programming is like 80% abstract thinking and 20% dealing with people, yet somehow many programmers are poor at both. People taking Bruce Schneier too literally and not capable of thinking for themselves.
It was on youtube interviewing him with his recent book. The context was he was talking about the 1% genetic difference between humans are apes(or whatever) and how even the most intelligent of apes are only as smart as a typical 3 year old human. He was saying that we think the laws of the Universe are "hard", but that's hubris because a species 1% different from us may have their 3 year old children being as smart as our smartest physicists, and what's difficult to us may be a simple logic problem to them.
Many problems in life we that call "difficult" are because they require physical effort or lots of knowledge which may be incredible difficult to acquire. But problems of pure reasoning, like many "difficult" aspects of programming, are only relatively difficult to the person(s) claiming it to be, not an inherent fact.
I don't claim to be "smart" as in better at everything, but I do have my strengths. In those strengths, I have solved issues that have stumped entire communities of seasoned professionals for years within seconds of reading of the problem. My guess is most people are like me and we're just not letting people who have intuitive understandings of certain issues to be fully utilized. I've heard of people who can't do basic arithmetic, but are gods at Calculus, but were prevented from even learning Calculus until much later and became recognized as leading physicists in their niche. It was only happenstance that a teacher allowed them to skip remedial math and go into advanced math. There's probably many more out there.
A big problem of intuition is it's nearly impossible to explain and few believe you if they can't understand. Let me explain how you ride a bike. Sit on the seat and start peddling.
I'd rather have-not than have-crap. I can't stand dealing with the unreliability of an unpolished product. I have no idea how the typical person can be so accepting when they're also equally short fused. For example. I've seen people calmly "accept" that their wireless AP is a pile of crap, while yelling at their device, yet refuse to spend a small amount extra to get something that is nearly perfect in every way.
Many of these people also complain they don't have any money, yet "It's payday!" and drop $100 in one night at the bar. People are irrational.
When I was super poor, I purchased a $10 belt. Thing fell apart in 2 months. Then I decided to step-it-up and get a $30 belt. Fell apart in 6 months. F that. Next belt was a $100 solid-one-layer full-grain english bridle leather sourced from a 100+ year old tannery, with marine-grade nylon edge stitching. Belt is now indestructible. Just a quick cleaning and some conditioner 2x a year. I leave the shirts untucked, no one can see it, but I love knowing that I no longer need to worry about my belt looking like stretched laughy taffy at the holes and parts flaking off onto my pants and chairs.
I know people who regularly replace their $20-$30 belts 2-3 times a year because they break down, but tell me they can't afford a $100 belt.
If you're doing a one-off that you do not plan to support, high quality code is more expensive. If you plan on supporting your product, high quality code is easy relative to supporting crap code. I spend more time reading code that writing code. The higher quality the code, the faster I can read it and the easier making changes are, and the less risk of changes creating bugs.
There is nothing difficult about programming. The only thing difficult is when a programmer makes it difficult. To paraphrase Neil deGrasse Tyson, "To think a problem inherently difficult is hubris". Just because a problem is difficult for you doesn't mean the problem is difficult.
FreeBSD is still maintained by many of the original AT&T Unix, BSD, and Solaris engineers. Some have taken more high level project management positions, but quite a few are still in the trenches writing code.
I have to deal with tight SLAs for bug-fixes or work-arounds. You can argue about ideals from an ivory tower, but in the real world, a customer has a $10mil contract that is contingent on next-day turn-arounds, you get interrupted. 99% of the time, the issue is not with our code, but 11th hour feature changes that threaten the contract or with interfacing with under-designed code that the team can't even tell you what is defined as "working". Many "agile" teams define "working" as when the customer isn't able to get an issue to be reproduced.
Sarcasm? If you don't have a design, then anything could be considered "working code". A "bug" is anything that doesn't work according to the design. Without a design, you have no bugs, everything is a feature! Is your data getting corrupted? If it's working as designed, then it's an undocumented feature.
I asked a trainer on how to handle architecture and design with Agile since it doesn't really fit. I was told to "timebox". Yeah... ummm... no. Agile is a development process, not an architecture or design process. I haz hammer, everything a nail!
My company uses Agile more as a time management and priority planning process than a full development process. I think it works great in that sense. I can never really work on any one thing 100% of the time. Agile allows us to take in new work, see it relative to other work, and plan and communicate with others how we plan to spend our time for the next 2 weeks.
When someone comes to us with work that "must get done" we can show them all of our scheduled work and figure out which other work might need to get pushed and communicate with the stake holders of that work to find out who's work really is more important. It also helps with resource allocations. We can show to upper management where we spend our time and they can decide to shift work away from us, further delay work, or let us hire.
Slashdot Mirror
I can see most LCD monitors at work mostly fine with my polarized sun glasses. Only a rare few are nearly pitch black and that goes away if I tilt my head at all. Even at home I have to rotate my glasses 45 degrees to make it dark enough to not easily read. Even the slightest misalignment and I can read my screen.
In my very limited experience, I've seen many different polarization orientations. There's no way a polarization based filter will universally work.
That's only in the case where you assume to have installed the CA from the proxy. If all you did was indicate that you "trust" the proxy, then the proxy could be trusted for only the matter of privacy, but still require the content be signed by the site.
Encryption in this case provides two benefits: 1) Privacy, knowing that you're only talking to the one site 2) Signing, knowing that the data you got was unaltered from the site
What if they made it so the MITM HTTPS proxies only broke #1 and could just pass through the content. Then the client could at least know that the content was unaltered. Assuming the proxy is decently implemented and validates the site, the proxy could now become responsible for making sure that the connection is secure and the client can assume that the proxy is handling this.
By some definition of "thinking logically". That's the issue. Humans are currently the highest form of intelligence that we can compare anything against. Yet for certain categories of "thinking logically", ability is distributed on a power curve. If you take the smartest human at a particular form of reasoning, nearly all other humans would be considered retarded.
Ever hear the "10,000 hours to master". That is a general rule of thumb, but the time required to master a particular skill varies wildly per person. For skill domains where repetition is important, like physically training your muscles, the range is +-1 magnitude. Some people can master in 1,000 hours, others will take 100,000 hours, but the median works out to around 10,000. For mental related domains, it's about +-2 magnitudes. One person may take 100 hours and another 1,000,000 hours. That's already a 10,000x difference between the high and low humans.
Imagine if a substantial portion of the human population found themselves reliably reproducing those humans who learn 100x+ faster than the current median. One may easily consider them almost like a separate species in the way that a sudden large population of 100x+ smarter humans, albeit at a limited scope of skills.
In summary, humans have a ridiculous std-dev when it comes to obtaining mastery. A typical human is already only a fraction of a percent as smart as the best humans. There is no reason to assume another species couldn't reliably create our best reliably even within the limitations of current human biology.
Level 3 was saying some years ago that bandwdith has become a commodity. Low margin and constantly changing. The only way to compete in the long run is with services. Even right now, we have a multi trillion dollar set of businesses running on top of a messily $150 bil worth of world wide network equipment. The value of the services running on top of the network is growing exponentially and the network itself is mostly a one-time sunk cost with some upkeep and maintenance.
Upgrading endpoints is easy and cheap, and most of the trenching has already been done. A small amount of physical growth. Most of the improvements in network speed are from an increase in technology, not capital expenditure.
It's not surprise that these service providers are wanting to just peer and have free bandwidth. The administrative overhead to manage the nickle-and-diming is more than the cost of the bandwidth. Not to mention the opportunity costs of long negotiations. Cut out the middle-man, make it free and compete with services.
Very true. But there's always a middle ground. We can have anti-social specific geniuses destroying a team of skilled workers. But we shouldn't be keeping out those who have a rare ability because they can't weave baskets as well as a typical human. I'm using basket weaving as an example of the mostly arbitrary "requirements" that many places have.
While this isn't the best example, it is an example. At work, I overheard that there were about 10 of our most senior programmers, system administrators, and support-contract specialists trying to figure out a problem with a $500,000 3rd-party appliance that was dragging on for 2 days. The problem go so bad they paid to fly in additional specialists. They had zero leads, just trying out different settings.
At this point, I was fresh out of college with 1-2 weeks of programming time under my belt. I was interested in what kind of "difficult" problem could have so many of what many would consider "very smart" veterans of their trade. I caught one of them on their way to lunch and asked if I could get a description of the issue. They forwarded the original email that the customer sent in. Not the head of the email chain, so I have no information of any discussions or findings. 15 minutes later I had a theory, another 15 minutes later my co-worker helped me prove the theory. One hour later the problem was fixed.
Remember, this was a 3rd-party custom appliance to which I had no prior experience or knowledge of. All I did was hit wiki to find out what this company specialized in, read some sales brochures about what features the device had, made some assumptions about how a sane person could have implemented those features, and thought about different ways those different implementations could interact with other systems in a way that could manifest the issues the customer described.
At this point my my carrier I suddenly went from thinking these experience programmers were solving hard problems to having great disdain for their their lack of ability. After these many years, I have mellowed out. I have realized how important working as a team is, but that doesn't excuse such incompetence being acceptable in technical positions.
My team very much recognizes my ability to do certain things infinitely better. Problems they could never solve in a life-time, I can slap together. But many day-to-day things I am absolutely horrible at. I am very forgetful of anything fact related, am very stress sensitive, no concentration for anything "boring", burn out quickly when task switching, among other deficiencies. But in my strengths, I can debug systems without having seen the code, notice even the smallest nuance of difference in semantics, breeze over code and catch bugs that hundreds of other programmers over the years have looked at but never noticed, think of corner cases so well that most of the systems I have designed have NEVER had an undefined case.
I'm like soup-spoon when trying to eat soup. Not very good for anything else, but I got soup eating down. In a land where most people eat steak, a fork and knife seem like the standard to compare all eating utensils against. But is seems quite spiteful to say a soup-spoon is not very useful for eating when you'd dealing with mainly soup.
What actually happens is that coding transforms a somewhat to very abstract description into a concrete
That's called design. Coding is literally the act of write code. Code is how human currently communicate with computers and potentially other humans. "Designing" code is taking an idea and thinking of a way to express it in code. Design is something rarely done. Most people just get to working pumping out code.
"FOR US HUMANS" may even be an over generalization. My main point has been that society tried to shoe-horn everyone into some bell-curve that doesn't represent anything except a bell-curve. And in order to do "harder" stuff, you need to be at the top of the curve. Some people are inverted. What 99.999% of people consider hard, they consider easy, and what other people consider easy, they consider hard. Those people seem to be all over the place, yet are not involved with the "hard" problems.
Seems the only time you hear of these people is when they get a lucky break and someone with connections takes them under their wing to get them in touch with people who have influence.
I propose that the issue isn't "humanity's inability", it's humanity's refusal to acknowledge those with talent by filtering them out by making them jump through hoops. People exceptionally smart in one area seem to trade abilities in other areas. When you look at them as a whole, they seem mediocre, but if you focus on the very limited area that they excel in, they make everyone else look stupid.
Coding is just a transcription process. There's a fundamental issue that in order to make a system that can code for you, that you need a way to unambiguously tell that system what you want it to do. Guess what coding is. Telling a system in an unambiguous way what you want it to do. What we really want is a way to further divorce programmers from the nitty-gritty details that consume most of our coding time.
Languages up to this point have done a decent job of just that by hiding ASM from the coder, but we've hit a brick wall. We keep creating new specialized languages, but each has a trade-off and most of the time they're specialized in order to deal with specific back-ends or front-ends, not so much as general purpose.
I personally think the first effective usage of AI to enhancing coding is better refactoring tooling. It can be a time-consuming operation, especially in large systems. Imagine instead of refactoring bits at a time, you can do the entire system in one step and have it ready for the next release. Could be done by assigning attributes to methods and variables and specify guarantees required. You still have an architectural and design issue that you have to specify the correct attributes, but even if you miss one, it could be as easy and adding the missing or changing an incorrect one and letting the AI restructure the system.
You do point out the issue of current systems and there's no hardware silver-bullet that wouldn't changes to algorithms and datastructures of existing currency logic. But cache-coherency is not a requirement, but does have certain trade-offs when it comes to concurrency like latency, and execution units within a CPU do not require being in sync. There are async CPU designs that can clock very high, but they're much more complex, few people are able to designing them, almost no tooling to design them, and have thus far been more difficult than just throwing more transistors at the problem. I'm not sure what performance trade-offs there would be.
The answer to the problem is to let people who can do concurrency well, have a say in the architecture and design of systems. The problem is this whole top-down management style. It needs to be bi-directional. Most of your talent is in the trenches and it's a recipe for disaster to tell your talent how to do their job when they see the flaws in the designs. No one person can both be technically fluent and have the communication skills required to be the perfect lead.
Programming is a huge industry. People saying "concurrency is hard" is akin to a typical person saying calculus is hard. Some people find it easy. But don't expect people who find calculus easy to find communication easy.
Spin up several worker nodes and load balance?
The fact of the matter is that for many important classes of algorithms, using more cores slows things down and that is a hard, theoretical fact
While you are technically correct, there are trade-offs that can be made. Many programmers limit themselves to preserving ordering and never losing data. There are cases where a lossy or non-order preserving alternative algorithm can have near perfect linear scaling, but you need to make sure you system is designed and can fundamentally accept this trade-off.
A simple example that I've done. I wrote a high concurrency library that had an estimated time to completion. The way it did that was to update the average rate of work units processed and the remaining. When I did proper locking, the fine grained work units were causing high contention, resulting a maximum of 80-90% utilization on a quad core HT CPU. I removed the locks and just optimistically checked a variable padded to its own cache-line. If the data-structure was in use, just don't update and discard the timing results of the current work unit, and if it wasn't in use, then flag it in use and update. If a race condition occurred and two updates happened at the same time, it didn't matter because the the values were designed to not be accumulative and would approach correct.
In the end, there was an ever so slight increase of variability in the presented ETC, but it was still capable of predicting what time it would finish within 1% of error within the first few minutes of a multi-hour run, and now it was able to scale to 99% CPU on a 32core HT server. Not that the increased variability mattered much because there was already a natural amount of minor variability due to available computational resources. In short, the increased variability was measurably different, but within the std-dev of existing uncontrollable fluctuations.
Moral of this store. In concurrency, perfect can be the enemy of good.
As long as we understand that "X is difficult" has an implied "X is difficult to me or most others". I find a lot of things difficult that are considered simple to most. I really dislike how society tries to force everyone into some bell-curve of ability. I'm lucky enough to have the confidence in the very narrow band of what I'm great at and a team to back me up. The important part is I'm part of a team. Each with our own strengths. I just so happen to be exceptionally good at what most of them find difficult or impossible, yet I have extreme difficulty dealing with every day problems.
I very much get the feeling that humanity would be much further if we didn't artificially restrict people by requiring them to have skills orthogonal to the problem at hand. Referencing back at the "You can't do arithmetic so you can't enter high end physics classes". I have a similar issue. I am horrible at math in my head, even though I understand it very well. I am good at manipulating symbols and found out too late that I excel at higher maths, but they were not my passion. Just because I can't do something does not mean I do not understand it. Computers are great at math, but have zero understanding.
The world is filled with broken, insecure code written by people who treated Bruce Schneier's "Applied Cryptography" book like a howto-cookbook instead of a very, very old & out of date high-level overview.
Programming is like 80% abstract thinking and 20% dealing with people, yet somehow many programmers are poor at both. People taking Bruce Schneier too literally and not capable of thinking for themselves.
It was on youtube interviewing him with his recent book. The context was he was talking about the 1% genetic difference between humans are apes(or whatever) and how even the most intelligent of apes are only as smart as a typical 3 year old human. He was saying that we think the laws of the Universe are "hard", but that's hubris because a species 1% different from us may have their 3 year old children being as smart as our smartest physicists, and what's difficult to us may be a simple logic problem to them.
Many problems in life we that call "difficult" are because they require physical effort or lots of knowledge which may be incredible difficult to acquire. But problems of pure reasoning, like many "difficult" aspects of programming, are only relatively difficult to the person(s) claiming it to be, not an inherent fact.
I don't claim to be "smart" as in better at everything, but I do have my strengths. In those strengths, I have solved issues that have stumped entire communities of seasoned professionals for years within seconds of reading of the problem. My guess is most people are like me and we're just not letting people who have intuitive understandings of certain issues to be fully utilized. I've heard of people who can't do basic arithmetic, but are gods at Calculus, but were prevented from even learning Calculus until much later and became recognized as leading physicists in their niche. It was only happenstance that a teacher allowed them to skip remedial math and go into advanced math. There's probably many more out there.
A big problem of intuition is it's nearly impossible to explain and few believe you if they can't understand. Let me explain how you ride a bike. Sit on the seat and start peddling.
I'd rather have-not than have-crap. I can't stand dealing with the unreliability of an unpolished product. I have no idea how the typical person can be so accepting when they're also equally short fused. For example. I've seen people calmly "accept" that their wireless AP is a pile of crap, while yelling at their device, yet refuse to spend a small amount extra to get something that is nearly perfect in every way.
Many of these people also complain they don't have any money, yet "It's payday!" and drop $100 in one night at the bar. People are irrational.
When I was super poor, I purchased a $10 belt. Thing fell apart in 2 months. Then I decided to step-it-up and get a $30 belt. Fell apart in 6 months. F that. Next belt was a $100 solid-one-layer full-grain english bridle leather sourced from a 100+ year old tannery, with marine-grade nylon edge stitching. Belt is now indestructible. Just a quick cleaning and some conditioner 2x a year. I leave the shirts untucked, no one can see it, but I love knowing that I no longer need to worry about my belt looking like stretched laughy taffy at the holes and parts flaking off onto my pants and chairs.
I know people who regularly replace their $20-$30 belts 2-3 times a year because they break down, but tell me they can't afford a $100 belt.
If you're doing a one-off that you do not plan to support, high quality code is more expensive. If you plan on supporting your product, high quality code is easy relative to supporting crap code. I spend more time reading code that writing code. The higher quality the code, the faster I can read it and the easier making changes are, and the less risk of changes creating bugs.
There is nothing difficult about programming. The only thing difficult is when a programmer makes it difficult. To paraphrase Neil deGrasse Tyson, "To think a problem inherently difficult is hubris". Just because a problem is difficult for you doesn't mean the problem is difficult.
You can choose to not validate. It's a fundamental issue that there have to be an authority of some sort if you want to validate against an authority.
FreeBSD is still maintained by many of the original AT&T Unix, BSD, and Solaris engineers. Some have taken more high level project management positions, but quite a few are still in the trenches writing code.
I have to deal with tight SLAs for bug-fixes or work-arounds. You can argue about ideals from an ivory tower, but in the real world, a customer has a $10mil contract that is contingent on next-day turn-arounds, you get interrupted. 99% of the time, the issue is not with our code, but 11th hour feature changes that threaten the contract or with interfacing with under-designed code that the team can't even tell you what is defined as "working". Many "agile" teams define "working" as when the customer isn't able to get an issue to be reproduced.
Sarcasm? If you don't have a design, then anything could be considered "working code". A "bug" is anything that doesn't work according to the design. Without a design, you have no bugs, everything is a feature! Is your data getting corrupted? If it's working as designed, then it's an undocumented feature.
I asked a trainer on how to handle architecture and design with Agile since it doesn't really fit. I was told to "timebox". Yeah... ummm... no. Agile is a development process, not an architecture or design process. I haz hammer, everything a nail!
My company uses Agile more as a time management and priority planning process than a full development process. I think it works great in that sense. I can never really work on any one thing 100% of the time. Agile allows us to take in new work, see it relative to other work, and plan and communicate with others how we plan to spend our time for the next 2 weeks.
When someone comes to us with work that "must get done" we can show them all of our scheduled work and figure out which other work might need to get pushed and communicate with the stake holders of that work to find out who's work really is more important. It also helps with resource allocations. We can show to upper management where we spend our time and they can decide to shift work away from us, further delay work, or let us hire.
Unallocated IPs are scarce. Some companies are sitting on a stock pile.