msluyter

I would add that a lot of the job entails quickly learning new things and solving new problems. For example, just yesterday I had to work with RavenDB, which I've never seen before. The complaint that you shouldn't need to know how to, say, write a BFS because you never have to do that IRL has only surface validity when you consider that much of your job amounts to doing things you've never done IRL.

In other words, if you can't (re) learn certain CS fundamentals in preparation for an interview, perhaps you'll have trouble on the job as well.

This isn't to let interviewers off the hook, however. Standard whiteboard problems like "reverse a linked list" are still suboptimal, IMHO, and even with these, there are better and worse ways to handle them. Do you focus on the interviewees reasoning and use the problem as a basis for deeper discussion or simply focus on their end result? Do you treat Sr & Jr interviewees the same? Do you seek out curiosity and ability to learn or a specific knowledge set. IMHO, if the latter, you're probably doing it wrong.

Schools -- We're trying to provide the highest possible quality education for our daughter, which means living in the best public school district we can find or within range of the best private school we can afford. And while I'm sure there are exceptions, this means living in a city.

Jobs -- Even though in theory I could work remotely, my wife (a lawyer) couldn't. Wherever we live has to be able to provide employment opportunities for two disparate professions.

Arts/Culture/Etc... -- I take my daughter to the Thinkery (a neat kid's museum here in Austin) monthly. She takes ballet and swim lessons, perhaps music lessons soon. It's important for our family to be in proximity to a vibrant art/music scene.

None of this is meant to denigrate small towns or rural areas, and perhaps there are some areas that provide the above (I'd be curious to hear about them if there were, actually...) I merely mention this to indicate how difficult the project is.

Sample cheat sheet:

https://readline.kablamo.org/emacs.html

You don’t have to learn it all, but mastering the basics like moving to the end/beginning on the line, moving/deleting by word, yank, history search and the like will pay off handsomely.

So I'd be curious if someone can comment how VSCode compares to PyCharm wrt language aware features, such as: contextual selection, refactoring, finding usages, method/function extraction, auto-fixing, etc...?

You could do this, although it's admittedly uglier than your example:

  In [1]: sorted(enumerate([('b', 1), ('c', 3), ('a', 2)]), key=lambda x: (x[1][0], x[0], x[1][1]))
  Out[1]: [(2, ('a', 2)), (0, ('b', 1)), (1, ('c', 3))]

  In [1]: sorted((x, i) for i, x in enumerate([('b', 1), ('c', 3), ('a', 2)]))
  Out[1]: [(('a', 2), 2), (('b', 1), 0), (('c', 3), 1)]

IMHO, the best kids book we've encountered. Some of the nice features:

a) well drawn and sharply delineated characters. (One of my pet peeves about some kids books is difficult to distinguish images that tend to get lost in a sea of bright colors.)

b) the text is _large_ and changes size according to the emotions of the characters.

c) phrases are repeated -- great for language acquisition -- but not in a way that's irritating or vacuous.

d) funny stories; real emotions that toddlers can grok.

e) good construction -- high quality printing, thick pages, etc...

There was a recent thread[1] on twitter by Noah Smith on this topic, related to a study[2] that suggests that a) relative life satisfaction tends to correlate with their relative ranked income and that b) upward comparisons matter more than downward comparisons.

From those premises, Noah Smith appears to be arguing that high inequality has a negative impact on overall happiness.

[1] https://twitter.com/Noahpinion/status/969676076912750592

[2] http://journals.sagepub.com/doi/abs/10.1177/0956797610362671

Once out of school, I opted to take a software test development (SDET) position, which provided the sort of hands on training and practical exposure I needed at the time. And, while technically it was a "QE position," the role did provide opportunities for coding in the form of automated tests, deployment scripts, test frameworks, etc...

Although I ended up staying in QA longer than I desired -- the bursting of the web bubble in 2000 sort of pulled the rug out from under me -- I eventually laterally shifted into a dev role and have been quite happy ever since.

I think this sort of path is still a viable option for aspiring Jr. devs, especially given our increasingly complex ecosystems/stacks. It's a great way to learn, and these days there seems to be less clean separation between QE/Dev roles in any event. QE people write code, devs write tests (or rather, they should ;)). (Note, I'm explicitly recommending an SDET role, not a manual testing role.)

OTOH, system tests provide a realm where external implicit/explicit requirements may actually be validated. Perhaps.

Anythiing comparable now in fish land?

It's not hard to argue. At a minimum, the topic is under debate:

https://immigration.procon.org/view.answers.php?questionID=0...

https://www.forbes.com/sites/artcarden/2015/08/28/how-do-ill...

(Might actually be an interesting project.)

One problem I often find myself facing w/Python is that the ecosystem is so large that it's hard to keep up with the vast numbers of libraries. I have a list of a dozen or so in my head that for a large enough project I'd probably want to use. But personally keeping that list fresh is non-trivial. That, and of course, newer devs in an ecosystem don't have one.

I think these sorts of projects speak to that need.

Now, obviously as you suggest, people have differing needs/preferences, so there's room for competing visions, and in some cases this can become a sort of "now we have N+1 problems" meta-problem. But I don't think the fundamental impetus is misguided.

"So even if the disparities don’t start off as discrimination, you can still end up with an environment in which women who could be great engineers decide they’d rather do something else. A “natural” split of, say, 65-35 could evolve into a much more lopsided environment that feels downright unfriendly to a lot of women. And the women who have stuck around anyway are apt to get very mad indeed when they hear something that seems to suggest they’re not experiencing what they quite obviously are."

Worth reading in full: https://www.bloomberg.com/view/articles/2017-08-09/as-a-woma...

It may be that as a lot of folks have argued (including Scott Alexander[1]) that women are simply less inclined to go into tech for innate reasons. (Not saying that's true, but it seems at least plausible.) But even if true, it may also be true that systemic bias is still a problem. IOW, what the Google memo and a lot of other folks seem unable to acknowledge is that these points aren't mutually exclusive.

Ross Douthat -- not exactly a raging progressive -- makes this point well[2]:

"The memo was sometimes tone deaf, clinical, insensitive (in, well, a stereotypically male sort of way), understating the ways in which self-selection and sexism can shape an industry. Even if more men than women are attracted to a particular field, a male-dominated profession can be distinctly unpleasant for the women who work in it, in ways that can justify special scrutiny, recruitment and redress."

[1] http://slatestarcodex.com/2017/08/07/contra-grant-on-exagger...

[2] https://www.nytimes.com/2017/08/09/opinion/google-women-memo...

The first case -- the one I hated -- had a) long rows of desks, b) bright overhead fluorescent lights, c) a lot of noise due to being in a large room with sales/marketing, d) a lot of visual distractions due to people walking up & down the aisles, and e) few available areas to go to collaborate away from your desks.

Now, I'm also in an open office, but I find it quite livable, because: a) my desk faces the wall, for fewer visual distractions, b) the room is comfortably lit (ie, not too bright)[1], c) it's a smaller room with only engineering and is generally quieter[2], d) there are enough areas to go if you need to collaborate.

All this is to say that, while the evidence is that open offices generally suck, there's probably a number of ways to ameliorate their problems to some degree without having to resort to private offices. I don't think I'd prefer an office to my current setup, actually.

[1] I think this element is underrated. In fact, I'd be curious to know if there's a verifiable correlation between brightness levels and how loud people tend to talk. There's something about a dim room that seems to induce people to lower their voices.

[2] Small, but not too small. There's a sort of sweet spot. I was once in a room with 3 other people and it was maddening because it was generally quiet but every little noise -- coughing, swallowing, etc... -- was seemingly amplified by the overall quietness to became hugely annoying. (An inverse concept explains why I can work quite well in a coffee shop despite the background din.)

AKA, collective action problem. https://en.wikipedia.org/wiki/Collective_action#Collective_a...

https://inflationdata.com/Inflation/Inflation/DecadeInflatio...

(Note that the graph on the parent article is inflation adjusted. "Note: Inflation-adjusted annual average growth using income after taxes, transfers and non-cash benefits.")

We've recently run into slow performance with gettimeofday on Xen systems, such as EC2 (see: https://blog.packagecloud.io/eng/2017/03/08/system-calls-are...) This hits particularly hard if you're running instrumented code. Switching the clocksource from xen to tsc seems to help and we're still evaluating the ramifications of doing so (various sources including the above seem to suggest that tsc is unsafe and prone to clock skew, but others suggest that it's ok on more modern processors.)

The apps I find myself using more than any others are the timer/chronograph, which I use constantly when cooking/grilling. And the ability to take voice calls with it is occasionally quite helpful.

The Pebble's silicone wristband caused a rash on my wrist, but I've had no problems with the Nike Apple watch wristband (perhaps that's simply due to the holes that provide better ventilation.)

It's far from clear to me that any beyond a small percentage of people generally, but perhaps Americans in particular, have the capacity to become lifelong learners. Not saying folks are stupid -- the problem isn't a lack of raw cognitive capacity, IMHO.

What actually makes someone a lifelong learner? Curiosity. If you don't _want_ to learn, it's going to be very difficult to do so, except perhaps while under the gun for short periods of time. And, unfortunately, our education system seems ideally tailored for stamping out children's natural curiosity. If that sounds overly pessimistic, I'd welcome a demonstration to the contrary.

I feel that the answer is basically "let's fix our education system," which I -- again, perhaps overly pessimistically -- believe to be politically impossible.