Hacker News Reader

Comment by therealwill | Hacker News Reader

"B) Are overly emotional and they all take things way too seriously."

This can be a positive. My experience with 40+ year olds is that they tend to sacrifice user experience/security for what they know. "Our customers won't care if they have to use Internet Explorer with ActiveX as long as it gets the job done." My point is that an experienced programmer who is not up to date can be as detrimental an arrogant 20 year old. The 40+ year old programmer who stay up to date though... They are worth their weight in gold and I aspire to join them one day.

Edit: Background - Got really pissed off at a 40+ dev using active x to launch external programs and making it a requirement that our end users use IE with ActiveX enabled. Almost lost my job because management sided with the person who had more experience.

View on HN

"My experience with 40+ year olds is that they tend to sacrifice user experience/security for what they know."

I'm sure there are some people who don't expand, though I am in my 40s and am constantly pressing for the best UX possible for customers. I've suffered enough with bad UX, I won't go along with inflicting that on anyone no matter how challenging it might be to fix. On the other hand I am (almost) always grateful for people pointing out bugs in things I write now, but used to be a lot more insecure about it. A hit to the pride is nothing compared to the pain of shipping something broken.

"A hit to the pride is nothing compared to the pain of shipping something broken."

Well said. This should be the golden rule of development. I feel that too often we (both young and old) don't ask questions because we fear the repercussions of appearing ignorant.

Depending on what industry you're in, it's quite possible that your users won't care if they have to use Internet Explorer with ActiveX. A number of older and slower-to-change industries still require IE6 on corporate computers; supporting anything other than that is counterproductive, because their employers' IT departments won't permit them to load other browsers anyway.

I can't know if you're in one of these industries, but one of the virtues of experience is knowing when something isn't important because you know facts about your particular niche that an outsider wouldn't.

It is a HIPAA regulated industry that deals with patient data.

That makes it far, far more likely that they're stuck on IE6. Last time I went to the doctor's office, I saw a lot of very old Windows machines. You may wish that the world was a certain way (and frankly, I do too), but that won't actually make the world a certain way.

If you want to win this technical battle, your best bet is to say "I'll implement it in ActiveX if you really believe it is necessary for the business. However, Microsoft ended support for WinXP and IE6 in 2014. They have been actively campaigning to get their customers off of it. There are A, B, and C startups out there with competitive offerings that work on the iPad. iPad market share among healthcare organizations has gone up from X to Y% in the last 3 years, while IE6 market share has declined from Z to W%. If we implement this software as an ActiveX control, we will lose out on $M in sales, with the worst-case scenario being that our userbase upgrades from IE6 and we find ourselves out of business with zero market. It's happening already, as you saw from the market share numbers I just shared with you."

Basically, put the fear of going out of business into your management chain, with the data to back it up. (And if you can't find that data - then your management is right, and you shouldn't bother upgrading.) That goes over a lot better than "I read you should never use IE6 for HIPAA data on the Internet."

> Background - Got really pissed off at a 40+ dev...

Why generalize from one encounter with one 40+ year old developer?

True, but to be fair I did praise the 40+ year olds who stay up to date and know their stuff. Just slightly jaded due to the ageism at my current job and lack of fact checking by management.

Software is a tricky balance between practicality and ideals.

In this example, the older programmer may figure he can meet the real requirements faster and with less risk using technologies he's already familiar with. He might be right!

Unfortunately, there's also a good chance he's being lazy, or political, or etc.

Try to give it a really good objective look to see for yourself which one it is. If the latter, you can try to influence the developer in an ego-friendly way or consider leaving if it becomes unbearable. If your managers have no real technical experience themselves then they are useless in these situations.

Good chance it won't be the last time you have to deal with this sort of thing. (coming from an old-ish dev)

Other 'sticks with what they know to a detriment' are devs that stick with SCMs such as svn or cvs or even rcs when things like git or mercurial are out there.

Younger devs who do have experience with this stuck in their ways behaviors and it can be frustrating and they try to side step it by not engaging the older devs.

Other 'sticks with what they know to a detriment' are devs that stick with SCMs such as svn or cvs or even rcs when things like git or mercurial are out there.

Don't mistake not buying the hype for sticking with something just because you know it. While there aren't a lot of reasons to favour RCS or CVS when Subversion exists, there are sensible reasons you might favour SVN over a DVCS for some projects.

It's been 10 years since git has been released, and in my personal case when this happened, there wasn't any good reason other than 'it's what I know'. The company started with SVN when git had been around for a while.

It's slowed down the company globally, prevents us from using various tools that don't have svn compatibility (like android's repo, gerrit or git's client side pre-commit hooks) and overall just been a relative pain the ass compared to git.

The very small edge cases that svn might be better at now did not apply to us. Notice I didn't say perforce, or google's custom solution in my example.

There are certainly good things about DVCSes like Git or Mercurial that you miss when using SVN.

On the other hand, every project I've ever worked on that has used Git still had some sort of centralised repository that was considered authoritative for controlled release purposes. The smart projects had a local server for this that everyone pushed to. The over-enthusiastic used GitHub, and in at least one case then found themselves unable to deploy when their systems were all up but GitHub was down.

Within that master repository, having a single linear history so you can identify exactly which code you've got in any given release with just a revision number is often helpful. In Git you simply don't have this, so you have to manually tag everything you might ever want to reproduce, which is basically everything on your master server, which requires extra hassle and clutters your log.

A separate but very practical issue is that SVN has worked fine on Windows for years. Git's support for Windows is getting better, but still far from ideal even today.

The sheer complexity of Git, up to and including data loss bugs because even Git's own scripts didn't track everything properly, is another recurring concern.

I've seen more than one very experienced developer, well aware of the pros and cons of different tools, argue for using SVN on a new project for these reasons alone.

Reply on news.ycombinator.com