My first programming job was working in a food manufacturing company as a junior programmer. There was a team of programmer/analysts. We knew the business of food manufacturing. We understood our own business. We understood the day-to-day jobs of employees who had to use our software. We tested our own code. There was no formal "QA" for the software. Part of the job was testing the code. If you didn't test your code, repeatedly had failures, your ass was fired. It's as simple as that.
Most pieces of software do not require a separate formal team to test it. All it requires are programmers who understand what they are doing, what business they are in, and how their software is going to be used. What the hell has happened to this business?
Woodworkers have more capability, domain understanding, and work ethic than programmers these days. A good woodworker tests their angles for trueness. They design their cut sheets to maximize wood usage and eliminate scrap waste. They test their joints for racking. They will sand every edge of a piece to make sure no blood can ever be drawn. They will make sure that every plane is perfectly level.
If you want to be a good programmer, get off your lazy ass and make an effort to understand your customer and the business you are developing software for. Test your own code and be intellectually honest with yourself while you do. If you need to automate, fine, but automate where it makes sense. Test things that make sense. If you do that, most of your code will be free of critical bugs.
Any subject in general could be extremely fun to learn if the educational pace was more easy going. THAT is the problem.
We are a generally long-lived species these days. Why in the hell do we need to compress several times the knowledge of 60 years ago into the same time span they had 60 years ago? It makes no sense to me. High school teenagers in AP (advanced placement) classes are competing so hard that they need to be up until 1am or 2am in the morning three or four times a week just to keep up with the homework. 4 to 5 hours of sleep per night. Terrible sleeping and eating habits. No physical activity. It has gotten RIDICULOUS. I don't know what in the hell we think we're teaching kids these days, but we're sure not teaching them that learning is fun.
There has to be a breaking point soon. Kids should be able to enjoy being kids. Kids should also feel like they don't have to pressured to have half of their college credits finished by the time they graduate high school. They also shouldn't feel like they should need to get their PhD by the time they are 21.
At its inception, the Agile manifesto was simple. Four priority/value statements and then a list of simple principles. The goal? Merely to say that delivering value to the customer, collaborating with customers, frequent delivery and feedback, and team empowerment are the way to deliver software. Focus on delivering value. Don't focus on delivering things that aren't valuable. Very simple.
Once Agile values started to become embraced and a couple of new development processes came along (SCRUM, etc), you all of a sudden had a bunch of consulting companies and community meetups appear that all but destroyed the perception of Agile. For these companies and community groups, it's all about the process. They will teach you how to "do agile". They will provide you with bodies/contractors who can "do agile". They will sell you certifications which show you "do agile". They will sell you seminars and training on how to "do agile". They will sell you software which "does agile". Agile has went from a basic set of values to becoming a fundamentalist religion.
So my statement to "Agile Process Improvement" firms is this: You are all just scammers and profiteers. You are software development Pharisees. It is amazing that you focus on profiting from creating processes, enforcing processes, teaching processes, and writing process software... for a methodology where the first value statement is "Individuals and interactions over processes and tools". Why don't you guys teach REAL agile? Why don't you teach companies how to better define value and deliver it to customers instead of selling new processes, fundamentalism, and bodies?
For the rest of you, if you want to be "Agile". Read the Agile manifesto. Create your own process that suits your team and your business. Work continuously with your customers to understand what is valuable to them. Deliver good value to them often and get their feedback. Allow your team to learn and grow and understand the needs of the customer. THAT is Agile. THAT is all you need to do.
Netflix isn't raising prices just for the hell of it. Prices get raised for two reasons: 1) Increased upstream costs (passed on to the customer), and/or 2) Increase in demand.
The reality is, Netflix has run the numbers and they believe that the demand for their product is such that most of their customer base will be willing to pay the higher price. They'll definitely have some attrition, but that loss in revenue will surely be replaced by the increase in revenue from the customers that stay. Believe me, they've already run these numbers.
Netflix has a great product, it is served through far more mechanisms than it used to be (phones, gaming consoles, televisions, set-top boxes). As demand has increased, I'm certain their delivery costs have increased. As Netflix's demand has increased, I'm sure the entertainment industry has raised their prices to meet the demand. It isn't that big of a deal. Okay, yes, they could have done a better job of publicly positioning the price alterations, but so what?
In the end, we have a company that raised the price of it's higher demand service and lowered the price of it's lower demand service. Is this really surprising?
I think you are seriously understating the rake...
Of course the rake is capped. If it weren't, nobody would play. Because the rake would be unbeatable by even the most skilled of players. Any rake is intended to maximize the house's profit while still keeping good and bad players interested in playing.
The situation you describe is a rare one. For every hand where the "rake doesn't matter", there are probably 10 or 20 hands where the rake DOES matter. Hands where you paid an ante to simply fold. Hands where you paid a rake to fold on the turn. This happens WAY more often than not.
Like you said, you can't be a winning player by winning only the small pots. I'll go further to say that you can't be a winning layer by winning medium pots. The only way you can be a winning player is to maximize the profit potential of all hands -- small, medium, and large.
I am a poker player. I do believe poker to be a skill game. But the reason why poker is not a complete skill game is because of the rake. Being consistently more skilled than your opponents at poker is not enough to make you profitable. You have to be skilled enough to also overcome the rake.
Let's say that in an ideal world, with no rake, I am skilled enough to win 5 dollars per hour. After introducing the rake, I could potentially lose 10 dollars per hour... putting me at a net loss. Even though I didn't change my playing style one bit. Overcoming the rake is a hard feat given that it is at least 10%. Over the long run, that is an incredibly huge amount of money. And you pay the rake regardless of whether you win or lose.
Being better than your opponent isn't good enough. You have to be skilled at maximizing profit. This is what most people don't understand.
I know very skilled players who win a lot of hands... but are losers... because they don't know how to maximize their winning value to surpass the rake.
Niris, I have helped teach several people how to program. What you really need to next is apply what you have learned and solve a problem. Ideally, solve a problem that you know something about. Or solve a problem where you have some subject-matter expertise.
I'm not sure if you actually like being a security guard or not. Maybe you do. Maybe you don't. But you are probably familiar with the subject matter. Write a program that will solve a problem related to the subject matter. Using problems that are in operations research are really good ones. For example, a problem I might give you:
Security Scheduling Program for a Business
Purpose The program should create the optimum shift schedule for a week -- guarding a business 24 hours a day.
Requirements 1) The program must allow for the user to input the number of available security guards. 2) The program must print out the shifts for each security guard. 3) No shift schedule can be over 8 hours long. 4) No security guard can work more than four days in a row. 5) All guards must be used in the schedule. 6) Each guard must have a 30 minute lunch and two 15 minute breaks each day. 7) During a break or lunch period, another guard must cover the watch. 8) If any of the constraints cannot be met -- given the number of guards available -- then the program should indicate that more guards are needed.
This problem is just an example of an operations research problem -- finding optimality. If you don't like this problem, you can make up another one. Or do a search on the internet. The idea is that you find a problem to solve that you: 1) know something about and/or 2) have some interest in.
When first learning to program, the key isn't the language you learn. The key is proving that you can solve a real world problem using programming. Good luck to you.
Interesting. I've never heard the converse question... "When the manager comes in early, should the developers come in early?" But that's another topic...
The real question is "why would the manager stay?" Here are some possible -- one or more -- reasons:
1) Because the manager does not trust that the job will get done... "trust but verify".
2) Because the manager feels like it will gain him/her credibility with the team.
3) Because the manager feels guilty and wants to share in the pain.
4) Because the manager feels like it will give the bosses peace of mind during hard times.
I can't think of any other reasons. But it is important to say that usually, if a manager wants to stick around, it is for noble reasons.
My advice to developers, is that if reasons #2, #3, or #4 are any of the motivations for their boss to stick around... cut them a break. Even if #1 is also a reason.
One of the earlier posts talked about the difficulties around "too big to fail" or "to big to succeed". To me, this is where the concept of finding a Nash Equilibrium is critical.
To resolve this situation optimally, a means to an end must be found where all of the affected parties benefit the greatest as a whole. You can't simply issue a patent judgment and say "have a nice day, you have X days to comply". That might benefit i4i, but it really hurts a lot of other stakeholders in the system -- including consumers (who do you think will bear the cost of that judgment?). Like it or not, by the law, i4i deserves something for the infringement (if the court finds the patent valid).
However, this is where our legal system in the free market breaks down. You've got to make sure you can come to judgments where the market isn't overly harmed, but everyone gets a taste of what they deserve.
You are exactly right. It does NOT matter at all who's fault it is.
The reality is, the manager has to address any kind of motivational issues. Regardless of the source of de-motivation. De-motivation kills individual productivity, team productivity, and can even sour an entire organization.
Uh, exactly. If you have an employer that uses terms like "self-motivated", "works smarter and not harder", "ability to work without direction"... et cetera.... RUN (don't walk) for the hills.
These are companies who have incompetent managers who delegate their own management responsibility to their workers.
Managers are supposed to actually serve a purpose.
As a director of a software development organization, I won't be popular for saying this. But... it is your boss' fault. Not yours.
You simply aren't motivated. I want to slap the person somewhere in another post who said... "motivation comes from within". It *rarely* comes from within.
When one of my managers or peers comes to me and complains about "unfocused" or "unmotivated" employees, I tell them to get off their collective ass and motivate their team or their employee. Psychologically, as an employee, you should feel driven by your surroundings to achieve a goal. That feeling should be driven by your team, your boss, your organization.
Being "self-motivated" is the single, biggest path to burnout in existence. Don't even begin to blame yourself.
Here is what I would recommend. Go to your manager. Tell your manager that you simply aren't feeling very motivated about the work you are doing. Have an open and honest conversation about it. You might be surprised. Your boss might actually bring some out some of the motivational mojo that you need. If your boss doesn't come through for you, then think about going to another organization.
But don't quit programming. You probably love it and you probably are pretty decent at it. You just need to be motivated, that's all.
I am a Democrat, and while I think the Mike Huckabee is a complete idiot on the great majority of his stances, I think his income tax abolishment and consumption tax proposal has great merit.
All we need to do is increase the state sales tax rate by the amount of the consumption tax. Then, the state can make tax payments to the federal government. No more income tax. Take a tax whenever money is exchanged for goods or services.
This means that we get all of the tax revenue when illegally acquired revenue gets spent. We also get federal tax revenue from visiting tourists. We also (finally) get the federal tax revenue from churches when they spend money. It also means that people who save (and not spend) actually get an immediate benefit by investing/saving.
Taxing income is moronic. There's too many ways to dodge it, too many ways to loophole it, too many ways to deduct it, too many ways to make exceptions.
Make it fair for everyone. Charge federal tax at the cash register.
This theory breaks when the person who uses the bomb doesn't care about their own destruction. Once you stop caring about retaliation, all bets are off.
It isn't when the person doesn't care. It is when the entire chain of individuals responsible for launching the nuke doesn't care.
This is why MAD works. If MAD was in the hands of any one individual, it wouldn't work.
Even if a crackpot leader wanted to launch a nuke or some other WMD, they couldn't do so if their subordinates couldn't be convinced to follow the order. I'm fairly certain that crackpot leaders have wanted to push the button in the past -- and were rebuked. You are naive if you think this situation hasn't occurred before.
I'm not worried one bit about North Korean or Iranian leaders and their grandstanding.
What does worry me is that world leaders don't do enough to understand and address the motivation behind this grandstanding.
What we have is an MIT CS dork who is bringing everything full circle and realizing that actually rotation, movement, and proximity are important factors in a human-to-machine interface.
NO SHIT SHERLOCK.
Is this really that ground-breaking? My god. Ever see a music mixing board? Ever see a keyboard synthesizer? Ever see a hifi music component? Ever see a car? Ever see a door? All of these machines have knobs, sliders, buttons, handles, and a brain which can alter the behavior of the machine based on the combinations of positions of knobs and sliders and buttons.
So this guy is asserting that these concepts are going to introduce a new and innovative way that humans interact with machines? GIVE ME A BREAK.
Perhaps next, he should create a new tool called a "roundling" which looks exactly like a tire and will revolutionize the way that humans move from one place to another.
I have to say after reading this article -- Stroustrup is a tool. It is just that simple. Nothing more than a pundit at this point. He had a stroke of genius in programming and now is an expert in everything related to programming.
He thinks companies aren't happy with their graduates? Well, I say companies have terrible hiring practices, terrible mentorship programs, and ridiculous expectations.
Balance the theoretical and the practical? Wow. Brilliant observation. Great, Bjarne. Please give us more sweeping Karate-Kid style one-liners.
High schools should teach students to work hard? Great, Bjarne. Thanks again for that. Search out information as needed? Another stroke of brilliance. Express ideas in writing and verbally? WOW. PINCH ME. Such genius can only be dreamed of.
Then, the article closes with him trying to be edgy and go out "with a bang". Sloppy, fat geeks. Nice. This guy is a douchebag. Pure and simple.
Here is my own contribution to douchbaggery... I think we should take aging, isolated, self-important pundits out into a remote area and bury them neck deep in the dirt.
This kills me every time I see it. I was just talking to a co-worker about this yesterday. We were doing some campus recruiting and this subject came up.
I run a software development organization now, but back in the day, I held a similar stereotype about "QA"... until I had to actually be responsible for quality.
QA is as much a science as art. Being a good tester takes skill, excellent understanding of the area being tested, an understanding of use-cases, understanding of likely vs. non-likely failure points, and how to truly measure quality itself. It requires (usually) a medium to high level of IT admin knowledge. In some cases (such as hardware)... the best testers are true engineers... EE(electrical) or CE(computer). Most test automation QA people are actually coders who know how to write software and do it every day.
I realize that there are lots of flighty "button clickers" out there. But there are equally as many "code monkeys" who write garbage code.
I wish QA would stop getting this bad wrap. Testing a complex piece of software (or hardware) is equally as tough as creating it.
If you are looking to use QA as a stepping stone into software development, I urge you to reconsider. You can rise into the ranks of a QA organization and easily make 100k a year... just doing testing.
All Computer Engineers are qualified 'software engineers' though.
It depends on the kind of software engineers you are talking about. Firmware engineering? OS engineering? Yeah, sure.
Business software engineering? Not a chance in hell. CS grads are WAY more qualified in that arena.
Which brings up an important point. Maybe the OP needs to go look for a job at a place such as Motorola, HP, Cisco, or the like. Those folks hire CEs all the time. But if the OP is trying to find a job at a commercial/business software company, then he's looking in the wrong place.
If I had mod points, I'd mod this up as insightful.
The OP is either the unluckiest guy in the world, or is being rejected for very legitimate reasons.
The OP should take a very close look at himself. I would recommend the following:
1) Ask friends or acquaintances -- who are software developers -- to give you a mock interview. After that, have them give you an objective appraisal.
2) Go get certified in something to do with software development. Computer engineering has little overlap with software engineering. Taking a certification is going to give you a clue as to what you are missing. Plus, it will give your resume a (little) boost.
Going from technical support into R&D is a tough move. But you need to get the advice and direction from people in the business that you trust.
Remember, if you want a different result, then do something different. Seek counsel and advice.
This group of doctors is solving a problem that might yield a small amount of additional expected value over commercially available limit poker bots.
This group of doctors IS NOT taking on the problem of sitting a computer down at a table of 6 or 7 no-limit/pot-limit professionals -- and having the computer win. Why? Because they can't solve it.
A computer sitting down at a no-limit table, surrounded by pros, would be pounded into playing only the highest value hands. Because it would "learn" that the only way it could predictably win is to play those hands.
Hell, the best no-limit computer/bot out there would be one that doesn't even consider its own cards. The best no-limit bot would simply pick a hand it wanted to represent at the beginning of each hand... and then play each hand as if it actually had those cards.
At least then it would be closer to a professional level of play.
Slashdot Mirror
My first programming job was working in a food manufacturing company as a junior programmer. There was a team of programmer/analysts. We knew the business of food manufacturing. We understood our own business. We understood the day-to-day jobs of employees who had to use our software. We tested our own code. There was no formal "QA" for the software. Part of the job was testing the code. If you didn't test your code, repeatedly had failures, your ass was fired. It's as simple as that.
Most pieces of software do not require a separate formal team to test it. All it requires are programmers who understand what they are doing, what business they are in, and how their software is going to be used. What the hell has happened to this business?
Woodworkers have more capability, domain understanding, and work ethic than programmers these days. A good woodworker tests their angles for trueness. They design their cut sheets to maximize wood usage and eliminate scrap waste. They test their joints for racking. They will sand every edge of a piece to make sure no blood can ever be drawn. They will make sure that every plane is perfectly level.
If you want to be a good programmer, get off your lazy ass and make an effort to understand your customer and the business you are developing software for. Test your own code and be intellectually honest with yourself while you do. If you need to automate, fine, but automate where it makes sense. Test things that make sense. If you do that, most of your code will be free of critical bugs.
If this was Yahoo's goal, then good for them.
Any subject in general could be extremely fun to learn if the educational pace was more easy going. THAT is the problem.
We are a generally long-lived species these days. Why in the hell do we need to compress several times the knowledge of 60 years ago into the same time span they had 60 years ago? It makes no sense to me. High school teenagers in AP (advanced placement) classes are competing so hard that they need to be up until 1am or 2am in the morning three or four times a week just to keep up with the homework. 4 to 5 hours of sleep per night. Terrible sleeping and eating habits. No physical activity. It has gotten RIDICULOUS. I don't know what in the hell we think we're teaching kids these days, but we're sure not teaching them that learning is fun.
There has to be a breaking point soon. Kids should be able to enjoy being kids. Kids should also feel like they don't have to pressured to have half of their college credits finished by the time they graduate high school. They also shouldn't feel like they should need to get their PhD by the time they are 21.
What are we doing to these kids?
At its inception, the Agile manifesto was simple. Four priority/value statements and then a list of simple principles. The goal? Merely to say that delivering value to the customer, collaborating with customers, frequent delivery and feedback, and team empowerment are the way to deliver software. Focus on delivering value. Don't focus on delivering things that aren't valuable. Very simple.
Once Agile values started to become embraced and a couple of new development processes came along (SCRUM, etc), you all of a sudden had a bunch of consulting companies and community meetups appear that all but destroyed the perception of Agile. For these companies and community groups, it's all about the process. They will teach you how to "do agile". They will provide you with bodies/contractors who can "do agile". They will sell you certifications which show you "do agile". They will sell you seminars and training on how to "do agile". They will sell you software which "does agile". Agile has went from a basic set of values to becoming a fundamentalist religion.
So my statement to "Agile Process Improvement" firms is this: You are all just scammers and profiteers. You are software development Pharisees. It is amazing that you focus on profiting from creating processes, enforcing processes, teaching processes, and writing process software... for a methodology where the first value statement is "Individuals and interactions over processes and tools". Why don't you guys teach REAL agile? Why don't you teach companies how to better define value and deliver it to customers instead of selling new processes, fundamentalism, and bodies?
For the rest of you, if you want to be "Agile". Read the Agile manifesto. Create your own process that suits your team and your business. Work continuously with your customers to understand what is valuable to them. Deliver good value to them often and get their feedback. Allow your team to learn and grow and understand the needs of the customer. THAT is Agile. THAT is all you need to do.
Netflix isn't raising prices just for the hell of it. Prices get raised for two reasons: 1) Increased upstream costs (passed on to the customer), and/or 2) Increase in demand.
The reality is, Netflix has run the numbers and they believe that the demand for their product is such that most of their customer base will be willing to pay the higher price. They'll definitely have some attrition, but that loss in revenue will surely be replaced by the increase in revenue from the customers that stay. Believe me, they've already run these numbers.
Netflix has a great product, it is served through far more mechanisms than it used to be (phones, gaming consoles, televisions, set-top boxes). As demand has increased, I'm certain their delivery costs have increased. As Netflix's demand has increased, I'm sure the entertainment industry has raised their prices to meet the demand. It isn't that big of a deal. Okay, yes, they could have done a better job of publicly positioning the price alterations, but so what?
In the end, we have a company that raised the price of it's higher demand service and lowered the price of it's lower demand service. Is this really surprising?
I wish I had mod points. GREAT post. The analogy of teaching a child to write is spot on. Excellent post.
I think you are seriously understating the rake...
Of course the rake is capped. If it weren't, nobody would play. Because the rake would be unbeatable by even the most skilled of players. Any rake is intended to maximize the house's profit while still keeping good and bad players interested in playing.
The situation you describe is a rare one. For every hand where the "rake doesn't matter", there are probably 10 or 20 hands where the rake DOES matter. Hands where you paid an ante to simply fold. Hands where you paid a rake to fold on the turn. This happens WAY more often than not.
Like you said, you can't be a winning player by winning only the small pots. I'll go further to say that you can't be a winning layer by winning medium pots. The only way you can be a winning player is to maximize the profit potential of all hands -- small, medium, and large.
I agree with you conceptually.
But the big problem is *THE RAKE*.
I am a poker player. I do believe poker to be a skill game. But the reason why poker is not a complete skill game is because of the rake. Being consistently more skilled than your opponents at poker is not enough to make you profitable. You have to be skilled enough to also overcome the rake.
Let's say that in an ideal world, with no rake, I am skilled enough to win 5 dollars per hour. After introducing the rake, I could potentially lose 10 dollars per hour... putting me at a net loss. Even though I didn't change my playing style one bit. Overcoming the rake is a hard feat given that it is at least 10%. Over the long run, that is an incredibly huge amount of money. And you pay the rake regardless of whether you win or lose.
Being better than your opponent isn't good enough. You have to be skilled at maximizing profit. This is what most people don't understand.
I know very skilled players who win a lot of hands... but are losers... because they don't know how to maximize their winning value to surpass the rake.
Brainfuck.
Niris,
I have helped teach several people how to program. What you really need to next is apply what you have learned and solve a problem. Ideally, solve a problem that you know something about. Or solve a problem where you have some subject-matter expertise.
I'm not sure if you actually like being a security guard or not. Maybe you do. Maybe you don't. But you are probably familiar with the subject matter. Write a program that will solve a problem related to the subject matter. Using problems that are in operations research are really good ones. For example, a problem I might give you:
Security Scheduling Program for a Business
Purpose
The program should create the optimum shift schedule for a week -- guarding a business 24 hours a day.
Requirements
1) The program must allow for the user to input the number of available security guards.
2) The program must print out the shifts for each security guard.
3) No shift schedule can be over 8 hours long.
4) No security guard can work more than four days in a row.
5) All guards must be used in the schedule.
6) Each guard must have a 30 minute lunch and two 15 minute breaks each day.
7) During a break or lunch period, another guard must cover the watch.
8) If any of the constraints cannot be met -- given the number of guards available -- then the program should indicate that more guards are needed.
This problem is just an example of an operations research problem -- finding optimality. If you don't like this problem, you can make up another one. Or do a search on the internet. The idea is that you find a problem to solve that you: 1) know something about and/or 2) have some interest in.
When first learning to program, the key isn't the language you learn. The key is proving that you can solve a real world problem using programming. Good luck to you.
Interesting. I've never heard the converse question... "When the manager comes in early, should the developers come in early?" But that's another topic...
The real question is "why would the manager stay?" Here are some possible -- one or more -- reasons:
1) Because the manager does not trust that the job will get done... "trust but verify".
2) Because the manager feels like it will gain him/her credibility with the team.
3) Because the manager feels guilty and wants to share in the pain.
4) Because the manager feels like it will give the bosses peace of mind during hard times.
I can't think of any other reasons. But it is important to say that usually, if a manager wants to stick around, it is for noble reasons.
My advice to developers, is that if reasons #2, #3, or #4 are any of the motivations for their boss to stick around... cut them a break. Even if #1 is also a reason.
The possessive form of "yall" is "yall's". Here is an example sentence.
"I saw the car outside and figured it was yall's."
"Yall's" is a contraction of Yours (all of yours).
In the northeast, a variation is "youze guys'es". In the deep south, another variation is "your'n".
Gotta love English.
One of the earlier posts talked about the difficulties around "too big to fail" or "to big to succeed". To me, this is where the concept of finding a Nash Equilibrium is critical.
To resolve this situation optimally, a means to an end must be found where all of the affected parties benefit the greatest as a whole. You can't simply issue a patent judgment and say "have a nice day, you have X days to comply". That might benefit i4i, but it really hurts a lot of other stakeholders in the system -- including consumers (who do you think will bear the cost of that judgment?). Like it or not, by the law, i4i deserves something for the infringement (if the court finds the patent valid).
However, this is where our legal system in the free market breaks down. You've got to make sure you can come to judgments where the market isn't overly harmed, but everyone gets a taste of what they deserve.
Your analogy is off. Let me restate it.
You don't need to have knowledge of engineering to engineer a bridge.
Likewise...
You don't need to have knowledge of programming to write a computer program.
Stop getting the wires crossed. Engineering != Programming. The two are completely orthogonal.
This is so well said.
You are exactly right. It does NOT matter at all who's fault it is.
The reality is, the manager has to address any kind of motivational issues. Regardless of the source of de-motivation. De-motivation kills individual productivity, team productivity, and can even sour an entire organization.
Uh, exactly. If you have an employer that uses terms like "self-motivated", "works smarter and not harder", "ability to work without direction"... et cetera.... RUN (don't walk) for the hills.
These are companies who have incompetent managers who delegate their own management responsibility to their workers.
Managers are supposed to actually serve a purpose.
I'd argue that you don't want to work for such a boss, then.
As a director of a software development organization, I won't be popular for saying this. But... it is your boss' fault. Not yours.
You simply aren't motivated. I want to slap the person somewhere in another post who said... "motivation comes from within". It *rarely* comes from within.
When one of my managers or peers comes to me and complains about "unfocused" or "unmotivated" employees, I tell them to get off their collective ass and motivate their team or their employee. Psychologically, as an employee, you should feel driven by your surroundings to achieve a goal. That feeling should be driven by your team, your boss, your organization.
Being "self-motivated" is the single, biggest path to burnout in existence. Don't even begin to blame yourself.
Here is what I would recommend. Go to your manager. Tell your manager that you simply aren't feeling very motivated about the work you are doing. Have an open and honest conversation about it. You might be surprised. Your boss might actually bring some out some of the motivational mojo that you need. If your boss doesn't come through for you, then think about going to another organization.
But don't quit programming. You probably love it and you probably are pretty decent at it. You just need to be motivated, that's all.
I am a Democrat, and while I think the Mike Huckabee is a complete idiot on the great majority of his stances, I think his income tax abolishment and consumption tax proposal has great merit.
All we need to do is increase the state sales tax rate by the amount of the consumption tax. Then, the state can make tax payments to the federal government. No more income tax. Take a tax whenever money is exchanged for goods or services.
This means that we get all of the tax revenue when illegally acquired revenue gets spent. We also get federal tax revenue from visiting tourists. We also (finally) get the federal tax revenue from churches when they spend money. It also means that people who save (and not spend) actually get an immediate benefit by investing/saving.
Taxing income is moronic. There's too many ways to dodge it, too many ways to loophole it, too many ways to deduct it, too many ways to make exceptions.
Make it fair for everyone. Charge federal tax at the cash register.
This theory breaks when the person who uses the bomb doesn't care about their own destruction. Once you stop caring about retaliation, all bets are off.
It isn't when the person doesn't care. It is when the entire chain of individuals responsible for launching the nuke doesn't care.
This is why MAD works. If MAD was in the hands of any one individual, it wouldn't work.
Even if a crackpot leader wanted to launch a nuke or some other WMD, they couldn't do so if their subordinates couldn't be convinced to follow the order. I'm fairly certain that crackpot leaders have wanted to push the button in the past -- and were rebuked. You are naive if you think this situation hasn't occurred before.
I'm not worried one bit about North Korean or Iranian leaders and their grandstanding.
What does worry me is that world leaders don't do enough to understand and address the motivation behind this grandstanding.
Wow, what amazing genius.
What we have is an MIT CS dork who is bringing everything full circle and realizing that actually rotation, movement, and proximity are important factors in a human-to-machine interface.
NO SHIT SHERLOCK.
Is this really that ground-breaking? My god. Ever see a music mixing board? Ever see a keyboard synthesizer? Ever see a hifi music component? Ever see a car? Ever see a door? All of these machines have knobs, sliders, buttons, handles, and a brain which can alter the behavior of the machine based on the combinations of positions of knobs and sliders and buttons.
So this guy is asserting that these concepts are going to introduce a new and innovative way that humans interact with machines? GIVE ME A BREAK.
Perhaps next, he should create a new tool called a "roundling" which looks exactly like a tire and will revolutionize the way that humans move from one place to another.
I have to say after reading this article -- Stroustrup is a tool. It is just that simple. Nothing more than a pundit at this point. He had a stroke of genius in programming and now is an expert in everything related to programming.
He thinks companies aren't happy with their graduates? Well, I say companies have terrible hiring practices, terrible mentorship programs, and ridiculous expectations.
Balance the theoretical and the practical? Wow. Brilliant observation. Great, Bjarne. Please give us more sweeping Karate-Kid style one-liners.
High schools should teach students to work hard? Great, Bjarne. Thanks again for that. Search out information as needed? Another stroke of brilliance. Express ideas in writing and verbally? WOW. PINCH ME. Such genius can only be dreamed of.
Then, the article closes with him trying to be edgy and go out "with a bang". Sloppy, fat geeks. Nice. This guy is a douchebag. Pure and simple.
Here is my own contribution to douchbaggery... I think we should take aging, isolated, self-important pundits out into a remote area and bury them neck deep in the dirt.
This kills me every time I see it. I was just talking to a co-worker about this yesterday. We were doing some campus recruiting and this subject came up.
I run a software development organization now, but back in the day, I held a similar stereotype about "QA"... until I had to actually be responsible for quality.
QA is as much a science as art. Being a good tester takes skill, excellent understanding of the area being tested, an understanding of use-cases, understanding of likely vs. non-likely failure points, and how to truly measure quality itself. It requires (usually) a medium to high level of IT admin knowledge. In some cases (such as hardware)... the best testers are true engineers... EE(electrical) or CE(computer). Most test automation QA people are actually coders who know how to write software and do it every day.
I realize that there are lots of flighty "button clickers" out there. But there are equally as many "code monkeys" who write garbage code.
I wish QA would stop getting this bad wrap. Testing a complex piece of software (or hardware) is equally as tough as creating it.
If you are looking to use QA as a stepping stone into software development, I urge you to reconsider. You can rise into the ranks of a QA organization and easily make 100k a year... just doing testing.
All Computer Engineers are qualified 'software engineers' though.
It depends on the kind of software engineers you are talking about. Firmware engineering? OS engineering? Yeah, sure.
Business software engineering? Not a chance in hell. CS grads are WAY more qualified in that arena.
Which brings up an important point. Maybe the OP needs to go look for a job at a place such as Motorola, HP, Cisco, or the like. Those folks hire CEs all the time. But if the OP is trying to find a job at a commercial/business software company, then he's looking in the wrong place.
If I had mod points, I'd mod this up as insightful.
The OP is either the unluckiest guy in the world, or is being rejected for very legitimate reasons.
The OP should take a very close look at himself. I would recommend the following:
1) Ask friends or acquaintances -- who are software developers -- to give you a mock interview. After that, have them give you an objective appraisal.
2) Go get certified in something to do with software development. Computer engineering has little overlap with software engineering. Taking a certification is going to give you a clue as to what you are missing. Plus, it will give your resume a (little) boost.
Going from technical support into R&D is a tough move. But you need to get the advice and direction from people in the business that you trust.
Remember, if you want a different result, then do something different. Seek counsel and advice.
This group of doctors is solving a problem that might yield a small amount of additional expected value over commercially available limit poker bots.
This group of doctors IS NOT taking on the problem of sitting a computer down at a table of 6 or 7 no-limit/pot-limit professionals -- and having the computer win. Why? Because they can't solve it.
A computer sitting down at a no-limit table, surrounded by pros, would be pounded into playing only the highest value hands. Because it would "learn" that the only way it could predictably win is to play those hands.
Hell, the best no-limit computer/bot out there would be one that doesn't even consider its own cards. The best no-limit bot would simply pick a hand it wanted to represent at the beginning of each hand... and then play each hand as if it actually had those cards.
At least then it would be closer to a professional level of play.