Hacker News Reader

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

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

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.

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.

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

[1] https://www.scrumalliance.org/community/articles/2013/august...

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

> they do not effectively communicate timeline expectations

Of course, that is in part by design.

If you are delivering solution X that is just an instance of iteration Y of system Z with a few customer-specific tweaks, Agile methods will work just fine in combination with GANTT charts, and teams that are engaged regularly in that sort of work aren't too likely to object.

However, as soon as a task is a known unknown (that is, a well characterized problem with an understood though as-yet nonexistent solution) requiring new code that isn't just a variation on familar themes (ie. whatever is the equivalent of a CRUD web application for your industry), you start having to deal with uncertainty and risk (which humans are very bad at reasoning about). GANTT charts can make things worse because they foster a false sense of control (padding time estimates by x% for example feels like it helps, for example). And if anything in your critical path is a known unknown, your timeline expectations, however consensus-driven and reasonable as they may be, are likely to get smashed to smithereens, and all a GANTT chart is going to do is tell you when your carefully constructed schedule is starting to slip.

Throw unknown unkowns into the mix (from "we haven't yet figured out how to solve this" all the way to "are we even solving the right problem"), and timelines become entirely fictional.

I am not aware of any chart format that incorporates this sort of risk and uncertainty well (FogBugz for example, which incorporates probability and risk based on an estimator's past track record, basically just sticks that data into a chart's tooltips)

Now, if you are willing to mitigate these risks by basing your timeline around deadlines for handoffs with the understanding that what gets handed off is "best effort working system in available time" (in which case continuous integration/delivery is your best friend) that's a different matter, but that just isn't how most projects are concieved or managed. Yet.

BTW, related to all this is the conflict between feature-based and time-based approaches to software releases.

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.

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.

> start acting like a scientist.

I started late (38, 41 this year) and I couldn't imagine jumping from Ruby to Rust to whatever new hotness arrives when it's clear that there are handful of technologies that go deep (enough) and that are being used to solve problems that require someone to be more than a coder or even a dev.

I'm in the connected-car space and the only question I'm asking myself right now is: will my current skill set (mostly iOS in Swift/Obj-C/C) allow me to build for the future of augemented reality in vehicles or will going down the path of C++ -only- allow me to grow as a "software scientist" (perhaps a third way...)? Honestly I don't know, but I do know that I won't/can't find out if I jump into every HN rabbit holes that opens.

> will going down the path of C++ -only- allow me to grow as a "software scientist" (perhaps a third way...)?

I have no idea what higher level language in-vehicle AR will be written in, but C++ may be overkill, or a blind alley, or both.

You might be better off learning one or more of C, Go, Rust, Python, or Java (each has its own advantages and disadvantages) over C++.

> 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

I've had a project manager (very insightful guy) tell me something similar before. He said "as you get more experienced you'll (ideally) write less code and instead reuse code from libraries you've written in the past". I've always wondered how that works for someone? I'm assuming certain projects will have requirements where specific technologies would be used in the front-end and persistent layers depending on the kind of project you are building and so those wouldn't be as reusable but perhaps algorithms you've written before might be reusable on the computational side of things. Like perhaps if you had a library that handles very advanced moving cost calculations you could ideally use that same library in different software forms (mobile, web, desktop, command-line).

Edit: Git might be a good example of a library that can be reused a lot and used within many kinds of applications (IE: inside web app, within IDE, from command-line, desktop app, etc)

Git is not a library, it's a program. There are, of course, libraries in many languages for using git[0] from within many other kinds of applications.

Another example of a library would be libjpeg[1] for reading and writing the jpeg image format and dealing with all the different ways the format can be adjusted, which gets incorporated into many applications, for example ImageMagick[2].

Basically, a library consists of code that is intended to be reused by calling it from other code.

[0] It's astonishing how often this gets reinvented. Here are just Python libraries: https://pypi.python.org/pypi?%3Aaction=search&term=git

[1] https://en.wikipedia.org/wiki/Libjpeg

[2] https://en.wikipedia.org/wiki/ImageMagick

> It's astonishing how often this gets reinvented

Wow, I'd only heard of libgit2 before. I can't believe how many git-related python packages there are. Yes git isn't a library, it's a program like you said, good catch

Everything you build becomes your code library that you carry forward.

Smart devs know this and cultivate their personal repetoire.

For example in the veeeery first days of .NET I had the opportunity to build a nice internal application for a client. Of course I didn't have a .NET library - the tech was just coming out of beta - but Microsoft was nice enough to provide a bunch of "example code" and "starter sites" to give all us noobs some patterns we could work from - at least most of the skeleton of a working, database back-ended website with a working security model.

From this .NET project it was easy to find another, and now I had a complete .NET library with solutions to all kinds of problems - how to do doc management, how to solve image resizing problems in .NET, how to talk to all kinds of heterogeneous systems using .NET, how to implement webservices, etc. because I'd built these once. With that toolbox I could easily solve all kinds of other problems with only a little creative remodelling of the skeleton app.

Then in 2007 when I jumped into OSS I got to start an all-new library building solutions on the LAMP stack. By 2009 I had a nice little library built up again.

The pattern is amenable to any software tech. Every project builds from the last one, if you do it right.

>If you like writing code, start acting like a scientist about it.

Could you elaborate more on this?

I completely disagree with this. I am also a few years shy of 50 and way ahead compared with 20+ year old self-styled "ninja" developers. They simply don't know what they don't know. They truly believe that they are "experts" or "ninjas" because they have read a few tutorials on the latest soon-to-be-forgotten fashionable language/framework. Or believe that framework/language X is truly something new because a "hello world" web application is easy to write. And then a year later, when things get tough and the realise that the wonder framework/language has limitations, they jump ship to yet another shiny "silver bullet" framework/language that will save them from having to actually learn the hard stuff, allowing themselves to still believe that they are "ninjas". Meanwhile, people who actually know their stuff take over the ruins of their efforts and make it work. Rewriting it step by step to fix it.

And how do I know this by the way? Because I have done it many many times in my career. Taking over a ruin build by "ninjas" and making it actually work and bug free in production. Meanwhile the "ninjas" have jumped ship to another company, building a new ruin with some new "better" framework/language. Until of course things get tough and they again jump ship, leaving the ruin to somebody who actually know what they are doing.

Er, one of the best developers I know is over 50. However, they consciously chose that path instead of tracking into management because they like being a principal engineer where that means they still get to work with code, but also have enough experience to anticipate pitfalls and make considered decisions.

Great reply. Interesting how your decision to become a generalist stands in direct opposition to most of the replies to this thread: https://news.ycombinator.com/item?id=13409239

Given that you probably have much more experience than many of the people here, I'm going to assume that your advice is more sound than theirs.

The truth is somewhat in the middle, I think. An experienced generalist is a very different prospect to a graduate "generalist" - in some sense, all graduates are generalists because they don't have experience. See the thread the other day about how many people with physics degrees crosstrain into tech and programming.

Generalism is insurance, while specialism can be more profitable if the speciality you pick ends up in demand.

I must add that I have undergraduate and graduate technical degrees and spent from 1983-2005 building lots and lots of apps (I started coding at ~ age 15). So I pursued "generalism" only after being a reasonably qualified (but not specialized) technologist.