People are not resources, like a vein of coal. They are individual. Which was your point. But using the word "resource" instead of "person" perpetuates bad ideas.
It's hard for a lot of people on here to imagine dealing with 100k+ other coworkers but at a point you oftentimes have to abstract away what makes people human to work in most large corporations. I'm not advocating that this is correct, but much like slavery and flat world theory, I hope this becomes outdated and struck out as both completely ineffective from a business standpoint as well as unconscionable.
Really? Seems like most people describe it these days as a craft.
> Assembly lines reproduce a product model in volume.
Right, and software development is the process of building the assembly line.
> People forget that developing the model takes loads of time from designers and engineers.
But they know design an assembly line for a new task takes loads of time from designers and engineers...
> Software developers are the designer, engineer, and assembler all at once.
You can break of that work if you are working on a project of sufficient scale.
It's more like the process for developing the prototype.
Working myself for a company of 150K+ employees, I can confirm this is totally true.
I hate a lot of high-level business speak like "resources", but what I've come to realize is that one cannot think of 150K people as individuals. It's too much for the human mind. If you see this as an indictment of large corporations, I wouldn't blame you. Just realize it's a reality of operating inside them.
A resource isn't intrinsically a fungible commodity (when they are, we call them "commodities" ;-); often they are unique. The common trait of resources from a businesses perspective is that they are valuable to the business. Sure, I'd like to think I have more significance to this world as a person, but the day my employer doesn't see me as valuable is the day I start sending my resume around...
The other way to look at it is that while employees are individuals, they all take a paycheck. So, on the cost side, employees are all just different sized paychecks. When you are looking to assign employees to a task, you absolutely think about which individuals could/should be dong what, but before that, there is a decision about how much in the way of paychecks, if any, you ought to burning on that work. That first decision has little to do with the individuals involved.
A person is not a resource outside of contexts in which chattel slavery exists. Labor is a resource, of which persons -- laborers (whether independent contractors or employees) -- are contracted suppliers, not units.
This dehumanizing confusion of supplier with the resource they supply seems to only happen with labor.
Your reference to chattel inspired me. Consider the cow. Cows are resources. There are a ton of rules about what one can and cannot do with cows, but businesses still think of the "cow" as their resource, and "beef" and "milk" as some of the value they get from the resource.
Now, to your point on slavery, the rules for what you can and cannot do to people are very different from cattle. Of course, slavery is pretty irrelevant to whether someone is considered fungible (owning people is horrible, but it doesn't change whether they are interchangeable or not).
In practice resources are often suppliers and often the value the business extracts from them are provided under contract or at least a generalized regulatory framework. You are again confusing properties of certain kinds of resources with properties of resources in general.
Labour is very much how you marshall your "people" resources. It's a far more impersonal window through which to view people's relationships with businesses.
> Labor is a resource, of which persons -- laborers (whether independent contractors or employees) -- are contracted suppliers, not units.
Check out the definition of a "resource". It's the asset you draw upon to accomplish something.
Strictly speaking, the real "resource" is the employment or contract with the person, not the labour. However, thinking in those terms is terribly impersonal and not terribly useful for reasoning about a business (outside of legal disputes); in reality the person(s) under a contract correlate with suitability, outcomes, etc. a heck of a lot more than the contracts themselves. So what you really think in terms of are the people, not the contracts.
I have a hard time fathoming how it is dehumanizing to suggest that labour from one person is not the same as labour from another.
I don't get where this idea that developers can be easily replaced come from. No other profession is, and really, not even machines work this way.
Someone needs to explain to me why would this be a bad thing?
They bleed lots of money and that allows the Darwinistic decimation process to kick in and ultimately wipe them out.
A fool and his money are easily parted, and that is how it should be.
You see, someone who is not capable of programming, should not be allowed to manage programmers, because that simply amounts to an insult. He cannot do what you can do. Therefore, he is an idiot. Nobody wants to take orders from an idiot. Every single business on the planet is now, one way or another, turning into a technology platform. This means that in the end, it is programmers who will own and control everything, and not that bunch of idiots.
Humans are social animals. The power to cause (or prevent) change in organizations is political in nature. The power to affect operations through technology is at best instrumental to the power to decide what effect is to be implemented. By ignoring these facts, programmers forego the opportunity to be seen as valuable allies and turn themselves into exploitable resources. No amount of progress, or "platformization" is going to change that.
Sure, getting high paying jobs with little accountability can be kind of cool, in the short term. But you need to think what happens next. If social Darwinism is true, idiot managers will die out and be replaced with more competent managers. It will take years, but at the end of day, they will wise up. And if so many of them see programmers as a threat they will cut our jobs.
To a degree, this is what we are seeing now. The older generation of managers learned that programmers are unreliable, so they outsource not to save money, but to mitigate the risk of having to deal with programmers directly. The next generation is learning that the 3rd parties that isolate them from programmers are unreliable too. I expect the next generation will be very reluctanct to have in house development at all, and that they will limit themselves to existing products from reputable companies, if at all.
Hard to tell what happens when that option is also shown to be not reliable.
I hate this trope. There are thousands of professions out there, and most of them involve some kind of specialized knowledge/ability/skill. Do you really expect the head of your organization, the person least likely to have time to do independent work, to be the one with mastery of all the activities in the organization?
> He cannot do what you can do. Therefore, he is an idiot.
This one is even worse. It's not like programmers know how to do everyone else's jobs, and they aren't idiots.
> Nobody wants to take orders from an idiot.
Some cynical folks have argued that the advantage is that idiots are easily manipulated...
> Every single business on the planet is now, one way or another, turning into a technology platform.
Technology != software, and even if it did, very few businesses are viable as a software platform. Software is becoming an increasingly intrinsic part of most businesses, but so is accounting, legal, hr, management...
> This means that in the end, it is programmers who will own and control everything, and not that bunch of idiots.
I can imagine an accountant thinking much the same thing a century ago...
It's considered unethical for doctors or lawyers to have their work supervised by anyone who isn't a doctor or lawyer. They enforce the rule through professional conduct rules and boards. the result is very high prestige, pay, and working conditions for people with similar skills and education to programmers.
But the atomistic libertarianism and lack of solidarity among programmers makes us targets of mass low wage immigration, outsourcing, and every kind of unpleasant work situation.
With lawyers (more familiar there than with doctors) I don't think that's usually the case; the ABA model rules don't prohibit lawyers from being supervised by non-lawyers (though they do prohibit lawyers from co-owning law firms with non-lawyers, or sharing legal fees with non-lawyers, and they do prohibit lawyers from allowing their employer to "to direct or regulate the lawyer's professional judgment" in providing legal services -- whether or not the employer is a lawyer; this doesn't prevent supervision of the lawyer as an employee, it just essentially means that the lawyer doesn't have a Nuremberg defense of "just following orders" for professional nonfeasance or misconduct.)
http://www.americanbar.org/groups/professional_responsibilit...
I've supervised lawyers, though I'm not a lawyer. I know the same applies to other people with regards to doctors. The trade establishes rules they can't violate, but there are a ton of caveats on that. Regardless, those restrictions are actually needed by the organizations for specific roles. If a programmer was needed in a similar way for a specific role, it'd largely work out the same way. The main difference is there'd be no independent review board that has no idea what is going on in the day-to-day unless otherwise alerted.
The prestige/pay/working conditions thing is more a result of a trade group, and the consequent standards for people even being part of the trade, than due to supervision by those who lack skill expertise.
If you restrict yourself to the subset of programmers who have similar education, training, and professional validation processes as doctors & lawyers, I think you'll find a lot of prestige, pay, and quality work conditions (lawyers and doctors will tell you that it isn't quite as good as you imagine anyway).
Agreed. How would you even run a small town according to this "logic"? You would need to be a professional in many different fields. That's why you have advisers for, and that's why a good manager will listen to the people he is managing.
Better yet -- they bleed lots of money but don't die out, due to being hugely profitable, so they continue bleeding lots of money and we finally get the trickle-down economy Reagan promised us.
> inept endive
Here's an example: I did some BI work in Qlikview. The existing reports for a particular division were badly written, and were each loaded manually for each client. Due to a number of reasons, we weren't able to change this situation immediately, but we kept what we had running even though it was incredibly inefficient.
Eventually it got to the stage where we needed to get the reports working in an automated fashion. I had a solution I was willing to work on, but was unable to find the time to do it as my primary responsibility was to another BI project.
The manager kept putting off getting new resources, and tried to "fix" the reports himself, only ending up breaking them completely.
The solution that management came up with was to employ a new resource. However, by the time they employed the new person they had 3 days to get the reports working. The problem was that even though the new person understood Qlikview exceptionally well, he didn't understand (and had no way of knowing immediately!):
1. What the dashboards needed to show (not documented)
2. The data sources used in the Qlikview dashboard
3. The way the Qlikview load script had been coded
As the guy was really, really good it ended up taking just under two weeks to get to grips with the underlying data structures and business requirements. The implementation to fix the numerous dashboards took another week. Then fixing any issues took another week and a half. So that was about a month and a half of work to get the guy up to speed, then implement a solution.
Management expects someone to be like a field replicable unit, that you can drop-in and replace on a project. But that is not the way these things work - the nature of people and projects (which are each different) is that there is ALWAYS a lead time - sometimes up to months depending in the complexity of the project - where the new person you employ (no matter how good they are) needs to familiarise and understand the systems and requirements of the business before they can actually do productive work.