Don't Call Yourself a Programmer • Hacker News Board

Re: Don't Call Yourself a Programmer

#131

Post by rewind » Sat, Oct 29, 2011, 8:14 AM UTC

patio11 wrote: post #85

rickmb wrote: post #82

Earlier quoted context omitted.

Please note, he got to do this working for a boss who "never even asked what produced the deliverable". This sounds like a very dysfunctional company in the first place.

So here's another reason not to call yourself a programmer: it suggests that you are a peon who needs micromanagement. At Japanese megacorps, which are not historically known for huge degrees of flexibility, it is assumed that Software Engineers should be able to tie their own shoelaces without needing to be told what kind of knot to use. The boss asked for me to produce comprehensible and comprehensive documentation…

My take on what you said in the article was that you were encouraging developers to implement software (that was not tied into other software, but that was still used by end users) in a language that they want to learn. From what you said here, it sounds like you mean something you run just for yourself to get your work done, then toss. I thought you were suggesting doing this for actual software that is used internally or by a client, but that had no other dependencies and you could work on by yourself; as in software that may need to be maintained, have bugs that users discover that need to be fixed, etc. If you mean software for your own purposes as a tool to get a project done, but is not used at all once the project is done, and nobody will need to know or care that it existed, then my comment does not apply to that and I'm mistaken on my interpretation of your original meaning. If you mean software that is used more than once internally or by a client and you're writing it in a language that someone has to support that is NOT supported by the company you work for, then my original opinion stands ;-)

Either way, the parent to your comment has no bearing on my original comment or this one. You replied here, so I'm just replying to you.

Re: Don't Call Yourself a Programmer

#132

Post by ajtaylor » Sat, Oct 29, 2011, 8:14 AM UTC

Patrick has some great advice.

I'll add my own anecdote: earlier this year I had an interview which required taking a plane. I decided to wear my suit on the plane, and it was an entirely new experience. I can't put my finger on exactly what it was, but the people simply seemed nicer, more pleasant and accommodating. If you want people to think of you as a professional, dressing the part certainly helps.

Re: Don't Call Yourself a Programmer

#133

Post by tomjen3 » Sat, Oct 29, 2011, 8:24 AM UTC

adgar wrote: post #64

andrewflnr wrote: post #42

Earlier quoted context omitted.

Assuming he had a green light on the project itself, and it creates value, I don't see why that would be selfish.

Maintenance takes a lot more time than the initial implementation. By using a language nobody else knows, you increase the cost for 90% of the project's lifetime to decrease the cost of the initial 10%. It's selfish if the numbers are such that maintenance ends up costing more than you saved by using your favorite language for the initial implementation. That depends on a lot of things: your co-workers' experience, y…

For some projects maintainance cost a lot more than initial development. This is kot the case for a large segment of programs though.

Hint: any kind of problem that need only be solved once (or where it is cheaper to write the code again rather than to make it general enough for everybody) can be written however the original developer believes he will create the most value

Re: Don't Call Yourself a Programmer

#134

Post by ramchip » Sat, Oct 29, 2011, 8:48 AM UTC

adgar wrote: post #64

andrewflnr wrote: post #42

Earlier quoted context omitted.

Assuming he had a green light on the project itself, and it creates value, I don't see why that would be selfish.

Maintenance takes a lot more time than the initial implementation. By using a language nobody else knows, you increase the cost for 90% of the project's lifetime to decrease the cost of the initial 10%. It's selfish if the numbers are such that maintenance ends up costing more than you saved by using your favorite language for the initial implementation. That depends on a lot of things: your co-workers' experience, y…

He said a "one-off" project. Not all projects have such huge maintenance costs.

Re: Don't Call Yourself a Programmer

#135

Post by icebraining » Sat, Oct 29, 2011, 9:08 AM UTC

Jach wrote: post #113

mechanical_fish wrote: post #18

Earlier quoted context omitted.

Once you run the company it doesn't matter what you call yourself. That is probably a great topic for another essay, assuming PG hasn't written it already. It might matter what you call the company or the product , however, since that is the brand that the people who pay you are seeing. Programmers are so literal. Let me try and translate: When Patrick says "don't call yourself a programmer" he isn't necessarily sayi…

I'm a programmer. I program things. What, specifically, changes pretty frequently still. Going into detail can be useful when trying to score social points from the smalltalk question of "So, what do you do?" But depending on what you program, I think for most people "programming" is sufficient compared to "I currently write software to manage an elastic computer server farm running data analysis jobs for people." In…

I think the point is to make your job description less technical, not more. You're not a programmer, you're "the guy who made $X for your company last Y".

Re: Don't Call Yourself a Programmer

#136

Post by anon1385 » Sat, Oct 29, 2011, 9:38 AM UTC

cageface wrote: post #104

In the real world, picking up a new language takes a few weeks of effort and after 6 to 12 months nobody will ever notice you haven’t been doing that one for your entire career. I wish more HR/recruiting people understood this.

I have put in at least a few weeks trying to learn Haskell. I certainly never got to the point of being able to solve real world problems with it. Even after 2 years of coding in C most days of the week I wouldn't claim to know it well, and wouldn't be able to keep up with a 'real' C programmer. I've also spent far more than a few weeks (cumulatively) using Javascript and don't really have a solid grasp of the language (although in that case I have made no effort to actually learn the language).

Maybe this just reflects my poor aptitude for programming and I've very much behind the curve, so to speak. In which case it is probably correct that recruiters would do well to avoid recruiting me and to filter out those who are not able to learn new languages in a few weeks.

Re: Don't Call Yourself a Programmer

#137

Post by anthonyb » Sat, Oct 29, 2011, 9:39 AM UTC

maaku wrote: post #127

cbs wrote: post #124

Earlier quoted context omitted.

>If you work at a place like that, I feel sorry for you. I came to the comments to express the same sort of opinion. I work at a place that understands and values programmers. I can't imagine working in any other kind of environment unless I was between real jobs and really strapped for cash. If you're at a place run by a bunch of clueless MBAs that don't understand the value of their in-house engineers you just don'…

Are those MBA's clueless? Programmers are costs, and expensive ones at that. We start off underwater on the value proposition. Saying "I'm a programmer" is saying "I'm a large, fixed cost." The question for the businessman is always: what value do you add, and does it exceed your costs? Yes, there's value for an in-house engineering team , but with widely varying skill distributions and unevenly matched compensation.…

The value of programmers tends not be linear with cost though. Paying an extra 25-50% for decent ones gets you at least a 2x improvement, possibly more if they can rewrite large chunks of your corporate code to improve it.

Re: Don't Call Yourself a Programmer

#138

Post by anthonyb » Sat, Oct 29, 2011, 9:42 AM UTC

wallflower wrote: post #67

rewind wrote: post #35

"Want to get trained on Ruby at a .NET shop? Implement a one-off project in Ruby. Bam, you are now a professional Ruby programmer — you coded Ruby and you took money for it. (You laugh? I did this at a Java shop. The one-off Ruby project made the company $30,000. My boss was, predictably, quite happy and never even asked what produced the deliverable.)" Unless an employee actually gets permission to do this, this mak…

Technically, the employee would not be fired right away. He or she, however, would be red flagged for close observation by being put on a Performance Plan. Basically, a PP is required to legally fire you. For example, if you had a bad record of coming in at a consistent time, they could put you on a PP. In this PP (which you would have to sign as a condition of further employment), there would be a contract for comin…

PPs (and similar shenanigans) are a great way to turn your company into a smoking crater, programmer-wise. Doubly so for relatively insignificant things like not turning up at 9.00am...

Re: Don't Call Yourself a Programmer

#139

Post by dlo » Sat, Oct 29, 2011, 9:50 AM UTC

nickknw wrote: post #87

kamaal wrote: post #43

One of the things that I see among hardworking smart people is they somehow tend to use 'difficult work' as a yardstick to measure 'good work'. Difficult work need not necessarily be good work. Unfortunately if you fall for this, you will end up wasting a lot of time, effort and energy over years and at the end wonder why you are not as rich as someone who does has half the difficult work as you do. 'Good work' or so…

> "One of the things that I see among hardworking smart people is they somehow tend to use 'difficult work' as a yardstick to measure 'good work'. Difficult work need not necessarily be good work. Unfortunately if you fall for this, you will end up wasting a lot of time, effort and energy over years and at the end wonder why you are not as rich as someone who does has half the difficult work as you do." A connection…

True, but when entering a new line of business, the ability to solve difficult problems is a competitive advantage that a small start-up can leverage against a large company.

"Use difficulty as a guide not just in selecting the overall aim of your company, but also at decision points along the way. At Viaweb one of our rules of thumb was run upstairs. Suppose you are a little, nimble guy being chased by a big, fat, bully. You open a door and find yourself in a staircase. Do you go up or down? I say up. The bully can probably run downstairs as fast as you can. Going upstairs his bulk will be more of a disadvantage. Running upstairs is hard for you but even harder for him."

Source: http://www.paulgraham.com/wealth.html

Re: Don't Call Yourself a Programmer

#140

Post by mhartl » Sat, Oct 29, 2011, 9:52 AM UTC

Strive to help people. It is the right people to do

A heads-up for patio11: There is lots of good stuff here, but it needs to be copyedited. There are a bunch of little errors like the one quoted above.