I have a Brazilian boss, and I can claim overtime for answering e-mail from home, too...
Won't make a damn bit of difference in my paycheck, since I'm on salary, and we have the 70+ club for people who work 70+ hours a week - I think the club members got a T-shirt last year, or maybe it was a ball cap, anyway, all those hours over 40 sure are appreciated, hardly compensated at all, but appreciated.
When said bags come up missing it is a huge red flag to management that they have a thief employed in the chain. Might be what tipped the authorities off in Miami.
If it is the same Miami I used to live in, it was the corrupt TSA agents "tipping" the authorities with 10% of their take...
I might add that a number of people have written about another strategy for preventing "loss" of luggage or contents: Sending important/valuable luggage to your destination (typically a hotel) via any of the package delivery services (postal, FedEx, etc).
Yeah, they are so much better than baggage handlers:
Those elements in the TSA are a fucking embarassement to both their agency and their country; that behavior should not be tolerated, and this situation can be easily remedied with heavy penalties that will act as a warning to the rest of the TSA lot that is there to loot while in uniform.
Findings suggest that 76% of active criminals and 89% of the most violent criminals either perceive no risk of apprehension or are incognizant of the likely punishments for their crimes.
Different definition of popular. This is using it in the "most used" sense, not the "most liked" sense.
I'd say "most used" not "most useful," which sounds good but is a little off-target on the meaning. For a meaning targeted pair, I'd go with "most used" not "most efficient," or even better "most used" not "most universally applicable."
Liked is a subjective opinion, Objective-C and C# are objectively less portable than C++.
Yes. I've been trying for years to tell managers that the only reason that resources are so tight in the present is because they've been thinking that way in the past.
It's a valid point, but remember you are assessing with hindsight. I have actually lived through two catastrophic crashes where any effort expended for returns beyond the 3 month horizon would literally have been wasted. It is an unfortunate situation, and to be avoided if possible, but these things do happen.
What really bothers me is when the true horizon is 3+ years, but management continues to act like it is 3 weeks.
If you want worker protections, the first place you can start is by attaining a position of self employment. I've never had the discipline to save enough money to make that possible for me and my family, but if I had lived on 1/2 of my income instead of 9/10 for the last 20 years, I could "be my own boss" right now, with enough savings to get through the lean times and pick and choose my employers and make my own protections in the terms of employment.
Living on 1/2 my income for 20 years woudn't have been much fun, and working for "the man" isn't much fun, either. Pick your poision - or just be born to a top 1% rich family, that solves all problems.
Treat documentation as as valuable as code, and it will get done.
Who is it valuable to? When is is valuable to them? It is a complicated time-value of resources problem, and while documentation is very valuable when you need it, your time of need is a) uncertain, and b) in the future, both of which steeply discount its value (but not its cost) in the present.
Decisions are made in the present, and if resources are tight in the present, things of potential value in the future are discounted further.
Most of the time the problem doesn't lie with the developer. The developer who actively refuses to document is rare. In my experience, the real problem lies in managers not taking documentation seriously. It is caused by developers being under the stress of deadlines with a manager that really needs this piece of software to be finished yesterday. Managers just don't schedule in any time for documentation.
Roll it up the chain, the Manager's manager doesn't value documentation, they value product, as does the customer. Internal documentation is something with a payoff next quarter, or more often next year. When is the last time you heard of an American business strategy that involved taking more time to do something now so that you could take less time to do something next year?
The second half of the article, while not explicitly saying it, does suggest that if a person spends a little time learning to code they'll magically get an awesome ("high-paying", in the words of the author) job. This is a major oversimplification, at least. The author provides no convincing evidence that this is true, except for a quote from his CEO friend.
Supply and demand - I graduated in 1990 - starting coders were paid $30-35K, by 1995 you'd be lucky to be making $40K. Dot com hit, demand spiked up, kids straight out of my same university with my same degree were getting starting offers in the $70K range. With those offers on the table, supply soon increased, starting pay is more chaotic now, but mostly sinking back to that $30-40K range, even though cost of living is up significantly.
Magic koding skool koderz may get high-paying jobs for a little while, until there are a bunch of them on the market.
Stop reading the ads - work up some personal contacts and get a trial audition with somebody who needs somebody to do something. You just might surprise yourself with how competent you are.
Average users have a hard enough time even using software competently after a year's time. Let alone creating it.
Just think about many people still don't know how to find something simple like the control panel in XP after all these years...
I made $60 one night for an "emergency tech call" - the guy didn't tell me what was the problem over the phone, just that he needed my help. When I arrived, we talked about status of a few ongoing projects, but the only real reason for me to be there was because his sound output had stopped.
The volume control was muted (and visible as such in the task bar).
I've worked with plenty of people who had 5+ years of "experience" who perform at the competency level of a 1st year coder. Especially in very large companies I've found that the day-to-day tasks are usually designed to shield the employees from any apparent consequences of their own incompetence or any risk of becoming competent. Typically, 90% of the job is just being attractive and good-smelling enough that your co-workers can be nice to you without trying hard.
That's called stability. If you're going to grow a company, you want a stable structure that can hire (and fire) readily available people as needed to support the business' growth and contraction cycles. If you try to build a business out of top 1% best in class superstars, you're going to have one hell of a problem finding them in the first place, retaining them after you do get them, and getting them all to play nice together while you have them.
So, accepting the premise that, once you grow beyond garage-shop size (say 30 employees) roughly 1/2 of your new-hires are going to have an I.Q. below 100, how are you going to structure your system to get productivity out of them? It's even worse than that, since there are a lot of small businesses out there, and small businesses do tend to let the dolts go when times get hard because they simply can't afford to keep them around, what's available in the labor market is, on average, well below average.
Not saying that you'll never find a good candidate, just that it's kind of like gold mining in an iron-pyrite rich stream.
One of my pet hates are coders who love the art so much that they relentlessly strive for the next level of coding nirvana, re-factoring things that work perfectly well in the name of flexability, extensability, and support for things that may or may not ever come to pass.
You can increase the complexity of code to fulfill a specification by an order of magnitude by adding "API layers" to take a simple one-to-one problem and providing a many-to-many solution.
It's cool that you can think at that level of abstraction, but don't force us to all learn your made up language in the name of supporting things that aren't really there...
Hackers write code. Professional software engineers deliver business solutions. For the beginning professional software engineers out there, here's a tip : comment your code (and comment it correctly.)
Code tell you what. Comments tell you why.
For those attempting to "Level up" - Comments tell you why, but the story should be short and to the point. This is not a comment on how to comment, it is a comment on how to code. If the code needs a lot of explanation, it probably needs rethinking. If the code's comments are significantly larger than the specification they are fulfilling, there is something wrong. If the specification is incomplete or not present, you are not doing professional software engineering.
No, it says lean-to code. As in coding while in a lean-to.
I thought it was an analogy for making code like a lean-to, you know, slapped together with whatever material is at hand, resulting in a small, uncomfortable, difficult to improve structure that is poor protection from the elements at best, and likely to blow over in a stiff wind.
Not in the medical device industry, at least not the R&D branch... go into animal research (you know, cutting them open, inserting all kinds of invasive instrumentation in their brain, heart, liver, and what have you, running an experiment, and then killing them with an injection of KCl) that's where the girls are. There, and marketing.
The recognition that some people are better than others at certain tasks is not elitism, it is merely recognition of reality.
Elitism is the idea that those better people ought to rule over the other ones.
If I think that coders who know architecture, security, testability, and portability principles should be the ones who are advanced into management instead of the frat boys who made a website, am I being an elitist, or just unrealistic?
3) I'm currently dealing with a small handful of College trained, experienced developers who can't seem to code their way out of a wet paper bag which does not make me excited about the possibility of hiring someone who's programming knowledge is based on an online Java Script Tutorial.
This is nothing new. In the late 1980s I was a Teaching Assistant for a senior level Computer Engineering lab... each new batch of 30 about to be Baccalaureated Computer Engineers contained about 2 people I might consider worth hiring.
Slashdot Mirror
I have a Brazilian boss, and I can claim overtime for answering e-mail from home, too...
Won't make a damn bit of difference in my paycheck, since I'm on salary, and we have the 70+ club for people who work 70+ hours a week - I think the club members got a T-shirt last year, or maybe it was a ball cap, anyway, all those hours over 40 sure are appreciated, hardly compensated at all, but appreciated.
When said bags come up missing it is a huge red flag to management that they have a thief employed in the chain. Might be what tipped the authorities off in Miami.
If it is the same Miami I used to live in, it was the corrupt TSA agents "tipping" the authorities with 10% of their take...
http://boardingarea.com/blogs/flyingwithfish/2010/11/20/how-the-tsa-legally-circumvents-the-fourth-amendment/
Yet, Americans are sheep and will do nothing.
I wouldn't say that I have done precisely nothing... before 9-11, I flew an average of 6 times a year, perhaps once international and 5 domestic.
Since 9-11, I believe I have flown a total of 5 times, 4 domestic and 1 international, in 11 years.
I might add that a number of people have written about another strategy for preventing "loss" of luggage or contents: Sending important/valuable luggage to your destination (typically a hotel) via any of the package delivery services (postal, FedEx, etc).
Yeah, they are so much better than baggage handlers:
http://news.yahoo.com/viral-video-fedex-delivery-man-throws-computer-monitor-050009440.html
$2.49 is what they hand over (from, say, and average of 10 checkpoints, so $0.25 per checkpoint per day.)
How much do you think is actually being left behind? I'd guess closer to $0.25 every 10 minutes.
Those elements in the TSA are a fucking embarassement to both their agency and their country; that behavior should not be tolerated, and this situation can be easily remedied with heavy penalties that will act as a warning to the rest of the TSA lot that is there to loot while in uniform.
Heavy penalties, like hanging pickpockets?
http://aler.oxfordjournals.org/content/4/2/295.abstract
Findings suggest that 76% of active criminals and 89% of the most violent criminals either perceive no risk of apprehension or are incognizant of the likely punishments for their crimes.
legislation that would direct the TSA to transfer unclaimed money
You mean: legislation that would disincentivize TSA from collecting the money in the first place.
(and, instead, the money will wind up as "tips" for the checkpoint agents.)
Different definition of popular. This is using it in the "most used" sense, not the "most liked" sense.
I'd say "most used" not "most useful," which sounds good but is a little off-target on the meaning. For a meaning targeted pair, I'd go with "most used" not "most efficient," or even better "most used" not "most universally applicable."
Liked is a subjective opinion, Objective-C and C# are objectively less portable than C++.
Interesting how both Objective C and C# are walled garden languages - sure, they're both "open" but in reality, you use them inside walled gardens.
Yes. I've been trying for years to tell managers that the only reason that resources are so tight in the present is because they've been thinking that way in the past.
It's a valid point, but remember you are assessing with hindsight. I have actually lived through two catastrophic crashes where any effort expended for returns beyond the 3 month horizon would literally have been wasted. It is an unfortunate situation, and to be avoided if possible, but these things do happen.
What really bothers me is when the true horizon is 3+ years, but management continues to act like it is 3 weeks.
I prefer the theory that well developed code is it's own documentation.
Yes, it is. IME, most people who claim their code is well developed enough that it needs no documentation, are wrong.
Now, tell us how you really feel.
If you want worker protections, the first place you can start is by attaining a position of self employment. I've never had the discipline to save enough money to make that possible for me and my family, but if I had lived on 1/2 of my income instead of 9/10 for the last 20 years, I could "be my own boss" right now, with enough savings to get through the lean times and pick and choose my employers and make my own protections in the terms of employment.
Living on 1/2 my income for 20 years woudn't have been much fun, and working for "the man" isn't much fun, either. Pick your poision - or just be born to a top 1% rich family, that solves all problems.
Treat documentation as as valuable as code, and it will get done.
Who is it valuable to? When is is valuable to them? It is a complicated time-value of resources problem, and while documentation is very valuable when you need it, your time of need is a) uncertain, and b) in the future, both of which steeply discount its value (but not its cost) in the present.
Decisions are made in the present, and if resources are tight in the present, things of potential value in the future are discounted further.
Most of the time the problem doesn't lie with the developer. The developer who actively refuses to document is rare. In my experience, the real problem lies in managers not taking documentation seriously. It is caused by developers being under the stress of deadlines with a manager that really needs this piece of software to be finished yesterday. Managers just don't schedule in any time for documentation.
Roll it up the chain, the Manager's manager doesn't value documentation, they value product, as does the customer. Internal documentation is something with a payoff next quarter, or more often next year. When is the last time you heard of an American business strategy that involved taking more time to do something now so that you could take less time to do something next year?
The second half of the article, while not explicitly saying it, does suggest that if a person spends a little time learning to code they'll magically get an awesome ("high-paying", in the words of the author) job. This is a major oversimplification, at least. The author provides no convincing evidence that this is true, except for a quote from his CEO friend.
Supply and demand - I graduated in 1990 - starting coders were paid $30-35K, by 1995 you'd be lucky to be making $40K. Dot com hit, demand spiked up, kids straight out of my same university with my same degree were getting starting offers in the $70K range. With those offers on the table, supply soon increased, starting pay is more chaotic now, but mostly sinking back to that $30-40K range, even though cost of living is up significantly.
Magic koding skool koderz may get high-paying jobs for a little while, until there are a bunch of them on the market.
Stop reading the ads - work up some personal contacts and get a trial audition with somebody who needs somebody to do something. You just might surprise yourself with how competent you are.
Average users have a hard enough time even using software competently after a year's time. Let alone creating it.
Just think about many people still don't know how to find something simple like the control panel in XP after all these years...
I made $60 one night for an "emergency tech call" - the guy didn't tell me what was the problem over the phone, just that he needed my help. When I arrived, we talked about status of a few ongoing projects, but the only real reason for me to be there was because his sound output had stopped.
The volume control was muted (and visible as such in the task bar).
I've worked with plenty of people who had 5+ years of "experience" who perform at the competency level of a 1st year coder. Especially in very large companies I've found that the day-to-day tasks are usually designed to shield the employees from any apparent consequences of their own incompetence or any risk of becoming competent. Typically, 90% of the job is just being attractive and good-smelling enough that your co-workers can be nice to you without trying hard.
That's called stability. If you're going to grow a company, you want a stable structure that can hire (and fire) readily available people as needed to support the business' growth and contraction cycles. If you try to build a business out of top 1% best in class superstars, you're going to have one hell of a problem finding them in the first place, retaining them after you do get them, and getting them all to play nice together while you have them.
So, accepting the premise that, once you grow beyond garage-shop size (say 30 employees) roughly 1/2 of your new-hires are going to have an I.Q. below 100, how are you going to structure your system to get productivity out of them? It's even worse than that, since there are a lot of small businesses out there, and small businesses do tend to let the dolts go when times get hard because they simply can't afford to keep them around, what's available in the labor market is, on average, well below average.
Not saying that you'll never find a good candidate, just that it's kind of like gold mining in an iron-pyrite rich stream.
Judging by my experience as a regular software user, lousy and uninspired software is exactly what companies want.
Its all they want to pay for.
One of my pet hates are coders who love the art so much that they relentlessly strive for the next level of coding nirvana, re-factoring things that work perfectly well in the name of flexability, extensability, and support for things that may or may not ever come to pass.
You can increase the complexity of code to fulfill a specification by an order of magnitude by adding "API layers" to take a simple one-to-one problem and providing a many-to-many solution.
It's cool that you can think at that level of abstraction, but don't force us to all learn your made up language in the name of supporting things that aren't really there...
Hackers write code. Professional software engineers deliver business solutions.
For the beginning professional software engineers out there, here's a tip : comment your code (and comment it correctly.)
Code tell you what.
Comments tell you why.
For those attempting to "Level up" - Comments tell you why, but the story should be short and to the point. This is not a comment on how to comment, it is a comment on how to code. If the code needs a lot of explanation, it probably needs rethinking. If the code's comments are significantly larger than the specification they are fulfilling, there is something wrong. If the specification is incomplete or not present, you are not doing professional software engineering.
No, it says lean-to code. As in coding while in a lean-to.
I thought it was an analogy for making code like a lean-to, you know, slapped together with whatever material is at hand, resulting in a small, uncomfortable, difficult to improve structure that is poor protection from the elements at best, and likely to blow over in a stiff wind.
And there are more girls in biology.
Not in the medical device industry, at least not the R&D branch... go into animal research (you know, cutting them open, inserting all kinds of invasive instrumentation in their brain, heart, liver, and what have you, running an experiment, and then killing them with an injection of KCl) that's where the girls are. There, and marketing.
The recognition that some people are better than others at certain tasks is not elitism, it is merely recognition of reality.
Elitism is the idea that those better people ought to rule over the other ones.
If I think that coders who know architecture, security, testability, and portability principles should be the ones who are advanced into management instead of the frat boys who made a website, am I being an elitist, or just unrealistic?
3) I'm currently dealing with a small handful of College trained, experienced developers who can't seem to code their way out of a wet paper bag which does not make me excited about the possibility of hiring someone who's programming knowledge is based on an online Java Script Tutorial.
This is nothing new. In the late 1980s I was a Teaching Assistant for a senior level Computer Engineering lab... each new batch of 30 about to be Baccalaureated Computer Engineers contained about 2 people I might consider worth hiring.