I'm an in-house programmer (left grad school because I thought I'd get some money). The job is painful. The layers of bureaucracy are suffocating. It probably doesn't help that I'm actually working for contractor that produces in-house software for the federal government.
Oh well, at least its expected that an employee will move around a bit.
The way to combat that is to convince your bosses that you completely understand why the business exists (to make money). Convince them that they can use technology to be better at that and the job will become a lot more interesting and fun.
If you're going to be stuck doing something shitty, it's well worth the effort to try and make it less shitty.
...until the auditors come in and tell you the shareholders don't like you innovating like that.
Trust me, even when your bosses are onside, in-house programming is a PITA. You're better off talking to your boss about how the product you made on your own is better than some of their in-house stuff, and that he/she should buy it.
Yeah. I've got a startup that's two weeks from launching (soft launch unfortunately) and I'm unbelievably excited about it. I'm giving this everything I've got because I don't think I can go another year or two not doing my own thing.
I currently work as an in house guy and it really is a PITA.
In-house programming doesn't need to be as bad as Joel's experience. Yes, you are in what is called a "cost center" that doesn't get the same management priority as a "revenue center." But the more closely your work is aligned with a revenue center, the better treatment you'll get.
In a software company, you're in a revenue center. The problem is that you may have to sign a draconian intellectual property agreement, jeopardizing side projects. This is less likely as an in-house programmer.
In-house programming is usually worse than product progamming, but there are exceptions.
Some companies really do see their in-house programming as critical for success, and treat it accordingly. I get the impression that NetFlix, for instance, is a pretty good place to be a developer, because the company sees logistical software (for optimizing DVD delivery) as a critical components in winning against blockbuster (they also do video downloads, from what I've heard, but that's so close to an actual software product that I'm not sure I'd call it "in-house"). I gather that Amazon is also pretty innovative, but I don't know anyone who works there.
On rare occasion, product companies are clueless enough to treat their developers like typists - I've been at exactly one. The difference, of course, is that these companies don't really last long. A textiles company with crappy software management practices can survive anyway, whereas a product company with that attitude will almost certainly fail, and quickly.
So in general, I agree - though there are some notable exceptions.
I don't think Netflix qualifies as in-house programming. IMO, when Joel refers to in-house programming, he refers to companies that have a core competency that has nothing to do with software.
If you work at an insurance company or tech support company, you'll be writing code to make lives easier for people who work at the company. Your customers are in-house employees.
Why not try to be an in-house developer for a big universities?
I haven't tried it out yet but I think it might be fun. Less pressure/stress/deadline and huge opportunities to roll-your-own web-app for students (in the area of 20-40k students). Salary wise is also great (especially those government funded universities).
I currently work as an in-house developer for a University of about 30k students. While there is less deadline stress, it's not exactly like actually being a student again. We have cubes and an organizational bias towards Java-Is-The-Best-Solution-For-Everything.
That said, the people here are all happy. Employees get 22 paid vacation days a year, and the dress is casual, excepting meetings with the very high ups. There is no prototypical office asshole, and we usually have more money than people, so you have a lot of freedom to buy equipment you need or software that will solve a problem if it makes more sense than writing it yourself. It's kinda nice to be in-house and yet not have to reinvent the wheel. It leaves you free to tackle fun/interesting/non-cookie-cutter problems, rather than writing some ERP module that should be a commodity.
I did this for a while. There are some good aspects to this job - you tend to get plenty of vacation, futher education and conferences are well supported. Salaries are only the low side in my experience, definitely not great - but when adjusted for pensions and stability (very difficult to get fired), there isn't much to complain about.
There are also some really horrible elements to this job. For starters, the stability - which sounds great - means that you will truly be surrounded by dead weight. Utterly unmotivated people work in some of these departments. It really got to me, to the point where I couldn't stand to be there anymore. A pension is great, but I'm not going to hover around for 30 years in a spiritually dead place (I'm not exaggerating here). I'll find another way to save for retirement.
Another problem is that the jobs almost never lead to the top. There are a few CIO/style or "Chief Architect" style jobs at universities, and those are pretty sweet gigs for those who get them. But if you have a job in a non-academic department, you're definitely a cost center, the definitive in-house programmer. There are very interesting projects in academic departments, but expect what I'd call a "parchment ceiling" - ie., you can't progress without the right degree. In a software company, people seem to like grad degrees, but if you can bring it, they'll put you in a high impact position with a lot of creativity and automony. At a university, the Ph.D grant-holder is in charge. Period. The dev is more or less a (decently paid and well appreciated) paraprofessional.
This was just my experience (I worked for a university as a dev for almost 3 years). Overall, I'd say that unless you really want the stability, don't do it.
I agree with your statement regarding "unmotivated" people.
I'm currently working part-time at school just for fun and to have the experience of how it feels working there. This isn't a "research developer" kind of job but really IT job, developer.
Sometime it is hard to convince your boss that his/her approach was wrong in terms of software engineering point of view.
I like how people don't work overtime and sometime leave early :). Might be good to start a startup or get a consulting side-job there since there's no NDA or whatsoever to be signed (at least in my place). Plus you'll get to know in which area you should write your own software and sell it to them in the future.
Here in DC Georgetown has a bunch of job listings that seem to average about half the market rate. The non-profit sector pays slightly better, but it's far more lucrative to work for a contractor or one of the product companies in NoVa or DC (my strong bias is toward the former). As stated, it's profit-center vs. cost-center dynamics.
This was a much more interesting (and painfully accurate) portion of the talk (I assume it is just one talk, just reporting it in 3 parts). Lots of stuff he has mentioned years ago, but slightly refined (fine with me - Joel always makes me optimistic that things can be better and should be and will be).
This is exactly the one big fear I have as I'm beginning my career in software. I really don't want to end up sitting in a cubicle coding boring ass software for the next 40 years...
20 comments
[ 3.5 ms ] story [ 56.3 ms ] threadOh well, at least its expected that an employee will move around a bit.
If you're going to be stuck doing something shitty, it's well worth the effort to try and make it less shitty.
Trust me, even when your bosses are onside, in-house programming is a PITA. You're better off talking to your boss about how the product you made on your own is better than some of their in-house stuff, and that he/she should buy it.
Of course, that's got it's own set of problems.
I currently work as an in house guy and it really is a PITA.
In a software company, you're in a revenue center. The problem is that you may have to sign a draconian intellectual property agreement, jeopardizing side projects. This is less likely as an in-house programmer.
Some companies really do see their in-house programming as critical for success, and treat it accordingly. I get the impression that NetFlix, for instance, is a pretty good place to be a developer, because the company sees logistical software (for optimizing DVD delivery) as a critical components in winning against blockbuster (they also do video downloads, from what I've heard, but that's so close to an actual software product that I'm not sure I'd call it "in-house"). I gather that Amazon is also pretty innovative, but I don't know anyone who works there.
On rare occasion, product companies are clueless enough to treat their developers like typists - I've been at exactly one. The difference, of course, is that these companies don't really last long. A textiles company with crappy software management practices can survive anyway, whereas a product company with that attitude will almost certainly fail, and quickly.
So in general, I agree - though there are some notable exceptions.
If you work at an insurance company or tech support company, you'll be writing code to make lives easier for people who work at the company. Your customers are in-house employees.
I haven't tried it out yet but I think it might be fun. Less pressure/stress/deadline and huge opportunities to roll-your-own web-app for students (in the area of 20-40k students). Salary wise is also great (especially those government funded universities).
That said, the people here are all happy. Employees get 22 paid vacation days a year, and the dress is casual, excepting meetings with the very high ups. There is no prototypical office asshole, and we usually have more money than people, so you have a lot of freedom to buy equipment you need or software that will solve a problem if it makes more sense than writing it yourself. It's kinda nice to be in-house and yet not have to reinvent the wheel. It leaves you free to tackle fun/interesting/non-cookie-cutter problems, rather than writing some ERP module that should be a commodity.
I also noticed that your statement regarding hardware/software is 100% correct in the university where I am working right now.
There are also some really horrible elements to this job. For starters, the stability - which sounds great - means that you will truly be surrounded by dead weight. Utterly unmotivated people work in some of these departments. It really got to me, to the point where I couldn't stand to be there anymore. A pension is great, but I'm not going to hover around for 30 years in a spiritually dead place (I'm not exaggerating here). I'll find another way to save for retirement.
Another problem is that the jobs almost never lead to the top. There are a few CIO/style or "Chief Architect" style jobs at universities, and those are pretty sweet gigs for those who get them. But if you have a job in a non-academic department, you're definitely a cost center, the definitive in-house programmer. There are very interesting projects in academic departments, but expect what I'd call a "parchment ceiling" - ie., you can't progress without the right degree. In a software company, people seem to like grad degrees, but if you can bring it, they'll put you in a high impact position with a lot of creativity and automony. At a university, the Ph.D grant-holder is in charge. Period. The dev is more or less a (decently paid and well appreciated) paraprofessional.
This was just my experience (I worked for a university as a dev for almost 3 years). Overall, I'd say that unless you really want the stability, don't do it.
I'm currently working part-time at school just for fun and to have the experience of how it feels working there. This isn't a "research developer" kind of job but really IT job, developer.
Sometime it is hard to convince your boss that his/her approach was wrong in terms of software engineering point of view.
I like how people don't work overtime and sometime leave early :). Might be good to start a startup or get a consulting side-job there since there's no NDA or whatsoever to be signed (at least in my place). Plus you'll get to know in which area you should write your own software and sell it to them in the future.