[michaelochurch]

Zed Shaw already solved this problem: http://programming-motherfucker.com .

What made programming great (before the Douchebag Invasion came in and we were divided into these stupid warring camps) is now what makes "data science" attractive: the generalist flair and the ability to pick your projects and move around the economy by your own sail.

By the way, I personally hate the term "software engineer", at least as commonly used. It sounds Corporate and I feel like I need a shower after I say it. Genuine software engineering (like, what people who build rockets do, where attention to code quality is critical and people actually consider proving code) is actually very important, but you're only an engineer if you have professional autonomy. If you answer to managers and build CRUD apps to support their careers rather than your own, then you're not a professional.

Right now, most of us live under a worst-of-both-worlds regime where it's not clear whether we're genuine professionals, entre- or "intra"preneurs, or glorified labor. Of course, this allows management to frame-change freely among all of the possibilities depending on the specific negotiation, leaving us with the bottom of each possibility.

[potatolicious]

I feel that you're over-romanticizing traditional engineering. I'm a mechanical engineer by education (who knows how I ended up here, oops) and went to school with many civil, chemical, and electrical engineers.

Their jobs have as much corporate-ism and debilitating big management as ours. Perhaps more, since there's a distinct lack of startups in those arenas.

Sure, what they do has a boatload of ethics and standards that apply to it (unlike software, which is still very much fly by the seat of your pants), but they sure as hell don't have a lot of autonomy. Most traditional engineers also answer to managers, and build the equivalent of CRUD apps to pay the bills and get promoted.

I suppose by your sentiment no one is a professional.

[bruceboughton]

>> Genuine software engineering (like, what people who build rockets do, where attention to code quality is critical and people actually consider proving code) is actually very important, but you're only an engineer if you have professional autonomy. If you answer to managers and build CRUD apps to support their careers rather than your own, then you're not a professional.

Because people who build rockets don't have to answer to middle management...

Read Mike Mullane's book [1] if you genuinely believe that

[1] http://mikemullane.com/riding-rockets/

[codegeek]

"If you answer to managers.."

I know you usually have good comments on HN, but is it just me or you really have something against "management". Anyway, the fact is that everyone answers to someone in some ways when it comes to money which we need to make to survive in this world unless you have family inheritance. Having said that, I am not saying that managers are necessarily the best thing in this world but i don't understand how you can get away without answering to someone. Even if you are a superstar entrepreneur who is his own boss, I have one word for you: customers.

"people who build rockets do, where attention to code quality is critical "

So are you saying that code quality is not critical elsewhere ? I agree in general that many companies have shitty code but there are many places which actually do care about code quality and code reviews are actually important.

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

Just think about what you said here.

[michaelochurch]

I wrote about my views on management, here: http://michaelochurch.wordpress.com/2013/04/30/gervais-macle...

Essentially, "manager" is a conflation of several corporate needs: (a) mentoring junior hires, (b) protecting the company from bad-faith employees, (c) protecting good employees from bad ones, (d) setting project priorities, and (e) putting a public face on the company (e.g. CEOs). Some of these jobs are more fun than others. There are huge conflicts of interest within what is called a "manager" and ultimately, employees get shafted.

Managers ultimately end up as the internal police force, because they're the ones who make firing and promotion decisions. However, there are a huge number of dirty cops. Most of them, in fact, are dirty. There are a few sadists who enjoy using the badge-and-gun just to fuck with people. There are others (much more common) who go full-on extortionist and use their power to build an image of outsized performance so they can hop out of cop work and into an executive or high-level strategic position. Rare is what police are supposed to be: principled public servants.

I don't have a problem with police. Society needs them. However, if the police started acting like the mob (with them making most of their income "on the economy") then I would. Corporate management is mostly dirty cops.

[samatman]

Perhaps you don't have much experience with the modern police force? Much of their budget comes from asset forfeiture, which is your basic perverse incentive.

[kyllo]

So are you saying that code quality is not critical elsewhere ? I agree in general that many companies have shitty code but there are many places which actually do care about code quality and code reviews are actually important.

He's saying safety-critical. Like NASA software. As in, if the code hits an NPE or array out-of-bounds or int overflow, people die. They actually use formal methods which is an exhaustive testing of every possible state the program could possibly enter.

We don't do this for business applications because it's extraordinarily expensive--can cost $100's per LoC.

And yeah, I think the several times daily I see "Microsoft Excel has encountered a problem and needs to close" is evidence that most major software shops have very poor quality control.

[jfb]

Code quality clearly isn't important, or we would have better tools. More controversially, why should it be important? Software quality is ineffable, unmeasurable, and therefore impossible to manage. So organizations just kick the ball downfield and accumulate technical debt by the bucketload, and they're arguably correct to do so. The only people who suffer are the programmers, and they're plenty of those, and more every day.

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

[bguthrie]

I worked for one of the places Zed is describing. Like many of Zed's rants, it has a pleasant, self-righteous ring to it, but the problem is misdiagnosed and its solution is no help at all. I'll say no more.

[Shorel]

Going by definitions, if you get paid for something, then you are a professional.

You may not be a real engineer, but a professional you are.

[tocomment]

As an aside about CRUD apps. I've been kicking around the idea of building and selling a universal CRUD app. Do you think there would be a market for that? How would I sell it?

[woah]

Hhhhhmmmm... I would develop it in an interesting language from Japan...

[tocomment]

Sorry, I don't follow.

[stcredzero]

RoR

[tocomment]

There's still a lot of coding for that. I'm thinking a drop-in app that looks at a database and creates list and record level editors for each table automatically. Users could still customize it from there but they'd have a good start.

[dreamfactory]

The trouble with reflecting your UI from your physical schema is that it is a horribly leaky abstraction with very close coupling.

An extreme DWTF-style example I've seen was a 'CMS' in this style. The CMS was clearly modelled on phpMyAdmin - if you wanted to create a new content type, create a new table and it would be right there in the UI. In this CMS, news articles were the main content type - and they could be linked to other news articles and other content types in the system such as celebrities and events, which was implemented as a simple drop-down for each referenced item when you were adding or editing an article. However, this drop-down for selecting referenced entities was of course reused everywhere - meaning that you had a global setting on whether the items were ordered in alphabetical or most recent.

(Obviously you could code around this particular case, but it illustrates a general problem with the approach. And god forbid you should ever want multiple pluggable storage engines or service-based data sources.)

[stcredzero]

I think it's a cool idea. So have lots of others over the decades. (From the 70's I'd bet.) In a way, RoR is just the latest wrinkle in this quest. If you can do it, you might well have something. (BTW, are you familiar with SQLAlchemy?) If you are serious, I invented a graphical interface for dynamically exploring reporting information from such an app.

[adregan]

What is "the Douchebag Invasion"?

[michaelochurch]

Douchebag Invasion: when we as a tribe lost the high-autonomy blue-sky R&D environment and it became the reality for most of us to answer to clueless douchebags who lack any respect for what we do.

[stcredzero]

> Douchebag Invasion: when we as a tribe lost the high-autonomy blue-sky R&D environment and it became the reality for most of us to answer to clueless douchebags who lack any respect for what we do.

This has always been. There is no single Douchebag Invasion. It's just when it hit your particular part of the programming world.