5 ms·

> Plan your exit into management, a related field, or some other job altogether. If you expect to be a coder at age 50 you're going to be disappointed. I'd lik

> Plan your exit into management, a related field, or some other job altogether. If you expect to be a coder at age 50 you're going to be disappointed. I'd like to simultaneously disagree and agree with you. If you were a 50 year old coder 10 years ago, then your only hope of remaining in the tech industry would be to add "Manager" to your job title. If you are a 50 year old coder today, that's still a sound direction to go, but increasingly becoming less necessary. If you'll be a 50 year old coder 10 years from now...I think you'll be ok. Yes, at 50 you almost certainly cannot crank out as much code as you can at 20, but so what? As a coder it is important to understand that most problems in technology are not solved with more code, but less. That you will generate less code at 50 should be seen as a benefit. The advantage you have at 50 over someone who is fresh and new at 20 is that you can recognize that there is very little that's happened in the last 30 years that is genuinely new. So, if you are 20, go ahead and spend your weekends on side projects learning the latest frameworks. As you continue to do this over the years and decades, shift to focusing more on patterns. By the time you reach 50, you might only generate half as much code as your younger colleagues, but you should be able to solve problems with a quarter of the code required, still making you twice as efficient as them. When coding was new, code was the only metric by which to measure coders, and non-technical management types would view anyone who generated less code as less valuable. If you're not writing 500 lines of code a day, the argument goes, then you should be managing coders who can. But management and problem solving are not a completely overlapping skill set. Some engineers make good managers, but most do not. Luckily, the more technically inclined individuals that populate the ranks of company management, the more this is being recognized and the more these companies are willing to hire the 50-year-old-coder-who-codes-less-but-solves-more-problems.

riprowan 10y ago
> As a coder it is important to understand that most problems in technology are not solved with more code, but less. That you will generate less code at 50 should be seen as a benefit. This is precisely my argument as a generalist. I may not write code as fast or even as elegantly as I once did, but I'm much, much better at "seeing around corners" to avoid problems, and I'm much more likely to "build the right thing" due to my very broad but not deep technical base. I do not fall into the trap of "when all you have is a hammer everything looks like a nail." > there is very little that's happened in the last 30 years that is genuinely new This is true, but try to convince your 20something peer group of it. They are all convinced that their technical skills are revolutionary. I studied waterfall systems engineering in 1998. But at the same time they also taught "RAD" iterative waterfall, or the precursor to Agile. I ran with RAD, and made it mine, so I've been doing something very similar to "Agile" for two decades. However, I still think that Gannt charts and top-down planning have value. Showing that shit to the wrong 20something developer is a great way to be excommunicated.
- jballanc 10y ago
  Right, my only quibble with your previous comment was the notion that being 50 in tech means migrating to a management role. I think that advice is slowly (hopefully) becoming outdated as there is more recognition that software engineers have more value than just the SLOC/day they produce.
  - riprowan 10y ago
    Ah, I see. I agree. I think "management" includes lots of quasi-technical roles, in which people and project leadership are the core skills, with one's technical base serving as a platform for managing others with highly focused technical skill sets. Hopefully you are also right that these jobs are increasingly in demand.
- webmaven 10y ago
  > However, I still think that Gannt charts and top-down planning have value. Of course they do. What you're seeing is a backlash to the way GANTT charts have been misapplied to projects that are less well defined, and to managers that ask for estimates and then are unpleasantly surprised when an estimate isn't entirely accurate. Anyway, if you want to provide the same sort of value but present it in a different format, consider using a network diagram or a user story map[1]. [0] https://www.quora.com/What-are-the-best-alternatives-to-using-a-Gantt-chart/answer/Brad-Bigelow-1 https://www.quora.com/What-are-the-best-alternatives-to-usin... [1] https://www.scrumalliance.org/community/articles/2013/august/creating-an-agile-roadmap-using-story-mapping https://www.scrumalliance.org/community/articles/2013/august...
  - riprowan 10y ago
    > What you're seeing is a backlash to the way GANTT charts have been misapplied to projects that are less well defined, and to managers that ask for estimates and then are unpleasantly surprised when an estimate isn't entirely accurate. You think I don't know this? I think you missed the point :( (As an aside, in my experience, network diagrams and user-story maps pale in comparison to Gantt charts, as they do not effectively communicate timeline expectations IMO.)
bsenftner 10y ago
I'm seeing a lot of mythic stereotypes here. I am a 52 year old full time coder, and have been actively developing since taking a college pascal class at age 11. > If you were a 50 year old coder 10 years ago, then your only hope of remaining in the tech industry would be to add "Manager" to your job title. People outside the startup bubble value delivering, regardless of age. Developers outside the startup bubble work consistently in a few areas of technology, they develop deep personal understandings with cookbook / solution / frameworks they personally authored enabling them to construct stable solutions that expertly address the problems being addressed. Essentially, if you remain a "coder" and you use your brain at all above simply being a coder, you will become a software scientist. I never start anything from scratch, as I have about a dozen application skeletons ready for various specific purposes, plus similar libraries I wrote, plus a knowledge of several large commercial SDKs, and developer experience in several major FOSS applications. The work that I do now would give my 20 or 30 year old self a heart attack with the large scope, number of complex technologies, and the time frame I'm expected to deliver. But I've been writing code for 40 years now, and I may bitch at my tools, but it will deliver, it will be well written, fully documented, and so on because anything less just creates technical debt. If you like writing code, start acting like a scientist about it. Few developers do, and in time you will accelerate away from your peers into a truly enjoyable professional space very few seem to occupy.
- riprowan 10y ago
  I appreciate your different perspective enormously. I have spent the bulk of my career working in larger, team-based environments. In my experience, being able to conform to cultural norms is essential to being a high-performing team leader or member. Many, many teams have prejudices and / or litmus tests. For example, I've spent decades doing project management. I use Gannt charts. Why? Because they are the best way to communicate timeline expectations with stakeholders. I don't use them to manage the project. But I've encountered more than one Agile team that flat-out considers the use of these charts to be anathema. You might as well crap on the rug. That's just one example. Obviously there are also the buzzword technologies. Here's an overgeneralization you might agree with: young developers tend to naturally gravitate towards newer, less proven tech. Us older developers naturally gravitate towards more mature, established tech. This creates a source of age-related friction. Then there's the inability of others to grasp the applicability of your experience. For example in the 1990s I built a lot of actually awesome Lotus Notes/Domino applications. Now that's a technology that, if you mention it in various meetings, will get you laughed at. However, Domino was kind of the original "noSQL" / "BigTable" world, and it turns out that my application architecture experience in the Domino world translates meaningfully into these "newer" (ha!) database technologies. But try to tell that to team members. So I guess my comments are orthogonal to yours. I agree with pretty much everything you write, but it leaves out the important social aspect.

riprowan 10y ago

> As a coder it is important to understand that most problems in technology are not solved with more code, but less. That you will generate less code at 50 should be seen as a benefit. This is precisely my argument as a generalist. I may not write code as fast or even as elegantly as I once did, but I'm much, much better at "seeing around corners" to avoid problems, and I'm much more likely to "build the right thing" due to my very broad but not deep technical base. I do not fall into the trap of "when all you have is a hammer everything looks like a nail." > there is very little that's happened in the last 30 years that is genuinely new This is true, but try to convince your 20something peer group of it. They are all convinced that their technical skills are revolutionary. I studied waterfall systems engineering in 1998. But at the same time they also taught "RAD" iterative waterfall, or the precursor to Agile. I ran with RAD, and made it mine, so I've been doing something very similar to "Agile" for two decades. However, I still think that Gannt charts and top-down planning have value. Showing that shit to the wrong 20something developer is a great way to be excommunicated.

jballanc 10y ago
Right, my only quibble with your previous comment was the notion that being 50 in tech means migrating to a management role. I think that advice is slowly (hopefully) becoming outdated as there is more recognition that software engineers have more value than just the SLOC/day they produce.
- riprowan 10y ago
  Ah, I see. I agree. I think "management" includes lots of quasi-technical roles, in which people and project leadership are the core skills, with one's technical base serving as a platform for managing others with highly focused technical skill sets. Hopefully you are also right that these jobs are increasingly in demand.
webmaven 10y ago
> However, I still think that Gannt charts and top-down planning have value. Of course they do. What you're seeing is a backlash to the way GANTT charts have been misapplied to projects that are less well defined, and to managers that ask for estimates and then are unpleasantly surprised when an estimate isn't entirely accurate. Anyway, if you want to provide the same sort of value but present it in a different format, consider using a network diagram or a user story map[1]. [0] https://www.quora.com/What-are-the-best-alternatives-to-using-a-Gantt-chart/answer/Brad-Bigelow-1 https://www.quora.com/What-are-the-best-alternatives-to-usin... [1] https://www.scrumalliance.org/community/articles/2013/august/creating-an-agile-roadmap-using-story-mapping https://www.scrumalliance.org/community/articles/2013/august...
- riprowan 10y ago
  > What you're seeing is a backlash to the way GANTT charts have been misapplied to projects that are less well defined, and to managers that ask for estimates and then are unpleasantly surprised when an estimate isn't entirely accurate. You think I don't know this? I think you missed the point :( (As an aside, in my experience, network diagrams and user-story maps pale in comparison to Gantt charts, as they do not effectively communicate timeline expectations IMO.)

bsenftner 10y ago

I'm seeing a lot of mythic stereotypes here. I am a 52 year old full time coder, and have been actively developing since taking a college pascal class at age 11. > If you were a 50 year old coder 10 years ago, then your only hope of remaining in the tech industry would be to add "Manager" to your job title. People outside the startup bubble value delivering, regardless of age. Developers outside the startup bubble work consistently in a few areas of technology, they develop deep personal understandings with cookbook / solution / frameworks they personally authored enabling them to construct stable solutions that expertly address the problems being addressed. Essentially, if you remain a "coder" and you use your brain at all above simply being a coder, you will become a software scientist. I never start anything from scratch, as I have about a dozen application skeletons ready for various specific purposes, plus similar libraries I wrote, plus a knowledge of several large commercial SDKs, and developer experience in several major FOSS applications. The work that I do now would give my 20 or 30 year old self a heart attack with the large scope, number of complex technologies, and the time frame I'm expected to deliver. But I've been writing code for 40 years now, and I may bitch at my tools, but it will deliver, it will be well written, fully documented, and so on because anything less just creates technical debt. If you like writing code, start acting like a scientist about it. Few developers do, and in time you will accelerate away from your peers into a truly enjoyable professional space very few seem to occupy.

riprowan 10y ago
I appreciate your different perspective enormously. I have spent the bulk of my career working in larger, team-based environments. In my experience, being able to conform to cultural norms is essential to being a high-performing team leader or member. Many, many teams have prejudices and / or litmus tests. For example, I've spent decades doing project management. I use Gannt charts. Why? Because they are the best way to communicate timeline expectations with stakeholders. I don't use them to manage the project. But I've encountered more than one Agile team that flat-out considers the use of these charts to be anathema. You might as well crap on the rug. That's just one example. Obviously there are also the buzzword technologies. Here's an overgeneralization you might agree with: young developers tend to naturally gravitate towards newer, less proven tech. Us older developers naturally gravitate towards more mature, established tech. This creates a source of age-related friction. Then there's the inability of others to grasp the applicability of your experience. For example in the 1990s I built a lot of actually awesome Lotus Notes/Domino applications. Now that's a technology that, if you mention it in various meetings, will get you laughed at. However, Domino was kind of the original "noSQL" / "BigTable" world, and it turns out that my application architecture experience in the Domino world translates meaningfully into these "newer" (ha!) database technologies. But try to tell that to team members. So I guess my comments are orthogonal to yours. I agree with pretty much everything you write, but it leaves out the important social aspect.