Live data from Hacker News

Don't Call Yourself a Programmer

kalzumeus.com

171–180 of 274 posts

Re: Don't Call Yourself a Programmer

#171
post #164

I love corporate, boring, "soul-crushing" work. Why? Because I can sit down, whip out a basic CRUD form with a small approval cycle in a day. It saves a company 100K over the year, I am loved by the customers, and because it is so simple, it normally requires no maintenance. Maybe we update the fields once a year or so. At the end of the week, I've already saved the company more than my salary. After a year, I am a c…

Corporate work has a lot more to do with the relationships than with the work itself. That's the most important take-away. It's not about how much math you know or what data structures you use. It's how you get along with the guys (and gals) you're doing the work for. You want people who are smart enough to understand that what you're doing is important, but humble enough not to think of what you do as "grunt work" that they could do just as well, and decent enough not to try to "trap" you or to browbeat you into doing as much work for as little as possible.

I'm also not a fan of the "hostage employer" situation. It's a way to get a steady paycheck, but also a toxic relationship that kills you slowly. Better to do the best work you can so that if your client wants to let you go, he can.

If you're doing "boring" corporate work for people you like (and not all "business people" are assholes; it's about half IME) then it can be fun. You do great work for them in a small amount of time, and they pay you well and are happy to have you.

I've met a lot of consultants who can make this work really well. When you choose your clients and don't have a manager-as-career-SPOF, you can develop positive relationships like what you described.

Re: Don't Call Yourself a Programmer

#172
The language stuff is only part true. It's true enough, perhaps, that it's not usually the most important thing to emphasize on a resume, especially if you're doing simple CRUD apps, but nevertheless programming languages and their implementations are varied and complex.

Yes, you can become productive in a new language after 6 months of using it, but most people will still have a long way to go before they can claim a reasonably high level of proficiency, especially if there's significant dissonance between the languages. Going from Java (or most languages, really) to Python isn't going to be too difficult, but a lot of that is because Python is a very easy language to get started with. But even with Python it will probably be a lot longer before you really understand some of its less obvious features, pitfalls, performance profile, and are comfortable writing idiomatic code. For a more complicated language, like Perl, or a more distant language, like Haskell, it'll probably be a lot longer.

Re: Don't Call Yourself a Programmer

#173

Does this cause people to read "The Genius and Tragedy of Patrick McKenzie" http://www.sebastianmarshall.com/the-genius-and-tragedy-of-p... (posted last month by an observer of the author of the submitted post here) with a different reaction?

It was posted in 2010 and generated the following discussion: http://apps.ycombinator.com/item?id=1720244

Re: Don't Call Yourself a Programmer

#174

Enjoyed the post. Do programmers really not know who Peter Drucker is?

It would be sort of sad for programmers to not know who Drucker was, since he's the guy who coined the term "knowledge worker" to name the class of job roles that encompasses programmers (and also a large percentage of the people who use computers and software in the business world).

(See http://en.wikipedia.org/wiki/Knowledge_worker.)

Re: Don't Call Yourself a Programmer

#175

Earlier quoted context omitted.

I think we're disagreeing mostly on what "getting into the labs" means. Sure, you can't walk into a lab filled with expensive equipment and start doing your own research; but you could absolutely walk into someone's lab and start helping to do their research. My father studies chemical reactions in supercritical water using a beam of spin-polarized muons from a cyclotron; there's many millions of dollars of equipment…

Ah, okay, if you want to be an unpaid lab tech I agree that you can get that job pretty darned easily. It hadn't occurred to me, recently, to have such low standards for hanging around in a lab. ;) The novelty wears off, you see. EDIT: just to summarize for the audience, I believe cperciva and I are in agreement with Patrick that it's easy to flawlessly impersonate a university student for free; We are debating the e…

Yes, "unpaid lab tech" is a pretty low standard. But if you hang around as an unpaid lab tech for long enough, you start picking up more useful skills and have a good chance of eventually getting paid. (No, I never did this. But I know people who have.)

As for impersonating a junior professor: I wander into seminars and if anyone doesn't recognize me they just assume I'm from the university on the other side of town. Given my age they usually assume I'm a postdoc; but if I was ten years older I'm sure they'd assume I was a faculty member.

Of course, "faculty member from a different institution" doesn't really get you very much.

Re: Don't Call Yourself a Programmer

#176
post #81

Earlier quoted context omitted.

It's a very business oriented article. E.g. "You’re in the business of unemploying people. If you think that is unfair, go back to school and study something that doesn’t matter.)" I for one have created more jobs than I've destroyed in my coding career. By building a business, as you've done, you're going in the opposite direction of this kind of sentiment.

Don't take this the wrong way, but ... really? I find that hard to believe. Pretty much all programming is in the short term unemployment producing, since pretty much all programming is automation. Automating a job means that no one does it anymore, hence one fewer job. In the long run those people are usually repurposed into productive work, and there are occasional moments where a programmer will create a massive n…

There are types of programming that create jobs, but you're right, most of them eliminate jobs while making the rich (owners of our companies) richer. Which kind of sucks if you think about it.

The programming that creates job is the kind that sells to consumers. Pretty much any consumer product will create jobs. B2B will eliminate jobs. Most programming is B2B (I think...) because it's easier to take money from other companies.

Examples of programming that creates jobs:

Games

Iphone Apps

Todo lists

Products that make money by showing advertising

Re: Don't Call Yourself a Programmer

#177

Earlier quoted context omitted.

Basically, a PP is required to legally fire you. Where are you talking about? Laws vary, even among the states in the USA.

When I mean legally , I mean to protect the company against being sued for firing you. Yes, there are cases where there are immediate terminations. PP assist in the less egregious cases where there is gray areas. In fact, you can argue that the entire point of an HR department is to protect the company from getting sued.

It depends on the state. You can't (successfully) sue a company in Massachusetts (like California) for any reason besides discrimination. They don't need to give a reason why they fire/lay you off. They just fire you and that's how it goes. Not all states are like this.

Re: Don't Call Yourself a Programmer

#178
post #115

> If you really like the atmosphere at universities, that is cool. Put a backpack on and you can walk into any building at any university in the United States any time you want. Backpacks are a lot cheaper than working in academia. You can lead the life of the mind in industry, too — and enjoy less politics and better pay. You can even get published in journals, if that floats your boat. (After you’ve escaped the min…

You missed the point of the article. You can do cool thing even at large companies iff you put yourself out there and look for opportunities that interest you. You can also get paid for it if you are smart.

It's actually pretty hard to get on to the most interesting projects in large companies. Your first project is a roll of the dice, and you usually have to do well on that first one to get an upgrade on your second.

Yes, there's cutting-edge work going on at Fortune 500 tech companies. It's about 5% of the workload, and it's competitive to get onto these projects. You're competing against PhDs who have been with the company for 10+ years, have major internal accomplishments to their name, and are objectively more qualified than most of us are.

This doesn't mean you shouldn't try. There are other benefits to working at these large companies (high salaries, good benefits, and work that, even if unglamorous, is a part of something successful people care about). I do think, however, that the idea that a 25-year-old can walk into Intel and Oracle and expect to be allocated to cutting-edge work because of raw talent, is patently absurd.

Most large software companies have 6 de facto tiers which may not correspond to job titles: Freshman, Junior, Senior, Lead, Senior Lead, and Fellow. The type of work you get depends largely on this tier:

Freshman: low-impact but "fun" projects, "bait" work designed to ease you into the company. This is what people get straight out of school.

Junior: mid-priority but grungy projects, maintenance of others' architectures. Keep in mind adverse selection: the good architects generally want to assist in the maintenance load for their creations, while the bad ones tend to run like hell.

Senior: mid-priority but more interesting and autonomous projects. Opportunities for junior-level IC (individual contribution) on high-priority projects. This is where most people are expected to plateau.

Lead: leadership roles on low- and mid-priority projects, plus encouragement toward IC on high-priority work. Good point from which to move into middle management if one hits a technical plateau.

Senior Lead: leadership roles on mid- and high-priority projects, plus expectation of IC on high-priority work. Fun but low-priority work is generally not accepted (it won't get you fired, but you'll stop advancing and your peers will think you're wasting your time.) Most SL are trying to get into lower-upper management (yes, large companies have a de facto lower-upper, mid-upper, and upper-upper management) because so few people make it to the next technical tier.

Fellow: complete autonomy, high degree of influence, implicit trust. Ability to flit between high-priority and low-priority projects based on what one wants to do.

To get interesting technical work and enough income to raise children in NYC or SF without an awful commute, you generally need to make it into the Fellow tier, which is much harder than moving into management. At Lead, you have enough autonomy and status to take on whatever project you want, but having real influence (or high income) requires going higher, and going higher requires spending a substantial portion of your time (40+ hpw) on grungy work because that's what Senior Leads do.

The bitchiest tiers are Junior and Senior Lead. Juniors have something to lose (3-4 years' career investment) and are skilled enough to take the worst of the work (middling priority maintenance, both unglamorous and underappreciated). Senior Leads are the one you see on-call at 11:30pm despite having two kids. And if you think working on a mid-priority, grungy project is bad, imagine what it's like to manage that project and have to deal with people quitting, transferring, or getting fired at a rate of 2-3/year.

Re: Don't Call Yourself a Programmer

#179
post #164

I love corporate, boring, "soul-crushing" work. Why? Because I can sit down, whip out a basic CRUD form with a small approval cycle in a day. It saves a company 100K over the year, I am loved by the customers, and because it is so simple, it normally requires no maintenance. Maybe we update the fields once a year or so. At the end of the week, I've already saved the company more than my salary. After a year, I am a c…

Corporate work has a lot more to do with the relationships than with the work itself. That's the most important take-away. It's not about how much math you know or what data structures you use. It's how you get along with the guys (and gals) you're doing the work for. You want people who are smart enough to understand that what you're doing is important, but humble enough not to think of what you do as "grunt work" t…

A more important thing is you won't really need much of those data structures and algorithms for nearly 99% of the tasks that your are likely to do in any large corporate/typical business driven software today. Most of the data structures that you will need are covered by the standard tool kit that comes with the language. Most of your common sorting and searching needs come covered with the libraries.

But you sort of need to have other skills, like productivity , delivering extra value to business etc.

Also I don't see why all that is wrong. After all software there is written to make money. And if something helps you do that with ease. It's perfectly OK. You don't have to always take the most difficult path to prove you are good. Doing what is required to 'get things done' is just good enough.

Re: Don't Call Yourself a Programmer

#180
post #113

Earlier quoted context omitted.

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

Doesn't that depend on what sort of job you're trying to get? If someone is hiring for embedded systems development, and your resume has no details about your technical skills, but lots about Providing Value, there's a good chance they're going to wonder if you're technically qualified. They certainly won't be impressed if your attitude in the interview is: ok, sure, I don't yet know all of these details, but anyone can pick up a language in 3-4 weeks; did I mention I'm really good at creating business value?
Post reply on HN