Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I love IT, and I love being a code monkey and staying a working programmer with my various startup projects, but let's face it: although well-paid, the world treats programmers like crap. Long hours, working weekends, staying on call, impossible deadlines, complex and ever-shifting technologies, and high-stress deployments. It's no wonder that the people at hot-shot firms all look like they're in their 20s.

Some folks just get caught up in, well, life. They have kids, a house, and grow a life and hobbies. That means that they are no longer staying current, and their heart just isn't really in it any more. After you've kicked ass and conquered the world with code a dozen or so times, you've gained weight, you're missing out on the rest of life, and there are just a dozen more impossible missions ahead of you. It never ends. I'd throw out some kind of pithy remark like "work at a sustainable pace" but the sad truth is that a "sustainable pace" for a 23-year-old is not the same as it is for a 40-year-old. Not even close.

I like the model I've seen of moving great programmers into lead roles (with PM-type duties) and then "uber lead" roles, which also include some program-management duties. That way you keep your technical talent close. It's easier to teach a programmer business than it is to teach a businessperson programming. This idea that we move good programmers out simply because they start acting much more like middle-aged people than college students is hurting the industry. In my mind, the MBAs are much more expendable than some guy who has just spent 15 years of his life learning our business systems inside-out.



I, too, also love IT and programming. But lately because of the re-hash after re-hash (SOA vs REST, Java vs .NET vs Ruby, JavaScript, Functional, polyglot, Agile, XP, Scrum), I'm kind of losing it. Seeing programmers swinging their d*ck around saying language X is better or how their favourite tool is better drifts my heart slowly away.

I felt like I want to be a team lead or a manager whipping undisciplined developers to get better at ever lasting all-around skill as opposed to jumping between bandwagons too early.

So I made a decision to work my butt off in people skill, communication (and writing of course). Decided to branch out into PM and BA as well.

We'll see how things will develop.


I hear you. As a 46 year old "senior technical lead", I have to be choosy about what new things I commit the time to delve into.

That said, sometimes the little things matter, but you have to trust your intuition about the big picture to determine which techniques may be important in the near future, as be willing to understand that some of these technologies really are largely equivalent in many ways.

If I can just get my juniors to stop writing N*100 line subroutines, ironically coupled with "kangaroo code" with too many useless abstraction/indirection layers, and learn enough about the functional style (even though working in Java -- AKA "Object COBOL") to write small routines with clearly defined inputs and outputs, I'll be a happier man at this point.


Long hours, working weekends, staying on call, impossible deadlines, complex and ever-shifting technologies, and high-stress deployments.

Maybe I'm just lucky, but that hasn't been my experience at 3 companies over 15 years. Occasional crunch time yes, but overall I've averaged less than 45 hours a week.

I like the model I've seen of moving great programmers into lead roles (with PM-type duties) and then "uber lead" roles, which also include some program-management duties.

What's worked for me is putting a great PM on the team, where she (they've invariably been women) gets whatever information she needs from me, and then goes off and does the scheduling and meetings and internal negotiations that would drive me crazy if I had to.


I love EMS, and I love being a trauma junkie and staying a street medic with my various emergency services, but let's face it: never well-paid, the world treats EMTs and paramedics like crap. Long hours, working weekends, staying on call, impossible deadlines, complex and ever-shifting technologies, and high-stress responses sometimes involving deadly diseases and gunfire. It's no wonder that the people at ambulance firms all look like they're in their 20s.

Some folks just get caught up in, well, life. They have kids, a house, and grow a life and hobbies. That means that they are no longer staying current, and their heart just isn't really in it any more. After you've kicked ass and conquered the world with trauma saves a dozen or so times, you've eaten too many donuts and too much stale coffee and too little exercise and gained weight, you're missing out on the rest of life, and there are a never-ending series of impossible missions ahead of you. The calls never end. I'd throw out some kind of pithy remark like "work-life balance" but the sad truth is that a "sustainable pace" for a 23-year-old is not the same as it is for a 40-year-old. Not even close.

I like the model I've seen of moving great street medics into lead roles and senior roles, but there just aren't enough of those roles. You could keep your technical team close, but it's easier to train another new, green paramedic than to keep a senior EMT or medic from burning out. This idea that we allow good EMTs and paramedic to burn out is hurting the industry. In my mind, the MBAs are much more expendable than some guy who has just spent a decade learning our patients and our regional medical system and that ever-shifting patient IT system inside-out.


What you are missing is the inherently multi-disciplinary nature of programming. People who develop deep technology solutions by necessity have to get a crash course in whatever business system they are automating and improving. If you spend 15 years working on various projects, you have not only stayed current with a shifting base of state-of-the-art tech, you've also been exposed to critical parts of operations and learned what the issues, risks, and drivers are. You don't get that in the EMT world, or the brain surgery world, or the nuclear physics world. In those worlds, you have a single industry and set of problems that you live inside for your entire career.

There's also a huge bedrock of many business-related disciplines that don't change. Want to be a manager? I can throw out every book written in the last 20 years and still sit down and put together a damn effective course in management. Want to learn accounting? While GAAP has changed, many accounting systems are still using the double-entry ledger system that was in place in Dickens' time. The business practices of running an A/R system now is going to look very much the same as running that kind of business did in 1980.

Yes, it's true that great performers in any field will naturally pick up a bunch of things in other fields, but these are mostly peripheral to their job, not a critical part of it. Pilots may learn a bit about how radios work, but it's not the same thing as spending two years writing software radio code. Technology development is unlike any other field of endeavor because it is a meta-discpline: it encompasses all other disciplines. Everything you do in life, including being an EMT, is being assisted by technologists somewhere. Programming and technology development is the bedrock of every other kind of activity. Good technologists are not only experts in one area, they are experts in learning new areas. This is one of the reasons why Google is involved is so many things and so many other companies are not. You have a breadth of capability with 40,000 generic engineers that you simply wouldn't have with 40,000 rocket scientists, fishermen, or history majors.


I well understand your point, and I respectfully disagree.

There's a whole lot more practical knowledge outside of the technologies and tools that the programmers know about and use.

Some of the least educated folks I've worked with are arguably the smartest, and the most practical. Some of the most educated can be the most useless. You never really know what you're going to learn, and from who.

EMTs and firefighters or other folks working in other vocations outside of programming are commonly designing and building and experimenting; you'd be surprised what some of the folks have come up with.

As for the technologists, a lack of field skills or a lack of experience can work detriment of what the programmers are implementing. You need look no further than much of the medical equipment to realize how little the programmers involved truly knew about the problem. (And that's from my own experience using the devices, as well as many years of programming similar systems.)

Everybody thinks they're special, of course. And ego kills brains. Which was my point.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: