If a company thought someone could do your job for less money and let you go that is not discrimination. That's a healthy labor market. They may have, mistakenly, undervalued your experience but that's a bad leadership decision, not discrimination.
You can't legally be fired for that reason though.
In what jurisdiction? In the US, most jobs are "at will", and you can be fired from them for no reason at all. There are some reasons that are actually illegal, but I don't believe "we think we can hire someone cheaper" is among them.
Consider getting a low-level job in a shop which is doing Java/Android work (presuming this is your interest). You might at first do 2nd-level customer support, testing, or other non-programming things. However, especially if you position yourself to employers as someone taking on such a role so you can learn on-the-job, you'll be able to finagle your way into more challenging work. Maybe there's some manual testing…
I disagree. If you want to program, program. If someone can't bluff / impress / negotiate their way into some kind of programming position - and they need 'a job' - then they are better off improving their skills or addressing whatever the issue is that is stopping them succeeding. These days 'lack of experience' should not be an issue - one can always start doing something on their own, help out an open-source project and so on.
I guess I approach this from the point of view that you should never settle for less than what you want to do. Sure, some 'careers' involve a 'start at the bottom and work up' or 'start somewhere and work sideways' component, but I do not believe that coding / software development is one of those areas.
You can't legally be fired for that reason though.
In what jurisdiction? In the US, most jobs are "at will", and you can be fired from them for no reason at all. There are some reasons that are actually illegal, but I don't believe "we think we can hire someone cheaper" is among them.
In Germany it is not allowed to fire someone because you found someone cheaper and can be challenged in court.
In what jurisdiction? In the US, most jobs are "at will", and you can be fired from them for no reason at all. There are some reasons that are actually illegal, but I don't believe "we think we can hire someone cheaper" is among them.
In Germany it is not allowed to fire someone because you found someone cheaper and can be challenged in court.
Same in the UK. You can only be fired for disciplinary or performance reasons; or if your position has been made redundant then they must offer you another job if one is available.
I'm sure it will vary in the USA in different States.
In Germany it is not allowed to fire someone because you found someone cheaper and can be challenged in court.
Same in the UK. You can only be fired for disciplinary or performance reasons; or if your position has been made redundant then they must offer you another job if one is available. I'm sure it will vary in the USA in different States.
Same here, too, but I think nirvana lived in the USA before being accepted to Startup Chile, so that was probably where he was laid off from. And I don't think it does vary significantly between states in the US.
tl;dr - Ship something, THEN look for a job. In the real world, your age is a handicap, no matter what people say. Look for differentiators. A great one is the ability to point to something reasonably complicated that you built from scratch and shipped. Very few programmers can do that, and the ones that can are a class above in the eyes of many employers. One thing you have going for you is actual life experience th…
Don't read the entire VM spec. This thinking of knowing something inside out helps you how to use it is bunk. You don't have to know the how the rules of chess came into being to play chess. Or you could go that way, and do it as the parent says, and end up like me, somewhat dazed and confused a decade later. Just because you invented radio does not mean the programming you put on it is the best. Realize that program…
>Knowledge is power.
I do not think that phrase means what you think it means, given the rest of your post.
Don't read the entire VM spec. This thinking of knowing something inside out helps you how to use it is bunk. You don't have to know the how the rules of chess came into being to play chess. Or you could go that way, and do it as the parent says, and end up like me, somewhat dazed and confused a decade later. Just because you invented radio does not mean the programming you put on it is the best. Realize that program…
>Knowledge is power. I do not think that phrase means what you think it means, given the rest of your post.
Don't read the entire VM spec. This thinking of knowing something inside out helps you how to use it is bunk. You don't have to know the how the rules of chess came into being to play chess. Or you could go that way, and do it as the parent says, and end up like me, somewhat dazed and confused a decade later. Just because you invented radio does not mean the programming you put on it is the best. Realize that program…
>Knowledge is power. I do not think that phrase means what you think it means, given the rest of your post.
You mean, be able to come up with in ten years, or understand in ten years? The former is good. But in case of the latter, I wouldn't want to touch your code with a ten foot pole. (Even complicated Haskell type trickery, or, say, mathematical optimization algorithms shouldn't take longer than a few weeks to explain.)
"domain specific" means something like, your code implements the thing you spent the last 10 years becoming an expert on, which you hopefully understand to such a degree that expert coding will be no help in trying to replicate it.
Yes. That's why I mentioned not only type trickery but the one domain specific example where I can claim to be an expert in (mathematical optimization).
"domain specific" means something like, your code implements the thing you spent the last 10 years becoming an expert on, which you hopefully understand to such a degree that expert coding will be no help in trying to replicate it.
Yes. That's why I mentioned not only type trickery but the one domain specific example where I can claim to be an expert in (mathematical optimization). I guess, the original ten years was hyperbole?
I think you're missing the point completely. Patrick's comment wasn't about a
specific for loop and how hard it is to understand.
Knowing what types of problems people have and how to write code to solve them is much harder
than learning the JVM spec and much more valuable.
How long did it take you
to become an expert in mathematical optimization, for example? I doubt very much that that's
something you picked up in a few weeks.