The problem is that there's no way to do that with the current short term management techniques and high CxO salaries. If they get away with it for 1 year and make 10-20 million, which the lawsuits can't touch, they don't care. We need to change the corporate veil so it protects small investors but not those who run the company day to day.

Depends on if you care. Most likely these employees are talented programmers, and the hiring environment is good right now. For those who have a bit of money set aside losing their job is an inconvenience at worst, a nice vacation at best. Especially if they were smart enough to start shipping resumes as they took their stand.

Designers who don't code are worthless. They make horrible solutions because they're too separated from the actual problems with their designs. Senior devs should be designing, but they should still be coding most of their own designs.

Like I said- there's exceptions. Maybe you're one of them, I can't tell as I don't know you. But you'd need to prove you were an exception in the interview, because most of the people who stay that long have stagnated.

I stick by 3 months though. That's plenty of time to learn the system, if it takes longer than that you aren't really trying. If it takes you a year (as a senior, not as an intermediate or junior), you've been let go by that time. Of course your experience could be biased in some ways- the best engineers I know would avoid the kind of place where you work on 1 system for 5 years, so you may be looking at a lower overall talent pool.

May I pass up on some good talent because of this? Maybe. But I'm not particularly worried about it- passing up on a good hire is a less harmful mistake than making a bad hire. Besides which, the few exceptions that I'd miss aren't looking for new jobs anyway. And they probably wouldn't be happy at the type of company I prefer.

One other comment, I forgot in my original reply. Each year of experience doing the same thing brings diminishing returns. By branching out and doing other things, you learn additional skills and tricks that are used in other fields. I've done firmware, web services, mobile software, porting, etc in my career. I can bring knowledge from one field to bear on another. Someone who's moved has seen a variety of business practices, protocols, and development practices while someone who's stayed in place likely hasn't. So 10 years of mixed experience will very likely just be a better programmer than 10 years of staying in place.

I use that method of subtraction today, and have since grade school. I just typically do it in reverse- figure out what numbers I need to add to the smaller number to make the bigger number, and typically with larger numbers. Its a solid way of doing the math, there's no reason it shouldn't be taught to them.

I agree that the term shouldn't be taught to them. Its something educators should know so they can discuss techniques. Although you will find that term in a lot of math textbooks these days.

I see 10 years of experience as a valuable thing, you've been around long enough to see a lot of mistakes and know to avoid them. 10 years in one place isn't- you're likely stuck in your ways. The fact that you were willing to do the same job for 10 years shows a lack of ambition or mental curiosity in other realms in the field of programming.

In fact your post proves me right. "Stable job" "all the way to retirement". You're looking for safe over interesting, over doing something worthwhile. Those aren't the types of companies I would even interview at, and not the type of programmer I'd hire. You're even looking at it in terms of doing it for a salary increase- my last job change was a pay cut to go to a startup. Not because I expect to become rich (I know that at best I'll break even), but because its more interesting, more fun, an idea that could really make things better, and I have more leeway to do things how I want and define how this company runs. You might be technically competent, but unlikely to be a culture fit.

And ignoring the culture fit part- most people I know who want safety that much require it because they're average to below average and don't want to risk being on the job market, and depend on institutional knowledge to be useful. There's a few exceptions, but I'd say that goes for 80-90% of them. I wouldn't refuse to interview someone like that to see if they are the exception, but it would be a yellow flag and I'd need to be convinced otherwise in the interview to give them an offer.

Horrible advice.

I don't care if you have a bear or not, it doesn't effect your ability to code. Same with the hair cut. As or the suit- if you need to try and impress me with how you dress, I assume its because you can't impress me with your code. You can overcome that, but it won't help you and may hurt you.

Why the hell would you want to do that? If you like coding, keep doing it. You'll be miserable as a manager if you don't have a passion for it but do have one for programming. You're better off retiring than that.

3 years isn't long, but in the programming industry its pretty standard. 5 years is a fairly long stint somewhere. Much more than that is a real long sting- if I see 7 or so years at a place I wonder about his ability to switch to a new job. Its a series of less than 2 years (or less than 1) that worry me- less than 1 means he's always looking for the next job, less than 2 means he's easily bored.

A year to get up to speed? A senior programmer should be contributing something by the end of week 1, and should be fully up to speed on language and architecture by 3 months. If someone takes anywhere near a year they need to be fired- they aren't pulling their weight (junior and intermediate level programmers get more time, of course).

I think having them thinking about how something might work before feeding it to them is the best way to teach. When you figure it out for yourself, you'll remember it better. Even when you don't, you'll understand it better when you are taught, because you've already started thinking in terms of principles. My absolute most effective courses in college all worked like that- homework would start testing what we learned in a lesson, then lead into the concepts for the next one. This is how you teach people to figure out new concepts, its thinking like a scientist.

100% agree that helping!=doing. If you're doing it for them, they aren't learning anything. The only time you should do it for them is if they completely don't understand as an example, and then they need to be told to do another one on their own.

It isn't questionable at all. You're not going to bring out your phone for every simple problem in life. Need to make change for a 10? Do you really want to have to take out your phone and type this in? The vast majority of math people need its an order of magnitude quicker to do it in ones head than to do it on a calculator.

A better argument is that paper and pen math is what's no longer needed, as the problems complicated enough to do that on actually are as fast to type into a computer. But those are far rarer, and paper/pen is pretty much a necessary step to learning how to do it mentally.

In 13 years I've never worked at a place where everyone used the same IDE. Generally there was a mix of IDE users, terminal vim and emacs enthusiasts, and a few people in between (using souped up graphical text editors). There's no good reason for forcing people to use the same editors- the loss of efficiency from learning a new way will never be made up.

With a very biased verdict. Giving Android Studio the edge because of Gradle support? That's great- if you want to use gradle. I don't. I don't even know what it is- before Android Studio came out I'd never heard of it. And I have better things to do than play with build tools unless it offers a huge advantage- which it doesn't. The fact its impossible to use Android Studio without switching is a negative, not a positive as Eclipse supports both. The edge here should go to Eclipse for giving you choice between build systems.

UI? The UI that you know is better than one you don't- always. If I have to spend even an hour finding new options, that's an hour I'll probably never make back. Eclipse has lots of flaws, but I'm used to those. The real advantage here is Eclipse if you know it, or draw if you don't.

Basically his argument seems to boil down to he likes new shiny stuff. No thanks.

Really, you're complaining about typing 3 extra letters? THe fact that they didn't add properties is the smartest thing they've done in decades. Properties are a stupid idea. If you want them to set a variable directly, make it public. If not, don't hide the fact a function is being called by making it look like an assignment- it causes bugs and inefficiencies for absolutely 0 gain.