It's not clear whether or not the original poster will be needing to work for the money, or whether the income will be just a nice retirement bonus.
If you don't need the extra income, then there are no shortage of outlets where you can "scratch" your programming "itch". Contribute to an open-source project (or start your own), write some useful piece of shareware, write some business applications for your local non-profit organization, teach programming at a community school, etc. None of these avenues will provide much income (if any), but it does allow you to take your hobby to the next level.
If you are looking to actually make money out of your hobby in retirement, my advice would be to leverage your pre-retirement vocation. There is a branch of software development known as "embedded programming", which is writing software for special-purpose hardware devices. As a hardware engineer, you probably have a lot of knowledge that would be very attractive to a potential employer. Also, you probably have contacts from your hardware days who might be able to help you land a job in this area.
This may be a obvious observation, but if someone knew they were getting a windfall on 4/15, then why would they give notice on 4/1? I think most _rational_ people would delay giving their notice until 4/16, so that they would collect their bonus. Anyway who would give their notice on 4/1 is either insane, or hates the work environment so much that they would be willing for forgo their bonus in order to get out of that place.
I worked at a place where you got a year end bonus that was paid as "restricted stock" that you could not sell for five years. If you quit before the five year period had elapsed, you forfeited a pro-rated portion of your bonus. Having a bonus vest in half-a-month seems quite generous in comparison.
Thank you for indulging me with a response. This is an interesting discussion, even if it is slightly off-topic.
And the PhDs, they should be doing something more useful. But they applied, and we hired them.
In a sense, the PhD's DID help them to get the job at your company. You stated in your earlier post that their programming skills were quite weak, so I would assume that it was the piece of paper that got them the position, rather than their ability to actually do the job. Therefore, it is hard to say that degrees don't matter, when it obviously did in this case.
I think this actually illustrates one of the BEST reasons to get a degree: it gets your foot in the door at a variety of companies. There is some logic to this. Obviously, there are people without degrees who may be more qualified to do the job. However, if someone has a degree, odds are they have a certain baseline level of knowledge and skill. When you hire someone, it is often a crapshoot determining how well the person can do the job, so the HR person can use a degree as a simple "filter" to weed out candidates. There may be some people with degree who are idiots who slip through the filter, and there may be some candidates without degrees who are genius who get unfairly weeded out. However, that is the way the "game" is played, for better or for worse.
Most of whats designed online schools haven't caught up with yet, unless you count countries like India, where IT companies are actually creating their own colleges and teaching what they use, and not theory.
Actually, I would argue that only teaching people today's "hot" tools is NOT what you should be teaching. The average person will probably be working for 40 years. That is a long time, especially in the computer field. Odds are that today's "hot" technology is going to be replaced by something else in a few years.
In college, though, you don't necessarily learn specific technologies. You learn the basics of algorithms, data structures, software engineering principles, operating systems, compilers, and a host of other foundational skills. With a strong foundation like that, it doesn't matter what technology is "hot", since you have the foundation to be able to apply it according to the principles that you learned in college. That way, you can be useful and productive no matter what technology is hot today.
Also, when I mention college, I am talking about a BS or MS degree. You seem to be equating "college" with "PhD". PhD's are a different matter entirely. A PhD degree teaches you to do _research_ in a particular area of Computer Science. It is a much more theory-oriented course of study, for the most part, then what a professional software developer needs. On the other hand, a BS or MS degree is still more slanted towards the practical side.
I do acknowledge that if you are doing simple business applications that just pull and display data from a database on some web page or GUI, then you probably can just read "Teach Yourself X in 21 Days", and be able to put something reasonable together. However, if you are talking about a complex application with thousands and thousands of lines of code, complicated dependences, that needs to be extensible, maintainable, reliable, and all of the other -ibles, then you really need to have a strong foundation that a degree provides. This type of programming takes place at a lot more places that just Google. I would argue that this type of environment is more the rule than the exception.
Again, you can learn all this stuff on your own, so you don't NEED a college degree. However, college provides good mechanism to learn this stuff, and it gives the HR folks a nice warm and fuzzy feeling.
Your post seems very trollish, but I'll "bite" anyway...
First off, it makes no sense to hire a PhD as a junior programmer. PhD's aren't coders. They are researchers... "idea people". It is sort of like hiring Picasso to paint your house.
Second, you don't seem to have a good grasp of logic. Your argument boils down to the following:
Large companies require degrees -> Large companies are boring -> Degrees are useless
Small companies accept "equivalent experience" -> Small companies are exciting -> Better to not have a degree
Finally, you state that you have yet to see a college that teaches anything useful in the real world. What is that based upon? As someone who didn't go to college, you are basing this on conjecture rather than experience.
I think you suffer from the "I-didn't-go-to-college-and-I-turned-out-okay-so-c ollege-must-be-useless" affliction. I am happy that you turned out okay and all, but consider for a moment that you might be the exception rather than the rule.
Thanks for your response. This seems somewhat counter-intuitive in that if you are employed "at will", then a company can, in theory, fire you on the first day you show up to work. That would effectively render any employment offer worthless, unless there was some agreed upon term of employment.
However, I did a little research into this topic, and I found some commentary on case law in California. In particular there is a case called Agosta vs Astor, where the plaintiff was persuaded to leave his old job based upon promises related to salary and job duties. However, when he quit his old job to accept the new one, the company who made the offer reneged on its promise.
The California court ruled in favor of the plaintiff saying that even though his employment was termed "at will", because the company used fradulent means to induce him to take the job, he is entitled to damages.
That would suggest that the original poster might have a case, at least in California (of course, I am not a lawyer so you better talk to a professional for REAL advice)!
Two thoughts... First, I have applied for many jobs online, and I don't recall ever having to give my SSN or DL number on a job application. Usually you only have to give them your SSN when you are employed and filling our your W4.
Second, I disagree that not giving your SSN marks you as a person with "something to hide". Most companies are sensitive to people's desire to keep certain information private, given all of the press that "identify theft" is getting these days. Any HR drone who would think of you suspiciously for not handing over your SSN on a job application hasn't been paying attention to the news for the past 10 years.
Let me ask a question... I honestly don't know what the real answer is, but it is something I was thinking about when I started reading this thread.
If you are hired "at will", meaning that either you or the company can terminate employment at any time, what is the purpose of having a written offer. If the company decides to change the terms of the offer, it seems like they can come back to you and say, "if you don't accept these new terms, then we will exercise our right to terminate your employment." For all practical purposes, that would render any written agreement worthless.
Here is a somewhat different spin on the original poster's situation. A few years ago, I accepted a job offer with a company that included a bonus plan consisting of company stock. Based upon the performance of the company, I would get a certain number of shares. However, last year, the company decided to change the bonus plan so that the shares vested over 5 years, rather than being granted immediately. This was obviously a change from the original employment offer that I had received. Could I have sued them for "breach of contract"? I am not a lawyer, but it would seem like I couldn't since I was employed "at will". If I wasn't willing to accept this change, they could always get rid of me, rather than allow me to continue under the terms of the original agreement.
Even though I am not a lawyer, in my experience, companies constantly are changing their policies and benefits (pension, compensation plans, vacation plan, etc), and I rarely hear about law suits contesting these changes based upon "breach of contract". The only exception is where there is a union involved. For us non-union, "at will" workers, we really don't have any choice but to either take what we are given, or find another job.
ROTFLMAO A CIO is never in a position to know or understand the benefits. You measure the benefits of the computer from OUTSIDE the computer, not from INSIDE the computer. Seems like all of IT sees everything from INSIDE the computer.
I think you are making the mistake of equating CIO with "the bearded IT uber-guru who is holed up in his cubicle with a case of Mountain Dew trying to increase the efficiency of the network by 2%".
The CIO is a business person first. It is the job of the CIO to set the IT direction of the company with the goal of using technology to MAKE MONEY for the company. In order to set that direction, they better be prepared to back up their decisions with some sort of business case. Otherwise, they will be out of a job pretty quickly.
It seems like people on this board view the CIO as being the top techie guru of the company. The truth is that the role of the CIO is a MANAGEMENT role and NOT a technical role.
Sure the CIO probably needs to have a little bit of a clue about technology, but they definitely need to have a BIG clue about finance and management in order to approve the expenditure of millions, if not billions, of dollars of IT spending.
I doubt it has anything to do with a "cost center" mentality, since any good CEO knows that IT can be a "profit center" in that good systems will benefit the bottom line.
Maybe the problem with CIO's is that they are too technical and are blinded by whiz-bang stuff without a appreciation that their role isn't to be the resident techie. A CIO's job is to weigh the benefits of an IT expenditure versus its cost. In essense, the position of CIO is a management/financial function, rather than a technical function. A good CIO won't be amazed by the latest tech for its own sake, but he will be amazed if there is a way to USE that tech to make money for the company. It would seem like a good CIO would make a good CEO, based upon this criteria, so maybe the issue is that there aren't a lot of good CIO?
Tax software is only deductible if you itemize deductions. Also, tax software is considered a "miscellaneous deduction". For miscellaneous deductions, you can only deduct the amount that is above 2% of your income. Therefore, for most people, tax software will not end up being deductible.
Actually, options and futures (which are both considered derivatives since they "derive" their value from some underlying asset), when properly used, can actually REDUCE your investment risk.
For instance, say you own a block of stock in XYZ corporation. Let's say that you are a risk averse type and you want to make sure that the price of the stock doesn't go below $50 per share. In order to do this, you can buy a put option, which is an option to sell the stock for $50, regardless of what the actual market price of the stock is. If the stock price goes below $50, you can still sell your stock at $50 because of your put option.
In a sense, you buying insurance that your stock will not be worth less than some amount. If the stock stays above $50, then your option is worthless. However, this is just the insurance premium for the certain knowledge that your loss will be limited. Because your loss is limited, your risk is reduced. In general, options like this are a few pennies per share, so you may only be giving up a percent or two of return in order to insure your investment.
Options and other derivatives get a bad reputation, because people buy them not to insure an underlying asset, but to gain additional leverage which INCREASES their reward as well as their risk.
Here is a simple example of this type of investment...
Let's say that you believe that XYZ corporation, which is currently trading at $50, is going to go up to $100. If you only had $1000 to invest, you might buy 20 shares of XYZ, and then when the stock goes up to $100, you could sell those shares for double their value and make $1000 profit. However, another alternative is to buy call option with a strike price of $50. This option gives you the option to BUY the stock at $50. When the stock price is also $50, the call option might only be worth $1, so you could buy 1000 of these options. However, once the stock goes to $100, the call option is now worth $50, since you could exercise your option to buy stock at $50 and then sell the stock immediately for an immediate $50 profit. Thus, if the stock goes up to $100, you would have options worth $50,000! Thus, you have the potential to make more money buying the call option than you do with the underlying stock.
The downside in this situation is if the stock goes to $25 instead of $1000. If you had bought the stock, then you could sell your 20 shares for $25 and still have $500. You lost some of your investment, but you still have something to show for your efforts. However, if you had bought the options, your options would have a value of $0, since nobody would pay you for an option to buy a stock at $50 when you could buy the stock in the market at $25. Therefore, you have lost all of your initial investment.
In summary, while options give you the potential to make a lot of money, they also have the potential to wipe you out completely. However, if you use them to insure some underlying asset, they can be very beneficial and they can actually REDUCE your risk.
I feel EXTREMELY qualified to talk about the actuarial profession, since I am a recovering... er... former actuary.
First of all, it is definitely a profession that you can go into right out of school with a BS in Math. In fact, you can go into it with a degree in pretty much anything as long as you have the requsite math aptitude.
Second, unlike other careers, your career is pretty much defined by passing exams. This can be a double-edged sword. On the plus side, it provides an objective means to determine how you progress in your career. Instead of getting promoted because of how well you kiss the butt of some old fart, you get promoted for achieving passing grades on exams. (Of course, once you are done progressing through exams, your promotions are determined by the usual political stuff). On the downside, there are people who would made great leaders or managers, but who are limited in their career if they cannot pass exams for whatever reason. If you cannot pass exams in the actuarial profession, then you are better off leaving the field, since you won't get very far.
As far as the exams go, they are hard in the sense that the pass rate is usually around 50% or so. If you do not pass on the first try, you must wait for up to a year to take the exam again, which can slow your progress. The first few exams are math and statistics oriented. They do require some good math aptitude, but like all exams, there are "tricks" that can be learned which are indepedent of your skill. If you are good enough to get a BS in Math, you certainly should be able to master the math necessary to pass the exams. The later exams focus on insurance, finance, and business. These exams are less-math oriented and involve more memorization of various rules, procedures, and standards of practice. I found that these exams required a very large time committment since there was a lot of reading, memorization, and regurgitation of facts. People who breeze through the hardcore math exams often had a hard time with the insurance-related exams. Likewise, there are people who struggle with the math exams but have an easy time with the later exams.
I feel that to be successful on these exams, you don't necessarily have to be a math genius, but you have to have the mental fortitude to handle a high-pressure exam situation, and you have to have the committment to be able to dedicate the time necessary to study and practice for the exams. If you are one of those people who don't like the pressurized atmosphere of exam taking, or if you don't feel like you can dedicate the time to reading thousands of pages of esoteric insurance regulations, then all of the math genius in the world isn't going to help you with the exams.
As far as the work environment goes, this varies depending upon the area you decide to specialize in. I worked for a life insurance company, which, in general, is considered to be the more laid back environment. Rarely did I work more than your standard 40 hour week (not including time to study for exams). However, you can also work for a benefits/pension consulting firm, which I am told, is a real high pressure grind, especially for the lower level people. I have heard stories of people working 80+ hour weeks for consulting companies because they just had to get some project done for a client.
Most of the work I did was actually writing computer programs to perform various actuarial calcuations. In fact, most of actuarial work nowadays is done by computers. The higher level actuaries might suggest changing various assumptions and factors, and then I would modify the program to use those changes, run the program, and produce a new model. I really enjoyed the work quite a bit. In fact, I enjoyed it so much that I decided to switch my career from being an actuary to being a software engineer. I figured that since the part of the job I enjoyed the most was the programming aspect, I might as well concentrate on that aspect for a living. I did end up getting the first level of
I think the problem isn't that there is too MUCH focus on the beginning of the software lifecycle. The problem is that there is too LITTLE focus on the beginning of the software lifecycle.
The beginning of the software lifecycle is supposed to consist of analysis and design - both of which can lead to the construction of a superior product if done right. The issue is that many of these "quick start" languages and frameworks make is easy for a programmer to dive right into the coding phase without considering the overall design of the system. Thus, they skip the beginning steps in the software lifecycle.
Actually, being first to market really isn't that big of a deal. There are tons of products which were first to market which have slided away into oblivion because they were rushed out the door. Because they were rushed, they ended up sucking the big one. Then, another company comes out with a better, more polished version of the same product and everyone forgets about the first, sucky product.
The dotcom bust is littered with companies whose business model was, "be first or else", and nobody seems to remember them.
I have worked on a number of software projects and the kind of projects that end up being real success stories usually have very tightly knit client/developer contact. Many of our projects (I work for a firm that writes custom web and windows applications on the small to medium scale) have weekly client meetings, initial face to face introductions, and after-deployment training and handshaking. Its cheaper by the hour, but the end/net result of using outsourced labor for programming ends up being a wash, or even worse, cheaper for using American Labor.
Preach it brother!
I have been on projects where the users and development team are in the same building and requirements STILL get misinterpreted and change requests still pile up. If we can't even get it right when we are all talking face-to-face, I can't imagine the carnage when you add distance, cultural differences, languages differences to the mix. Personally, I think it is a clusterf*ck waiting to happen.
personally think this is bad advice. I certainly would not hire someone for a software position who has focused on hardware throughout their schooling and career. Hardware jobs are harder to find, and you end up less suited to the more prolific software industry. The only way I could recommend ECE is if you don't mind going back to school in a few years to train for your real career.
I both agree and disagree. To being with, let me say that I am somewhat biased since I am in EE who happens to work in the software field. Personally, I feel that having an EE background gives me a leg up in a very general sense for two reasons. First, I think that an engineering background gives you a good appreciation for analysis, design, and the all-important concept of "engineering tradeoffs". Having that "engineering" mindset is extremely helpful when it comes to designing software. Second, having a hardware background and understanding is helpful when it comes to understanding a lot of what goes on at the software level. This is especially true if you are doing what I would call "low level programming", but it can come in handy with any type of application.
That being said, an EE or hardware background alone isn't sufficient to be a code monkey. You still need to have a basic understanding of the software side of things, too. This may necessitate some self-study, some electives in the CS department, or some on-the-job training. In my case, it was through all of the above. You cannot take an EE who knows nothing about coding and throw them into the fire and expect them to be successful right away. However, if they have some of the fundamentals of coding down, they can easily shine in a software role.
In my personal observation, I have found that most of the best programmers I have encountered came from an EE background (for the record, even though I am from an EE background, I do not include myself in this category). I think the discipline and mindset that comes from an engineering background, combined with software skills is an awesome combination.
If the one means of application is broken, then EVERYONE who wants to apply can't apply. Therefore it is not, by definition, discrimination since nobody is given preferential treatment. Everybody is getting equally screwed by the busted machine.
Personally, I found that VB6 (and its various Visual and non-Visual precursors) was a beginner's language, but not necessarily a good language to learn as a teaching tool.
It is a beginner's language in the sense that it is easy for a non-programmer to pick up, since it hides a lot of the complexity from the developer. Thus, it was well suited for someone who isn't necessarily a coder, but who has a need to write some tool or application for his or her specific domain.
However, for someone who actually wants to actually learn the craft of programming, it is really not a very good language to start with. It has a lot of constructs which aren't generally found in other languages and which force the programmer to code things in a way that go against good programming practices.
I think that VB.Net, on the other hand, is the complete opposite of VB6 and prior versions. In my opinion, it is a lot more difficult for a non-programmer to learn. However, because it doesn't have the baggage of the older versions of Basic, it would actually be a good first language to learn for someone who really wants to get into programming. Unlike previous versions, there are a lot of concepts and constructs which actually are transferable to other languages.
That being said, I think that VB.Net was a big mistake. VB6's "niche" was as a language that a non-programmer could use if they wanted an simple application, but they didn't want to have to go to 4 years of college in order to be able to code it up. As far as I can tell, VB.Net is just C# with some syntactic sugar sprinkled on top. In the Microsoft programming language landscape, it really doesn't have anything to differentiate it from the other languages. You can't even upgrade code from VB6 to VB.Net without re-writing it, so it's not like it provides VB programmers with an upgrade path. Without a clear niche, I predict that VB.Net will die a slow death.
Here are some simple steps that you can take to figure out where the bottleneck is:
1. If you see the disk activity LED lit up a lot, you probably need more memory. The system is trying to extend the memory of the system by swapping data from RAM to disk and back. If you had more memory, the system would be able to keep more data in RAM. You can also confirm this by looking at the memory usage statistics in Task Manager (assuming this is a Windows box).
2. Another thing you can see from Task Manager is the CPU utilization. If it maxed out at 100%, the CPU is probably the bottleneck, so you may benefit from having a faster processor.
3. If neither of these things is the issue and the game you are running has a lot of complex graphics going on, then the issue could be your Video Card.
In my limited experience with benchmarking games, these seem like the three most common bottlenecks.
I see a lot of people saying things along the lines of "thats what you get for sticking with Microsoft". I think this is a somewhat unfair statement.
First off, it's not like.Net 2.0 makes 1.1 obsolete. I know that programmers are attracted to all the "new and shiny stuff" like lemmings to a cliff, but if logically speaking, unless there is a true BUSINESS REASON for porting an application, why not just leave it where it is. It is not like Microsoft is suddenly going to pull the plug on 1.1. It'll still work just fine and dandy. In fact, you can run a 2.0 and a 1.1 application pretty much side-by-side, so there really isn't any issues here.
Second, it's not like Microsoft is the only one coming out with new revisions every few years. This is pretty much the same strategy employed by most software makers, including the open source folks. Some people have brought up Java as this great and wonderful language. I am not a Java expert but I know that Java has gone through several iterations and during that time, many of their libraries and frameworks have changed. Functions have been deprecated. Libraries and their API's have been rewritten. New features have been added. I am not saying that this is a bad thing, but it is strange that people throw Microsoft under the bus, while giving Sun a pass.
I think the migration path from 1.1 to 2.0 is fairly simple from what I understand. There are various tools and wizards to convert over some of the changed libraries. For the most part, though, the core language hasn't changed. It is only the associated libraries. I say for the most part since there have been certain enhancements to the language, like generics (which I think was also added to Java at some point as well, so again there is a double standard here).
I think if one were going to debate that Microsoft has too much software churn, a better example would be the change from VB6 to VB.Net. In that case, there was a much bigger change which very little migration path, other than interoperability and re-writing code. From my point of view, VB6 was totally toss into the trash can there. In contrast, the path from 1.1 to 2.0 really isn't that big of a deal. Microsoft took a lot of flak for the VB6-to-VB.Net debacle, so maybe they learned their lesson.
I know you were being sarcastic, but you do bring up a good point: how can the bank trust Fortify?
First off, I know nothing about this Fortify product, so you may want to take what I say with a grain of salt. However, it does appear as if the bank is putting a LOT of faith in this product that it will find these supposed security holes. A wise man once said that there is no such thing as a "silver bullet", but it appears as if this bank has not taken this wisdom to heart. They are under the false impression that by running their source code through this magically software package that it will come out secure. If only it were that simple. I find it hard to believe that there is any software product out there that can ferret out all security holes.
I would guess that this Forify product employs some sort of static analysis to look for conditions in code which might possibly be security holes. This approach looks for various constructs in code which appear to match the "signature" of known security holes. However, there are two leaps of faith here. First is that the structure of all possible security vulnerabilities is known. Second is that a software tool can detect all of these possible cases. Neither of these suppositions seem rock solid to me.
They do seem to recognize the drawbacks of relying on a software tool to detect holes because they also have a manual code review. Again, this could be an expensive proposition for a medium to large size program, and it is not likely to reveal all security problems.
That being said, I totally understand why the bank would want to try and certify the security of their applications. Most likely, they are afraid that a unscrupulous programmer could inject some code into the application that would compromise the security of the data. Most security breaches are the result of a insider attack. This is especially true of a product that they buy from a third party. At least with their own in-house software, they have some measure of control over the people hired, over the design and coding process, and over the testing and certification. However, with software which they buy from the outside, they do not have that level of control.
I guess the bottom line is that I understand the reasoning behind what the bank is doing, but I hope it doesn't give the bank a false sense of security, since the process isn't perfect.
I do not quite understand it when you say that an employer has a MORAL RESPONSIBILITY to pay you fairly for your work. The only thing the employer has an obligation to do is to pay you what you and he have negotiated. If you didn't negotiate a proper wage for yourself, then the fault is YOURS, and not the business owner, and you need to accept the responsibility for this error, rather than pushing off the responsibility on someone else.
Also, your statement assumes that there is some higher power that sets what the proper wage is for everyone, which is, of course, doesn't happen. Your proper "market value" is solely based on what someone is willing to pay you. Just because someone happens to want to pay you more doesn't necessarily mean that the first person didn't give you a fair wage. It just means that one particular company is willing to pay you X and another is willing to pay you Y. Who's to say that the second company isn't actually overpaying you, because you happen to have a expertise which that company needs more than the first company.
Let's say that the second company is actually overpaying you because you fill a particular niche which that company just needs to have. Are you going to refuse the additional bump in salary above your market value? After all, according to your moral structure, you are acting immorally by accepting this extra money. In your own words, you are "stealing" from them, because you are accepting a wage higher than you believe that you are worth.
I have NEVER heard of someone going into their manager's office and saying, "You know, I really appreciate the fact that you value me so highly, but I think that I am being overpaid, so I am asking you to cut my salary so that you are only paying me what I am actually worth." However, according to your own morality, you would be a hippocrate if you didn't do such a thing. Despite your supposedly high moral character, I seriously doubt that you would ever do such a thing. Therefore, I find it hard to take your moralizing very seriously.
In fairness, as I have said in another thread, human nature is such that we all have a higher regard for our abilities than what is warranted. Therefore, it is more likely that we THINK that are we underpaid than to believe that we are overpaid. So it is understandable that you did not consider the flip side that you may be "stealing money" from your employer by being overpaid.
This may be a dumb question, but why do you have to tell them? Just because they ask you nicely? As you point out, the original poster has a job while the company doing the interviewing doesn't have someone filling the job, so the job seeker is in a position of power here. Therefore, the person should just refrain from answering that question.
I think a better route would be for the person to find out what the average salary is for a person with his particular skills, experience, education, etc. Obviously if the person feels that he is underpaid, so he must have some basis for coming to this conclusion. Thus, he probably has some idea what his "market value" is. Then, when the subject of salary comes up, politely ask what the salary range is for the position. Let the employee put their cards on the table first. If they tell you what they are expecting to pay, and it is in line with your "market value", then you are home free.
However, if the hiring manager has some savvy, they will try to get you to reveal your hand first instead. By asking you what you make now, they are trying to gauge what it will take to have you say "yes". Most people think in terms of making a certain percentage over their current salary, so by asking you for your current salary, they might gain some insight into what they need to offer you. They may feel like if they give you X% above your current salary, maybe you will say yes, even if it is still below the "market value". In fact, they may verbalize this by saying something along the lines of "I am going to offer you X, which is a 20% raise over your current salary. This is a fair offer since you are getting an immediate bump in salary". This may sound attractive, but if your market value is 50% above your current salary, they may be trying to get you "on the cheap".
If pressed into a corner, instead of revealing your current salary, reveal what range of salary you would expect to be paid for this position, even if it is a big jump in salary. "The average salary for someone with my skills is in the range of X to Y, so I would expect my salary to be commensurate with my experience." If they think you are being outrageous, you can either accept their lowball offer, or walk. No harm, no foul.
If you are finding, after a number of offers, that you are getting nowhere near your "market value", then maybe it is time to question your assumptions. Maybe you really are getting paid what you are worth, but because of people's natural tendencies to overvalue themselves, you are still unsatisfied. At this point, you may have to adjust your expections a little bit.
In summary, always try to make the employer reveal what they are thinking in terms of salary first. However, if you cannot do this, then stick to talking about what you are worth in the market, rather than what you are currently being paid. You are under no obligation to reveal this information, and from your point of view, there is no reason to do so. Resist the urge.
By law, you are only obligated to reveal this information to the tax man (or woman as the case may be). You probably will want to reveal it to your spouse, and anyone from whom you are seeking a loan. Other than that, keep that info to yourself.
I would guess that when you called health care a "fundamental human right", you probably didn't give much thought to your choice of words. You probably just put that phrase down just because it sounded nice. However, if I really stop to think about the phrase "fundamental human right", I come to the conclusion that this is an empty phrase. Is there really such a thing as a fundamental human right?
I guess I interpret a "fundamental human right" as a privilege that every human should have, and no human should do without, regardless of what type of society they are living in. Based on my definition of this phrase, I have a hard time coming up with any right that is a "fundamental human right".
Even the ever popular rights to "life, liberty, and pursuit of happiness" don't fall into this category. There are people who, according to society, forfeit the right to life under certain circumstances. Therefore, you cannot call it a "fundamental" right. Likewise for the other two "famous" rights.
So the question to you is, if the right to life isn't even fundamental, because not all humans are entitled to it, based upon the moral framework of most societies, then what exactly fits this category? Certainly if someone doesn't have a _fundamental_ right to live, just based upon their humanity, then they certainly can't have a _fundamental_ right to health care.
The moral structures of our society, under certain circumstances, dictate that we deny people of their "right" to health care. Let's say that someone is in a vegetative state and they have not left a "living will". In this situation, we do not err on the side of keeping them alive. Instead, we leave the decision to that person's next of kin. Therefore, it would seem in this situation that access to health care is not fundamental. If it were a fundamental right, we would act to keep that person alive, regardless of the wishes of the person's family.
Slashdot Mirror
It's not clear whether or not the original poster will be needing to work for the money, or whether the income will be just a nice retirement bonus.
If you don't need the extra income, then there are no shortage of outlets where you can "scratch" your programming "itch". Contribute to an open-source project (or start your own), write some useful piece of shareware, write some business applications for your local non-profit organization, teach programming at a community school, etc. None of these avenues will provide much income (if any), but it does allow you to take your hobby to the next level.
If you are looking to actually make money out of your hobby in retirement, my advice would be to leverage your pre-retirement vocation. There is a branch of software development known as "embedded programming", which is writing software for special-purpose hardware devices. As a hardware engineer, you probably have a lot of knowledge that would be very attractive to a potential employer. Also, you probably have contacts from your hardware days who might be able to help you land a job in this area.
This may be a obvious observation, but if someone knew they were getting a windfall on 4/15, then why would they give notice on 4/1? I think most _rational_ people would delay giving their notice until 4/16, so that they would collect their bonus. Anyway who would give their notice on 4/1 is either insane, or hates the work environment so much that they would be willing for forgo their bonus in order to get out of that place.
I worked at a place where you got a year end bonus that was paid as "restricted stock" that you could not sell for five years. If you quit before the five year period had elapsed, you forfeited a pro-rated portion of your bonus. Having a bonus vest in half-a-month seems quite generous in comparison.
Thank you for indulging me with a response. This is an interesting discussion, even if it is slightly off-topic.
And the PhDs, they should be doing something more useful.
But they applied, and we hired them.
In a sense, the PhD's DID help them to get the job at your company. You stated in your earlier post that their programming skills were quite weak, so I would assume that it was the piece of paper that got them the position, rather than their ability to actually do the job. Therefore, it is hard to say that degrees don't matter, when it obviously did in this case.
I think this actually illustrates one of the BEST reasons to get a degree: it gets your foot in the door at a variety of companies. There is some logic to this. Obviously, there are people without degrees who may be more qualified to do the job. However, if someone has a degree, odds are they have a certain baseline level of knowledge and skill. When you hire someone, it is often a crapshoot determining how well the person can do the job, so the HR person can use a degree as a simple "filter" to weed out candidates. There may be some people with degree who are idiots who slip through the filter, and there may be some candidates without degrees who are genius who get unfairly weeded out. However, that is the way the "game" is played, for better or for worse.
Most of whats designed online schools haven't caught up with yet, unless you count countries like India, where IT companies are actually creating their own colleges and teaching what they use, and not theory.
Actually, I would argue that only teaching people today's "hot" tools is NOT what you should be teaching. The average person will probably be working for 40 years. That is a long time, especially in the computer field. Odds are that today's "hot" technology is going to be replaced by something else in a few years.
In college, though, you don't necessarily learn specific technologies. You learn the basics of algorithms, data structures, software engineering principles, operating systems, compilers, and a host of other foundational skills. With a strong foundation like that, it doesn't matter what technology is "hot", since you have the foundation to be able to apply it according to the principles that you learned in college. That way, you can be useful and productive no matter what technology is hot today.
Also, when I mention college, I am talking about a BS or MS degree. You seem to be equating "college" with "PhD". PhD's are a different matter entirely. A PhD degree teaches you to do _research_ in a particular area of Computer Science. It is a much more theory-oriented course of study, for the most part, then what a professional software developer needs. On the other hand, a BS or MS degree is still more slanted towards the practical side.
I do acknowledge that if you are doing simple business applications that just pull and display data from a database on some web page or GUI, then you probably can just read "Teach Yourself X in 21 Days", and be able to put something reasonable together. However, if you are talking about a complex application with thousands and thousands of lines of code, complicated dependences, that needs to be extensible, maintainable, reliable, and all of the other -ibles, then you really need to have a strong foundation that a degree provides. This type of programming takes place at a lot more places that just Google. I would argue that this type of environment is more the rule than the exception.
Again, you can learn all this stuff on your own, so you don't NEED a college degree. However, college provides good mechanism to learn this stuff, and it gives the HR folks a nice warm and fuzzy feeling.
Your post seems very trollish, but I'll "bite" anyway...
c ollege-must-be-useless" affliction. I am happy that you turned out okay and all, but consider for a moment that you might be the exception rather than the rule.
First off, it makes no sense to hire a PhD as a junior programmer. PhD's aren't coders. They are researchers... "idea people". It is sort of like hiring Picasso to paint your house.
Second, you don't seem to have a good grasp of logic. Your argument boils down to the following:
Large companies require degrees -> Large companies are boring -> Degrees are useless
Small companies accept "equivalent experience" -> Small companies are exciting -> Better to not have a degree
Finally, you state that you have yet to see a college that teaches anything useful in the real world. What is that based upon? As someone who didn't go to college, you are basing this on conjecture rather than experience.
I think you suffer from the "I-didn't-go-to-college-and-I-turned-out-okay-so-
Thanks for your response. This seems somewhat counter-intuitive in that if you are employed "at will", then a company can, in theory, fire you on the first day you show up to work. That would effectively render any employment offer worthless, unless there was some agreed upon term of employment.
c fm?aid=621
However, I did a little research into this topic, and I found some commentary on case law in California. In particular there is a case called Agosta vs Astor, where the plaintiff was persuaded to leave his old job based upon promises related to salary and job duties. However, when he quit his old job to accept the new one, the company who made the offer reneged on its promise.
The California court ruled in favor of the plaintiff saying that even though his employment was termed "at will", because the company used fradulent means to induce him to take the job, he is entitled to damages.
Here is a reference to the article: http://www.jacksonlewis.com/legalupdates/article.
That would suggest that the original poster might have a case, at least in California (of course, I am not a lawyer so you better talk to a professional for REAL advice)!
Two thoughts... First, I have applied for many jobs online, and I don't recall ever having to give my SSN or DL number on a job application. Usually you only have to give them your SSN when you are employed and filling our your W4.
Second, I disagree that not giving your SSN marks you as a person with "something to hide". Most companies are sensitive to people's desire to keep certain information private, given all of the press that "identify theft" is getting these days. Any HR drone who would think of you suspiciously for not handing over your SSN on a job application hasn't been paying attention to the news for the past 10 years.
Let me ask a question... I honestly don't know what the real answer is, but it is something I was thinking about when I started reading this thread.
If you are hired "at will", meaning that either you or the company can terminate employment at any time, what is the purpose of having a written offer. If the company decides to change the terms of the offer, it seems like they can come back to you and say, "if you don't accept these new terms, then we will exercise our right to terminate your employment." For all practical purposes, that would render any written agreement worthless.
Here is a somewhat different spin on the original poster's situation. A few years ago, I accepted a job offer with a company that included a bonus plan consisting of company stock. Based upon the performance of the company, I would get a certain number of shares. However, last year, the company decided to change the bonus plan so that the shares vested over 5 years, rather than being granted immediately. This was obviously a change from the original employment offer that I had received. Could I have sued them for "breach of contract"? I am not a lawyer, but it would seem like I couldn't since I was employed "at will". If I wasn't willing to accept this change, they could always get rid of me, rather than allow me to continue under the terms of the original agreement.
Even though I am not a lawyer, in my experience, companies constantly are changing their policies and benefits (pension, compensation plans, vacation plan, etc), and I rarely hear about law suits contesting these changes based upon "breach of contract". The only exception is where there is a union involved. For us non-union, "at will" workers, we really don't have any choice but to either take what we are given, or find another job.
ROTFLMAO A CIO is never in a position to know or understand the benefits. You measure the benefits of the computer from OUTSIDE the computer, not from INSIDE the computer. Seems like all of IT sees everything from INSIDE the computer.
I think you are making the mistake of equating CIO with "the bearded IT uber-guru who is holed up in his cubicle with a case of Mountain Dew trying to increase the efficiency of the network by 2%".
The CIO is a business person first. It is the job of the CIO to set the IT direction of the company with the goal of using technology to MAKE MONEY for the company. In order to set that direction, they better be prepared to back up their decisions with some sort of business case. Otherwise, they will be out of a job pretty quickly.
Hear Hear!!!
It seems like people on this board view the CIO as being the top techie guru of the company. The truth is that the role of the CIO is a MANAGEMENT role and NOT a technical role.
Sure the CIO probably needs to have a little bit of a clue about technology, but they definitely need to have a BIG clue about finance and management in order to approve the expenditure of millions, if not billions, of dollars of IT spending.
I doubt it has anything to do with a "cost center" mentality, since any good CEO knows that IT can be a "profit center" in that good systems will benefit the bottom line.
Maybe the problem with CIO's is that they are too technical and are blinded by whiz-bang stuff without a appreciation that their role isn't to be the resident techie. A CIO's job is to weigh the benefits of an IT expenditure versus its cost. In essense, the position of CIO is a management/financial function, rather than a technical function. A good CIO won't be amazed by the latest tech for its own sake, but he will be amazed if there is a way to USE that tech to make money for the company. It would seem like a good CIO would make a good CEO, based upon this criteria, so maybe the issue is that there aren't a lot of good CIO?
Tax software is only deductible if you itemize deductions. Also, tax software is considered a "miscellaneous deduction". For miscellaneous deductions, you can only deduct the amount that is above 2% of your income. Therefore, for most people, tax software will not end up being deductible.
By the way, I am not a CPA, but you can reference http://www.irs.gov/pub/irs-pdf/i1040sa.pdf if you have any doubts.
Actually, options and futures (which are both considered derivatives since they "derive" their value from some underlying asset), when properly used, can actually REDUCE your investment risk.
For instance, say you own a block of stock in XYZ corporation. Let's say that you are a risk averse type and you want to make sure that the price of the stock doesn't go below $50 per share. In order to do this, you can buy a put option, which is an option to sell the stock for $50, regardless of what the actual market price of the stock is. If the stock price goes below $50, you can still sell your stock at $50 because of your put option.
In a sense, you buying insurance that your stock will not be worth less than some amount. If the stock stays above $50, then your option is worthless. However, this is just the insurance premium for the certain knowledge that your loss will be limited. Because your loss is limited, your risk is reduced. In general, options like this are a few pennies per share, so you may only be giving up a percent or two of return in order to insure your investment.
Options and other derivatives get a bad reputation, because people buy them not to insure an underlying asset, but to gain additional leverage which INCREASES their reward as well as their risk.
Here is a simple example of this type of investment...
Let's say that you believe that XYZ corporation, which is currently trading at $50, is going to go up to $100. If you only had $1000 to invest, you might buy 20 shares of XYZ, and then when the stock goes up to $100, you could sell those shares for double their value and make $1000 profit. However, another alternative is to buy call option with a strike price of $50. This option gives you the option to BUY the stock at $50. When the stock price is also $50, the call option might only be worth $1, so you could buy 1000 of these options. However, once the stock goes to $100, the call option is now worth $50, since you could exercise your option to buy stock at $50 and then sell the stock immediately for an immediate $50 profit. Thus, if the stock goes up to $100, you would have options worth $50,000! Thus, you have the potential to make more money buying the call option than you do with the underlying stock.
The downside in this situation is if the stock goes to $25 instead of $1000. If you had bought the stock, then you could sell your 20 shares for $25 and still have $500. You lost some of your investment, but you still have something to show for your efforts. However, if you had bought the options, your options would have a value of $0, since nobody would pay you for an option to buy a stock at $50 when you could buy the stock in the market at $25. Therefore, you have lost all of your initial investment.
In summary, while options give you the potential to make a lot of money, they also have the potential to wipe you out completely. However, if you use them to insure some underlying asset, they can be very beneficial and they can actually REDUCE your risk.
I feel EXTREMELY qualified to talk about the actuarial profession, since I am a recovering... er... former actuary.
First of all, it is definitely a profession that you can go into right out of school with a BS in Math. In fact, you can go into it with a degree in pretty much anything as long as you have the requsite math aptitude.
Second, unlike other careers, your career is pretty much defined by passing exams. This can be a double-edged sword. On the plus side, it provides an objective means to determine how you progress in your career. Instead of getting promoted because of how well you kiss the butt of some old fart, you get promoted for achieving passing grades on exams. (Of course, once you are done progressing through exams, your promotions are determined by the usual political stuff). On the downside, there are people who would made great leaders or managers, but who are limited in their career if they cannot pass exams for whatever reason. If you cannot pass exams in the actuarial profession, then you are better off leaving the field, since you won't get very far.
As far as the exams go, they are hard in the sense that the pass rate is usually around 50% or so. If you do not pass on the first try, you must wait for up to a year to take the exam again, which can slow your progress. The first few exams are math and statistics oriented. They do require some good math aptitude, but like all exams, there are "tricks" that can be learned which are indepedent of your skill. If you are good enough to get a BS in Math, you certainly should be able to master the math necessary to pass the exams. The later exams focus on insurance, finance, and business. These exams are less-math oriented and involve more memorization of various rules, procedures, and standards of practice. I found that these exams required a very large time committment since there was a lot of reading, memorization, and regurgitation of facts. People who breeze through the hardcore math exams often had a hard time with the insurance-related exams. Likewise, there are people who struggle with the math exams but have an easy time with the later exams.
I feel that to be successful on these exams, you don't necessarily have to be a math genius, but you have to have the mental fortitude to handle a high-pressure exam situation, and you have to have the committment to be able to dedicate the time necessary to study and practice for the exams. If you are one of those people who don't like the pressurized atmosphere of exam taking, or if you don't feel like you can dedicate the time to reading thousands of pages of esoteric insurance regulations, then all of the math genius in the world isn't going to help you with the exams.
As far as the work environment goes, this varies depending upon the area you decide to specialize in. I worked for a life insurance company, which, in general, is considered to be the more laid back environment. Rarely did I work more than your standard 40 hour week (not including time to study for exams). However, you can also work for a benefits/pension consulting firm, which I am told, is a real high pressure grind, especially for the lower level people. I have heard stories of people working 80+ hour weeks for consulting companies because they just had to get some project done for a client.
Most of the work I did was actually writing computer programs to perform various actuarial calcuations. In fact, most of actuarial work nowadays is done by computers. The higher level actuaries might suggest changing various assumptions and factors, and then I would modify the program to use those changes, run the program, and produce a new model. I really enjoyed the work quite a bit. In fact, I enjoyed it so much that I decided to switch my career from being an actuary to being a software engineer. I figured that since the part of the job I enjoyed the most was the programming aspect, I might as well concentrate on that aspect for a living. I did end up getting the first level of
I think the problem isn't that there is too MUCH focus on the beginning of the software lifecycle. The problem is that there is too LITTLE focus on the beginning of the software lifecycle.
The beginning of the software lifecycle is supposed to consist of analysis and design - both of which can lead to the construction of a superior product if done right. The issue is that many of these "quick start" languages and frameworks make is easy for a programmer to dive right into the coding phase without considering the overall design of the system. Thus, they skip the beginning steps in the software lifecycle.
Actually, being first to market really isn't that big of a deal. There are tons of products which were first to market which have slided away into oblivion because they were rushed out the door. Because they were rushed, they ended up sucking the big one. Then, another company comes out with a better, more polished version of the same product and everyone forgets about the first, sucky product.
The dotcom bust is littered with companies whose business model was, "be first or else", and nobody seems to remember them.
I have worked on a number of software projects and the kind of projects that end up being real success stories usually have very tightly knit client/developer contact. Many of our projects (I work for a firm that writes custom web and windows applications on the small to medium scale) have weekly client meetings, initial face to face introductions, and after-deployment training and handshaking. Its cheaper by the hour, but the end/net result of using outsourced labor for programming ends up being a wash, or even worse, cheaper for using American Labor.
Preach it brother!
I have been on projects where the users and development team are in the same building and requirements STILL get misinterpreted and change requests still pile up. If we can't even get it right when we are all talking face-to-face, I can't imagine the carnage when you add distance, cultural differences, languages differences to the mix. Personally, I think it is a clusterf*ck waiting to happen.
personally think this is bad advice. I certainly would not hire someone for a software position who has focused on hardware throughout their schooling and career. Hardware jobs are harder to find, and you end up less suited to the more prolific software industry. The only way I could recommend ECE is if you don't mind going back to school in a few years to train for your real career.
I both agree and disagree. To being with, let me say that I am somewhat biased since I am in EE who happens to work in the software field. Personally, I feel that having an EE background gives me a leg up in a very general sense for two reasons. First, I think that an engineering background gives you a good appreciation for analysis, design, and the all-important concept of "engineering tradeoffs". Having that "engineering" mindset is extremely helpful when it comes to designing software. Second, having a hardware background and understanding is helpful when it comes to understanding a lot of what goes on at the software level. This is especially true if you are doing what I would call "low level programming", but it can come in handy with any type of application.
That being said, an EE or hardware background alone isn't sufficient to be a code monkey. You still need to have a basic understanding of the software side of things, too. This may necessitate some self-study, some electives in the CS department, or some on-the-job training. In my case, it was through all of the above. You cannot take an EE who knows nothing about coding and throw them into the fire and expect them to be successful right away. However, if they have some of the fundamentals of coding down, they can easily shine in a software role.
In my personal observation, I have found that most of the best programmers I have encountered came from an EE background (for the record, even though I am from an EE background, I do not include myself in this category). I think the discipline and mindset that comes from an engineering background, combined with software skills is an awesome combination.
If the one means of application is broken, then EVERYONE who wants to apply can't apply. Therefore it is not, by definition, discrimination since nobody is given preferential treatment. Everybody is getting equally screwed by the busted machine.
Personally, I found that VB6 (and its various Visual and non-Visual precursors) was a beginner's language, but not necessarily a good language to learn as a teaching tool.
It is a beginner's language in the sense that it is easy for a non-programmer to pick up, since it hides a lot of the complexity from the developer. Thus, it was well suited for someone who isn't necessarily a coder, but who has a need to write some tool or application for his or her specific domain.
However, for someone who actually wants to actually learn the craft of programming, it is really not a very good language to start with. It has a lot of constructs which aren't generally found in other languages and which force the programmer to code things in a way that go against good programming practices.
I think that VB.Net, on the other hand, is the complete opposite of VB6 and prior versions. In my opinion, it is a lot more difficult for a non-programmer to learn. However, because it doesn't have the baggage of the older versions of Basic, it would actually be a good first language to learn for someone who really wants to get into programming. Unlike previous versions, there are a lot of concepts and constructs which actually are transferable to other languages.
That being said, I think that VB.Net was a big mistake. VB6's "niche" was as a language that a non-programmer could use if they wanted an simple application, but they didn't want to have to go to 4 years of college in order to be able to code it up. As far as I can tell, VB.Net is just C# with some syntactic sugar sprinkled on top. In the Microsoft programming language landscape, it really doesn't have anything to differentiate it from the other languages. You can't even upgrade code from VB6 to VB.Net without re-writing it, so it's not like it provides VB programmers with an upgrade path. Without a clear niche, I predict that VB.Net will die a slow death.
Here are some simple steps that you can take to figure out where the bottleneck is:
1. If you see the disk activity LED lit up a lot, you probably need more memory. The system is trying to extend the memory of the system by swapping data from RAM to disk and back. If you had more memory, the system would be able to keep more data in RAM. You can also confirm this by looking at the memory usage statistics in Task Manager (assuming this is a Windows box).
2. Another thing you can see from Task Manager is the CPU utilization. If it maxed out at 100%, the CPU is probably the bottleneck, so you may benefit from having a faster processor.
3. If neither of these things is the issue and the game you are running has a lot of complex graphics going on, then the issue could be your Video Card.
In my limited experience with benchmarking games, these seem like the three most common bottlenecks.
I see a lot of people saying things along the lines of "thats what you get for sticking with Microsoft". I think this is a somewhat unfair statement.
.Net 2.0 makes 1.1 obsolete. I know that programmers are attracted to all the "new and shiny stuff" like lemmings to a cliff, but if logically speaking, unless there is a true BUSINESS REASON for porting an application, why not just leave it where it is. It is not like Microsoft is suddenly going to pull the plug on 1.1. It'll still work just fine and dandy. In fact, you can run a 2.0 and a 1.1 application pretty much side-by-side, so there really isn't any issues here.
First off, it's not like
Second, it's not like Microsoft is the only one coming out with new revisions every few years. This is pretty much the same strategy employed by most software makers, including the open source folks. Some people have brought up Java as this great and wonderful language. I am not a Java expert but I know that Java has gone through several iterations and during that time, many of their libraries and frameworks have changed. Functions have been deprecated. Libraries and their API's have been rewritten. New features have been added. I am not saying that this is a bad thing, but it is strange that people throw Microsoft under the bus, while giving Sun a pass.
I think the migration path from 1.1 to 2.0 is fairly simple from what I understand. There are various tools and wizards to convert over some of the changed libraries. For the most part, though, the core language hasn't changed. It is only the associated libraries. I say for the most part since there have been certain enhancements to the language, like generics (which I think was also added to Java at some point as well, so again there is a double standard here).
I think if one were going to debate that Microsoft has too much software churn, a better example would be the change from VB6 to VB.Net. In that case, there was a much bigger change which very little migration path, other than interoperability and re-writing code. From my point of view, VB6 was totally toss into the trash can there. In contrast, the path from 1.1 to 2.0 really isn't that big of a deal. Microsoft took a lot of flak for the VB6-to-VB.Net debacle, so maybe they learned their lesson.
I know you were being sarcastic, but you do bring up a good point: how can the bank trust Fortify?
First off, I know nothing about this Fortify product, so you may want to take what I say with a grain of salt. However, it does appear as if the bank is putting a LOT of faith in this product that it will find these supposed security holes. A wise man once said that there is no such thing as a "silver bullet", but it appears as if this bank has not taken this wisdom to heart. They are under the false impression that by running their source code through this magically software package that it will come out secure. If only it were that simple. I find it hard to believe that there is any software product out there that can ferret out all security holes.
I would guess that this Forify product employs some sort of static analysis to look for conditions in code which might possibly be security holes. This approach looks for various constructs in code which appear to match the "signature" of known security holes. However, there are two leaps of faith here. First is that the structure of all possible security vulnerabilities is known. Second is that a software tool can detect all of these possible cases. Neither of these suppositions seem rock solid to me.
They do seem to recognize the drawbacks of relying on a software tool to detect holes because they also have a manual code review. Again, this could be an expensive proposition for a medium to large size program, and it is not likely to reveal all security problems.
That being said, I totally understand why the bank would want to try and certify the security of their applications. Most likely, they are afraid that a unscrupulous programmer could inject some code into the application that would compromise the security of the data. Most security breaches are the result of a insider attack. This is especially true of a product that they buy from a third party. At least with their own in-house software, they have some measure of control over the people hired, over the design and coding process, and over the testing and certification. However, with software which they buy from the outside, they do not have that level of control.
I guess the bottom line is that I understand the reasoning behind what the bank is doing, but I hope it doesn't give the bank a false sense of security, since the process isn't perfect.
I do not quite understand it when you say that an employer has a MORAL RESPONSIBILITY to pay you fairly for your work. The only thing the employer has an obligation to do is to pay you what you and he have negotiated. If you didn't negotiate a proper wage for yourself, then the fault is YOURS, and not the business owner, and you need to accept the responsibility for this error, rather than pushing off the responsibility on someone else.
Also, your statement assumes that there is some higher power that sets what the proper wage is for everyone, which is, of course, doesn't happen. Your proper "market value" is solely based on what someone is willing to pay you. Just because someone happens to want to pay you more doesn't necessarily mean that the first person didn't give you a fair wage. It just means that one particular company is willing to pay you X and another is willing to pay you Y. Who's to say that the second company isn't actually overpaying you, because you happen to have a expertise which that company needs more than the first company.
Let's say that the second company is actually overpaying you because you fill a particular niche which that company just needs to have. Are you going to refuse the additional bump in salary above your market value? After all, according to your moral structure, you are acting immorally by accepting this extra money. In your own words, you are "stealing" from them, because you are accepting a wage higher than you believe that you are worth.
I have NEVER heard of someone going into their manager's office and saying, "You know, I really appreciate the fact that you value me so highly, but I think that I am being overpaid, so I am asking you to cut my salary so that you are only paying me what I am actually worth." However, according to your own morality, you would be a hippocrate if you didn't do such a thing. Despite your supposedly high moral character, I seriously doubt that you would ever do such a thing. Therefore, I find it hard to take your moralizing very seriously.
In fairness, as I have said in another thread, human nature is such that we all have a higher regard for our abilities than what is warranted. Therefore, it is more likely that we THINK that are we underpaid than to believe that we are overpaid. So it is understandable that you did not consider the flip side that you may be "stealing money" from your employer by being overpaid.
This may be a dumb question, but why do you have to tell them? Just because they ask you nicely? As you point out, the original poster has a job while the company doing the interviewing doesn't have someone filling the job, so the job seeker is in a position of power here. Therefore, the person should just refrain from answering that question.
I think a better route would be for the person to find out what the average salary is for a person with his particular skills, experience, education, etc. Obviously if the person feels that he is underpaid, so he must have some basis for coming to this conclusion. Thus, he probably has some idea what his "market value" is. Then, when the subject of salary comes up, politely ask what the salary range is for the position. Let the employee put their cards on the table first. If they tell you what they are expecting to pay, and it is in line with your "market value", then you are home free.
However, if the hiring manager has some savvy, they will try to get you to reveal your hand first instead. By asking you what you make now, they are trying to gauge what it will take to have you say "yes". Most people think in terms of making a certain percentage over their current salary, so by asking you for your current salary, they might gain some insight into what they need to offer you. They may feel like if they give you X% above your current salary, maybe you will say yes, even if it is still below the "market value". In fact, they may verbalize this by saying something along the lines of "I am going to offer you X, which is a 20% raise over your current salary. This is a fair offer since you are getting an immediate bump in salary". This may sound attractive, but if your market value is 50% above your current salary, they may be trying to get you "on the cheap".
If pressed into a corner, instead of revealing your current salary, reveal what range of salary you would expect to be paid for this position, even if it is a big jump in salary. "The average salary for someone with my skills is in the range of X to Y, so I would expect my salary to be commensurate with my experience." If they think you are being outrageous, you can either accept their lowball offer, or walk. No harm, no foul.
If you are finding, after a number of offers, that you are getting nowhere near your "market value", then maybe it is time to question your assumptions. Maybe you really are getting paid what you are worth, but because of people's natural tendencies to overvalue themselves, you are still unsatisfied. At this point, you may have to adjust your expections a little bit.
In summary, always try to make the employer reveal what they are thinking in terms of salary first. However, if you cannot do this, then stick to talking about what you are worth in the market, rather than what you are currently being paid. You are under no obligation to reveal this information, and from your point of view, there is no reason to do so. Resist the urge.
By law, you are only obligated to reveal this information to the tax man (or woman as the case may be). You probably will want to reveal it to your spouse, and anyone from whom you are seeking a loan. Other than that, keep that info to yourself.
I would guess that when you called health care a "fundamental human right", you probably didn't give much thought to your choice of words. You probably just put that phrase down just because it sounded nice. However, if I really stop to think about the phrase "fundamental human right", I come to the conclusion that this is an empty phrase. Is there really such a thing as a fundamental human right?
I guess I interpret a "fundamental human right" as a privilege that every human should have, and no human should do without, regardless of what type of society they are living in. Based on my definition of this phrase, I have a hard time coming up with any right that is a "fundamental human right".
Even the ever popular rights to "life, liberty, and pursuit of happiness" don't fall into this category. There are people who, according to society, forfeit the right to life under certain circumstances. Therefore, you cannot call it a "fundamental" right. Likewise for the other two "famous" rights.
So the question to you is, if the right to life isn't even fundamental, because not all humans are entitled to it, based upon the moral framework of most societies, then what exactly fits this category? Certainly if someone doesn't have a _fundamental_ right to live, just based upon their humanity, then they certainly can't have a _fundamental_ right to health care.
The moral structures of our society, under certain circumstances, dictate that we deny people of their "right" to health care. Let's say that someone is in a vegetative state and they have not left a "living will". In this situation, we do not err on the side of keeping them alive. Instead, we leave the decision to that person's next of kin. Therefore, it would seem in this situation that access to health care is not fundamental. If it were a fundamental right, we would act to keep that person alive, regardless of the wishes of the person's family.