How Long Will Programmers Be So Well-Paid?
-
I just recently had my share of interviews. Let's look at it from the other perspective. Becoming a code monkey is the last thing I would want and during the interview I try to find out what they are looking for. When they just keep asking questions about rules, best practices or standards, then they probably want a code monkey. Code monkeys do not need to know why they are doing something. They just have to know the rules and use them to do what they are told. Things usually get interesting for me when they start to ask questions which require understanding, not mindless devotion to rules and standards.
CDP1802 wrote:
during the interview I try to find out what they are looking for
Sometimes they only have a vague idea about what that really is.
CDP1802 wrote:
Code monkeys do not need to know why they are doing something. They just have to know the rules and use them to do what they are told.
Now, that is a recipe for disaster - and far too common. When you're about to instruct the worlds most efficient idiot - which I think aptly describes a computer - it certainly helps that you know the why of things. If you don't understand it, how can you model and implement it?
Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra
-
CDP1802 wrote:
during the interview I try to find out what they are looking for
Sometimes they only have a vague idea about what that really is.
CDP1802 wrote:
Code monkeys do not need to know why they are doing something. They just have to know the rules and use them to do what they are told.
Now, that is a recipe for disaster - and far too common. When you're about to instruct the worlds most efficient idiot - which I think aptly describes a computer - it certainly helps that you know the why of things. If you don't understand it, how can you model and implement it?
Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra
I already had that dubious pleasure and do not wish to repeat it. But that's what all that talk about 'standards' is all about. The developers are just better secretaries to do the typing. What they are supposed to type is dictated by the 'standards' and enforced by style checking tools. Understanding is not required. It's even unwanted, since it makes the people ask awkward questions instead of being 'productive'. And you can probably guess what happens when such a team runs into problems. They can't even start to deal with them, because they went through all the motions and rituals in the 'standardized' way which magically should eliminate any problems beforehand.
-
I already had that dubious pleasure and do not wish to repeat it. But that's what all that talk about 'standards' is all about. The developers are just better secretaries to do the typing. What they are supposed to type is dictated by the 'standards' and enforced by style checking tools. Understanding is not required. It's even unwanted, since it makes the people ask awkward questions instead of being 'productive'. And you can probably guess what happens when such a team runs into problems. They can't even start to deal with them, because they went through all the motions and rituals in the 'standardized' way which magically should eliminate any problems beforehand.
CDP1802 wrote:
Understanding is not required. It's even unwanted, since it makes the people ask awkward questions instead of being 'productive'.
I think I can sympathize with this :laugh: It's usually best to just leave them to it (and perhaps run for the hills). Awkward questions should be on the table as early as possible, but that might not be practical because we just landed the deal, sales is happy, management is happy - please don't ruin the mood. Good developers are really, really hard to find - and defining what actually makes a developer good is pretty hard too, it's just that some of the biggest companies in the industry has worked very hard to sell the concept of outsourcing/offshoring - which is based on a fundamental untruth about architecture and systems development: You can just hire a head.
CDP1802 wrote:
dictated by the 'standards'
Seems you are talking about the kind of coders that can, and perhaps should, be replaced by code generators.
CDP1802 wrote:
when such a team runs into problems
Oh, you mean blame shifting ;)
Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra
-
CDP1802 wrote:
Understanding is not required. It's even unwanted, since it makes the people ask awkward questions instead of being 'productive'.
I think I can sympathize with this :laugh: It's usually best to just leave them to it (and perhaps run for the hills). Awkward questions should be on the table as early as possible, but that might not be practical because we just landed the deal, sales is happy, management is happy - please don't ruin the mood. Good developers are really, really hard to find - and defining what actually makes a developer good is pretty hard too, it's just that some of the biggest companies in the industry has worked very hard to sell the concept of outsourcing/offshoring - which is based on a fundamental untruth about architecture and systems development: You can just hire a head.
CDP1802 wrote:
dictated by the 'standards'
Seems you are talking about the kind of coders that can, and perhaps should, be replaced by code generators.
CDP1802 wrote:
when such a team runs into problems
Oh, you mean blame shifting ;)
Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra
Espen Harlinn wrote:
Oh, you mean blame shifting ;)
That's also a standard. You are supposed to do it as you are told and if it works the lead will take all the credit for his brilliant planning. When it fails, you are immediatly under suspicion of having violated the unfailing standards and should expect the inquisition. In case you get off the inquisition's hook, you still are guilty because you suddently are expected to think for yourself and should have foreseen the problem.
-
Espen Harlinn wrote:
Oh, you mean blame shifting ;)
That's also a standard. You are supposed to do it as you are told and if it works the lead will take all the credit for his brilliant planning. When it fails, you are immediatly under suspicion of having violated the unfailing standards and should expect the inquisition. In case you get off the inquisition's hook, you still are guilty because you suddently are expected to think for yourself and should have foreseen the problem.
I'll freely admit that on a number of occasions I've gone ahead and actually trusted a few people in the workplace - and looking back, I can't remember that anything good ever came out of it. Lessons learned: 1. Do things in writing - if it isn't written, it might as well never have happened. 2. If you're going to do something extraordinary, will it be worth the effort? If somebody really has f**ked up - make sure that it's well documented, that the initial effort is shot to **ll and that there is absolutely nothing worth saving - in other words make sure you get the freedom, time and funding to do things the "Right Way™". 3. Never assume that people around you understand what you are doing, and remeber that the original team will, if given the chance, stab you in the back. Logic seems to be that it wasn't their fault things didn't work out - somehow it was you fault, and besides you are making them look bad. 4. Make sure the project manager understands that his role is to facilitate your work, make sure the other team members understands their roles. Write down a plan, develop an architecture and make sure that the stakeholders agree that this is what they want/need. This is were standardized procedures has more than one point in their favor. This is the dark side of software development: Everybody wants to have their say; whether they know what they are talking about or not - and people are at their most dangerous when they don't.
CDP1802 wrote:
expect the inquisition
Always expect them to come knocking, and with a few procedures in place, it can even turn out to be a good thing.
Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra
-
I'll freely admit that on a number of occasions I've gone ahead and actually trusted a few people in the workplace - and looking back, I can't remember that anything good ever came out of it. Lessons learned: 1. Do things in writing - if it isn't written, it might as well never have happened. 2. If you're going to do something extraordinary, will it be worth the effort? If somebody really has f**ked up - make sure that it's well documented, that the initial effort is shot to **ll and that there is absolutely nothing worth saving - in other words make sure you get the freedom, time and funding to do things the "Right Way™". 3. Never assume that people around you understand what you are doing, and remeber that the original team will, if given the chance, stab you in the back. Logic seems to be that it wasn't their fault things didn't work out - somehow it was you fault, and besides you are making them look bad. 4. Make sure the project manager understands that his role is to facilitate your work, make sure the other team members understands their roles. Write down a plan, develop an architecture and make sure that the stakeholders agree that this is what they want/need. This is were standardized procedures has more than one point in their favor. This is the dark side of software development: Everybody wants to have their say; whether they know what they are talking about or not - and people are at their most dangerous when they don't.
CDP1802 wrote:
expect the inquisition
Always expect them to come knocking, and with a few procedures in place, it can even turn out to be a good thing.
Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra
Espen Harlinn wrote:
1. Do things in writing - if it isn't written, it might as well never have happened.
Now, you are just the sort of troublemaker as they considered me to be. Can't you just do as you are told and leave the thinking to those who know everything far better than you do? :)
Espen Harlinn wrote:
2. If you're going to do something extraordinary, will it be worth the effort? If somebody really has f**ked up - make sure that it's well documented, that the initial effort is shot to **ll and that there is absolutely nothing worth saving - in other words make sure you get the freedom, time and funding to do things the "Right Way™".
They will interpret that as an effort to disrupt the team and call you a selfish prima donna.
Espen Harlinn wrote:
3. Never assume that people around you understand what you are doing, and remeber that the original team will, if given the chance, stab you in the back. Logic seems to be that it wasn't their fault things didn't work out - somehow it was you fault, and besides you are making them look bad.
We were the original team, most of us misused as dumb code monkeys with two lights of wisdom overseeing the whole thing. It's hard not to look bad under those conditions.
Espen Harlinn wrote:
4. Make sure the project manager understands that his role is to facilitate your work, make sure the other team members understands their roles. Write down a plan, develop an architecture and make sure that the stakeholders agree that this is what they want/need. This is were standardized procedures has more than one point in their favor.
Yes, both our lights of wisdom were great at that. At least they were good at sitting in meetings, writing all kinds of documents for anybody but us and otherwise telling us to do what we are assigned. Follow the 'standards', that's all you have to know. My way to deal with it: Ask for more specifications, get sent away with some hand waving and some talk about the 'standards'. Protest loudly and predict issues that may come to bite us later, thus earning the title of troublemaker. Then I shut off the brain and followed their 'standards' to the letter. Often enough the predicted trouble happened, the inquisition found no deviation from the 'standards' an
-
Espen Harlinn wrote:
1. Do things in writing - if it isn't written, it might as well never have happened.
Now, you are just the sort of troublemaker as they considered me to be. Can't you just do as you are told and leave the thinking to those who know everything far better than you do? :)
Espen Harlinn wrote:
2. If you're going to do something extraordinary, will it be worth the effort? If somebody really has f**ked up - make sure that it's well documented, that the initial effort is shot to **ll and that there is absolutely nothing worth saving - in other words make sure you get the freedom, time and funding to do things the "Right Way™".
They will interpret that as an effort to disrupt the team and call you a selfish prima donna.
Espen Harlinn wrote:
3. Never assume that people around you understand what you are doing, and remeber that the original team will, if given the chance, stab you in the back. Logic seems to be that it wasn't their fault things didn't work out - somehow it was you fault, and besides you are making them look bad.
We were the original team, most of us misused as dumb code monkeys with two lights of wisdom overseeing the whole thing. It's hard not to look bad under those conditions.
Espen Harlinn wrote:
4. Make sure the project manager understands that his role is to facilitate your work, make sure the other team members understands their roles. Write down a plan, develop an architecture and make sure that the stakeholders agree that this is what they want/need. This is were standardized procedures has more than one point in their favor.
Yes, both our lights of wisdom were great at that. At least they were good at sitting in meetings, writing all kinds of documents for anybody but us and otherwise telling us to do what we are assigned. Follow the 'standards', that's all you have to know. My way to deal with it: Ask for more specifications, get sent away with some hand waving and some talk about the 'standards'. Protest loudly and predict issues that may come to bite us later, thus earning the title of troublemaker. Then I shut off the brain and followed their 'standards' to the letter. Often enough the predicted trouble happened, the inquisition found no deviation from the 'standards' an
CDP1802 wrote:
those who know everything far better than you do?
I think I'll quote Bjarne on this one: People who think they know everything really annoy those of us who know we don't It can hit both ways though, and most people really aren't all that interested. Developing good software is hard, and most people want "easy".
CDP1802 wrote:
They will interpret that as an effort to disrupt the team and call you a selfish prima donna.
If you can, make sure you are not part of "the team". If they want to fail, be all means, let them do so without your help.
CDP1802 wrote:
It's hard not to look bad under those conditions.
As you mentioned, sooner or later, inquisition comes knocking - if it's later, they are probably looking for blood - and your previously "awkward" questions may just be what they are looking for. Depending on the scenario, you could even do it the "Right Way™" on your own time - if the your company needs it bad enough, it'll be worth your while. Just make sure that this is not about revenge - so be careful to make sure that you get across that you did it with the companys best interest in mind - and that you gave the initial effort your best shot - something that will require a wee bit of documentation, and a certain level of presentation skills.
CDP1802 wrote:
they were good at sitting in meetings, writing all kinds of documents for anybody but us
That works for a while, but in the long run management will usually notice - it may take some time though.
Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra
-
"But why has the supply of good engineers remained so strained? We're talking about work that can, in principle, be performed by anyone anywhere with a half-decent computer and a decent Internet connection." R-i-i-i-ght. :) /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
Nish Sivakumar wrote:
hard to hire a good developer
What makes a developer a good developer?
Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra
Espen Harlinn wrote:
What makes a developer a good developer?
From the hiring company's perspective, a good dev is one that meets their expectations and requirements. It's not a one-shoe fits all situation here.
Regards, Nish
My technology blog: voidnish.wordpress.com
-
Hi Nish, I have lived in Chiang Mai over eleven years (in two installments, separated by five years back in the U.S.). The merit of that TechCrunch article is really "undermined" for me by the author's ridiculous statements about Chiang Mai, based on a visit of a few days: "... I’ve spend the last couple of days chilling out in Chiang Mai, northern Thailand, a city where you could live like royalty and save money while making merely half of Google’s average developer salary." The author is correct about the possible cost-of-living you can have here, depending on your relative frugality of life-style, being a fraction of what the cost of living (in a "non-poverty" lifestyle) in any great American, or European, city, or Singapore, or Hong Kong, or Taipei, etc., would be. Where the author is absolutely wrong is in his later assumption that cost-of-living is the primary driving factor in expat migration to Chiang Mai(there are many other factors, and the author shows no evidence he has any statistical basis for his statements about expat demography): "... has tempted thousands of expats who now live here" The author then goes on to form a hypothesis from his short stay in Chiang Mai: "... And their presence [he's speaking of expats in Chiang Mai] has sparked a possible explanation for this apparent paradox." The "paradox" which the author claims is a causal factor of what he perceives as a "skewed" distribution of skilled programmers, not just in Thailand, but in other countries: is absurd; a violation of at least two of the logical principles of inference. Another absurdity in the article is where the author mentions "Chiang Mai" along with "Bangalore," as if there were a "parallel:" "Instead you’ll advance to the point at which you’re reasonably happy with your paycheck, which studies indicate is about $70,000/year in America. (But much less in Chiang Mai or Bangalore.)" Chiang Mai, and Thailand, is an "absolute zero" in software development compared to India: to Bangalore; or Hyderabad; or Mumbai. There are very few expat programmers here. Only two companies of small size that I know of in Chiang Mai, where the owners are expats, and employees, in general, Thai. There may be out-sourcing "sweatshops" here in Thailand I don't know of, where crap-work is being performed: but, since average Thai mastery of English is so poor, compared to India, you can be sure there is no out-sourcing on-line voice-chat support industry here that can be compared to India, or other
Thanks Bill, I didn't think the article would be entirely accurate. I was specifically interested in how it's hard to hire devs these days as I've personally experienced just that in the past 4-5 years. Great post there though!
Regards, Nish
My technology blog: voidnish.wordpress.com
-
I found the author's comments so off-putting, I actually took the trouble to respond at TechCrunch. First time I've ever commented on a blog/article outside CP! /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
CDP1802 wrote:
those who know everything far better than you do?
I think I'll quote Bjarne on this one: People who think they know everything really annoy those of us who know we don't It can hit both ways though, and most people really aren't all that interested. Developing good software is hard, and most people want "easy".
CDP1802 wrote:
They will interpret that as an effort to disrupt the team and call you a selfish prima donna.
If you can, make sure you are not part of "the team". If they want to fail, be all means, let them do so without your help.
CDP1802 wrote:
It's hard not to look bad under those conditions.
As you mentioned, sooner or later, inquisition comes knocking - if it's later, they are probably looking for blood - and your previously "awkward" questions may just be what they are looking for. Depending on the scenario, you could even do it the "Right Way™" on your own time - if the your company needs it bad enough, it'll be worth your while. Just make sure that this is not about revenge - so be careful to make sure that you get across that you did it with the companys best interest in mind - and that you gave the initial effort your best shot - something that will require a wee bit of documentation, and a certain level of presentation skills.
CDP1802 wrote:
they were good at sitting in meetings, writing all kinds of documents for anybody but us
That works for a while, but in the long run management will usually notice - it may take some time though.
Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra
Espen Harlinn wrote:
Developing good software is hard, and most people want "easy".
Much worse. They want it to work perfectly, even if they asked for some miracles. And they want to have it yesterday, for free if possible. They want it easy? A good way would be to use the team's experience and listen when somebody wants more information or sees a problem. That's what the scrum meeting is for, and not some kind of morning prayer which is treated as a ritual where everybody lies to the others about how happy he is.
-
Espen Harlinn wrote:
What makes a developer a good developer?
From the hiring company's perspective, a good dev is one that meets their expectations and requirements. It's not a one-shoe fits all situation here.
Regards, Nish
My technology blog: voidnish.wordpress.com
Nish Sivakumar wrote:
It's not a one-shoe fits all situation here
No, definitely not, but I feel it's an increasingly important question - even if it's impossible to provide a good answer. The skills we have differs wildly - and they are mostly aquired after leaving university, or whatever educational institution we've attended - and they are pretty hard to measure. We also, as a group, tend to get access to far more critical information than most people realize - which have aspects that's worth exploring.
Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra
-
Espen Harlinn wrote:
Developing good software is hard, and most people want "easy".
Much worse. They want it to work perfectly, even if they asked for some miracles. And they want to have it yesterday, for free if possible. They want it easy? A good way would be to use the team's experience and listen when somebody wants more information or sees a problem. That's what the scrum meeting is for, and not some kind of morning prayer which is treated as a ritual where everybody lies to the others about how happy he is.
CDP1802 wrote:
That's what the scrum meeting is for
I'm not sure scrum, or any other agile methodology, can be taught - it's what you may get after a significant period of time in a healthy workplace environment. The most fundamental ingreedient of any agile methodology is trust - and if that's not in place, it's just a futile exercise.
CDP1802 wrote:
morning prayer which is treated as a ritual where everybody lies to the others about how happy he is.
Not a happy situation - the morning meating is for raising and clarifying issues, determining actions and delegating resposibility - on a minor level. If you have major issues, they belong in another setting - perhaps a full project meeting involving all the stakeholders. If this isn't feasible, you're not doing scrum - just some bastardization intended to prove you're an agile organization. If the customers can't be brought into this, you - as an organization - really have a fundamental trust problem which in time will manifest itself in terms of a significant amount of trouble meeting expectations and requirements.
Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra
-
CDP1802 wrote:
That's what the scrum meeting is for
I'm not sure scrum, or any other agile methodology, can be taught - it's what you may get after a significant period of time in a healthy workplace environment. The most fundamental ingreedient of any agile methodology is trust - and if that's not in place, it's just a futile exercise.
CDP1802 wrote:
morning prayer which is treated as a ritual where everybody lies to the others about how happy he is.
Not a happy situation - the morning meating is for raising and clarifying issues, determining actions and delegating resposibility - on a minor level. If you have major issues, they belong in another setting - perhaps a full project meeting involving all the stakeholders. If this isn't feasible, you're not doing scrum - just some bastardization intended to prove you're an agile organization. If the customers can't be brought into this, you - as an organization - really have a fundamental trust problem which in time will manifest itself in terms of a significant amount of trouble meeting expectations and requirements.
Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra
I always called it a cargo cult. Blindly imitating some methodology without any understanding, degrading every part to a hollow ritual and expecting success to arrive by magic. And if its not successful, then that's obviously the doing of the unbelievers. SaR. Software as Religion.
-
I always called it a cargo cult. Blindly imitating some methodology without any understanding, degrading every part to a hollow ritual and expecting success to arrive by magic. And if its not successful, then that's obviously the doing of the unbelievers. SaR. Software as Religion.
CDP1802 wrote:
Software as Religion
Yes, we're seeing too much of that these days - and "Software Evangelist" has become a "respected" profession.
Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra
-
CDP1802 wrote:
Software as Religion
Yes, we're seeing too much of that these days - and "Software Evangelist" has become a "respected" profession.
Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra
-
Too bad. If any religious figure ever fit to me, then it would be the apostle Thomas. I always ask questions.
I'm off to a dinner party - t'was an interesting exchange - hope getting some of it off your chest helps, at least I've often found that it helps ...
Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra
-
I'm off to a dinner party - t'was an interesting exchange - hope getting some of it off your chest helps, at least I've often found that it helps ...
Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS Projects promoting programming in "natural language" are intrinsically doomed to fail. Edsger W.Dijkstra
-
I can't speak for other places but where I come from, programming isn't a popular profession and engineering degrees aren't easy to come by, (I'm from Norway). There are some universities which offer application development oriented degrees, but mostly its the title of engineer that get you the good salaries. But getting a Bachelors degree in computer engineering isn't just hard, it's only cream of the crop that get admitted in the first place. So though you have kids in their late teens dreaming of making their own software or games, they can't get in to the university programs due to grade requirements or not at a sufficient subject tier in math and physics. The result is that you have people with the drive and talent, but without any way to get into the job they want, they settle for something else. So if you ever come across someone with an IT Civil Engineering degree, (master's degree in engineering), from Norway, he or she will be the best of the best; but it leaves little opertunety for someone who'll settle for being a pure programmer. So I think that having programming as a vocation/profession track in high school, might be the solution, (this might not translate the way I mean it but it'll have to do), so that it's a professional skill easier to acquire. (engineering degrees need not be easier to get). that's my two cents worth! -frank
Frank Reidar Haugen wrote:
he or she will be the best of the best; but it leaves little opertunety for someone who'll settle for being a pure programmer.
You are saying that for some reason most or even all companies in Norway will only hire engineers to create programs? Is there a law that requires that? Or a cultural meme that requires it? Should note that it certainly isn't true in the US.
