OP gave you valuable feedback on how your point is not getting across. Should you edit, or should you lol and snark is a personal choice for you to make. But OP is just trying to help you.
You seem to be missing a lot of data points. From Microsoft to even Jack Welch's GE, absolutely everyone who was competitive was trying to butter up talent.
And then you affirm things such as "unprecedented job mobility", for which citation is sorely needed, and close it with "it's ending", though there is absolutely no evidence for it.
It seems to me that you are trying to ignite some flames, but your points are very thin on data.
Specifically "Fifth Freedom" flights, but they are a minority of Emirates flights, often with a subset of the people that flew the Dubai connecting section.
Yes, they have a few routes like that where it makes sense to have dogleg at the end of a distant destination instead of two direct flights. I took Emirates from Rio to Buenos Aires, which is a route that presumably exists so they don't have to fly to both cities directly from Dubai. Still, the vast majority of their flights are hubbed in Dubai.
Highly developed countries with access to affordable or free healthcare seem to be real blue zones. Especially in highly urban areas. Hong Kong, Singapore, and the big cities of some countries (Tokyo, Sydney) have very high life expectancy numbers.
Seems like getting treatment when you're sick, and having regular check ups to induce lifestyle changes are what makes a place a blue zone.
I think you're confusing correlation with causation. There is no reliable evidence that having regular check ups improves longevity, or even benefits healthy patients at all. And advice given by doctors about lifestyle changes is notoriously ineffective: long-term patient compliance close to zero.
"having regular check ups to induce lifestyle changes"
More likely that those areas have society level positive lifestyles by default, especially relating to foods (eg Okinawa eating until 80% full, Italy and the mederteranian diet, Loma Linda plant heavy diet, etc).
Plenty of people get at least an annual covered checkup, but that doesn't mean they will make lifestyle changes. Even the ones that try end up like a new years resolution - not being strict about it or giving up after a month or two.
Isn’t the whole point of this research that people Okinawa and Italy probably don’t live any longer. In fact these areas have shorter average life span? So, all the stories about the benefit of the Mediterranean fish heavy diet are post-hoc rationalizations of bad data?
"Isn’t the whole point of this research that people Okinawa and Italy probably don’t live any longer."
I didn't see that claim in the article. What I did see is that the data on centarians was shown to be invalid. It's certainly possible that the overall life expectancy stats could be distorted. In most cases (excluding Okinawa), I doubt that the mistakes or fraud are that rampant. The problem with the blue zone studies is that they explicitly focused on outliers from the beginning. Any mistakes or fraud become a big impact in a small population like that. If you use population level life expectancy, the impact should become much smaller, or at the very least any systemic fraud and mistakes should become readily visible and be able to be corrected in the numbers if further studies are done to measure it.
The article is very emotional and seems to mischaracterize some things, such as claiming that every blue zone must fit each piece of the suggestions. The idea of drinking every day is probably not a good suggestion as there is some research contesting the benefits of a glass of wine a day. But let's take Okinawa as an example. It's uncontested that the records have problems, it's trending in the wrong direction (younger generations, probably better records), and it doesn't fit all the practices (eg religion). But does this invalidate the longevity recommendation of eating to 80% full that comes out of the blue zone recommendation? No. There are independent studies showing the benefits of this practice to reduce cardiovascular disease, insulin resistance, and obesity.
So even if the blue zone centarian data is wrong (it is), that doesn't say anything about the suggested practices. Those have always needed their own studies to validate the suggested practices anyways. Fot example, there are numerous studies on the mederteranian diet that shows it is beneficial compared to a typical western diet and especially compared to the typical American diet.
The point is that, if the Blue Zones concept is BS and none of these places have high life expectancy, then there is no reason to discuss them in the context of nutrition or lifestyle recommendations of any kind. Those recommendations may be good or bad, but they are unrelated to the non-existent longevity of these "blue zones".
Yeah, but it's all ancient history at this point. The recommendations have already been proven or disproven through followup studies. Disproving blue zones at this point in time is basically moot.
(Author and implementer of the Swift Int128 proposal here)
There's lots of one-off uses for 128-bit integers scattered around systems programming (and programming in general, I just happen to come from more of a systems background). Individually using a pair of 64b integers for each case is totally workable, but eventually life is easier if you just have an Int128 type. There's not really any one use case that drove their inclusion in the standard library, rather lots of times that we were saying "it would be kind of nice if we had this".
You don't need anything. You choose the most convenient tool according to your professional judgment. I certainly hope that nobody is using Kubernetes because they are against the wall, and instead decide to use it for its features.
From the documentation on the site it says that they're running on dedicated servers from Hetzner... So they aren't auto-scaling anything, they are paying for that hardware 24/7. It makes absolutely no difference what the number of running containers are, the cost remains constant.
While you have a good point, I think the experts also branched off with some unreasonable requirements. I remember reading Yegge's blog post, years ago, saying that an engineer needed to know bitwise operators, otherwise they were not good enough.
I don't know. Curiosity, passion, focus, creative problem solving seem to me much more important criteria for an engineer to have, rather than bitwise operations. An engineer that has these will learn everything needed to get the job done.
So it seems like we all got off the main road, and started looking for shibboleths.
I have a hard time imagining someone who has "curiosity, passion, focus, creative problem solving" regarding programming and yet hasn't stumbled upon bitwise operators (and then immediately found them interesting). They're pretty fundamental to the craft.
I can see having to refresh on various bit shifting techniques for fast multiplication etc (though any serous program should at least be aware of this), but XOR is fundamental to even knowing the basics of cryptography. Bitwise AND, NOT, and OR are certainly something every serious programmer should have a very solid understanding of no?
There is a world of difference between stumbling upon, knowing about in general and being proficient with -because of using on regular basis- some tech piece.
I do know how bitwise AND, NOT, OR, XOR work but I don't solve problems on day to day basis that use those.
If you give me two bytes to do the operations manually it is going to be a piece of cake for me.
If you give me a problem where most optimal solution is using combination of those operations I most likely will use other solution that won't be optimal because on my day to day work I use totally different things.
A bit of a tangent is that is also why we have "loads of applicants willing to do tech jobs" and at the same time "skilled workers shortage" - if company needs someone who can solve optimally problems with bitwise operations "right here right now", I am not the candidate, given couple of months working on those problems I would get proficient rather fast - but no one wants to wait couple of months ;)
It's probably a matter of domain, but most backend engineers who are working in Java/Golang/Python/Ruby systems have very little use of those, and they don't come up easily. Frontend (web or mobile), it comes up even less.
Can you tell me how this knowledge makes one a serious programmer? In which moments of the development lifecycle they are crucial?
Without judgement, this feels like a switch up. It seems to me that the prior author did not suggest they were necessary, but instead ambient, available, and interesting. Indeed for many they are not useful.
At the same time, that might be a good indication of passion: a useless but foundational thing you learn despite having zero economic pressure to do so.
In the domains you have worked on, what are examples of such things?
It is not a switch up. The author said that an engineer would find these during their journey, and I am asking when. I don't have a strongly held opinion here, I literally want to know when. I am curious about it.
Personally, I think it’s possible to not encounter them. I surely avoided them for a while in my own career, finding them to be the tricks of a low-level optimization expert of which I felt little draw.
But then I started investigating type systems and proof languages and discovered them through Boolean algebras. I didn’t work in that space, it was just interesting. I later learned more practically about bits through parsing binary message fields and wonder what the deal with endianness was.
I also recall that yarn that goes around from time to time about Carmack’s fast inverse square root algorithm. Totally useless and yet I recall the first time I read about it how fun a puzzle it was to work out the details.
I’ve encountered them many times since then despite almost never actually using them. Most recently I was investigating WASM and ran across Linear Memory and once again had an opportunity to think about the specifics of memory layout and how bytes and bits are the language of that domain.
I've mostly done corporate Java stuff, so a lot of it didn't come up, as Spring was already doing it for me.
I've first got to enjoy low level programming when reading Fabien Sanglard breaking down Carmack's code. Will look into WASM, sounds like it could be a fun read too.
I found them in 2015 when I was maintaining a legacy app for a university.
The developer that implemented them could have used a few bools but decided to cram it all into one byte using bitwise operators because they were trying to seem smart/clever.
This was a web app, not a microcontroller or some other tightly constrained environment.
One should not have to worry about solar flares! Heh.
Maybe. Every time I write something I consider clever, I often regret it later.
But young people in particular tend to write code using things they don’t need because they want experience in those things. (Just look at people using kubernetes long before there is any need as an example). Where and when this is done can be good or bad, it depends.
Even in a web app, you might want to pack bools into bytes depending on what you are doing. For example, I’ve done stuff with deck.gl and moving massive amounts of data between webworkers and the size of data is material.
It did take a beat to consider an example though, so I do appreciate your point.
Coming from a double major including EE though, all I have to say is that everyone’s code everywhere is just a bunch of NOR gates. Now if you want to increase your salary, looking up why I say “everything is NOR” won’t be useful. But if you are curious, it is interesting to see how one Boolean operand can implement everything.
I can understand writing your own instance and deployment "orchestrator", but I would not consider trying k8s for fun, because it just seems like some arbitrary config you have to learn for something someone else has built.
Nobody that uses bit flags do it because they think it makes them look clever. If anything they believe it looks like using the most basic of tools.
> One should not have to worry about solar flares!
Do you legitimately believe that a bool is immune to this? Yeah, I get this a joke, but it's one told from a conceit.
This whole post comes off as condescending to cover up a failure to understand something basic.
I get it, someone called you out on it at some point in your life and you have decided to strike back, but come on... do you really think you benefit from this display?
I made a concerted effort to understand the code before I made any effort to adapt it to the repo I was working on. I'm glad I did (although honestly, it wasn't in the remotest bit necessary to solve the task at hand!)
> someone who has "curiosity, passion, focus, creative problem solving" regarding programming
would find this on their journey. Whereas you are describing someone who merely views programming as a job.
It's perfectly fine to view programming as "just work" but that's not passion. All of the truly great engineers I've worked with are obsessed with programming and comp sci topics in general. They study things in the evening for fun.
It's clear that you don't, and again, that's fine, but that's not what we're talking about.
Software for you is a job. I work in software because it's an excuse to get paid to do what I love doing. In the shadow of the dotcom bust most engineers where like this, and, they were more technical and show more expertise than most software engineers do today.
It might be an indication for passion, but not knowing them does not indicate lack of it.
The thing is there are unfathomable amount of such things to learn, and if somebody doesn't stumble upon them or won't spend time with them it doesn't indicate lack of it.
I'm sorry but bitwise operators are the most fundamental aspect of how computing works. If you don't understand these things it does indicate a lack of passion, at least in regards to programming and computation.
Bitwise operators are not a particularly complex topic and extend from the basics of how logic is implement in a computer system.
Personally I think ever one interested in programming should have, at least once, implemented a compiler (or at least interpreter). But a compiler is a substantial amount of work, so I understand that not everyone can have this opportunity. But understanding bitwise operators is requires a minimal investment of time and is essentially to really understanding the basics of computing.
Guess I have a lack of passion then, despite building countless of full stack side projects and what-not even before I knew these could make me money at my teenage years. I started out with PHP using txt files as storage in my teens so none of what you said would be relevant to what I've experienced, and that was I would say almost 20 years ago. And in my high school years I took part of coding competitions where I scored high nationally without knowing any of bitwise or otherwise things, despite deeply enjoying those things.
This weird elitism drives me mad, but maybe truly I haven't done enough to prove my worthiness in this arena. Maybe PHP or JavaScript is not true programming.
You're talking past one another. The whole point of being interested and passionate about a topic is that you want to learn stuff regardless of whether or not it's useful
I can be interested in front-end development and learn everything there is to know about templating while never knowing about bitwise operators. Point is domains are so large that even if you go beyond what is required and learn for the sake of curiosity, you can still not touch what others may consider fundamental.
Yeah, that sounds like someone claiming to be passionate about math, but who never heard of prime numbers. It's not that prime numbers are important for literally everything in math (although coincidentally they also happen to be important for cryptography), it's just that it's practically impossible to have high-school knowledge of math without hearing about them.
What other elementary topics are considered too nerdy by the cool people in IT today? Binary numbers, pixels...? What are the cool kids passionate about these days? Buzzwords, networking, social networks...?
> I remember reading Yegge's blog post, years ago, saying that an engineer needed to know bitwise operators, otherwise they were not good enough.
I think he's right, nearly every engineer needs a basic understanding IP routing more today than in the 2000's with how connected the cloud is. Few engineers do, however.
Every time you need to ask yourself, "Where is this packet going?" you're using bitwise operators.
Yegge no longer thinks knowing these kinds of details matter so much, can’t find the exact timestamp but it relates to the skills shifting to being really good at prompting and quickly learning what is relevant
This is something I have some expertise in (I run a recruiting company that uses a standardized interview, and I used to run assessments for another). It's also something I've thought a lot about.
There is absolutely truth to what you're saying. But like most obvious observations that aren't playing themselves out, there's more to it than that.
-----
One: curiosity, passion, and focus matter a lot. Every company that hires through us is looking for them in one form or another. But they still have to figure out a means by which to measure them.
One company thinks "passion" takes the form of "wanting to start a company someday", and worries that someone who isn't that ambitious won't be dedicated enough to push past the problems they run into. But another thinks that "passion" is someone who wants to tinker with optimizing some FPGA all night long because the platonic ideal of making a 15% more efficient circuit for a crypto node is what Real Technical Engineers do.
These companies are not just looking for passion in practice, but for "passion for".
And so you might say okay, screen for that. But the problem is that passion-for is easily faked - and is something you can easily fail to display if your personality skews the wrong way.
When I interviewed at my previous company many years ago, they asked me why I wanted to work there. I answered honestly: it seemed like a good job and that I'd be able to go home and sleep at night. This was a TERRIBLE answer that, had I done less well on other components of the interview or had they been interviewing me for more than a low-level job, would likely have disqualified me. It certainly would not have convinced them I had the passion to make something happen. But a few years later I was in the leadership of that company, and today I run a successor to it trying to carry the torch when they could not.
If you asked me the same question today about why I started a company, an honest answer would be similar: I do this business because I know it and because I enjoy its challenges, not because it's the Most Important Thing In The World To Me. I'm literally a startup founder, and I would not pass 90% of "see if someone's passionate enough to work at a startup" interview questions if I answered them honestly.
On the flip side, a socially-astute candidate who understands the culture of the company and the person they're interviewing with can easily fake these signals. There is a reason that energetic extraverts tend to do well in business - or rather, there are hundreds of reasons, and this is one of them. Social skills let you manipulate behavioral interviews to your advantage, and if you're an interviewer, you don't want candidates doing that.
So in effect, what you're doing here is replacing one shibboleth that has something to do with technical skill, with another that is more about your ability to read an interviewer and "play the game". Which do you think correlates better with technical excellence?
-----
And two: lots of people are curious, passionate, energetic, and not skilled.
You say that a person with those traits "will learn" everything needed. That might even be true. But "will learn" can be three years, five years, down the line.
One of the things we ask on our interview is a sort of "fizzbuzz-plus" style coding problem (you can see a similar problem - the one we send candidates to prep them - at https://www.otherbranch.com/practice-coding-problem if you want to calibrate yourself on what I'm about to say). It is not a difficult problem by any normal standard. It requires nothing more than some simple conditional logic, a class or two, and the basic syntax of the language you're using.
Many apparently-passionate, energetic, and curious engineers simply cannot do it. The example problem I linked is a bit easier than our real one, but I have reliable data on the real one, which tells me that sixty-two percent of candidates who take it do not complete even the second step.
Now, is this artificial? Yeah, but it's artificially easy. It involves little of the subtlety and complexity of real systems, by design. And yet very often we get code that (translated into the example problem I linked) is the rough equivalent of:
print("--*-")
with no underlying data structure, or
if (row == 1 && col == 3)
where the entire board becomes an immutable n^2 case statement that would have to be wholly rewritten if the candidate were to ever get to later steps of the problem.
Would you recommend someone who wrote that kind of code, no matter how apparently curious, passionate, or energetic they were?
I have failed simple coding interviews because of stress. Been coding for 2 decades or more, know I'm good at it, and have had multiple other people confirm this. But sometimes under interview stress, I can lock up. Especially if something goes fubar like their on-line editor.
If I was at work, that wouldn't be a problem, take 3 minutes and come back to it. You don't have that in an interview.
I'm thinking of the observation from the speed climbing event at the Olympics. They had set up the course wrong, and one of the holds in one of the lanes was like 2cm out of position-- and it wasn't even a hold that was used by the climbers. But that was enough that people in that lane consistently lost.
Yeah, this is one of the best arguments against timed interview problems, and I do think it's a good one. You could justifiably argue for a lot of other structures, but those structures do come with their own trade-offs (like time investment for a take-home, or "game-ability" for a behavioral interview, etc).
This has been one of the most interesting and insightful replies I've ever got in a discussion. Thank you for taking the time and explaining your points. It really resonates with what I've seen in real life.
> Hire mediocre people and run around micromanaging, countermanding orders, and generally undermining them
This is how most corporations operate. Tight budgets for headcount, cunning micromanagers, and emotional manipulation to try and get people to have less opinions and deliver more for a stale salary.
Now these corporations are never going go get any sort of competitive advantage through innovation, but they get a huge amount of corporate and governmental contracts.
Managers only hire and reward based on loyalty and threats in these highly political environments. It is very common to see a decent director with very weak managers under him, to ensure that nobody is a threat to his position.
Mediocre corporations work in a very different way from results oriented high performance companies. In mediocre places, games of power rule the place, even if it doesn't make sense economically.
On any given dimension, everyone/everything cannot possibly be above average. If you take competence, most companies will be mediocre. At best you have a bell curve, at worst it's an exponential curve with only a very small amount of high competence.
Hacker News folks tend to see the best side of corporations, working for well managed, innovation driven, purpose oriented places.
It's a privilege. Most corporations are not Google, Apple, Microsoft, Amazon, etc - which a lot of us either work for, or work for companies that were heavily inspired by these top companies.
Yes, past a certain point you are operating to reduce variance.
There's only so many top 1% players, and if you aren't able to pay as well as the GOOG/MSFT/AMZN/AAPLs of the world, then your not going to be able to hire 1000s and 1000s of them.
So most employers are not able to be as selective, especially at scale. Which means they are hiring for B+ players and putting in a lot of "administrivia" to prevent screwups. It's more about hiring for average outcomes and avoiding the downside.
Scrappy startups pre-scale can be an exception in that they have equity and independence to offer to hires in lieu of top tier compensation. Both of those of course are drastically reduced when you have 10s, 100s, 1000s and then 10,000s of employees.
It's not a diss on anyone, so much as the natural order of things.
Even those corporations aren't homogenous in how well they are managed and have a lot of "second class citizen" to whom the privilege doesn't have to apply (managed services, external dev partners, armies of contractors...)
I would argue they can get competitive advantage despite this, or thanks to this by squeezing more juice out of employees while externalizing some of the cost on employee health.
Code is primarily for execution. It is very important that it also communicates to people, for the sake of the business that the code supports, but the main thing is the execution.
Not intended to be pedantic or contrarian, but I think this falls apart when the code is making sure a signal is sent somewhere (aka communication). If I write a module that allows IPC am I focusing on execution or communication?
I understand one can say they were “executing the communication” but at that point we ought to remove execute from the phrase if it has to preface anything you do.
To fully disprove my point, at what point do we never execute something with code so the distinction is even worth mentioning?
OP talks about asking humans what good code looks like, and that's the scope of my response. Code as a communication tool between developers is not its primary reason to exist.
Then why do we keep code after it has been compiled to a functional executable? Why do we (those of us working on teams) have rules limiting how code is written, or even in what language? Why do we study abstraction strategies like OOP and FP? Codifying and then storing a solution is not a necessity essential to a solution, it’s a necessity satisfying an external pressure. My conjecture is that that external pressure is the authors’ need to transmit solutions across time (eg to oneself when it stops running for w/e reason) and space (eg to collaborators), so the solution can be read and understood, revised and extended, in the same way we transmit other ideas in natural language prose or other symbolic systems. If we want to treat this outside of the humanities, we need to abandon high level languages like bash and C and return to manipulating registers and memory directly.
OP gave you valuable feedback on how your point is not getting across. Should you edit, or should you lol and snark is a personal choice for you to make. But OP is just trying to help you.