[edw519]

If you answer to managers and build CRUD apps to support their careers rather than your own, then you're not a professional.

Pretty amazing statement from someone whose comments are otherwise among the best here on Hacker News.

1. CRUD apps run the world. They were here long before all this sexy unnecssary stuff and will be here long after these fads pass.

2. Whether you want to admit it or not, everyone answers to someone.

3. Make no mistake about it: if you build anything, you benefit, often more than those you built it for. In fact, to become an excellent programmer, there is no better way. It doesn't matter who you built it for, it just matters that you built it.

4. Literal definition of "professional": earns money. There's probably no better way to be a professional programmer than to build corporate CRUD apps. Looser definition of "professional": someone I would want to march into digital battle with. I would most certainly pick someone who has written many corporate CRUD apps over someone who has recently embraced some sexy new technology from the conference and community du jour.

[michaelochurch]

1. CRUD apps run the world. They were here long before all this sexy unnecssary stuff and will be here long after these fads pass.

Fair point. "CRUD" is a straw man. Actually, most apps should be simple. That's just good design. If CRUD is enough to solve the problem, then one shouldn't do more if it compromises simplicity or conceptual integrity.

2. Whether you want to admit it or not, everyone answers to someone.

Sure. What I like about Valve's model is that, yes, employees answer to the company. What isn't there is the middle-management extortion of "since I can fire you, you invest in my career, and you're lucky if I give you a 2-week 'plum' project".

Everyone answers to someone, but the terms are widely variable. We're a lucky set, being programmers. We have skills whereby, if we can solve the leverage problem (as a group, we're poor negotiators) we can deliver so much value to society as never to be poor. Unfortunately, because we are so critical to operations, and because we're terrible negotiators, there's a class of people (VCs, tech managers) who spends as much time devising ways to hack us as we spend coming up with ways to hack computers.

It's the fact of answering to a careerist middleman-- often for little in return, resulting in long-term career stagnation-- not the abstract "answering to someone" of having to deliver value, that makes corporate engineering so humiliating.

3. Make no mistake about it: if you build anything, you benefit, often more than those you built it for. In fact, to become an excellent programmer, there is no better way. It doesn't matter who you built it for, it just matters that you built it.

I agree, but at least in my experience, programmers are lucky if they get to spend 10-20% of their working time on building, and it's rare that we actually get to own and to finish a project.

Most of us get staffed on fourth-quadrant ( http://michaelochurch.wordpress.com/2013/01/01/fourth-quadra... ) maintenance work that's largely evaluative in purpose, while the company decides whether it trusts us enough to give us real work. Of course, the managerial gatekeepers who proctor and grade this years-long dues-paying/testing period use it for hard-core extortion.

I think this problem (of long slogs on evaluative make-work, and projects never getting to be finished) might be the visceral appeal of game development. Sure, it's a horrible industry if you look at the conditions, but unlike much of software, you actually finish and ship a product.

I'm 29 years old and I'm starting to have the experience of getting genuinely rejected for jobs that a top-talent person of my age should be able to get (and that I would be able to get, with better work experience). This is not a case "they're idiots" rejection (a pathetic defense mechanism) or "lost in the shuffle" bad luck, although that happens too. It's genuine rejection that occurs because the quality of my work experience is mediocre. There are a lot of jobs that I would be able to get at this point, had I not drawn a string of bad bosses and shit projects. Now, some of that's my fault: I should have shown initiative and started open-source hacking five years ago. Some of it is not my fault. If I had landed on a machine learning project when I joined Google, I'd be spending a lot less time ranting on HN and more time building awesome stuff.

4. Literal definition of "professional": earns money. There's probably no better way to be a professional programmer than to build corporate CRUD apps. Looser definition of "professional": someone I would want to march into digital battle with. I would most certainly pick someone who has written many corporate CRUD apps that someone who has recently embraced some sexy new technology from the conference and community du jour.

Disagree. The defining trait of a profession is a set of ethics (that one professes) and processes to which one subordinates. For programmers, "don't build logic-bombs and back-doors" would be an obvious first commandment. "Never compromise on quality to gain rapid career progress", i.e. "don't launch and flee", would be a more controversial second one.

When you're a professional, there are ethical principles which you have the right and obligation to place above managerial authority. To make sure this works, the profession controls the economy (a controversial process, for sure) in order to make sure you always have work and your boss never has you by the balls. Professionals can't use the "just following orders" defense. If a doctor's boss tells him to kill a patient, insubordination (against that boss, subordinate to the higher authority of the profession) is a requirement. He loses his license and possibly goes to jail if he fails it.

We don't have the right to tell our bosses, "I won't do that, because it's unethical". Nor do we have the right to expect our bosses to invest in our careers-- and, most often, they don't. Ergo, I'd say that we're not professionals.

[potatolicious]

I continue to think that you're over-romanticizing traditional engineering. I'm a mechanical engineer by training, have many peers still in the field, and worked in it before switching fields myself.

In fact, the major reason why I switched out of mechanical engineering into software was because my experience is very much the opposite of how you seem to think traditional engineering works.

> "The defining trait of a profession is a set of ethics (that one professes) and processes to which one subordinates."

This is reasonable. This is what separates accountants, lawyers, doctors, and yes, traditional engineers from software engineers.

The question is how well these ethics and standards are enforced in actuality. The sad reality is, for traditional engineering, not well at all, to the point where the ethical bar for software is frequently higher.

I left the field after working at an automotive parts maker (who shall rename blissfully unnamed) when I saw, first-hand, sub-standard products being shipped deliberately, extreme managerial incompetence, safety standards being compromised, willful disregard of the public's safety, and fraud. And none of this was particularly unique to where I worked.

There are many interesting stories here. Including one where the company shipped a large batch of motors to an automaker knowing full well that all failed QA standards in some way or another, and many were completely defective. When the automaker eventually returned the shipment, instead of replacing them with good parts, the company knowingly and deliberately hired minimum-wage workers to test and pick out the "best" parts from the defective pile, to minimize the amount of manufacturing the company would have to do.

I was also asked, at one point, to find "proof" that a series of car fires were not caused by the company's defective design. At this point it was already obvious to everyone that we were the culprits. Management spent weeks, if not months, ducking this while people continued driving those cars on the road.

I was also involved with a project where radiators were literally falling out of the cars due to cutting corners and the use of substandard materials. The solution to which is not replacement with good parts, but rather shipping dealerships strengthening screws and endcaps, the notion being that as long as the incidence rate was low enough the company can simply afford to settle whatever lawsuits came out of it. At no point was actually fixing the defective parts on the table.

And here we thought we learned a few things from the Ford Pinto.

Mind you, this is a regulated profession, with a well-stated code of ethics. It did no good here - management had employees over a barrel. People were dangerously overworked, both on the factory floor and in the design office, and the state of the auto industry meant that no one could afford to speak up. The whole place stank of the very thing you were originally railing against - people working on meaningless things, working for horrible managers, looking out for their own survival more than the public welfare.

So yeah, traditional engineering does a nice song and dance about being ethical, making it possible for employees to blow the whistle on abuse, that an engineer can just tell their boss to fuck off when something unethical is asked of them.

In reality, none of that truly exists. Traditional engineering, in actual practice, is closer to software engineering than you think.

[bennyg]

  We don't have the right to tell our bosses, "I won't do that, because it's unethical".

What do you mean we don't have that right? As a human being, I always hold that right and will use it if necessary. Fuck a job - if a decision that I have the power to make/not make results in something unethical happening then I'll make sure the person telling me knows this. And if they still insist, then I walk. Just like your doctor analogy.

[bchjam]

I've refused to do things I found unethical in the past (bulk spamming, lying to vendors to get better discounts/terms/freebies). I also have to argue the merits of technical solutions with my manager. Sometimes I help out on projects where solutions seem sub-optimal but if it's flat out wrong I'll be loud about it until people catch on and it gets changed. I've decided to use a different language on a project and had it eventually become the default language for new development (from VB.NET to C#). And I've never had my employment threatened doing any of these things, though most of them have occurred in a corporate setting, working on a framework for enterprise crud apps. So I definitely feel that there's room for being ethical (or at least relatively true to yourself) within a corporate environment without getting totally screwed over in short order.

[stcredzero]

> Fair point. "CRUD" is a straw man

That's not a straw man. It's not inventing a silly example and pretending that it's representative for the sake of argument. It's using negative connotations of something that is actually representative.

[kyllo]

The point is, building a CRUD app is a task that has been done so many times, and frameworks like Rails, Django, Play, et al have abstracted away the challenging parts to the point where it's no longer a technically hard problem and does not require a particularly skilled programmer. The current crop of frameworks are now just one level of abstraction away from the point where a non-programmer will be able to build a functioning CRUD app with a few mouseclicks (just like Wordpress), at which point it will no longer be necessary to employ professional programmers to build them. With the next generation of CRUD app frameworks, they'll be able to give that task to someone like a business analyst, who has other responsibilities and who they can pay much less than they would have to pay someone with a CS degree.

Programming belongs on the cutting edge, the place where we build things that were never possible before. CRUD apps are about collecting data, but that problem has been solved already. Now the problem is we have too much data and aren't sure how to make sense of all of it. So the cutting edge is now at building machine learning algorithms on top of MapReduce processing, to automate high-level decisionmaking based on massive, diverse, distributed sets of data. That's where the important "engineer" jobs are going to be.