Comment by chris_wot | Hacker News Reader

Comment by chris_wot | Hacker News Reader

Parent Full thread

Oh boy... That leads on to another thing that most non-technical (and even some technical!) managers don't understand: IT people are not drop-in modular components that will instantly work!

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.

Orthogonal nit, you tripped over one of my soapboxes: "employ a new resource".

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.

Agreed. My bad, in fact I acknowledge the irony, given my point (as you have picked up!) is you cannot treat contractors like a physical commodity! I appreciate you highlighting that discrepancy in my comment :-)

That's one of my own wee foibles - I never refer to a person as a "resource".

That's less a foible and more a character strength :-) the foible is referring to someone as a mere "resource" (and yes, I am acknowledging my own foible here!).

When you deal primarily with people whose primary roles and careers have been driven entirely by Taylorist managerial principles (fundamentally, the belief that managers are the ones that know best and most efficient instruments to allocate workers and efforts instead of relying upon workers themselves) then you're somewhat forced to deal with the language of contracts where people are interchangeable with the term and it's a reality you have to just deal with if you do business with them. It's treating all your workers like you're playing Starcraft rather than trying to manage an elite Navy Seals team where each person is fully capable of independent actions and thoughts. Rather, most large companies are used to rather low quality labor and I might dare to say that some companies prefer their "go do something" labor as fairly narrow while their managers are showered with praise and glory constantly for the work of those they're managing.

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.

Unfortunately I think we're still stuck in thinking of software development as being like assembling a product on a manufacturing line. Assembly lines reproduce a product model in volume. People forget that developing the model takes loads of time from designers and engineers. Software developers are the designer, engineer, and assembler all at once.

> Unfortunately I think we're still stuck in thinking of software development as being like assembling a product on a manufacturing line.

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.

> Right, and software development is the process of building the assembly line

It's more like the process for developing the prototype.

No, you prototype out the assembly line when you are working on it (actually not that different from how assembly lines are designed), though I guess in some cases you sell the assembly line itself, rather than the services it provides or the products it produces.

> 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.

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.

"An engineer". "A worker". It's not hard, if you haven't succumbed to the HR mindset.

In this context, the narrative was around hiring a single individual, not moving a thousand-person division of engineers onto the project. In a large-scale system, you also have to deal with the entailments of all those thousand people: the managerial overhead, the administrative overhead, the offices, etc. "Resources" becomes more appropriate, because it is more than individuals.

People rail against this, but I think it profoundly misunderstands the semantics. Gas is a resource. Money is a resource. Gold is a resource. A person is a resource. Nonetheless, only one of them is going to help my car go farther if I stick it in my fuel tank.

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.

> Gas is a resource. Money is a resource. Gold is a resource. A person is a resource.

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.

> This dehumanizing confusion of supplier with the resource they supply seems to only happen with labor.

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.

> A person is not a resource outside of contexts in which chattel slavery exists.

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.

Good point. I hate that word "resource" as applied to people, but I say it all the time, because everyone else does -- not a conscious choice, just a bad habit.

It's a remarkably hard one to break!

Anyway, I doubt any big industry in the world can integrate a new machine at an assembly line in 3 days.

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.

I don't think it came from anywhere. I think some people believe it is useful to project that it is true.

> Management expects someone to be like a field replicable unit, that you can drop-in and replace on a project.

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.

It's a bad thing because it doesn't work that way. Software engineers are skilled workers, not assembly line workers. And business Darwinism doesn't really work. Otherwise Comcast would have gone under years ago.

High barriers to entry would have to be a factor in business Darwinism, wouldn't they?

They bleed lots of money and that allows the Darwinistic decimation process to kick in and ultimately wipe them out.

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.

This is not how life works. It is how you wish life would work.

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.

> You see, someone who is not capable of programming, should not be allowed to manage programmers, because that simply amounts to an insult.

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...

> 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?

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.

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?

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.

> 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.

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).

> It's considered unethical for doctors or lawyers to have their work supervised by anyone who isn't a doctor or lawyer.

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...

Off topic, but possibly the best autocorrect change I've ever seen;

> inept endive

Lol! Dammed iPad :-) typos now fixed

Everything you say rings true to me. So, I sincerely wonder, why hasn't a drive for higher profits fixed this problem?

Reply on news.ycombinator.com