Live data from Hacker News

I am a programmer

jacquesmattheij.com

81–90 of 130 posts

Re: I am a programmer

#81
post #73

Earlier quoted context omitted.

I think you're missing the point - saying "I'm a programmer" essentially means jack and squat to most people. Saying what you did, and better, what that actually accomplished in real world terms isn't a lie at all, it's what people actually care about.

Do you think CNC operators give a damn whether most people know what a CNC operator does? This "make people understand what exactly I do and how much value I provide and how precious I am" is yet another manifestation of insecurity of software developers.

No, unless they work or want to work directly with CNC operators and need to know what they're actually capable of instead of just what they're called.

This is exactly what you don't put out a 'I need a dozen programmers' ad - people aren't a fungible commodity. You do actually need to know how much value they can provide.

Re: I am a programmer

#82
post #76

Earlier quoted context omitted.

Frankly, I dispute the existence of a "Software Engineer." The UK and parts of Canada may recognize and regulate people with this title, but I don't believe that the same rigor _can_ be applied to building software. You would have to work with formally verified (and I mean that in the mathematical sense) hardware and software all the way up and down the stack (that would include the language and compiler you utilize)…

> I don't believe that the same rigor _can_ be applied to building software. Check out aerospace software development processes. edit: also embedded automotive software

There was an article posted (I believe here) a while back about aerospace software development. They talked about the processes used to develop the software and it was definitely in line with engineering rigor. However, it went on to say the people doing the work were not professional engineers. So, at least in some countries, you still could not call it software engineering.

Re: I am a programmer

#83

The problem I had with Patrick's essay is how derogatory it is to what we do. I am a programmer because it's what I like to do. People pay me money to do it. And when I go home I read about it, talk to others about it, and I practice, practice, practice. I think about how I can write better software, reduce the amount of bugs, test better designs, and improve my productivity. I think about programming all of the time…

The point of Patrick's essay isn't "Programming is lame" or "you shouldn't be proud of your programming accomplishments." How did anyone take that away? > It isn't an easy profession and involves far more than typing in a bunch of things that make computers do stuff. This is true. Nobody said that wasn't the case. > I'm not afraid to tell others that I'm a programmer. I > think most people understand what that is by…

“Programmer” sounds like “anomalously high-cost peon who types some mumbo-jumbo into some other mumbo-jumbo.” If you call yourself a programmer, someone is already working on a way to get you fired.

That sounds derogatory to me. His opinion is that business types could care less about what you do. You're not a programmer but an exploitable resource. Since when is being a crafts-person and being proud of your work and what you do bad?

I get that you're proud of your development skills, but at some point your software has to solve a business need, and you need to understand what the need is and how your software is solving it.

I'm in the business of producing good software. How does calling myself a programmer have anything to do with what you just said?

It's a matter of perception. Patrick thinks people think programmers are clueless navel-gazing cogs who don't have a grip on reality. Of course nothing could be further from the truth -- a good programmer is probably more in touch with the needs of the business than the ignorant stakeholder who thinks programmers just type in a bunch of stuff. I think this perception is a disservice to both programmers and business people alike. I do not doubt that there are people in the world who perceive programmers in the way Patrick describes... but I wouldn't work for them for anything less than a big six-figure salary and very gracious vacation allowance. I think most people understand that programmers make software and software solves problems for businesses and consumers which makes money. Therefore programmers must be pretty important.

So yes, I still call myself a programmer. If I catch wind that the person interviewing me views me as a 'peon' I walk. If that's what they're looking for it's their loss. They can figure it out later I'm sure and might come back to me when their spending 80% of their time and budget fixing the errors their "peon" introduced into their software.

Good programmers are hard to find. I don't see anything wrong with calling myself a programmer.

Re: I am a programmer

#84

The problem I have with Patrick's essay ("you are not a programmer") is that it addresses a situation that hardly any developer ever finds himself in. If I go to interview for an engineer position, it matters exactly not one bit that I try to pass myself off as a solutions architect or a business problem solver, except for possibly some awkward glances back and forth. All they want to know is how long I've been codin…

> ... it matters exactly not one bit that I try to pass myself off as a solutions architect or a business problem solver, except for possibly some awkward glances back and forth.

Exactly, if he came to our shop to interview for an engineering position but would rather talk about making 'dreams come true' instead of algorithms or systems design, we would kindly show him towards the door.

Engineering shops don't like bullshit. If you are interviewing with HR sure, use business-speak all you want.

But perhaps the fact that there is even an HR dept. that will digest business speak like that, is a sign that you are interviewing at the wrong company.

Re: I am a programmer

#85
as long as you are calling other peoples modules you're not yet programming

How about while you're not calling other peoples' modules, you're not programming effectively?

Why am I supposed to waste my time rewriting code available in the STL, or better, why is it held against me that I don't waste my time on such?

Re: I am a programmer

#86

Earlier quoted context omitted.

The point of Patrick's essay isn't "Programming is lame" or "you shouldn't be proud of your programming accomplishments." How did anyone take that away? > It isn't an easy profession and involves far more than typing in a bunch of things that make computers do stuff. This is true. Nobody said that wasn't the case. > I'm not afraid to tell others that I'm a programmer. I > think most people understand what that is by…

“Programmer” sounds like “anomalously high-cost peon who types some mumbo-jumbo into some other mumbo-jumbo.” If you call yourself a programmer, someone is already working on a way to get you fired. That sounds derogatory to me. His opinion is that business types could care less about what you do. You're not a programmer but an exploitable resource. Since when is being a crafts-person and being proud of your work and…

  > Since when is being a crafts-person and being proud of 
  > your work and what you do bad?
Nobody said it was. Not the original article, not me, not anyone.

  > I'm in the business of producing good software.
I don't know, maybe you are.

Right now, I'm in the healthcare business. My main client is a medicare company and they want people to sign up for their plans and fill prescriptions, preferably for the cheaper generics that save them money but still provide therapy required.

I meet those goals by writing well-architected software with solid test coverage. I make my job easier on myself by making my deployment a single-click affair. That's part of being a good developer, but that's not what I'm paid for. I'm paid to meet business goals. We got this client by writing software that meets those goals better than their original vendor. If someone comes along who writes poorly-architected messes but that achieve those goals better my client will leave me for them. I will be disgusted as a programmer that this happened, but it only makes sense.

  > I don't see anything wrong with calling myself a programmer.
That's fine. Call yourself whatever you want. But -- and this is the entire point of Patrick's article! -- assuming that people understand the value of a good programmer is a mistake. Rather than dismissing folks who don't instantly comprehend your brilliance, maybe you might try explaining to them the value that you provide in terms they can understand.

Re: I am a programmer

#87
post #79

Earlier quoted context omitted.

Frankly, I dispute the existence of a "Software Engineer." The UK and parts of Canada may recognize and regulate people with this title, but I don't believe that the same rigor _can_ be applied to building software. You would have to work with formally verified (and I mean that in the mathematical sense) hardware and software all the way up and down the stack (that would include the language and compiler you utilize)…

I've worked on avionics flight management systems. We had reams of system requirements, multi-person code reviews for every line of code in the product, formal verification runs, system integration testing, field testing... The compilers used were qualified for our use. All libraries used were qualified. All operating system components used in the product were qualified. Internal tools that automated any part of the…

The aerospace and medical fields have done quite a bit to increase the rigor in building software, however there doesn't seem to be any push from them to codify their processes and establish some sort of push for the industry as a whole. The establishment of a true Software Engineering discipline would require some consensus on the use of formal methods in specification design, and then program verification.

The other hurdle is that you need the same rigor from your hardware designers. Just as structural engineers must rely on the rigor of steel manufacturers, we are held hostage by hardware manufacturers. Frankly the entire industry needs a wake up call.

As for formal verification, it is the mathematical proof (in the pure sense) that a program behaves exactly as speced -- the specification must also be formally verified for consistency. Currently this is only possible on relatively small programs, with the largest being several compiler back-ends being verified.

Here's a paper on what it took to formally verify the seL4 micro-kernel: http://www.sigops.org/sosp/sosp09/papers/klein-sosp09.pdf

Re: I am a programmer

#88
post #73

Earlier quoted context omitted.

I think you're missing the point - saying "I'm a programmer" essentially means jack and squat to most people. Saying what you did, and better, what that actually accomplished in real world terms isn't a lie at all, it's what people actually care about.

Do you think CNC operators give a damn whether most people know what a CNC operator does? This "make people understand what exactly I do and how much value I provide and how precious I am" is yet another manifestation of insecurity of software developers.

"Make people understand what exactly I do" is exactly the attitude I think Patrick is arguing against. That's why you don't call yourself a programmer or talk about what technologies you use. Because it doesn't matter to non-software companies. What matters is whether you can save the company money or increase their revenue.

Calling yourself a programmer is telling what you do. Describing how many hours of work you can save is telling how you can provide value.

When presented with a bunch of employees manually copying information from spreadsheet into a database, you can tell them, "I know Excel interop and SQL," or you can tell them, "I can make it so you never have to manually copy this information again." Only one of these statements is interesting to a non-programmer. The first implies the second to us, but not to a non-programmer, so you need to be explicit. You can't expect them to make the inference and present you with a spec for a spreadsheet-parsing, database-updating program.

The reason programmers have to learn this and not CNC operators is that the benefit of a CNC operator is much better understood in their sphere (manufacturing) than the benefit of a programmer is understood in their sphere (almost anywhere computers are used extensively). Most people who can benefit from a CNC operator know it and know how. Most people (outside of the software industry) who can benefit from a programmer don't know it and even if they did, wouldn't know how.

Programming is by no means the only field in which this applies though. It also applies in design, copy-writing, SEO, ergonomics, preventative medicine, and many other fields. Anywhere where the people who can benefit from a field's work don't understand the field's work, but do understand impact to their bottom line.

If you pitch a business with, "I increased productivity at another business by 10%," you'll have better results (at least this is the conjecture at hand) than if you pitch with, "I'm an ergonomics expert," even though the actual work being offered is the same. Either way, the business owners will probably never understand that ergonomics is more than adjusting desk height. But they don't, and shouldn't, need to. They just need to appreciate how it helps their bottom line and trust the experts to apply the expertise where it should be applied.

Trying to make people understand what you do is exactly the problem. Programmers naturally seem to want people to understand how computers work and what they can do. We want people to understand what code is, why it's important that it's written well, and so many other things that business owners simply shouldn't need to care about. That's why we tell people we're programmers, or that we know certain languages or frameworks. These things are only relevant to other programmers though. Business owners care about making money, so tell them how you can do that.

Re: I am a programmer

#89
post #76

Earlier quoted context omitted.

> I don't believe that the same rigor _can_ be applied to building software. Check out aerospace software development processes. edit: also embedded automotive software

There was an article posted (I believe here) a while back about aerospace software development. They talked about the processes used to develop the software and it was definitely in line with engineering rigor. However, it went on to say the people doing the work were not professional engineers. So, at least in some countries, you still could not call it software engineering.

I'd guess that a professional engineer is still required to sign off on the software before a plane gets certification. The same happens when non-licensed-engineers work on other engineering projects. Perhaps the software part does have less engineers working on it percentage wise.

Re: I am a programmer

#90
post #79

Earlier quoted context omitted.

I've worked on avionics flight management systems. We had reams of system requirements, multi-person code reviews for every line of code in the product, formal verification runs, system integration testing, field testing... The compilers used were qualified for our use. All libraries used were qualified. All operating system components used in the product were qualified. Internal tools that automated any part of the…

The aerospace and medical fields have done quite a bit to increase the rigor in building software, however there doesn't seem to be any push from them to codify their processes and establish some sort of push for the industry as a whole. The establishment of a true Software Engineering discipline would require some consensus on the use of formal methods in specification design, and then program verification. The othe…

Codify their processes?

http://en.wikipedia.org/wiki/DO-178B

On the avionics software I worked on, we (another group of people) designed and manufactured the hardware. I'm not as familiar with the process there, but I have no reason to believe that it wasn't done with similar rigor. [See http://en.wikipedia.org/wiki/DO-254]

I understand mathematical proof, but I wasn't sure that was what you meant. I did not realize that physical engineering projects are mathematically proven to that extent?

Post reply on HN