skysight-inc/HackerNews huggingface dataset:
I think I have to agree with you. The fact that Rick was allowed to be turned from a Dr. Jekyll to a Mr. Hyde is kind of the company's fault. No one stepped in to hold Rick accountable during meetings?

While I no longer work there, my first job with some programming had me training to understand the code, what it was about, and even how to write it.

To this day, I still use this method so I don't get lost or bored in my code.

These are the lines I actually use along with commenting my own code just in case I have to return back to it weeks or months or even years later, I don't have to try and trace every step back to a particular code.

// AUTHOR: MG
// FILENAME: functions.php
// STATUS: ACTIVE
// PURPOSE: All of the functions for this application (app name)
// NOTES: There are several unused functions in this file that are commented out but once in production
// They can be deleted as we likely will not be needing them at all.

Those 5 lines have saved me a lot of time. While I don't include the "author" line since it just me writing the code, if there are tons of hands in there, you should know EVERY SINGLE author as well as when code gets commented, it should contain the initials upfront, such as // mg: this does this and this does that. If I know multiple files touch.. I also add: "ASSOCIATIONS:" and list all files that call this one.

Using this method, I've been able to complete a bunch of projects much quicker because any time I start to forget: what am I doing? what does this code do? am I on the right track? I can look right at the beginning of a file and know the answer.

I'm not saying that a boss or supervisor has to be a micromanager, but meetings are necessary to understand where everyone is at. Leaving a programmer to do his own thing means that he really is doing his own thing and is more likely to get lost in the code. I'd say more like he wasn't a genius but thought he could do it alone.. and sometimes, it is nice to have someone step in and tell you: "Hey where we at? What can we do to speed this up?" or even provide their own insight... I can't tell you how many times I've talked with my spouse about an issue.. and she's suggested, "Why don't you just do this?" and it has saved me hours of time just because of someone not in the code is able to see another solution.
Another thing that is rarely mentioned, is that it’s very common to use color filters in B&W photography to tune the contrast.

That means the luminance values can be completely different from what they actually were, and skew the color choices. On the other hand, this might be something that a good ML algorithm can detect and compensate for.
Rick was not managed - at all. Rick became a monster because no one at the management layer was doing their job. If you're letting coders write custom tools instead of procuring where possible, that's management's fault. The list of mismanagement goes on and on. Sure Rick was a douchebag. Anyone who has spent any time in a cs program has met a potential Rick. The fact that you fostered one while he almost blew up your project is your failure, not his.

Edit: also if 90% of his code was able to be thrown out, then I don't think Rick was ever the super star that you or he thought he was.
I'm working on the website, repository has become so big, it's hard to get find anything easily.

Websites will have categories and global search so you can find anything you are looking for quickly.
merged most of them. :)
The problem is "we take care of people that need help" kind of ignores all of the jobs that were lost by off-shoring...

How many manufacturing jobs has the US lost due to competition in an open market with countries that don't have basic human rights (IE: Kids in sweat shops in various countries. The US doesn't make clothes anymore because we can't compete with those conditions.)

You say "those people need jobs too"... but then ignore all the lost American jobs, reduction in American competitiveness (due to closed factories, outsourced skills, etc) and the various human rights issues that take place around the world.

Am I simplifying things? Sure... but so are you...

It is a greatly complicated problem - and, as you said, not a zero sum... but at the end of the day, I don't think it's "unfair" to care more about "us" than "them" as long as "they" don't have the same standards we do.

I think there should be barriers that keep competition on a level playing field. 40 hour work week vs 40 hour work week. Basic human rights vs basic human rights.

Pipe dream? of course... but I think that countries would improve themselves to have entry to our markets (and to have us allowed into theirs).

And isn't that what you really want? Improvements all around?

I'm just focused on different improvements (Here at home and then abroad) instead of your improvements (Improvements abroad and maybe someday improvements here)
I like these types of discussions.

For me, note-taking is something which helps me digest complex ideas. It's a valuable thing and something you can improve at with time.

Then I read the reasoning behind why others don't take notes and I stop to think. Hmm, maybe there is such a thing as too much. Maybe note-taking has a fine balance. Breaking up complexity and summarizing it with notes can be very helpful with getting something finished. Writing journals of everything you do daily probably detracts time from actually performing the tasks required.

There's some science out there on how dopamine gets released when we TALK about performing an action with desirable results. (I'm going to create this project, I'm going to workout this summer and lose weight, I'm going to read 12 books this year). Basically, you're being rewarded for not doing but just saying.
If you spend too much time note-taking on a plan or project, you might be getting the dopamine fix, which might make it harder to execute.

Similar comparisons are with startups and large companies. Startups work fast and can ship products quicker, at the cost of maintainability. Large companies have to take their time documenting, grabbing requirements, assigning the team, and following internal processes. The process kills productivity, in favor of predictability and maintainability.
Not really, especially considering we're only fairly recently getting really fast global connections.

Also, shrewd programmers have been keeping the ball moving with a never ending stream of new ways (libraries/frameworks/platforms) to reinvent the wheel which has created a massive number of jobs for a long time. Some day this may come to an end as well, and I think the cloud might do it.
Isn't Apple a big tech company of the past even though they are quite successful at this time?
This to me sounds more or less like the meant-to-confuse arguments given by the people involved and their lawyers to confuse the general public until they throw up their hands in despair. I followed the financial crisis closely enough to know that there were numerous laws broken all over the place, and nothing happened.

And no, I'm not going to participate in some nonsense back and forth posting articles to "prove" this, es the ultimate "proof" is always going to be what was decided in a court of "law", which simply demonstrates OP's claim of widespread corruption, but only if you're willing to look honestly.
> AUTHOR: MG

This is already in your commit history, so why hardcode it into the source?

> FILENAME: functions.php

This is obvious because you just opened the file. So again, why even put it there? When the file gets renamed the documentation is no longer correct? These things are also hard to refactor.

> STATUS: ACTIVE

Every part of the code is always active...

> PURPOSE: All of the functions for this application (app name)

Okay, probably the most useful one here. But what if we're refactoring the code and the purpose changes? Or if someone adds a few functions and the documentation no longer covers the purpose?

> NOTES: There are several unused functions in this file that are commented out but once in production They can be deleted as we likely will not be needing them at all.

Very dangerous, again because the source might change while the documentation doesn't. But why even write "they can be deleted"? Why not just delete them? That's what version control is for.
I see this comment a lot. The issues are the same with any REST API. Often they have been solved many times by the community or are baked into whatever backend framework you happen to be using. GraphQL (and community) are still converging on a set of best practices, but you can still solve the issue yourself using the same techniques from REST. Here is how we do it at Bustle:

1. Wrap the entire query execution in an auth check. This is similar to whatever happens in a REST auth flow. Check the caller is legit before moving on. Nothing graphQL specific here.

2. Check auth on fields. This is a neat thing about graphQL. You can statically analyze the fields in the query to make sure the caller is only accessing fields they are supposed to. We do this by adding an `auth` property to the standard graphQL-js field object. When we build the schema we do some fanciness to wrap the resolvers in a new function that checks that field and behaves accordingly[1]

3. Throw errors on unauthorized data. Same as you would in a REST API. If you get back data the caller can't access, check it before replying. Obviously not ideal, but sometimes this is the only option.

At someone on twitter's request I wrote up some more thoughts a while back about running graphQL in production: https://gist.github.com/southpolesteve/08edb6a481c07f66eb71e...

I also gave a talk on this at Node Interactive last week: https://youtu.be/vI9ERvz9WWU

[1] https://gist.github.com/southpolesteve/e190e9572d060b5158366...
In many ways, I think we're actually in agreement :p

Free. Quick. Interactive. 4 lines. Done. What's the value proposition of Julia compared to that? Now you can argue that Julia will allow better type specification and specialisation, etc, etc. But that's not what's valued or used in your example.

Now, my mindset/domain has to engage with such, and i freak out at the implicit-ness/assumptions inherent in such code, especially with some of R's additional design choices.

In my mind, having code that crashes/errors out when something ambiguous/dangerous is encountered in your example a "good thing". But that's not what's valued in the above example.

And while Julia would allow someone to program in such a way as to specialise or raise these errors and concerns, what is valued is the ability to not think about them. And if you don't think about them, or even as a library designer, if you want to program in such a way that your user primarily doesn't want to think about them, then you're effectively very close to reinventing/reimplementing a new "R", with all its costs and benefits.

I'm just making this observation explicit, even though I actually do value the things the Julia crowd seems to value, but I'm not sure I'm in the majority, and I'm not sure you can push that down into the libraries without exposing concerns most users don't want to be exposed to.
But that's just not how human goals actually work. Nobody - except maybe a wireless radio engineer - wants to "turn off wifi". Nobody has that as their actual goal - turning off wifi is a way to accomplish some goal. That goal might be "make the internet work better (by using LTE instead)" or maybe "stop distracting me with notifications from the internet" or something else. But "turn off wifi" doesn't make sense as a goal in and of itself, and so Apple is trying to do something that better maps to what people want.

Now, whether they've done so correctly - both from the perspective of what actually happens, and how it is communicated to the user - that's certainly an issue and it's clear they haven't executed this well.
The Houston situation is as much the fault of regulation as its the fault of not having some.

Houston itself was only built up to the degree it was on the backs of federally subsidized flood insurance and huge amounts of public money spent to build the dams around it. If developers had to eat the real cost of building in a flood zone, many fewer would have done so.
I don't think your analogies are that good. Do you have a fire detector? If yes, are you expecting your house to burn down?

You have to weigh the cost and the risk. Here the risk, how unlikely it might be, should warrant some extra preparation.
My propaganda alarm is going off pretty loudly with this article.
The informative part is 2:57–3:23.

https://www.youtube.com/watch?v=xA4QWwaweWA&t=2m57s
I'm turning into this dude but I just play video games in my office :)
I agree with you that that wasn't the best comparison. As I wrote somewhere downthread, in a perfect world, I'd be comparing Clojure/GraphQL with Python/Graphene. But it is what it is and, even though the project I could compare to wasn't ideal, I still think we were able to draw valuable lessons for our use cases. It isnt't feasible to choose a technology just because it would be a better comparison.

> Interesting insight but I hope folks don’t read this post and think: “wow we are wasting our lives with Django and REST”.

God no! As the author, I hope to god no one thinks that after reading the article. We're mostly a Python shop and we love it, but sometimes it isn't the best choice.
The problem is that flood insurance doesn't work, as an insurance product.

Insurance amortizes across populations to create the illusion of amortizing over time. It doesn't actually amortize over time. The variance on floods even on a national scale is too high to make it work.
Of course, you don't need to write the whole thing. Both parts (XBox 360 and PS4) are at least similar to existing Radeon GCN parts, and we have good quality open source Radeon drivers which outperform the closed ones.
I've broken several motherboards and many cables over the years. It drives me crazy. The USB-C is the worst. I'm on my third cable now. At least I finally figured out to make sure I get USB-C chargers with removable cables. Now I only have to replace the cable, which I've done twice in the last month.

The Dell XPS 13, which I'm getting in a week or so, has both a proprietary power jack and supports USB-C charging. I'm very happy that I won't be breaking many more USB-C cables.
Soundly disproven for domesticated dogs, not wolves.
Disagree. Threaded programming is not that difficult. Design matters. If you are trying to back fit threads into legacy code that has a traditional process based model with massively shared data structures it can be a little ugly.

Most peoples problems come with being over clever with their per thread data/stack, priorities, affinities, attributes, etc..a simple threaded program with a couple of locks for shared data and a flat schedule is efficient and easy to understand on multi-core systems.

Event loops and aio are nice but they are not a superior standalone solution as evidenced by nodes use of libuv.
I'm hoping my dad kept his old scope. I haven't gone through his tools (he passed away a few years ago, and I didn't have the heart at the time, since fixing stuff was how I'd always bonded with my dad and every tool has associated memories), but plan to visit my mom in a few weeks. I'll see if it's still around. He owned a TV shop through the 70s and early 80s. His equipment was usually top notch stuff from the peak of the analog electronics era, but he got rid of some of it over the years, especially during moves.

Someday, I'll have more time to play with electronics. It's something I enjoy, and I have most of the tools for it (except a scope), but I always seem to have too many other things requiring my time and attention.

I worked with high-end 90s-era Tektronix scopes when I worked in television. They definitely weren't pure analog by that time, as they had memory and a variety of modes providing both digital and analog data, but they were still pretty cool.
I'm surprised this isn't the norm.
The same thing goes for Pluto, too, lots of astronomers don't really agree with the new "official" definitions, and it's unclear if these new definitions will hold up as additional planets/dwarf planets are discovered and observed more carefully.
Entrepreneurship in the Literature of Classical Economics
I’ve used multiple image editors for 25 years and the UI is fine, meaning good enough.
Makes you wonder why the company would consider him their "top talent".
1) Location. Very little would change my mind from desired location.

2) Indications of thoughtfulness and solid engineering practices.

Positives: "testing" "mentorship" "Craftsmanship" "clear communication" "clear scoping" and indications thereof. Also, 'boringness' of mission--I want to work on plumbing.

Negatives: "rockstar" "hot".

3) Salary

4) Tech stack

5) Not having candy in easy reach
I wish job descriptions said more about the team, culture, and engineering values. Sure, salary is important too, but there's a wide range I'd be open to if everything else was aligned.

If you look at https://www.keyvalues.io, you'll see what dozens of engineers said they cared about most when evaluating a new job. I used their responses to create engineering team profiles that would directly address these things.

Not surprisingly, I see many of the same values described in the comments in this post: "Work/Life Balance," "High Quality Code Base," "Flexible Work Arrangements," "Safe Environment to Fail," "Committed to Personal Growth," "Team is Diverse," "Remote-OK," "Thoughtful Office Layout," and questions around how "Product-Driven" the team is.
Sadly, Git won. BitKeeper solves a bunch of this stuff, not all, but a bunch but nobody cares. The reality is GitHub won. To 99.99% of the world version control is GitHub. Step outside of what GitHub can do and you get blank stares.

If you want to play with BK, it's at bitkeeper.org, all open source, apache v2 license (because that seemed to be the license that most people liked, contact me if that doesn't work for you).
I wonder if it is possible to use machine learning to win at code golf.

The fitness function seems quite obvious, but how you might get shorter code, while maintaining output is not trivial.
I don't have any USB-C devices, yet.

Is it possible to purchase USB-C cables that work for everything? Or are (some of) the different supported protocols incompatible?
I've seen this sort of thing happen before, and I think there's a big danger in leaving senior engineers lonely in a company.

Imagine how differently this would have played out if 'Rick' had someone at their technical level to talk to. They could bounce ideas off another person and they could help field questions from the team when busy. It sounds like Rick made some potentially questionable technical decisions - but with another very experienced dev around they could keep each other honest and on point.

The problems that come from having only 1 junior dev on the team are obvious - that person will feel alone and out of their depth, and like they're bothering everyone with their problems. But there are similar issues from having only 1 senior dev on a team. That person will naturally try to take responsibility for every aspect of your technology stack. They will do that naturally because the only other option they will see is to let mistakes slip in to the product. And a technical leadership position is a leadership position. Being a good technical leader requires time away from programming to mentor, code review and brainstorm. It requires you to hold meetings, support your team and keep others accountable to standards. The people side of that is a set of skills many programmers don't have.

Ultimately by firing that person you're saying that your team cohesion is more important than quality in the product. Thats a totally reasonable choice. Its also an option that a skilled manager would be able to bring Rick on board with. "Hey Rick, over the long term we want to build an amazing team. You're the most skilled person we have, and we think in the long run the mentoring you've been doing is going to provide more value than getting this particular iteration of our product out the door. We want you in on the long term vision of our company having great engineering, which might mean this next release slips - but we think extra mentoring will be worth it. What do you think?" ... Etc.
"Wolf," "dog," and "coyote" are just social constructs.

Given the immense body of data saying otherwise, it is my hope that your post is the most ignorant thing I’ll read today.
I'm not sure why you're being down voted, but this is a very reasonable counter point.

The purpose or brief should be at the top of every file, it should also evolve as class or implementation does. Arguable that it's really the only one that matters and can also come from no other tool or location.
The bulb limits the current draw from the battery. When the alternator is starting up, the field coil current comes from the battery. Simply connecting the battery across that coil with no additional resistance would draw to much current from the battery.

Alternators have a circuit such that when the battery current is no longer needed (the alternator has spun up and is putting out more voltage than the battery) an arrangement of diodes cuts off the battery field coil circuit and then the light goes out.

When the alternator is self-energizing, there is a feedback mechanism then at play which controls the field current, keeping the alternator voltage level: without it, the voltage would rise uncontrollably: more voltage from alternator -> more current through field coil -> greater induction of voltage. Before the alternator is self-energizing, what regulates the field current is that bulb.

So that is to say, if you see the light on all the time when the alternator is spinning, that warns you that it's not actually working. It is not it's not putting out enough voltage (perhaps none at all) to overpower the battery circuit and become self-energizing. This could be because the rotor coils are burned out, or other problem: wiring or whatever.

Since that bulb is off most of the time, we don't expect to have to change it very often.

If an alternator bulb has burned out, and the unit is not very old, that could indicate a problem.
Mind = blown! Wow! Just, wow!
Or you could set up a captive portal, and phish for login credentials at the same time as you exploit the DNS resolver.
I am the only one at work with the new MBP and I get frequent questions about it and the ports. I usually tell them that I firmly believe USB-C is the way of the future, but alas I live in the present.
So, if you can get a bunch of games for $1 you'll happily pay $5, but if you can get a bunch of games for $1 and even more games for $5, you'll pay $1 and gripe about it?

I'm not sure I follow your logic.
Lookup twisted deferred locks. https://twistedmatrix.com/documents/9.0.0/api/twisted.intern...
Not really, but there are a lot of “research chemicals” (= mostly unregulated drugs) that are serotonin receptor agonists like those. Some like 4-AcO-DMT and 1P-LSD seem to be almost identical to the classics.