DavidWoof

I'm pretty ignorant of your field, so it's hard to say. As an example of my ignorance, I'm honestly surprised you could even find 40 places in a small city to apply for an uncertified Stem Lab Coach job.

In terms of resumes and job search, though, software development is completely unlike every other field. I don't think anybody's advice here on "here's how my resume of 15 years of c++ is arranged" is going to help you at all. It's a completely different world.

People complain about ageism in tech, but I suspect programming is actually one of the least ageist fields out there due to its underlying meritocratic nature.

I did some A/B testing over the past couple of years with dropping the 90s from my resume, and I couldn't distinguish any difference in responses. Among those who got the shortened resume, nobody seemed to notice, although it's possible they noticed the age gap and just didn't mention it.

Although if OP has sent out 40 applications and gotten no responses, ageism isn't the issue. There's something about his experience or resume that is turning people off.

Out of curiosity, what is your experience in?

"Ban the box" laws have a pretty horrible track record. In practice, they unsurprisingly generally result in higher levels of discrimination against demographics with higher crime rates, especially low-skilled Blacks and Hispanics.

Here's a decent article on the topic.

https://www.theatlantic.com/business/archive/2016/08/consequ...

> And if it is a black-box rewrite, then all that tacit knowledge will be lost,

This is a thought experiment on how to avoid that tacit knowledge, not how to deal with it. Consider approaching every edit in the same way you'd approach new code: is the function adequately tested, does the function have a single responsibility, is the intent clear, etc.? The idea is that if you do this, then you won't reach the point where you have a 200-line method with tons of hidden business rules.

I agree there's probably a better way of framing this. Still, as a thought experiment, it's worth thinking about when you can and/or should do this.

That's sort of the point of the suggestion, I think. If you always rewrite from scratch rather than edit, this sort of tacit knowledge won't get embedded undocumented and untested into the middle of a function.

This is sort of the great contradiction of software development. Untested legacy software is hard to work with. So should our focus be on how to work with legacy software or how not to create it in the first place? There's really no answer to that.

It's a trade-off. One thing that's definitely going to get you more and better interviews is a section on your resume that lists major open-source projects you've contributed to. But yes, once you hit the interview you still might hit the old-style puzzle questions depending on the company.

Chocolatey is scriptable, it handles the downloads, checks the checksums, it's easily searchable, etc.

For various reasons I don't use it much anymore, but it's really convenient to go to a new machine after a rebuild and just run a standard script of

choco install -y vim; choco install -y python # ...another 20 lines

and I'm up and running with all my standard apps. Having to download all those apps, verify the checksums and go through the install wizard can easily take a couple of hours. It's especially useful if you're spinning up a lot of vms.

Thanks for the response. I was really just curious, I didn't mean to set off a mini-storm. It's just interesting who reads this site, since the topics are pretty highly directed towards startup and developer culture.

IT support in a rural area is more or less what I was suspecting (yes, Springfield is Country). It's ironic that the tech age was supposed to bring in an era of telecommuting, when in fact it's brought in an era of greatly increased centralization. Small towns needed doctors and lawyers, they don't need software developers or high end tech support.

In theory the increase in cloud services could change that, but I don't really see the trend changing.

I'm always kind of fascinated by posts like this on this site. Could I ask what field you're in that pays 35k/yr, apparently in the US, is in the field of your degree, and yet is somewhat related to Hacker News? Or are you not in tech at all and this site is an outside interest? Or maybe you're just in a rural area?

I don't mean this to sound challenging out all, I'm just kind of curious.

Alice is so vaguely portrayed here that I think it's impossible to draw conclusions, let alone call her a brilliant jerk.

As you mention, pointing out when things are wrong isn't being a jerk, it's doing your damn job. "Having little empathy for others" isn't describing behavior, so it's meaningless here. OK, "browbeating" might be bad, but what does that mean anyway? Is she repeating the issue a month later after the problem got ignored, or is she micromanaging it, or what? There's no indication here. Whatever it means, Equifax could have used some browbeating on security issues.

There's no indication about why people try to avoid working with her. Does that refer to other developers, or does HR try to avoid her they go around asking for donations for girl scouts or something? I don't see a real problem with the latter. If somebody had reputation for pointing out problems in code, I wouldn't be avoiding her, I'd be seeking her out.

A lot of this depends on context, and obviously we're not getting any of that in a quick anecdote (not OP's fault, just the nature of things).

In a larger company, where you're always hiring and there's specific time allotted for it, that approach makes some sense. But in a smaller company where I might have one or two positions to fill and the interview process is a serious hit on productivity, presumably the net step is to set up interviews and the first interviews are going to go to the people who didn't completely misread the exercise and submit Enterprise FizzBuzz.

I'm curious,how do you evaluate candidates? Or are you just never in that position?

1. Honestly, if I were giving a simple coding exercise and the candidate submitted work using their own custom framework (which is implied here), I might reject them also, or at least put them at the bottom of the interview list. It's just a complete misread of requirements, and points to an inability to follow directions.

2. On the one hand, Joel Spolsky created a lot of problems with his idea that a "no" from any interviewing dev results in a "no". Some people just don't evaluate interviews very well.

OTOH, everything looks like it went well here. One interviewer voiced concerned about a specific technical field, but the team as a whole gave that item its appropriate weight. No problem.

3. Yeah, HR often sucks. But I don't see how a story about the recruiter completely dropping the ball for two months is somehow a defense of how valuable recruiters are.

I've probably had more problems trying to work with bosses who were couldn't make decisions at all and avoided all confrontation and let the project slip to the level of the lower common denominator. By any reasonable definition, Linus Torvalds is a "tyrant", and the resulting quality of linux speaks for itself.

All successful projects of sufficient size probably need a tyrant at the top someplace who can and will make final decisions and enforce them, otherwise everything falls apart in conflicting requirements and bike-shedding.

Ahh, you might reply, but these are "toxic" tyrants, a phrase this article never bothers to define, allowing everyone to just project their own vision of a bad boss onto it.

Not really. Testing components is still really a pain: there's lots of boilerplate and the tests are extremely slow. In a medium-size project, they're far too slow to treat as unit tests: I break out all the TestBed stuff into a separate karma integration test config.

Angular is in desperate need of something like Enzyme.

All of those reasons sound reasonable, and if I were trying to come up with reasons in the abstract I'd probably come up with a list like that.

But as a programmer in his 50s, when I have personally encountered age discrimination, it's been instant. It wasn't just a thumb on the scale or issues with disparate impact, it was an obvious and clear reaction the moment I walked in the door. It's always stunning when a very pleasant and productive phone conversation becomes immediately hostile when somebody sees my face.

On the other hand, those moments have relatively been rare, and this industry is currently so competitive that they register as "I dodged that bullet" rather than anything truly harmful, although it's definitely been enough for me to see the words "culture fit" as having the definition "we practice illegal discrimination".

BTW, whenever these articles show up on HN we always seem to assume that "tech worker" means developer, but it really refers to everybody: support, manager, tester, etc. If you're a developer, there's tons of ways to keep your skills strong. But the support person who's been keeping a Sybase instance running for the last 20 years or who maintains some spaghetti netware system doesn't necessarily have any marketable skills. There's a lot of people whose skillset is essentially "I've been here a long time".

If Visual Studio is your example, then you're making the same argument as the author: there's a sweet spot. From the python world, c# may look statically typed, but from the Haskell/Idris point of view, the java/c# type systems look really sloppy and ambiguous.

I don't see anything in the article about older workers working themselves to death. It seems to be mostly about older workers getting laid off.

As a dev in his 50s, I have mixed feelings about this. On the one hand, age discrimination is real and I've definitely seen and experienced it. On the other hand, virtually everybody has some kind of trait that is going to be discriminated against by somebody, and the software development market right now is so overwhelmingly friendly to good programmers that the few spots of discrimination are really just minor irritations.

But if you aren't constantly upgrading your skills, I'm sure the landscape is bleak. And that's not nearly as true of

PS. The above is about programmers. Managers probably get much more direct age discrimination, and they can't fall back on a well-defined skill set to contest it.

AFAIK, Windows has never had a built-in way to remap keys. Sure, you can download third-party tools to do it, but that's often a dicey move in a corporate environment where you aren't allowed to install third-party software.

I'm really surprised more keyboards can't do this kind of simple remapping themselves. I used to remap the keys on virtually every machine I worked on, but these days I just bring in my CODE keyboard which does some simple remapping itself (e.g., caps lock -> ctrl).

I think most of this is, or should be, uncontroversial. While it's incredibly important to avoid bad developers, once you hit a certain high level of technical ability other traits become more important. Besides, this isn't a fixed scale. Except for a few outliers, the concept of "more skilled" doesn't really have a meaning once you pass a certain level.

At that point, what many shops do is hire people they enjoy being around, which is usually a shorthand for hiring people just like them, and then create all sorts of pseudo-psychological justification for it. The truth is that one day isn't going to tell you much about a dev. Some people are really good when first meeting strangers, some people are very uncomfortable for at least a week. Everyone deals with that nervousness differently, and on the other side, most people are incredibly unaware of their own prejudices that might be affecting their one-day reaction to a new person.

At the end of the day, there's really no magic formulas for creating great teams.

I honestly couldn't care less what she majored in a quarter century ago. Do you honestly believe a CS bachelors degree from a couple of decades ago would have any relevance to information security today?

> In fairness, I'm selective with the candidates I decide to interview, from usually large pools.

I agree with your thoughts on interviewing, but the "real-time coding" session in my mind isn't part of the interview, it's part of the pre-interview screening process that you gloss over here.

Asking programmers to code tough problems on the phone or whiteboard is a good test of certain personality traits, but not a good test of programming skills. On the other hand, there are problems so simple that a decent programmer should consider them to be typing rather than coding, and I think they make perfectly decent initial screening tasks. FizzBuzz is the obvious example here, but I think it's too popular to be useful. I periodically hear from devs who say they get so nervous in interview situations that they can't program at all, but no type of screening is going to be perfect.

And I much prefer this kind of objective screening process to more subjective ones, which tend tend to devolve into "let's choose people with backgrounds similar to mine".

OK, that's a good one.

Is this ActionScript that's doing the weird xml tag interpolation?

I stand corrected, this is definitely possible. Still, I bet this person's real problems stem from explicit coding.

I've been programming for over a quarter century, and I feel pretty confident that I've never written anything that could confuse 'null' with NULL. I can't even think of a language that would let you easily do this.

If web forms aren't accepting NULL, then somebody probably specifically programmed the word 'null' into a filter of disallowed entries. Probably to stop clerks from entering the word 'null' to mean empty string. This has nothing to do with null being a reserved word in many languages, I'll bet the forms that aren't accepting 'null' aren't accepting 'none' or 'empty' either.

This is basically one individual's musing on the topic of naming things in a UI. I don't know the author at all, so he might have tons of insight or he might just be making stuff up, I have no idea.

But at this point in time, why aren't we reading about studies rather than an individual's musings? I'd much rather read that x% of individuals didn't immediately make the connection between "my computer" and their workstation in testing at MS.

One reason Code Complete has always been my favorite programming book is that he backed up his suggestions with real numbers from serious studies. I'd love to see similar types of writings in the design field.

I'd note that all of the above also applied to travel agents and other middleman jobs. The job was time-consuming, companies couldn't afford to have their employees spend a lot of time on it, the majority of cases wound up with no sale, etc. And technology largely supplanted it.

Although you're not explicit, it seems that your post is suggesting that the primary value-added function of tech recruiters is as a filter for companies. But be honest, what useful filtering can possibly be done by a tech recruiter that doesn't know the tech? The vast majority of tech recruiters aren't capable of anything beyond keyword matching and basic "are you presentable" filtering (which can have important legal implications in the US, of course).

Anyway, whenever this topic comes up, one of the top 2% recruiters who know their business well pops up and claims recruiters do all sorts of useful things. Well, yeah, maybe you're part of that top tier that does great work. But that's not the bulk of the industry, the bulk of the industry is the army of know-nothings at CyberCoders other large job mills. And they're very successful, but I honestly don't know why.

Honestly, what is the point of tech recruiters? The tiny filtering they do for employers could be automated or done by a minimum wage worker. I don't see they have any value for candidates. Most of them just cruise the job boards doing keyword matches between applicants and jobs.

Why haven't they disappeared like other middlemen such as travel agents?

Is it just for protection against civil rights suits? I realize there's some highend headhunters that do real work, but the bulk of the industry seems worthless to me.

> He shouldn't blame a community of volunteers for not fixing his personal problems for free.

It seems to me that you're just repeating the author's point, but with a different tone. Issues of "blame" aside (what does that even mean?), his point is that open source software tends not to meet the needs of the accessibility community. One possible cause of this is that the devs who support open source software tend not to be disabled and tend not to have experience or even access to things like screen readers.

I honestly don't know enough about the issue to know how true this might be, but just dismissing it as a rant, even if the word "rant" is correct in this case, doesn't address the underlying issues.

BTW, a quick google search suggests that JAWS is far and away the most popular screen reader for windows. If it's not a priority, then accessibility for windows isn't a priority either, which is exactly the author's point.

His examples are kind of strange.

First, I don't really consider const vs let to be the same kind of stylistic rule as single quotes vs. double quotes. Single quotes vs double quotes really don't matter too much. Const vs. let though don't mean the same thing at all, and using them correctly can go a long way to reducing cognitive load. The two keywords simply don't mean the same thing and if his linter is complaining often, it's probably because he doesn't understand the difference.

And if you can't standardize on tabs vs. spaces, you're going to have all sorts of trouble in your commits. This is basic stuff. This article reads like the author has spent his entire career working on individual projects, and doesn't really understand working with a team.