skysight-inc/HackerNews huggingface dataset:
Curious how you're going to balance mentor expertise with the fact that a business generally requires multiple non-overlapping skillsets.

Lots of bootcamps crank out a disproportionate number of web development juniors compared to other specialties, but surely a business will also require other roles, many of which aren't strictly software engineers or which may involve more investment than a macbook (e.g. designers and wacom hardware + Adobe licenses)

I'm also curious how you plan on tackle tech debt in your platform, given that from my personal experience, some of the scariest codebases I've worked on were ones where there was a lot of newbie turnover.

Another thing I'm curious about scalability. At some point, adding more workers tends to not scale and you start to need a ballooning number of middle-level managers, whose required skillset might primarily be soft skills.
So you have to upgrade to Pro to get documentation and SASS sources?
I agree, Clojure is technically superior in almost every way when compared to JS IMO, and would much prefer to write Clojure than JS. My poor formulated point was that, sometimes the ecosystem is more important. An experienced dev that already knows how to do everything in the domain he's working on won't have much trouble with Clojure, but you don't always know how to do some things and this is were ecosystem(third party APIs, docs, books, libs, forums, etc...) helps greatly.

Also for Clojure and Clojurescript you need to at least have some good level read proficiency in Java and Javascript.
Huawei’s Plight Hangs over Wireless Industry Showcase
> My understanding is that hollow points were designed to prevent over-penetration rather than to harm more

The reasons they were designed to prevent overpenetration is because:

(1) overpenetration means energy which could go into damaging the target is instead wasted doing something else, and,

(2) that “something else” is sometimes harming things that one doesn't mean to harm.
We have to define what "winning" means here. Google uses POWER9 and specialized GPU-like chips for some workloads. All cloud providers can gain from being able to offer products that perform better or have lower prices than it would be possible with x86.

Right now ARM probably outnumbers x86 in number of machines running Linux by a very large margin. In my backpack there is one x86 machine and two ARM ones and that doesn't count the one that's in my hand

It all depends on what chips become available at what price. All cloud providers do lots of hardware design for their own metal. I'd they tell you that their next data center will be primarily ARM, they create a market for a million unit run of whatever CPU they choose.
> Making money is really a shorthand for sustainability. If developers aren't paid, their code can easily fall into disrepair which hurts all their users.

I agree, for many, though not all, developers and projects. Crucially, a lot of folks who can't currently afford to do free work for reputation or personal edification can't currently afford to release open source.

But I also think the money point emphasizes how unfortunate the term "sustainability" is. Typical software businesses don't seek sustainability. They seek profitability. Why should the developers they depend on settle for getting by?

"Profit" has a corporate, rent-seeking connotation to it. In my own side projects and writing, I've come to prefer "gainful", as in "gainful open software development".
I'd be nervous that Google would consider this click fraud even if you aren't the publisher and would limit some account features.
>They are masters of their own persons...

Wise words, from a slave owner.

Better a hypocritical slave owner than not, of course, but I still have a really hard time separating the arguments from the mind that created them.
Not new; just the link at the top is new. The hard part was what to call it. Since the point is to give people more to read, 'more' seemed right.

https://news.ycombinator.com/item?id=12073675

https://news.ycombinator.com/item?id=18512028

Edit: Oh, also: "more" fits with the "More" links you see at the bottom of the front page and other places, clicking which takes you back to previous posts.

Edit 2: Ok, you guys have convinced me you don't like "more", so let's go with "past". That word is overloaded with 'past' links that point to HN searches, but perhaps those meanings are compatible.
This idiotic court must hate money, because I now have absolutely no reason to visit Frisco or spend money there lol.
Yes, agreed. But it does show another pitfall when it comes to using a degenerate case as an interview question: someone who doesn't know anything about parsing or stacks might solve it easily if they have a different mindset. On the other hand, half-remembering something from school could really mess you up.
And the problem with switch in example is solved with a set of brackets. Why is that so bad? That code with brackets would be clear.
Futuristic Vistas and Cosmic Technoscapes: Perry Rhodan Vol. 3000
Nah, those are "old friends".
Your website suggest that "No experience in software development is necessary [...]" to "Become a Full-Stack Developer" after taking the course, and get employed as software engineer. ("Create a project portfolio and we find you a software engineering job")

Are you saying 5 months is not sufficient? ("[...] we will make the program longer (year or longer) and open it up to more people.")
There's a new story about passwords getting hacked and leaked every month, if not every week. This industry needs stronger standards, and if the industry doesn't come up with it ourselves, the law will.
Why Putting Xbox Games on Switch Isn’t as Ridiculous as It Might Sound
"38 year old bee loses game of hide and seek"
> Upstreaming of modifications is kind of orthogonal to the GPL licenses

Correct. And well put.
I think level of safety is higher for other professions; if you mess up as a doctor somebody dies, if you mess up as a lawyer an innocent person goes to jail.

If you mess up a CRUD app as a junior full-stack developer, prod is broken until somebody fixes it. And you can learn enough to not break prod pretty quickly on the fly. It's a very reversible mistake in comparison.
This is essentially one of the arguments made in The Equations of Life: How Physics Shapes Evolution by Charles S. Cockell
Theoretical physics and applied maths. I occasionally see people at the back of seminars with their laptop open, pugging away at their current puzzle with Mathematica.

I've used it to test and prototype calculations and algorithms.

The Stackexchange page for Mathematica is pretty amazing, and quite a good community.
Brexit has really damaged my faith in democracy.
> Outside of a special-case like certain CS students, this question is likely to give very inconsistent results, and those results are going to be dominated by a candidate’s recent familiarity with the underlying problem, rather than their coding skills.

> In most cases, that makes for a bad interview question.

Well, I'm going to have to disagree there. Asking the question and expecting full knowledge of the theoretics behind it, yes. But real-world "practical" software engineering often requires writing parsers, and yes, parsers for context-free languages (whether the parser-writer realizes that or not). A simple, hand-rolled recursive descent parser would suffice for this language.

> But what if someone hasn’t seen this stuff in a decade? Or learned to program without going through a formal CS education? Is it reasonable to expect them to work out the ideas in an interview?

Someone, in a decade of SWE experience, has never needed to implement a parser?

Parsing, as a category of things to talk about, has stuff that someone with a theoretical background should know, but it is also so imminently practical that someone without the degree should have hit it and be able to answer it. I'm not asking that they realize this is a deterministic context free language, or that a PDA is the appropriate machine to parse such a language.

The point of balanced-parens as an interview question is not to get you to recreate the entire history and hierarchy of languages. It's to get you to write a for loop that requires a moderately involved data structure (a stack) to see if you have any ability to reason and to code.

(I also dislike asking the single-variant form of this question, as you can solve it w/ a simple counter. If you involve a second type of matched character, e.g., {}s, then it should require a PDA.)

Are other engineering disciplines so readily accepting of folks w/o training in the field in which they're applying a job to?

If not this, then what? "They might not have run into this!" is why we (should…) ask more than one question in an interview. But I feel like this refrain gets used to justify never asking any question which might reveal that half the candidates that apply for "Senior Software Engineer" positions cannot express proficiency in any programming language…
(Note: obviously my opinion, not the actual rules)

I do think the rule should be based on the content of the release rather than the timing. If the software contains major new features every month that could be relevant to the HN audience I see no reason to remove the post, it's _new_ information being posted on Hacker _News_. (I haven't seen the referenced IDE update post so I don't have an opinion on it either way.)
Are you arguing for native macOS containers (like Windows containers but for the Xnu kernel rather than NT kernel?) or for macOS to somehow support Linux containers (and system calls) "natively," more like BSD's Linux system call emulation and Windows' so-called "Windows Subsystem for Linux?"
The problem with Dole was that there was not one single central ledger of stock transactions that was being kept updated in real time.

Would blockchain have solved that? It's centralized in that there is one ledger. But natively resolving and publishing transactions at high speed is not a feature of blockchains yet. A centrally managed ledger without distributed calculations would be way faster.

Also worth noting that Dole was a weird enough case to be news-worthy, and that it was ultimately resolved. I think it takes more than a few edge cases to justify completely rebuilding the entire basis for a major part of the global financial ecosystem.
I too am concerned that this point is often missed. The choice of where to live, for those who will find well-regarded (and paying) positions in any case, is one given as much weight as the organization for which one will work.
Governments have far more capacity to harm people though.
Url changed from https://slatestarcodex.com/2019/02/22/rip-culture-war-thread..., which is broken.
This is amazingly well written. You covered a good deal of any introduction to computational theory course in a straightforward, well motivated matter. This is definitely something I'll be passing around to some of my bootcamp friends who are curious taste some of the theory they don't get exposure to.

Ironically, what I thought what made this so effective and interesting was that it dug into the theory of a really really easy programming problem. This is a reasonable homework assignment for any first year student. Maybe not month one, but year one for sure.

> That suggests the question: Is balanced parentheses a good interview question?

If you just needed a solution to solve the problem and maybe check a few edge cases; yeah, it's great because it's simple. If you're using it to broach a conversation on automata, regular expressions, and context free languages well yeah delving into that is bad unless you're writing real parsers/compilers at this gig.

I was really put off my the musing over whether it's a good interview question. For such a beautifully written piece it seems to say: if you don't expect candidates to know as much as this don't ask it at all.

If you want to make an apple pie from scratch, you must first create the universe.

...

But if I ask you to make an apple pie I'm not going to ding you for starting with apples, flour, sugar, and butter.
> and how stupid your argument is

Didn't Linus recently go to sensitivity training or something? I think he missed out on the bigger picture.

It seems like his argument is more about shaming anyone who disagrees with him, instead of expressing an opinion.
Yeah, sorry. dotnet core to me has been an attempt by MS to not just get cross platform, but also to rewrite everything to get rid of the old kludges. Simple CLI, simple fsproj files, easy nuget, no differences on linux/osx/windows.

But there is still a lot of outdated docs out there. dotnet core has just come too fast, imo (though I'm thankful). These MS docs are accurate: https://docs.microsoft.com/en-us/dotnet/fsharp/get-started/g.... Though it does specify the use of sln, which isnt necessary for small projects.
A typical interview along these lines will get the candidate to the "single balanced parentheses" solution, then throw in multiple types of parentheses.

The whole script goes sideways if the candidates whips Perl or Ruby or whatever out, and provides a recursive regex.
You can also block people who are not your friends.
This would simply replace one way to monetize channels with a different one. What would this change? (Except allowing the advertisers to better sleep at night)
This is possible. Folks have done it. But consider that by releasing the open source under permissive terms, like MIT, anyone else can come by and do integration/adaptation work, too.

That leads to a kind of cross-purpose incentives. It won't be in your interest to make the code easy to understand or adapt. It won't be in your interest to document how you go about fulfilling those needs. You may face conflict in promoting the availability of your own services through documentation or other materials about the open source project.
It's not gatekeeping, it's an argument against false promises.
A lot of the program is project work and those sometimes require several people with different skills (e.g. UI/UX, a couple full-stack, manager). I think ultimately we'll be taking in different skill-training simultaneously (i.e. project managers learning beside programmers).

As for the core platform, we keep that to more senior people for now.
Making the payback at marginal rates (0% for below $40k and 20% for everything above that) would largely fix this issue.

If you are making around $40k per year, you have nothing to lose; if the program doesn't improve your state in life at least you don't have to pay too much back.

Non-marginal (15% of everything) plus the "you must work for us if we beat offers" theoretically could lead to them offering everyone a $40,001 per year job, essentially forcing them to work that for 2 years and incur high payback costs.
I don't think he's assuming any such thing. His argument is simply that ARM can't win until it has a reasonable dev box. He makes no speculation about if/when such a box is coming.
Why the Grammys Sound Amazing and Sometimes Go Wrong
Semantics aside, you haven’t established that those are primary drivers of cost or effectiveness. France and UK have 10x the population of Norway and are considerably more diverse. Can you prove where this impacts their respective costs?
Good question. I think about the values and principles of the self. For some people, their values and principles shift and their true self, then, changes over space and time.
Oh, to be clear... I'm perfectly HAPPY with release announcements, and believe that strict interpretation was ridiculous.

I was simply taking issue with the inconsistency, arbitrary interpretation, selective enforcement, etc.
The Road by Cormac McCarthy. Really got me thinking about what is in front of us.

The Royal Game by Stefan Zweig. Beautiful novella, a pleasure to read.
That's right. Iteration is key. Start small here on Earth, then build a somewhat crude factory in space. Solve any unexpected challenges that may arise, rinse, and repeat. Eventually you'll have factory-producing factories.
No, because singular they is a well-established idiom that conveys "unknown gender", it subsumes people who actually prefer "they" as well as people who prefer "he" and "she".
ARM is pretty much universally used on mobile these days and also in a fair bit of low end windows and chromebook laptops. With Apple being rumored to launch ARM on desktop and new OSS risc-v chipsets becoming a thing a lot of the arguments that Linus Torvalds is making ring more true looking backwards than forwards. Also WASM is becoming a thing.

I don't think it's as black and white as wanting the same CPU and OS on your deployment platform and development platform. When it comes to mobile development, having those two be completely different is the norm. It's not much of a problem in practice. The differences between different platforms with the same cpu architecture and OS from different vendors is a much bigger headache than the difference between each of those and the windows or mac + intel laptops the software is being developed on. The difference between windows and macs still causes some headaches of course but is mostly managable. If it works on Linux it generally also works on mac. And if it doesn't that's a good sign of immaturity. All I'm saying here is that most mainstream technologies work across all three of those without much headaches.
Could also be organizational. Constantly shifting whims of stakeholders, etc. Yes, requirements change but changing major requirements without a major refactor can cause these kinds of problems with the code. Or if the developer is being given unreasonable deadlines, no time/resources for testing, etc etc.
> AGPL forces AWS to be open with their changes.

Unfortunately, AGPL is full of loopholes, which are emerging now, because large enterprises with access to specialist legal talent are putting the microscope on licenses for projects like AGPL MongoDB.

https://writing.kemitchell.com/2018/11/04/Copyleft-Bust-Up.h...

MongoDB's counsel mentioned this directly in their statement submitting SSPL to OSI.
At the moment, and as a European, it seems to me that lately:

(I'm using quotes here because I don't think this is what the majority og the left, right or muslims want.)

-"the left" very much more often fight in the streets, throw stones, destroy property, burn cars. This happens on a daily basid now.

-"the right" has been responsible for a smaller number of much more deadly attacks.

-together with "the muslims" who'll also bomb a subway or concert from time to time.

A few decades back it was "the left" (RAF and others) that stood for the spectacular bombings and hostage takings while "the right" were shaving their heads, beating people and destroying property.

None of them are right and I wish them all behind bars.
Dev A is a junior developer that doesn't understand the time and opportunity cost of rewrites. Or that projects and managers don't care about style, they want new features and stability. Doing things better going forward is great. Going back to change legacy code for style? Frankly, that's a big waste of time, and management will not look fondly on your lack of visible or impactful progress.

I was Dev A a couple of years ago. Don't be Dev A for too long.
Starting from zero, most people will require at least 18 months to become productive software developers
I had a similar experience with Clojure a few years back. LISP--had never learned it, then suddenly decided to read "The Little Schemer."

I still hate this industry, though. It blows.
#9 might be a symptom of a structural problem. If developers routinely encounter problems arising from technical debt, and are continually asked to fix those problems, but are somehow never afforded the opportunity to retire the technical debt, that creates an aversion to the maintenance work.

"If it ain't broke, don't fix it; if it is broke, just use duct tape."

A lot of places have infinite budget for fixing things an a patchwork fashion, yet zero budget for planning ahead for the maintenance phase, or for scheduling preventative maintenance. It's the equivalent of never going to the doctor for a checkup, and only going to the Emergency Department at the nearest hospital when an organ explodes. Nobody wants to be in a long-term relationship with an exploding-organ person, and it's the same for code.

---

#10 is an organizational issue. If a dev has "ownership" of a particular domain, they will naturally work very hard in the short run at setting it up so that they may be as lazy as possible in the long run. But if they are continually kicked off their catbird seat of smoothly-running machinery in order to clean up other people's messes, then there is some incentive to exaggerate the effort it takes to clean up their own mess. Or to make it appear as though they have a mess to clean up.

Even worse, if no one has ownership over anything, there is incentive to always drag heels on the current thankless and tedious task just to delay assignment of the next thankless and tedious task. Do the minimum amount of work to fix the current issue, and let the next guy deal with the fallout, even if the next guy is also you. Because if you bust your ass to fix it right, the next guy won't thank you, because there is no next guy. You can only work on the stuff that is broken, and if there's not enough work to do, people get laid off.

And that is the equivalent of under-staffing the POS cashiers, so that none of them are ever idle. That strategy results in fewer customer transactions, because when cashiers are never idle, that also means that there is always a wait for customers to check out, no matter what size the order, and the cashiers have zero individual incentive to complete an order quickly. Monitoring scan rates only covers the problem, which is that employees are implicitly punished for doing their job too well. Go to Wal-Mart, and all the cashiers are always busy, but also always dragging ass, and all the check-out lines are three customers deep. Go to Publix, and cashiers with empty lanes cheerfully offer to check you out the instant you have found everything you need, and will direct you to the correct aisle if you haven't. Idleness is not just doing nothing, but is also customer responsiveness.

When other devs do this, your best tactic is probably just to follow their lead, and possibly collude with each another against management for your own benefit. The org is broken, and you won't be allowed to fix it.
Yes, in an ideal case, it would be nice if there were separate pronouns for "single unspecified gender" and "multiple". Unfortunately, we don't get to reboot spoken languages.

Even if we could, it's still not clear what the ideal solution would be. There are cases where you need to communicate ambiguous number too. It might be nice to have pronouns that distinguish "definitely more than one" from "potentially more than one".
Undefined behavior is not a compiler specific guarantee. UB can change based on almost random factors, especially between newer releases of the same compiler. They are bugs, they were just masked.
Blockchain is an incredibly elegant solution to a problem that doesn't exist.
Pretty much.

The current legal definition seems to make the assumption that when the founders sat around writing the constitution, one of them looked up and asked for a nice punchy way to say "the complete domain of reality from the ground to the infinite reaches of the heavens above" and the reply was "oh, just say interstate commerce."