Comment by jrochkind1 | Hacker News Reader

Comment by jrochkind1 | Hacker News Reader

Parent Full thread

Okay, me and you agree that most of the code produced is junk (not everyone in this thread does I think!).

I agree that the junky code is going to bite us eventually.

But what do you think it would take to change things so most of the code produced is not junk? Would it take more programmer hours? More highly skilled programmers? Whatever it would take... would it cost more? A lot more? A lot lot more? I think it would. And I think if this is so, it's got to be taken account in talking about why most code produced is crap.

I do not think it's because most programmers just aren't trying hard enough, or don't know that it's junk. I think it's because most places paying programmers do not give them enough time to produce quality (both in terms of time spent coding and time spent developing their skills). And if say 98% of code produced is junk, and it's because not enough programmer time was spent on them... that's a lot of extra programmer time needed, which is a lot of expense.

The utopian theory of the OP is that with the right tooling, it would not take any more time, or would even take less time, to develop quality software. I think it's a pipe dream.

As long as the job of a programmer is to be a business subordinate, it will not change and we'll see crappy code forever.

Mainstream business culture conceives of management as a greater-than relationship. You're a lesser being than your boss, who's a lesser being than his boss, and so on... It also is inhospitable to the sorts of people who are best at technology itself. Finally and related, it conceives of "working for" someone not as (a) working toward that person's benefit, as in a true profession, but (b) being on-call to be micromanaged. The result is that most programmers end up overmanaged, pigeonholed, disempowered, and disengaged. Shitty code results.

If you want to fix code, you have to fix the work environment for programmers. Open allocation is a big step in the right direction, and technical decisions should be made by technical people. Ultimately, we have to stop thinking of "working for" someone as subordination and, instead, as working toward that person's benefit. Otherwise, of course we're going to get shitty code as people desperately scramble (a) up the ladder, or (b) into a comfortable hiding place.

"As long as the job of a programmer is to be a business subordinate, it will not change and we'll see crappy code forever."

Well of course that's the job of the programmer. The programmer is supposed to build something that does something useful. Most of the time, the primary value of the code isn't that it's GOOD, it's that it DOES THE THING. Oh, sure, at the level of (say) the Linux kernel you can almost think of it as code for the sake of code, but you walk back up the chain and you'll find a lot of people contributing indirectly because they want to do THINGS and they find that they need a kernel for those things.

But most programmers aren't at that far of a remove from doing things, they work directly for a company engaged in doing something other than selling code. Management at that company wants things done. They insist upon this at a very high level of abstraction, that of "telling you to do the thing for them." You are a leaky abstraction.

Purpose and status aren't linked.

There are programmers who without direct day-to-day management produce code that is valuable to the business, and programmers who receive comprehensive managerial attention and produce code that costs the business.

>>I do not think it's because most programmers just aren't trying hard enough, or don't know that it's junk.

Actually, that's exactly the reason.

Back in 2003 I was a sophomore in college and I took an intro-level CS class. It was taught in Java. Back then we didn't have sites like Stack Overflow, so if you ran into issues during projects you had to find someone who could tell you what you were doing wrong. Often times this person was the TA or the instructor, and those had limited availability in the form of office hours. So it was super easy to get demotivated and give up -- which is indeed what made a lot of wanna-be programmers (including me) switch majors.

Fast-forward ten years. We now have a plethora of resources you can use to teach yourself "programming." While this is good in the sense that more people are trying to enter the profession, it's not so good because when you teach yourself something complex like programming, it is often difficult to know whether you are learning the correct habits and skills. I've been learning Rails for the past five months and I spend a lot of time obsessing about whether the code I write is high quality, but that's only because I've been an engineer for six years and I'm well-aware of the risks of building something overly complex and unmaintainable. In contrast, most people build something, get it to work, and then call it a day. They don't go the extra distance and learn best practices. As a result, the code they produce is junk.

Reply on news.ycombinator.com