You've provided a good example of why using the grouping "IT Job" is worse than useless.
On the one hand, you have companies struggling to hire software developers because of massive shortages in certain geographic or skill areas. On the other, cloud hosting technologies with decent tools for bringing up and connecting servers (think AWS) have reduced the need for whole classes of jobs, leading to network engineers and sysadmins seeing opportunities disappearing.
Talking about "IT Jobs" just leads to a lot of people shouting past each other.
If it isn't prying, what are your skills?
Speaking out of my own experience, I run an engineering group, and it's ridiculously hard for me to find good people. We aren't biased against Americans (nor, and you may not like this, are we biased for them), and we take a lot of trouble to make sure that the compensation we offer is in line with (or higher than) the rest of the industry. But, honestly, it's pretty rare for a top-notch person at any level of skill... even relatively junior... to respond to our job postings or recruiter, and then it's even more rare for us to manage to hire them away from the dozens of other great offers they're getting.
When I talk to other hiring managers in the area, I hear the same thing over and over. Too many jobs chasing too few good (or even not-good-but-could-be-mentored) candidates.
Thus my curiosity about your skillset.
(As an aside, I want to say that we do hire H1-B candidates, and that it's a point of pride for me that we pay them fairly and in line with anyone else who would have that job. I don't want to use their immigration situation to wring every last dollar from them. I'd rather that they were happy, and kept working for me because they liked it or were learning something.)
I have to say, you'd really hate trying to get a job if I were the hiring manager; I always give two rounds of technical questions.
The first is a take-home test, where you can use whatever resources the world and its internet provide to you. I email it to you, I expect you to email it back in an hour. It's a wide range of questions from simple coding exercises to complex problems that can't be solved in an hour. Getting some measurement of technical skill (and your ability to research) is only one part of what I'm trying to do here. More critically, I want to see if you can triage work, and identify what you can and can't accomplish in an hour; that skill is as valuable as knowing any language.
I'm also looking to see if the harder problems interest you. I think they're mildly cool, I'd like to hire someone who does too.
At this point, about 2/3 of the interviewees disappear from the process. They reply saying that they decided they were unqualified, they reply saying they didn't have time. Once, they replied that they were insulted that I would question their resume. In any case, without even spent 60 seconds of my time on a phone screen, I've narrowed the field to people who at least have basic coding skills and aren't offended that we might feel they should prove themselves.
Then, when the person comes in for an interview, I like to have them write some code on a whiteboard. I start with a simple problem, and start adding requirements as they go along. I want to understand what they're like to work with, how they handle changes in requirements, how they write code to be change-tolerant. I also want to see what they're like under stress; do they seem like a culture fit? Are they enjoying the challenge?
At the end, I will know a lot more about a person than if they have basic skills or not. I will have seen them in action, gotten a sense for how they solve problems, and understand a bit how they might work with me and other people on their potential new team.
You may not like the fact that I want to know these things, but they're important to me.
That's an interesting (albeit debatable) definition of lying. I won't disagree with it, but I will disagree with one of your other statements:
I think it is the Presidents right to select who he works with
That may be true for some of the President's advisors, but it certainly isn't true for the Secretary of Defense. As a member of the cabinet, the Senate has the responsibility to "advise and consent" on his appointment. So it's quite clear that the President doesn't have the absolute right to work with whomever he wants in this case, and that there is legislative oversight.
Seeing as there is legislative oversight, and seeing as the statement was made right before a legislative election, it is clearly an issue for the voters to be appropriately concerned about.
If you're working in Java, you should add assertions to your toolkit. You don't just preserve the institutional knowledge about where the code gets hairy, but you preserve institutional knowledge about what the internal state of the application is supposed to be.
What's especially potent is that you don't actually need to comment the assertions out : leave them in your code, so that downstream users can activate them and confirm that there's nothing broken in your code. There's no performance hit when they don't ask for them, and if you're writing code for others to incorporate into their apps, you've just given them a powerful support tool.
This is why configuration driven logging (like log4j) is such a leap over commented in/out println() statements : you can use them outside of your own development environment. Your customers, be they other developers or end users, can get an insight into how things are failing, either to diagnose problems for themselves, or to generate a report for you, so that you can find out what's going wrong for them.
OSRM is giving you something almost as good as black and white... they're giving it to you in green.
They're so confident of their claim, that they're willing to put their money where their mouth is.
In any case, what specifically would you want to see? All of the source code of all the operating systems they looked at with check marks next to each line? And who would you choose for an independant third party?
To be fair, not all managers are like this. Some managers do their best to create bubbles of sanity and stability, to allow their teams to do the very best work possible. The best of managers will recognize that the largest part of their job is to be a drama sponge... absorb the drama radiating down, dampen the drama radiating up, and shield their team to let them get work done.
However, what can a manager do when a project or organization starts to underperform? Too frequently, managers will attempt to improve performance by "shaking things up". They think "Okay, after one more reorganization, then things will be right." or "Well, if we put this process into place, it will be perfect."
The problem is really that management is as much an art as writing code or designing systems. There are a lot of people out there who can do it when the problems are normal, when the future is well understood. Unfortunately, most of them respond in counterproductive ways when confronted with crisis and uncertainty.
In short (too late!), it isn't that managers look for ways to stop people from being "happy, content, secure" out of spite. It's just that they're trying to do something, anything to make things better. They flail, and things get worse.
This assumes that fresh ideas and new ways of doing things have value. The only real values (IMO) are :
Does the system solve the problem?
Can the system be maintained?
Can we get more value out of the solution beyond solving the original problem?
And that's where 10 years of experience brings more value.
Two years of experience brings you competence in your toolkit and exposure to a few development lifecycles.
Ten years gives you an arsenal of already solved problems from which you can borrow ideas, an understanding of how problems interrelate across broader domains, and an awareness of out-of-scope and future problems that can be solved (or have the groundwork laid, to simplify solving later) with easier up-front work now.
I guess my response to the manager would be : not every developer with 10 years of experience should be an architect, because frequently that converts a happy developer into an unhappy architect. However, 10 years of experience gives you a developer who can think architecturally, and that's something you won't get from someone with only 2 years under their belt.
Go to http://www.real.com. Click on the download link. You'll get a page where the right two thirds is trying to get you to download the for-pay player and the right third is a link to download the free player.
Click on that download link on the right side of the page.
I had a problem answering the questions because I maintain two codebases : one I develop for my employer and one that I develop for open source, myself, my friends.
I am perfectly okay with the idea that my employer owns the former and that I can't treat that as a portable code library, and they're perfectly okay with me including my code library's code in their products, as long as my license (the BSD license, as it turns out) allows it with minimal encumberance.
It can complicated to decide which base I'm writing the code for, but I typically use the rule that if I'm in the office it's theirs, and if I'm at home it's mine. I write in Java, so I use package names to further delineate which is which.
Everybody wins this way : they get more code, I get code that makes my life easier throughout my career.
In the last three months, more than 40 percent of the unemployed have been out of work more than 15 weeks. That's the worst number since 1983.
According to the monthly payroll survey for January, jobs rose by 112,000. Before you start cheering, that doesn't actually keep up with population growth.
Since the recovery officially began in November 2001, employment has actually fallen by half a percent, while the working-age population has increased about 2.4 percent.
All of these facts (with more available) come from Paul Krugman's
editorial in the NYT today. His column should be required reading for anybody who wants to talk about the economy.
Re:Sun Should Embrace and Extend
on
How C# Was Made
·
· Score: 5, Insightful
I've been following the 1.5 release pretty closely for a while now, and it has some excellent additions. I'm especially pleased with the generics, the enumerated constants, the ability to define a method as accepting an undefined number of parameters, and the improved monitoring. The amount of code I'll be able to remove from my codebase will be large.
However, that doesn't invalidate what I said initially.
1.5 isn't a response to C# (well, maybe the enumerated types are), but seems to be kind of orthogonal to C#. It is a distinct improvement to the language, but that isn't the same thing as "embrace and extend". Those improvements don't give Java evangelists the ability to say "The C# language has no good feature that Java doesn't."
I'm also making an argument about intellectual honesty. Java (like any other piece of software) will never flower into its full potential unless the people who believe in it are willing to acknowledge the strengths of its competitors, and then adopt those strengths where it can.
It isn't a sign of weakness to do that, but a sign of strength.
Sun Should Embrace and Extend
on
How C# Was Made
·
· Score: 5, Insightful
It's very easy for Java devs (and I'm one) to sneer at C# as just another MS ploy to lure people away from quality, but I think that there's no question that C# has some language features that should be migrated into Java.
It's well known that the C# designers paid a lot of attention to Java, but more importantly, it's also quite clear that they also spent a lot of time paying attention to the experience of developing in Java.
So while I might not entirely agree with the uncaught exceptions or the way methods aren't virtual by default, I do think it would be a good idea for Sun to take the lesson from MS, and take what is best about C# and move it into Java.
I can agree with you up to a point... adding more diversity and security to key points in a network will have a protective effect well beyond the effort that's put into securing those nodes. However, if you stop there, you have an extremely brittle security model. A few compromises, and the whole system is now vulnerable.
Instead, you need (to extend a metaphor) to add "herd immunity" to your network. Not every machine needs to be absolutely immune to assault, but if a large enough portion of your network has some immunity, your whole network is "immune enough" to prevent major compromises.
The goal, IMO, isn't to prevent security breaches, but to block the easy ones and mitigate the hard ones. To only plan for the success of a few points in your fabric is disastrous...
I realize that you were doing a little pro-Python trolling (the hyperbolic "1000%" and the inference that only "mediocre" developers would be more efficient with Java), but I would be interested in you had any references or evidence that backed your number up.
All I can provide, unfortunately, is anecdotal evidence, and a little bit of theory. As a lead developer for a medium sized team of highly skilled developers, I find that many areas criticized by Python proponents actually contribute to a better development environment.
For example, Java's static typing vs. Python's dynamic typing. While there is no question that many keystrokes are saved by Python's dynamic typing scheme, there is also no question for me that static typing makes it generally easier to understand and follow code that I'm reading (by providing more information up front), and eliminates certain classes of logic errors from code that simply won't show up from a straight compile. This simplifies code reviews, transitioning code from one developer to another, and gives code longer shelf-life.
The same logic follows for Java's exception model (it certainly makes it easier to see when code is inappropriately swallowing an exception), and even for the general verbosity of the language as a whole. It makes it easier (again, the "for me" caveat should be assumed) to review the code of other developers, to follow that code, to transition that code.
So that's some of my anecdotal evidence. Now here's my theory : when developing large and complex pieces of software, writing the code is the cheapest and simplest part of the process. Extra keystrokes (given how good most IDEs are) are unimportant. What's critical is how quickly other developers can understand, review, modify, debug, and/or replace your work. The more information your code provides to those developers, the more detailed that information is, the better. Yes, it's a nuisance to chain together all of the decorators to open a file to read (buffered) characters, but it's very clear to other devs exactly what you're doing. Clarity is my goal, and the language that provides the most clarity to other developers is that language that I will prefer. Right now, in a comparison of Python to Java, I believe that language to be Java.
So I solved it by setting up two separate computers. One's my "work box" with my editors, shells, DB clients, etc. The other is my "communications box" with my email client, IM client, calendar, IRC clients, etc. Once I turned off all the alarms/alerts on the latter (except for the calendar), and once I made it so that I couldn't see the latter except by switching over to that box, my efficiency (and job satisfaction) skyrocketed.
Initially, it made me less available and less responsive, and that bothered me. However, my work habits started to change in response to it. Because I now control my exposure to communications, I find that I can flip to the other box, scan for messages, and flip back to my work box without exiting the flow state.
This has had some other really positive side effects. For example, people are aware that I'm in my office, even if I'm not responding to IM. That means that if something's really important, they'll often just drop by, replacing the thirty back-and-forth email with a simple 5 minute conversation. Sure, I lose my flow state, but high priority problems bubble up to the top of the list and get resolved in the most effective way (ie; face to face) possible.
While it's true that this can be a significant advantage to writing your own platform, the costs of maintaining and extending it can be high enough to kill your products.
The platform, after all, pays no bills, gets no clients, makes no sales. It's all overhead, and it's a constant drain on internal resources. Even if you decide to just let the code sit, it's a drain on your attention and something that requires the retraining of every new coder, tester, tech writer, employee.
Furthermore, the skills required for building and maintaining a platform tend to be different from those required to build on top of one. An organization that chooses to do both must be substantially larger, and must accept a certain loss of efficiency as some developers and development effort gets locked into the platform.
On the other hand, you get a heavy, early boost from building on top of an already ready platform, and you get the advantage of other people's incremental improvements to that platform without your team lifting a finger.
The buy-vs-build (or download-vs-build in the case of the free platforms) calculation isn't - and shouldn't be - a strictly technical decision. Every developer believes that they can do it better, given enough time and resources. This ignores the fact that time and money and bodies are always in short supply, and that there are significant advantages to "doing it like everybody else" (not least of which is that you can hire people and have them working the next day).
That's an overestimation of the powers of project management.
A project can be managed competently, or even well, and it can still go poorly. Things go wrong, the team can't respond to events quickly enough, dependencies fail, assumptions turn out to be false.
None of these are signs of a poorly managed project (though a well managed project can accomodate some amount of this), but it still happens.
Putting hyperbole aside, the truth is somewhere in between "Project managers are incompetent hacks." and "A good project manager is worth a dozen engineers."
If a project is going poorly, replacing twelve good developers with one good project manager won't advance the project one iota if the project is already being competently managed. Conversely, if you already have enough developers on a failing project, adding twelve good engineers and removing a good project manager isn't much of a save either.
To try and establish some kind of mapping between the two is absurd. It's like saying "An axle is worth a dozen engines!"; the car isn't going to go far if you're missing either set of skills. If a project is lacking project management, you need more project management. If it's missing engineers, you need more engineers.
Part of what leads to these sorts of statements, of course, is that neither skillset is easy or readily understood by either side of the debate. Coders don't understand how hard it is to do good project management (mostly because they're typically exposed to the lousy sort, and because you can always muddle your way through). Project managers often have no insight into what it takes to design and build good code... and they rarely understand that "good code" has important features that "code that satisfies the specifications" does not.
To compound the misunderstanding, they see that there's one project manager and a dozen developers and they think that they're worth a dozen developers. It's a fairly typical management error.
Ideally, project managers would all have heavy coding experience, and every developer would have project management training. If they don't, then it's up to the experts on both sides to educate across the aisle. If your project manager doesn't get it, it's your fault for not taking an hour to explain it. And if you don't understand why the project managers do what they do, try asking about the process they use to put together a project plan, to do resource balancing, risk amelioration planning, cross-team scheduling, and the like.
If the customer is unhappy, and it's your fault then it's your fault.
If the customer is unhappy, and it isn't your fault, it's still your problem. Frequently, they're unhappy about something other than the problem they're nattering on about and it's your job to figure out what and where the real problem is and fix it.
In practical terms, this means staffing your customer support team so that they can spend time with your customers working through their issues. Don't punish them for spending more time on the phone with the customer. Make sure that there's an easy flow of information from customer support to your engineers, and vice versa.
Also, have a short, easy to understand employee handbook that lays out rules that aren't stupid. Don't make your employees guess what the dress code is, don't make them ask what the comp time arrangement is... and if you don't pay your salaried workers overtime, you better have a comp time plan.
This doesn't have to be complex, this doesn't have to be 40 pages long. It's not ethical (in the sense that it isn't fair) to not lay out your expectations in advance, or to make people guess.
Seattle (and West Coast) accuracy is always going to be lower than you'd like (and lower than the East Coast's, for example) simply as a result of fewer observations.
The rest of the nation gets to see weather data from thousands of weather stations as patterns move from West to East, while Seattle gets its (relatively) skimpy data from satellites and scattered ocean stations.
It's precisely this attitude that has led to IT losing respect within organizations, and getting outsourced. An in-house IT department has some natural advantages, if only it exploits them : you have your customers in front of you, you can talk to them, find out what they need, find out where your services are needed, and find out where you're getting in the way.
If an IT group is unwilling to adapt itself to the organization that it's in, if an IT group is unwilling to adapt itself to the needs of its customers, if an IT group is unwilling to scale themselves up or down to an appropriate size... well, that's an IT group that essentially deserves to be outsourced.
Slashdot Mirror
You've provided a good example of why using the grouping "IT Job" is worse than useless.
On the one hand, you have companies struggling to hire software developers because of massive shortages in certain geographic or skill areas. On the other, cloud hosting technologies with decent tools for bringing up and connecting servers (think AWS) have reduced the need for whole classes of jobs, leading to network engineers and sysadmins seeing opportunities disappearing.
Talking about "IT Jobs" just leads to a lot of people shouting past each other.
If it isn't prying, what are your skills? Speaking out of my own experience, I run an engineering group, and it's ridiculously hard for me to find good people. We aren't biased against Americans (nor, and you may not like this, are we biased for them), and we take a lot of trouble to make sure that the compensation we offer is in line with (or higher than) the rest of the industry. But, honestly, it's pretty rare for a top-notch person at any level of skill ... even relatively junior ... to respond to our job postings or recruiter, and then it's even more rare for us to manage to hire them away from the dozens of other great offers they're getting.
When I talk to other hiring managers in the area, I hear the same thing over and over. Too many jobs chasing too few good (or even not-good-but-could-be-mentored) candidates.
Thus my curiosity about your skillset.
(As an aside, I want to say that we do hire H1-B candidates, and that it's a point of pride for me that we pay them fairly and in line with anyone else who would have that job. I don't want to use their immigration situation to wring every last dollar from them. I'd rather that they were happy, and kept working for me because they liked it or were learning something.)
I have to say, you'd really hate trying to get a job if I were the hiring manager; I always give two rounds of technical questions.
The first is a take-home test, where you can use whatever resources the world and its internet provide to you. I email it to you, I expect you to email it back in an hour. It's a wide range of questions from simple coding exercises to complex problems that can't be solved in an hour. Getting some measurement of technical skill (and your ability to research) is only one part of what I'm trying to do here. More critically, I want to see if you can triage work, and identify what you can and can't accomplish in an hour; that skill is as valuable as knowing any language.
I'm also looking to see if the harder problems interest you. I think they're mildly cool, I'd like to hire someone who does too.
At this point, about 2/3 of the interviewees disappear from the process. They reply saying that they decided they were unqualified, they reply saying they didn't have time. Once, they replied that they were insulted that I would question their resume. In any case, without even spent 60 seconds of my time on a phone screen, I've narrowed the field to people who at least have basic coding skills and aren't offended that we might feel they should prove themselves.
Then, when the person comes in for an interview, I like to have them write some code on a whiteboard. I start with a simple problem, and start adding requirements as they go along. I want to understand what they're like to work with, how they handle changes in requirements, how they write code to be change-tolerant. I also want to see what they're like under stress; do they seem like a culture fit? Are they enjoying the challenge?
At the end, I will know a lot more about a person than if they have basic skills or not. I will have seen them in action, gotten a sense for how they solve problems, and understand a bit how they might work with me and other people on their potential new team.
You may not like the fact that I want to know these things, but they're important to me.
That's an interesting (albeit debatable) definition of lying. I won't disagree with it, but I will disagree with one of your other statements :
That may be true for some of the President's advisors, but it certainly isn't true for the Secretary of Defense. As a member of the cabinet, the Senate has the responsibility to "advise and consent" on his appointment. So it's quite clear that the President doesn't have the absolute right to work with whomever he wants in this case, and that there is legislative oversight.
Seeing as there is legislative oversight, and seeing as the statement was made right before a legislative election, it is clearly an issue for the voters to be appropriately concerned about.
So, even given your definition of lying, he lied.It sounds like you hit the URL before the service actually went live. You might want to try again ...
The press release with details of the deal is here.
Methadone replaces the heroin addiction with a methadone addiction. It is no easier to stop taking methadone than heroin.
What's especially potent is that you don't actually need to comment the assertions out : leave them in your code, so that downstream users can activate them and confirm that there's nothing broken in your code. There's no performance hit when they don't ask for them, and if you're writing code for others to incorporate into their apps, you've just given them a powerful support tool.
This is why configuration driven logging (like log4j) is such a leap over commented in/out println() statements : you can use them outside of your own development environment. Your customers, be they other developers or end users, can get an insight into how things are failing, either to diagnose problems for themselves, or to generate a report for you, so that you can find out what's going wrong for them.
They're so confident of their claim, that they're willing to put their money where their mouth is.
In any case, what specifically would you want to see? All of the source code of all the operating systems they looked at with check marks next to each line? And who would you choose for an independant third party?
However, what can a manager do when a project or organization starts to underperform? Too frequently, managers will attempt to improve performance by "shaking things up". They think "Okay, after one more reorganization, then things will be right." or "Well, if we put this process into place, it will be perfect."
The problem is really that management is as much an art as writing code or designing systems. There are a lot of people out there who can do it when the problems are normal, when the future is well understood. Unfortunately, most of them respond in counterproductive ways when confronted with crisis and uncertainty.
In short (too late!), it isn't that managers look for ways to stop people from being "happy, content, secure" out of spite. It's just that they're trying to do something, anything to make things better. They flail, and things get worse.
- Does the system solve the problem?
- Can the system be maintained?
- Can we get more value out of the solution beyond solving the original problem?
And that's where 10 years of experience brings more value.Two years of experience brings you competence in your toolkit and exposure to a few development lifecycles.
Ten years gives you an arsenal of already solved problems from which you can borrow ideas, an understanding of how problems interrelate across broader domains, and an awareness of out-of-scope and future problems that can be solved (or have the groundwork laid, to simplify solving later) with easier up-front work now.
I guess my response to the manager would be : not every developer with 10 years of experience should be an architect, because frequently that converts a happy developer into an unhappy architect. However, 10 years of experience gives you a developer who can think architecturally, and that's something you won't get from someone with only 2 years under their belt.
Click on that download link on the right side of the page.
I am perfectly okay with the idea that my employer owns the former and that I can't treat that as a portable code library, and they're perfectly okay with me including my code library's code in their products, as long as my license (the BSD license, as it turns out) allows it with minimal encumberance.
It can complicated to decide which base I'm writing the code for, but I typically use the rule that if I'm in the office it's theirs, and if I'm at home it's mine. I write in Java, so I use package names to further delineate which is which.
Everybody wins this way : they get more code, I get code that makes my life easier throughout my career.
- In the last three months, more than 40 percent of the unemployed have been out of work more than 15 weeks. That's the worst number since 1983.
- According to the monthly payroll survey for January, jobs rose by 112,000. Before you start cheering, that doesn't actually keep up with population growth.
- Since the recovery officially began in November 2001, employment has actually fallen by half a percent, while the working-age population has increased about 2.4 percent.
All of these facts (with more available) come from Paul Krugman's editorial in the NYT today. His column should be required reading for anybody who wants to talk about the economy.However, that doesn't invalidate what I said initially. 1.5 isn't a response to C# (well, maybe the enumerated types are), but seems to be kind of orthogonal to C#. It is a distinct improvement to the language, but that isn't the same thing as "embrace and extend". Those improvements don't give Java evangelists the ability to say "The C# language has no good feature that Java doesn't."
I'm also making an argument about intellectual honesty. Java (like any other piece of software) will never flower into its full potential unless the people who believe in it are willing to acknowledge the strengths of its competitors, and then adopt those strengths where it can.
It isn't a sign of weakness to do that, but a sign of strength.
It's well known that the C# designers paid a lot of attention to Java, but more importantly, it's also quite clear that they also spent a lot of time paying attention to the experience of developing in Java.
So while I might not entirely agree with the uncaught exceptions or the way methods aren't virtual by default, I do think it would be a good idea for Sun to take the lesson from MS, and take what is best about C# and move it into Java.
Instead, you need (to extend a metaphor) to add "herd immunity" to your network. Not every machine needs to be absolutely immune to assault, but if a large enough portion of your network has some immunity, your whole network is "immune enough" to prevent major compromises.
The goal, IMO, isn't to prevent security breaches, but to block the easy ones and mitigate the hard ones. To only plan for the success of a few points in your fabric is disastrous ...
All I can provide, unfortunately, is anecdotal evidence, and a little bit of theory. As a lead developer for a medium sized team of highly skilled developers, I find that many areas criticized by Python proponents actually contribute to a better development environment.
For example, Java's static typing vs. Python's dynamic typing. While there is no question that many keystrokes are saved by Python's dynamic typing scheme, there is also no question for me that static typing makes it generally easier to understand and follow code that I'm reading (by providing more information up front), and eliminates certain classes of logic errors from code that simply won't show up from a straight compile. This simplifies code reviews, transitioning code from one developer to another, and gives code longer shelf-life.
The same logic follows for Java's exception model (it certainly makes it easier to see when code is inappropriately swallowing an exception), and even for the general verbosity of the language as a whole. It makes it easier (again, the "for me" caveat should be assumed) to review the code of other developers, to follow that code, to transition that code.
So that's some of my anecdotal evidence. Now here's my theory : when developing large and complex pieces of software, writing the code is the cheapest and simplest part of the process. Extra keystrokes (given how good most IDEs are) are unimportant. What's critical is how quickly other developers can understand, review, modify, debug, and/or replace your work. The more information your code provides to those developers, the more detailed that information is, the better. Yes, it's a nuisance to chain together all of the decorators to open a file to read (buffered) characters, but it's very clear to other devs exactly what you're doing. Clarity is my goal, and the language that provides the most clarity to other developers is that language that I will prefer. Right now, in a comparison of Python to Java, I believe that language to be Java.
Initially, it made me less available and less responsive, and that bothered me. However, my work habits started to change in response to it. Because I now control my exposure to communications, I find that I can flip to the other box, scan for messages, and flip back to my work box without exiting the flow state.
This has had some other really positive side effects. For example, people are aware that I'm in my office, even if I'm not responding to IM. That means that if something's really important, they'll often just drop by, replacing the thirty back-and-forth email with a simple 5 minute conversation. Sure, I lose my flow state, but high priority problems bubble up to the top of the list and get resolved in the most effective way (ie; face to face) possible.
The platform, after all, pays no bills, gets no clients, makes no sales. It's all overhead, and it's a constant drain on internal resources. Even if you decide to just let the code sit, it's a drain on your attention and something that requires the retraining of every new coder, tester, tech writer, employee.
Furthermore, the skills required for building and maintaining a platform tend to be different from those required to build on top of one. An organization that chooses to do both must be substantially larger, and must accept a certain loss of efficiency as some developers and development effort gets locked into the platform.
On the other hand, you get a heavy, early boost from building on top of an already ready platform, and you get the advantage of other people's incremental improvements to that platform without your team lifting a finger.
The buy-vs-build (or download-vs-build in the case of the free platforms) calculation isn't - and shouldn't be - a strictly technical decision. Every developer believes that they can do it better, given enough time and resources. This ignores the fact that time and money and bodies are always in short supply, and that there are significant advantages to "doing it like everybody else" (not least of which is that you can hire people and have them working the next day).
A project can be managed competently, or even well, and it can still go poorly. Things go wrong, the team can't respond to events quickly enough, dependencies fail, assumptions turn out to be false.
None of these are signs of a poorly managed project (though a well managed project can accomodate some amount of this), but it still happens.
If a project is going poorly, replacing twelve good developers with one good project manager won't advance the project one iota if the project is already being competently managed. Conversely, if you already have enough developers on a failing project, adding twelve good engineers and removing a good project manager isn't much of a save either.
To try and establish some kind of mapping between the two is absurd. It's like saying "An axle is worth a dozen engines!"; the car isn't going to go far if you're missing either set of skills. If a project is lacking project management, you need more project management. If it's missing engineers, you need more engineers.
Part of what leads to these sorts of statements, of course, is that neither skillset is easy or readily understood by either side of the debate. Coders don't understand how hard it is to do good project management (mostly because they're typically exposed to the lousy sort, and because you can always muddle your way through). Project managers often have no insight into what it takes to design and build good codeTo compound the misunderstanding, they see that there's one project manager and a dozen developers and they think that they're worth a dozen developers. It's a fairly typical management error.
Ideally, project managers would all have heavy coding experience, and every developer would have project management training. If they don't, then it's up to the experts on both sides to educate across the aisle. If your project manager doesn't get it, it's your fault for not taking an hour to explain it. And if you don't understand why the project managers do what they do, try asking about the process they use to put together a project plan, to do resource balancing, risk amelioration planning, cross-team scheduling, and the like.
If the customer is unhappy, and it's your fault then it's your fault.
If the customer is unhappy, and it isn't your fault, it's still your problem. Frequently, they're unhappy about something other than the problem they're nattering on about and it's your job to figure out what and where the real problem is and fix it.
In practical terms, this means staffing your customer support team so that they can spend time with your customers working through their issues. Don't punish them for spending more time on the phone with the customer. Make sure that there's an easy flow of information from customer support to your engineers, and vice versa.
Also, have a short, easy to understand employee handbook that lays out rules that aren't stupid. Don't make your employees guess what the dress code is, don't make them ask what the comp time arrangement is ... and if you don't pay your salaried workers overtime, you better have a comp time plan.
This doesn't have to be complex, this doesn't have to be 40 pages long. It's not ethical (in the sense that it isn't fair) to not lay out your expectations in advance, or to make people guess.
Seattle (and West Coast) accuracy is always going to be lower than you'd like (and lower than the East Coast's, for example) simply as a result of fewer observations.
The rest of the nation gets to see weather data from thousands of weather stations as patterns move from West to East, while Seattle gets its (relatively) skimpy data from satellites and scattered ocean stations.
It's precisely this attitude that has led to IT losing respect within organizations, and getting outsourced. An in-house IT department has some natural advantages, if only it exploits them : you have your customers in front of you, you can talk to them, find out what they need, find out where your services are needed, and find out where you're getting in the way. If an IT group is unwilling to adapt itself to the organization that it's in, if an IT group is unwilling to adapt itself to the needs of its customers, if an IT group is unwilling to scale themselves up or down to an appropriate size ... well, that's an IT group that essentially deserves to be outsourced.