The world doesn't run on "well-meaning" but realpolitik (look it up). The sort of discriminatory policies you espouse besides being corrosive poison to the unifying forces that create a nation state, fail to account for competition among nations.
The USA is free to teach CRT to kids, "decolonize mathematics", destroy meritocracy in public schools, lower the standards and burden young minds with race guilt and a feeling of entitlement (instead of striving for excellence) but one shouldn't be surprised if other countries that have maintained their connection with reality leave us in the dust.
I have a feeling it won't be dialed down, but dialed up to 12. There was an awesome cartoon that I can't find anymore - two VW busses side by side. One with a bunch of classic progressive stickers - "Liberty", "Civil Rights", "ACLU", "Free Speech", "EPA", etc. Another one that's beaten up, with "Race", "CRT", "Hate", etc. representing contemporary progressivism.
It’s crazy. I had a lot of respect for the ACLU, but the days where they stood for something; and everyone could point to the principles and at least begrudgingly admire it are long gone.
> Background: Worked on multiple FAANGs, including Google and Amazon, also fintech, now retired.
To the poster: this is why you don't want to work at FAANGs. There's no world where you can be excellent and simultaneously be this much of an entitled dick. That world is one of pioneers who have paved the way for the pretenders who live in it now.
If you want to be actually good at your job, you'll need to choose whether you want to know something or know someone. Money may or may not show up, but don't go chasing money if you want to build something worthwhile.
What you wrote makes me view the Guardian take suspiciously rather than the OP and also fails to address in any way the argument since you -conveniently- ignore all but a tiny fraction that you found a Guardian opinion piece to seemingly not support.
Looking at your chart, it has NZ at 188, UK at 114, FR 87, Germany 69, Canada 107. NZ looks higher on a skim than most (all) of Western Europe. What do you think I'm missing?
You can keep rearranging words around trying to make reality fit your expectations, but I'd say this isn't a useful modeling strategy for going about life. This is what you're missing.
I left SF and California years ago and started voting Republican at about the same time. The trigger was me reserving judgment and simply observing how the environment around me changed for the worst, while at the same time having to bring up two young children.
Looking at how things are today, I know I made the right decision.
Relying on libraries written in C is not an issue if the library doesn't make assumptions about / isn't tied to, a particular architecture. Some do but most (especially newer codebases written to C11 and beyond) don't.
There's also the issue of performance-optimised assembly routines, which impacts many native libraries doing things such as crypto, image processing, etc.
First time I was late paying AMEX they raised my interest rate north of 25%. They could legally do so, but they were the only card I had that did it so quickly; just one day late.
Discover was my favorite. They had a forgiveness policy and wouldn't raise your rate just because another card did. And their website was very friendly to use.
Their app is blasted easy to use for payments & viewing account information as well. I despise the Chase app where my auto loan sits, as it never loads correctly on my iPhone, or takes drastically longer. Whereas the Discover app and pages load without problem.
I guess that's how they make money and can afford great customer service, which is also something I'm fine with: I couldn't care less what their interest rate is since I'll never ever pay interest. If that's on the agenda, then I'd look somewhere else as you say.
Reviewing code is the elephant in the room. Filosotile -perhaps out of ignorance or disconnect- fails to mention that the vast majority of open source projects (log4j being a great recent example) are absolute shit. Nobody should be building anything on top, nevermind giving the maintainers more money.
In-house development, software BOMs, rising of standards and multiple rounds of code review are the processes that the industry is shifting towards and for good reason.
I would be fascinated to see your evidence that in-house code is any better on average than open-source code.
I haven't done a lot of consulting lately, so I haven't seen much in-house code in the last few years. But my experience is that the average in-house codebase is worse. And that makes sense from the incentives. Open-source projects that want more than one contributor need to be approachable enough that people join in. Whereas with most in-house code, people commit to working on it without ever seeing it. Switching to work on another open-source project is easy; switching to another job is hard. Open-source authors get to decide when to release; in-house code is generally driven by execs. And so on.
... keeps resulting in shit code, too! There's no evidence standards of quality are rising. In my own extremely limited view of in-house software -- i.e. my own professional experience -- code quality is crap, standard quality practices are very low and actually worse than in FOSS projects (I've seen someone mention more than once that "this crap PR simply wouldn't fly if this were an open source project, it's so bad nobody would want to review it!"), absolutely dumb bugs keep hitting production, and people think of automated testing as "that thing we don't want to do".
In-house code is just code you don't know is garbage because you cannot look at the code.
I didn’t say in-house code was good, but it does keep you from being exploited by things like what recently happened with NPM.
Companies genuinely don’t care about the software they use, as long as it works and isn’t hacked. This is especially true in non-tech enterprise. At my former place they still had hundreds of ASP Webforms with custom in-house ASP libraries that were utter shit, but they worked.
What I’m postulating is that this is the alternative to the current status que.
I’d personally love for NPM to review their packages, or for a big player like Microsoft to step in and make a more limited platform with reviews, but I just don’t think anyone is going to be willing to pay for it.
I think I’m too senior to believe in non-shit software.
I work in non tech enterprise. You’d think that things like the ransomware scandals, GDPR, the increased risk-awareness would have improved the business processes or management awareness or all the things are “corporate digital maturity” but the pressure to get things done fast with minimal resources has frankly never been higher.
In that environment we’re always going to have shit-software. If anything I agree with you, which is why I said that I thought that the current status quo was the best ever.
Every engineering-driven fintech company I know of (having myself worked there or having friends who work there) is doubling down on every single one of the processes I mentioned.
Yeah, and that is about 0.1% of total amount of software assembled and deployed in the world. It is like saying all my friends drink Evian water so that's the way we handle clean drinking water shortage in the world.
Your post ought to be ample proof that subjective opinions (like the one you display here) are not solid grounds for hiring decisions.
When looking at this person's Github page, I -unlike you- see a vast number of trivial projects that can best be described as regurgitations of other people's work. Even worse, if you actually look at his first pinned project (https://github.com/kevinburke/nacl), you'll see that it is nothing but a wrapper with trivial changes/updates... an anti-project.
In the end, I see code that provides the illusion of competence but, when actually inspected, is actually telling me not to hire this person. The fact that pretty much anyone can declare oneself "a software engineer" today and easily present a veneer of competence together with powerful financial incentives, makes it absolutely necessary for any serious engineering team to have objective measures in place in order to evaluate candidates.
There are so many terrible engineers out there (and some even slip through the cracks and land at places like FAANG) that doing anything less is irresponsible.
I never said you should just hire someone on the basis of their repo.
But rather, if you're looking for a basic smoke test which can answer the question "Can this person actually code? Do I want to spend more time engaging them?" -- there are better ways to do that than expecting them to cram on a list of algorithms to recite over the phone. Like looking at an actual work sample.
The fact that you looked at this work sample -- and came to your own conclusion about whether they would be worth engaging -- validates this very simple and basic point.
Which is your call of course. He may not meet your bar, but it would be absurd to say this guy can't code, and hasn't been around the block in terms of general CS concepts.
That said -- my own subjective opinion is that you're being exquisitely savage in your assessment of his NaCl implementation. Yeah, it's wrapper -- like it says in the Readme, and like a lot of working code out there. It's a pretty established way of solving a problem, in fact -- in some cases a very efficient and elegant way. It's not the same thing as writing 20k of primitives from scratch, of course. But that's not what he's presenting it as. He's not saying it's a "tour de force". He's saying "I think this shows we can talk about other things besides FizzBuzz".
And then other things you're like saying... like "an anti-project"? Wow.
Engineering is not about whether someone "can code", but whether someone can _engineer solutions to problems_. Has this person demonstrated that through the projects he chooses to put on display (and advertise as signal for his ability) on Github?
This is also what a lot of those engineering interviews are trying to ascertain, in a quantitative manner. I couldn't care less about someone's degrees or ivy league schools or Github projects (in isolation). These are all secondary -if that- considerations, problem solving ability being primary.
Has this person demonstrated that through the projects he chooses to put on display (and advertise as signal for his ability) on Github?
Using the example you disparaged (his NaCl implementation), I would say:
"On first appearances, clearly yes. The problem was to adapt the a set of standard Go functions to a foreign interface - something one does quite a lot in an engineering environment. Also, the fact that he's aware of projects like NaCl and seeks to learn from the likes of Bernstein and Lange is a positive signal."
If I wanted to, perhaps I could drill down into the code and/or the NaCl spec itself. I don't know Go, so for all I know, maybe his code is actually horseshit. But all I'm saying is - from first appearances, definitely a positive signal. Infinitely more informative that FizzBuzzing (which would insult both his intelligence and mine).
This is also what a lot of those engineering interviews are trying to ascertain.
I've already made it clear that a glance at a repo does not obviate the need for an actual interview.
So I wrote that because a client had a bunch of existing nacl messages that were signed using Python, but the existing Go library uses a different protocol to sign messages than the standard Python library. The existing Go library also didn't support all of the API's supported by nacl, I figured if I was running into this, then other people would too. Clearly based on the number of stars it seems like a lot of people _are_ finding it useful.
I guess in your eyes I should have also done the cryptography, however, I am not a cryptographer or a mathematician and one of the first things that you learn when you start doing work with cryptography is that you shouldn't roll your own crypto.
I decided to make that library prominent because in my consulting practice I saw a lot of clients using cryptographic primitives that were clunky and/or had a lot more overhead, for things like cookies or public key authentication or just sharing messages. nacl is difficult to use incorrectly, and is fast and efficient in terms of overhead. I wanted to promote use of nacl more than the work that I was doing for it in particular.
For that client (a smart lock company), I rewrote the backend, that someone else wrote in C for a specification that did not match the needs of the business. The C software was extremely difficult to read and maintain - socket writes in a callback in one part of the code and socket reads in a completely different part of the code, shelling out to curl, simple Mongo queries that would take 50 lines to set up. As a result the engineering team could hardly make any progress deploying new features. I ended up rewriting the whole backend in Go, a few thousand lines of understanding what the C code was doing, and porting it, to the point where the team could actually release patches and new features on a regular cadence, and figure out what on earth was going on with the Mongo queries and shell-to-curl.
That's not public though, if you're looking for public work, you could look at Logrole (github.com/kevinburke/logrole), a HTML client for your Twilio call, SMS, phone number, and recording data. Of course, you could say "that's just a regurgitation of whoever did the API client", which is true-ish, but I also wrote the API client (github.com/kevinburke/twilio-go). Of course, you could say "that's just a regurgitation of the Twilio API," but I also helped build and maintain the Twilio API, as well as the documentation and information architecture (https://www.youtube.com/watch?v=sQP_hUNCrcE), and the client libraries (https://www.youtube.com/watch?v=C_UJHqR_2Mo).
Most recently I was hired as the first engineer at Meter (meter.com) where I built out the entire backend API, the deployment infrastructure, the CI/CD infrastructure, a pipeline for the in-the-field servers to update themselves, and a method for access points to retrieve configuration from the backend. All in all this was probably about 30-50,000 lines of code over two years. I think the API has had one customer facing error in two years and no downtime.
It is true that anyone can call themselves "a software engineer" but not everyone can get contracts for a sole member consultancy and, crucially, get their contract renewed multiple times at every single client. If I was selling snake oil and not delivering anything, that would not have happened.
You're being disingenuous. With Manifest v3, it is not possible any more to block requests dynamically which has huge implications for the efficacy of ad blocking (example: forget blocking youtube ads). Additionally, you're limited in how many static rules you can have.
Therefore, it's not just about changing the mechanism, the end result is clearly a lot worse. One can say, they crippled ad-blocking which this change. Hopefully, once the millions of people using ublock origin start noticing what's happening, they will move away from Chrome. I already did, ublock origin is worth more to me than any feature Google puts in Chrome.
Python is terrible at juggling files, setting up pipelines and working with processes. The resulting code is more complicated than the equivalent bash, not to mention longer, and hidden gotchas abound (subprocess deadlocks anyone?). I'll take 50 lines of bash instead of 200+ lines of Python.
Welcome to (shameless plug) Next Generation Shell. It's a modern programming language for DevOps. It is both concise for running external programs (uses small subset of bash syntax) and it is a "real" programming language with data structures and sane error handling among other things.
Ability to run external programs is high on the priorities list. In NGS it means having its own short syntax and handling exit codes among other things. NGS throws exceptions on "bad" exit codes. Hint: not for all tools non zero exit code is "bad". Did not see equivalent exit code handling anywhere else.
Compared to bash... It's not fair comparison even. Another era, another reality, other expectations. Small example: When APIs return structured data, well... you better be able to handle it. See https://ilya-sher.org/2018/09/10/jq-is-a-symptom/
Compared to other modern shells, I would say, NGS is programming language first as opposed to shell first.
This has only been true for the smallest shell scripts in my experience: bash will be less code at first but once you to be portable, handle errors, locking, unicode, buffer or process output, perform non-trivial redirections, or need any data structure more complicated than a simple string it's been pretty common to replace hundreds of lines of spaghetti bash with less Python even after you add comments and a proper CLI interface.
I've never had subprocess deadlock — was this on Windows?
Interesting, I've never had that happen in heavy usage. I've had cases where the called processes blocked for some reason but that was solved by adding a timeout.
The USA is free to teach CRT to kids, "decolonize mathematics", destroy meritocracy in public schools, lower the standards and burden young minds with race guilt and a feeling of entitlement (instead of striving for excellence) but one shouldn't be surprised if other countries that have maintained their connection with reality leave us in the dust.
If you're not convinced, history is full of examples of ideology-driven politics leading to disaster : https://en.wikipedia.org/wiki/Lysenkoism