pitkali

I just have autofill disabled. To fill in the password, I need to actually click some buttons.

I have enough of astigmatism to have it corrected in my glasses and yet the colour scheme I found the most comfortable over the years is Zenburn. Though I do prefer the high contrast version with darker background.

The only time I managed to use a light theme for an extended period of time was a couple of years in a room with weird lighting and reflective screen of an imac. That's when I was using Solarised Light, because my Zenburn just couldn't provide enough contrast.

Then I moved to a different room and it was back to Zenburn.

It was actually a different article -- about how a test is going to be carried out. Today's article is about the results.

But isn't that just a matter of using a formatter to ensure correct style in addition to tabs? If you are using tabs for indentation, your style guide probably does not, or at least should not, depend on how wide they are on the user's screen.

> Many people need the social chitchat to feel OK. It is not a negative side of video conferencing, it is added value.

I think this aspect really needs more attention. Personally, I have never felt much need for much of social bonding at work but I am fully aware that many people have stronger desires in this area.

We ignore human psychology at our own peril. Even very technical people with low social requirements remain human and, more importantly, work with other humans that may have different needs.

I opened an account this week and it was a videochat (they call it IDNow).

However, while you need a German address, no registration is necessary (which I'm only having done on Monday). I didn't even have any German phone number yet at that point.

> - a lot of companies don't manufacture the product themself

But the brand is responsible for the quality as perceived by the customer. They retain any good brand image by properly managing supply/subcontractor chain with quality control.

For the end user expiernce, it is not important who manufactures what but what assurances about the quality are made.

> The average developer cannot pick up an entirely new language in a few days. Maybe I'm incompetent, but it takes me a few months before I start to feel comfortable with a new language and its ecosystem, and a year or two before I feel like I really understand the nuances and know just where to look when something goes wrong.

I have to agree that in most cases few days are not realistic, but I'm convinced you could apply Pareto principle and state that you can get most things done with knowing just enough of the language.

A year or two to understand nuances sounds like not making a deliberate effort to learn about them and instead just waiting until you get that through osmosis by just working with the language. It works, but it's slower than deliberate effort to identify differences from what you know already and learning specifically about them.

At any rate, arguments like that neglect that most languages are very similar, and after learning a few quite different ones the differences with most others become largely superficial.

> I can easily find someone with 5+ years of full time Java development (or JS, Python, and Ruby), and that means they're going to come fully equipped to dive into a problem, using familiar patterns and libraries.

Yes, and no. You assume that all people using the same language use similar patterns and libraries. Assuming recent experience with Python or Ruby that might be close enough to true in those languages, but I heard that in case of JS the ecosystem is incredibly diverse.

Setting aside any particular language, any sufficiently large codebase will have its own idiosyncrasies that add to the entry barrier.

> I don't want to hire people to make them learn Scala as quickly as possible and hope that they're able to figure it out very quickly.

You seem to be optimising for "very" short time horizon. It strikes me as short-sighted. You also seem to underestimate how much knowing the JVM as the runtime environment gives you.

> If you're working with Scala (or some other less popular language), you're going to have less results doing these things, because less people are going to have hit your special problem.

There will of course be fewer results, but you seem to assume that has to mean you will regularly run into trouble. Numerically, most Google results are bogus or even misguided anyway. You might try to argue that having more people using given technology increases the odds of finding a good solution, but that requires relatively stable signal to noise ratio across different technologies. I don't think that is necessarily the case.

Additionally, Scala might be poor example for this one, as it is actually used quite a lot in industry. It is nowhere near as esoteric as Haskell, for example.

> There is no amount of amazing language features that make this trade-off worth it.

This is a very dogmatic statement that I strongly disagree with. It is ironic to read it on Hacker News, given the emphasis from Paul Graham on how much velocity he gained by starting his career (were those e-shops?) in Lisp and being able to iterate much more quickly because of that. It is especially ironic given your focus on short term earlier in the post.

> And it's not just true for languages, it's true for frameworks too. Using common stuff (language choice, framework choice, library choice, compiler choice, etc) makes it so much easier to solve the problems you'll inevitably run into.

Straying from the common path should be weighed carefully for sure. But never forget that if you are far enough from the lowest common denominator for which it has to optimise, you might actually get way more mileage by using something else. Right tool for the job and all that.

I don't think it's fair to include F# in that list, what with its emphasis on explicitness. After all, it's not like functional programming requires writing obscure code any more than complex object hierarchies pushing events and callbacks all over the place until you have no idea how you got where you are.

What actually causes trouble in an enterprise setting is not any particular paradigm itself, but "magic." All that flexibility of Scala or Lisp is great in the small, but it doesn't scale easily. You are effectively building new DSLs in them, and then everyone that comes to the project has to first learn the specific variation that you ended up with.

The problem is that people usually neither acknowledge they are building a language, nor think about design of that language to make it easy to learn and use, including documentation. So new people come and are completely lost. If they are experienced in the given base language, it is only easier for them to find the starting point to reverse engineer what was done, but that work still has to be done.

This actually happens in Java and other less "magic" languages as well, but then nobody blames the language: they blame frameworks and development practices in a particular shop.

Additionally, the whole mindset of "easier to hire a Java dev" only makes sense for juniors, if at all. Developers are meant to be problem solvers, and any particular language or framework is but a small part of the overall toolset they should have. Sure, if they are experienced in a particular language that you are using, they will have easier time starting up, but that is only a short term benefit.

"It's nice while a hate speech ban matches everything you agree with, but too easy to pivot into something worse."

This kind of argument always strikes me as a rather poor defense that basically reads: we cannot find a perfect solution/system, so we're not going to do anything.

In reality, no system is perfect and can be abused one way or another. The task is to find a cost/benefit trade-off that most people are comfortable with. Instead of arguing that nothing should be done because it can later be abused, just own up to your value system and acknowledge that this is the cost of the way you frame/uphold your values and you are prepared to pay it.

Browser development is non-trivial, but browsers themselves are a commodity. There is no money in browser itself as an app, or at the very least not enough to support development.

So now it's okay because it's done to an actor that you consider deserving of such treatment? People said such behaviour is wrong, so they changed their act. Why wouldn't you hold others accountable to the same standard? What is the point of listening to the criticism and correcting your behaviour if it will be okay for others to keep punishing you?

Seems counterproductive to me.

Pretty sure he means that just seeing symptoms of Embrace is not enough to sound the alarm that it's going to be extended and extinguished.

After all, what's the point of building software, if it's never embraced, aka, used?

Why? Status quo is not the only alternative to equality of outcome.

I don't think it's intentional subversion. AFAIR, having command line wrappers in /usr/bin pointing to command line tools or xcode tool chain predates SIP. If anything, protecting developer tools was either neglected, or changing the concept of how it works to suit SIP was deemed not worth the cost.

I mean, SIP is generally only partial protection anyway, isn't it?

The sentiment against OS X might not show that strong, but it is clearly there. She doesn't even mention that what protects /usr/bin is System Integrity Protection, or that it can be disabled. The very idea that people might not be using system git is not even mentioned.

All in all, it really feels as if it was written from the perspective of someone that does not usually work with OS X and does not know the system well. In other words, she has not done her homework. Which is fine, if you acknowledge what you don't know. But then the condescending tone would be totally out of place.

The sentiment is there, and it does not help in spreading the message, unless what you really want is to flare up all the emotions. Otherwise, it's not the best course of action.

Fun fact, since we're comparing default system installations, my Ubuntu apparently still has git 2.5.0. I suppose I should find some PPA or something to update it.

I'm sorry, but on platforms I need to support this is not available.

Pop quiz: what are possible results of running sizeof(char)? It's just another thing to note ;)

I like the consistency of using parenthesis always. Just like some people insist of putting them in logical statements even if they do not affect the order of evaluation in that particular case.

I think the OP misread the article he's referring to. The point is not to avoid setting goals, but that if you want to actually get good at anything, you should first learn to create habits, and then just start doing it. Once you're already doing it, it'll be a lot easier to improve, and then go ahead and follow the usual advice on setting goals.

After all, what's the point of setting specific and challenging goals, if you're unable to stick to them?