[fsk]

Don't give out SSN or Birthdate information until after an on-site interview when you're at the offer stage. Someone dishonest can use that information for identity theft.

I'm already starting to be concerned about age discrimination, and I'm only 40 years old! It's very disturbing when you go on an interview and you're the oldest person there by 10+ years.

The only way out is to start your own business. Do you have enough savings? If you do, consider trying to bootstrap your own thing instead of going back to being an employee.

[annasaru]

Thats 1) A bit depressing - you seem to be conveying that there is no other possibility 2) Starting a new business is not everyone's cup of tea. Even for a young person. Its loaded with risks.

I do face this as well. Age does slow down a person. But age also helps us make haste slowly. I've seen younger engineers scattering their energy around, and then coming to realize that the common sense option was the best. And older programmers (like me) might be too set in our ways.

Can an old dog be taught new tricks? I'd say to test that, make sure you learn a new programming language every year. Show it with non-trivial projects on your github or other profile. Thats proof that you're still sharp.

Edit : Also adopt a new editor every year. That shows you can step out of your comfort zone. (I need to kick that emacs habit).

[tjradcliffe]

I think one of the advantages of being older is that it gives one the wisdom to be more selective about tools. I'm an expert in the tools I use (C, C++ and Python, mostly, although I know a dozen-odd languages well enough to crash a program in them) and not hugely keen on learning new ones. I poke around at new languages now and then but quickly learn they are either a) so much like ones I know there's nothing special or b) Haskell or Erlang, which I've run at a couple of times hard enough to be convinced there is something interesting there but not hard enough to really have learned much.

So rather than learn a new language every year I aim to learn something about the languages I already spend most of my time in. Functional techniques in Python, the new features in C++14... things like that.

Nor do I see any value in learning a new editor. Really, editing is a solved problem and if you're familiar with vi, teco, emacs, VisualStudio, Eclipse and that other one whose name I don't remember that Microchip based MPLABX on you've covered enough ground that anything you encounter is going to look basically familiar.

I've met programmers young and old who won't leave their comfort zone that I acknowledge it's a real problem, but I don't think you need to spend too much time very far afield of your core expertise to keep current.

[old-soft-man]

Why is being comfortable such a problem?

I'm fine with having bled the captains of big data and presentation (thereof) hysteria of enough resources to live the rest of my life on comfortably, and now enjoy embellishing whatever terminal window I'm inhabiting to suit my needs of the moment.

I'm happy in vi, wish I'd stuck with emacs, blah, blah. But when you can make things happen in a terminal window, does it really matter?

Personally, I'm finding a ton of joy in Lua. So clean and simple and fast and portable and easily extensible in venerable 'ole C. So much to love!

[annasaru]

What you say is absolutely fine. But sometimes being comfortable can mean that we have not adapted to changes. In your case (and mine), technology seems to have circled back to what our preferences are - emacs/vi as the editor, terminal/tmux as a conduit into the work area. And a screwdriver, or a pair of pliers never went out of use.

[developer1]

The editor thing can be kind of important. People who stick with emacs or vim tend to be horrible with following coding standards and being able to review and navigate code efficiently. There's nothing like an editor from Jetbrains for tooling (Eclipse works too, but seriously the Jetbrains line is the best).

I have never used emacs, but vim is horribly limited in what it can truly do in terms of handling code. You can add all the nifty little plugins you want, but it just isn't efficient. The mistake people make moving to a full IDE is installing the vim plugin to add some familiarity. I've seen coworkers take literally 5 minutes to hammer out the vim keystrokes to refactor a block of code that can be done in 15-30 seconds with 2-3 native IDE keyboard shortcuts and a mouse click or two. It's important to know how to use vim or similar for remote command-line work. When developing though, the functionality and built-in tools provided by a full-fledged IDE are priceless.

There was a time I didn't judge new developers for using vim to edit code - and a long time ago I was one of them. I used to see these people as "true developers" for mastering an editor like vim. Now, after years of encountering developers with hampered productivity and ability to work on a team with coding standards, I see a vim/emacs person as someone who is stuck in their ways, refusing to even try to modernize their workflow.

Just a random example: in PHP projects, my teams use CodeSniffer for coding standards validation. The settings for common IDEs are committed to the VCS so they are automatically in place for new developers cloning the project. In any modern IDE, notices/warnings are instantly and unobtrusively made available as you type code. You can also run the inspection against the entire codebase or files you have modified since last VCS update to catch anything you missed.

What do Vim users do? They write code for hours or days at a time without validating what they are writing. When done, they either a) commit without running their code against CodeSniffer while egotistically proclaiming that their personal coding style is clean and doesn't need to match what the rest of the team abides by; or b) they spend hours running the command-line version manually, ridiculously trying to parse the output and hunt each problem down.

This is the real problem with vim/emacs users. Nearly none of them are capable of following the same coding practices as the rest of the team who are sharing a set of project settings in modern IDEs. The worst I've seen was a team that had once had amazing code quality completely abandon all forms of coding standards when two new senior developers were hired who both used vim. They refused to follow the standards because vim simply doesn't contain the necessary tooling. The entire codebase went from being beautifully clean to a complete mess, all because the new guys used vim. That was the job I walked away from so fast after fighting over the ridiculousness and then learning that both new developers were basically hired for the simple reason they went to the same university as the hiring manager.

tldr; Use vim/emacs if you want; but if you're not going to be as productive as, or match the code quality of, your teammates - that's a problem.

[dinkumthinkum]

This is kind of ridiculous. You are indicting vim and emacs users for some alleged major catastrophe at your organization. You realize very large and well written software projects, probably my h larger than your's, have been built by people using vim and emacs and not having JetBrains did not hamper them.

Honestly, I have seen so many developers fumbling around with their "intellisense" and the kinda of things you are talking about, it makes me sleepy watching them. I feel like if only spent time learning how to program than their code completion and refactoring tools, they might produce better, more efficient work.

[MagaManGo]

The linux kernal an GNU tools were built by emacs and vim users. That software is running the world from android phones to servers.

Python, Ruby, and Javascript were built by emacs users. All the modern goodies the new hip people rave about.

Web browsers were created by emacs users. The entire industry we make a living in came from the belly of emacs.

But 2 guys at some company refused to follow coding standards, so yeah...

[fsk]

I've tried a couple of syntax-highlighting editors. I'm starting to get annoyed at them.

The problem is when they don't do it right, and it's impossible to configure it to have the correct behavior.

For example, JetBeans, when you type a ", automatically inserts the matching ". I couldn't figure out how to disable this feature, and it leads to strings like "data"".

Syntax-highlighting editors only seem necessary for scripting languages where you don't get proper error messages. In C/C++, if you miss a " on a string, the compiler rules will ensure you an error message in the right place. If you miss a " in Javascript, the console error may be useless, so you need a syntax-highlighting editor to find your bug.

[MagaManGo]

>> They write code for hours or days at a time without validating what they are writing.

In emacs we use flycheck to see errors and style warnings as we write in real time. For javascript there is js2-mode.

If you're a lisp programmer you take it a step further. Not only checking syntax in real time, but running the code in real time. Like a small talk developer! It's the tightest feedback loop you can get. Makes test driven development more enjoyable too. (skewer-mode allows this for javascript)

Don't judge text editor users based on your experience with a few people. Writing code for hours without style checks or execution is not a common workflow for an emacs user. I've met quite a few inept Eclipse and Visual Studio users but I know better than to correlate IDE's with traits.

[a3n]

> The editor thing can be kind of important. People who stick with emacs or vim [and went to the same university as the hiring manager --a3n] tend to be horrible with following coding standards and being able to review and navigate code efficiently.

Wow.

[old-soft-man]

Sounds to me like the issue wasn't the editor they were using. They're just prima donnas doing what prima donnas do. Surely it's more than a little silly to blame the gun when someone gets hurt or dies? As always, whose hands are the tools in?

To me, Vim or Emacs are more like a violin, and software that enforces style more like a kazoo. While some might consider the sound of the latter music, those with ears to hear - and hands to play - know better.

I'll take a developer who can create consistently beautiful code in Vim or Emacs over someone who can't be as productive without style-enforcing crutches any day.

[jbeja]

My daily stupidity dose, thanks!

[annasaru]

There is some truth in what you say. Variations both good and bad will exist.

[droope]

HAHAHA. I almost fell for the trolling.

[bgar]

Why do you want to stop using emacs?

[annasaru]

I don't think I want to eliminate emacs from my work. 'editing' is a term loaded with lots of meanings - especially when it comes to emacs one is talking of a lot of (mostly good) consequences. I would think adopting an editor, such as vim, or maybe atom (or something else in the future) - would imply stepping into a slightly different ecosystem and culture.