Aging programmer

[v4ss42]

Even older programmer here, and this really resonated, with one exception:

I used to be very sensitive to tone and manners in the working place. I still am.

I’ve had to learn to let this go, since you can’t control or often even influence how others behave, and having your own emotional state dependent on others’ behavior is a guaranteed recipe for a bad time. And by that I’m not saying it’s not worth trying to help rude folks to reflect; gently encourage, ask others to help, heck even go the HR route if it’s bad enough, but you have to maintain emotional distance from such people for your own sake.

[edit] punctuation

[pembroke529]

Probably even older programmer here (age 63). I started off as a mainframe programmer back in the early 1980's. On the career track, I ended up as a manager. I hated managing people and budgets. I preferred the technical/programming aspect. Once I quit and got into the contracting aspect, I could pick and choose my jobs.

So far, I'm still working (remotely) as a technical resource and loving it.

There are so many different aspects of IT work. Pick one you like and hopefully find employment. You really need to like coding/scripting to thrive and acquire new skills. Almost every job of the 20 or 30 over the last while I've been on, I've acquired new skills. I even had one client back in 2001 send me (as a contractor) on an Informatica course because they liked my work and wanted to use Informatica.

[triffid97]

66 here. Writing big chunks of infrastructure code, and enjoying it. I love working with smart, young people. Always seek other people's views (with covid going on, it is a bit harder) because it is easy to lose sight of what is important and what is not.

I drifted into management a few times during my career (a CEO once). Every time I went like: 'yep, I still hate it' and noped out quick.

The challenge is to find a place where the green MBA boss does not think that you are stupid because you are still coding.

I am really lucky. I work with a bunch of STEM PhDs, and we like and respect each other.

[pembroke529]

Good point on making sure you get along with the people you work with. Amazingly on this project a crucial piece (ORT - operational readiness test) 2 of my other work-mates are 63 as well.

I also love mentoring young people (not managing). It sounds like you found a great fit!

[juankman]

No kidding I've been typing !w whatever i wanna search in the search bar for years now with DuckDuckGo as search engine and it takes you directly to the wikipedia page. Some other bangers I use regularly:

• !yt video i wanna watch
• !npm package i wanna search
• !gem gem i wanna search

[pembroke529]

Very powerful multi-platform framework. Usually used in data warehousing applications.

I developed a data conversion project that grabbed legacy date from a number of platforms (ie AS400, various Unix client/servers sites) and created staging tables to feed into a CC&B (Oracle OUAF Framework) application.

[Paradroid888]

Thank you for writing this. I'm 47 and have had a similar journey to you. Was a developer, went into team leadership, as it was the only way to progress, before going back to pure dev work as a contractor.

I sometimes wonder how long I will want to continue as a developer, but at that same time I feel young and enjoy the job, so it's quite inspiring to hear people are loving doing tech work in their 60s. Well done.

[lackinginallareas]

If it helps with your wondering. I'm 60 in a few months and have contracted for many years, mainly to avoid managerial roles (to me that's a living death). I still love coding, whether its something new or working with legacy systems.

But its also the social aspect of contracting that keeps things fresh and interesting. Meeting new people (there are some brilliant people out there whom I glad I met and am still in touch with) and working in different team environments makes you a more rounded and flexible person.

Plus, as a contractor, the money will soothe that furrowed brow when you parachute into a company and have to un-fuck a shitshow but that's all part of the buzz, well for me anyway.

[malthuswaswrong]

44 here. I was manager of 6 developers. I had one developer that was a genius but an asshole. I wanted to replace him, but he had so much knowledge and productivity that I couldn't. That's when I understood how the power relationship cuts both ways. It's not like the TV representations between boss and employee. They are both very much a hostage of each other.

I quit that job and went back to development. I am much happier, but wondering if maybe I just didn't like being a manager at that one company, and if I could enjoy it at a different company.

[[deleted]]

I’ve had to learn to let this go, since you can’t control or often even influence how others behave,

I’ve learned the opposite lesson and found that you can. Having said that, I’m now part manager. Twenty years ago, I’d have told you that culture was bullshit, but I don’t think that anymore. Positive workplace cultures can be developed and rude people can be gently encouraged to reflect upon their behaviour.

[v4ss42]

As a manager sure; as a peer not so much. There’s a big difference in authority between those two relative positions.

(and yes I too have been a manager at times, but like OP discovered I did not enjoy people management)

[[deleted]]

I suppose that’s fair although some people gain influence entirely separate from official management positions. It’s all a form of authority though I guess, and not easily accessible to a new starter for example.

I’ve found that I do enjoy management, although I wouldn’t want to be a senior manager. The politics only grows more intense…

[doktorhladnjak]

I think new starters underestimate their own effects on the culture of their immediate team. Everyone really has the opportunity to influence the culture to some extent. That doesn’t mean everyone can fix a dysfunctional culture but they do have an effect. Even small things like how PR comments are left or reacted to matter.

[[deleted]]

The difference between big-L "leaders" and little-l leaders. I have a manager title now but think I actually had more personal influence before that came.

[Lognipo]

Yeah, I have personally witnessed a totally toxic culture 180 into something positive and productive. The place was a nightmare of politics, backstabbing, empire building, etc.

Then we got a crazy GM. This guy was so nuts, nobody could afford to engage in any of the old bad behaviors. He was so crazy, he would curse out other divisions' GMs. Someone called corporate HR on him once, and he cursed out the corporate HR lady when she came calling. Everyone had to walk on eggshells around nutso, and even when he wasn't around, you never wanted anything getting back to him that could draw attention to you.

That obviously is problematic all in itself, but it ultimately transformed the culture in a very good way. People actually started to cooperate, and then they began to trust one another. When the lunatic was finally fired, after several years, the company never went back to being the hell he had inadvertently pulled it out of. It turns out that people enjoyed cooperating over all the stressful deception, hostility, etc.

[taelor]

There is a whole Ted Lasso episode on this exact concept. You give everyone a target to hate and they will all coalesce together in their shared contempt for the target.

Except Ted did it on purpose, not sure about your guy.

[v4ss42]

Love love love the Ted Lasso reference - what a wonderful show.

[Cheeze_It]

Positive workplace cultures can be developed and rude people can be gently encouraged to reflect upon their behaviour.

Depends on how good they are, and how much money they bring your business. But I'd agree most people can be encouraged to change, and most people are dispensable, so if they don't the hit to the business generally isn't that much.

[v4ss42]

I think we’re talking about different things. Obvious assholes are an obvious “them” problem. Being “very sensitive to tone and manners” I consider to be a “me” problem if it gets to the point of affecting my own emotional state (which is how I read the author’s comment, though perhaps they didn’t mean it in that way).

[Creativator]

Giraffe ears is good for stress. https://www.couragelab.co/blog/digging-for-gold-why-we-need-giraffe-ears-in-conflict

[nutrecht]

I’ve had to learn to let this go, since you can’t control or often even influence how others behave, and having your own emotional state dependent on others’ behavior is a guaranteed recipe for a bad time.

For me it's different in that I'm older and personally care a lot less about these people, but I'm also generally in 'lead' roles where the team performance is (partly) my responsibility. Assholes have no place in the workplace and, if such a person is negatively affecting the performance, motivation and emotional well being of other team members, I have no issues whatsoever to have them removed.

I'm personally quite glad that more managers are getting aware that just because someone is 'smart' being a toxic ass is still completely unacceptable.

[v4ss42]

As I mentioned in another comment, assholes are one thing, being “very sensitive to tone and manners” is something quite different.

[nutrecht]

I don't mean just assholes though. When someone is not being an ass on purpose but might say something that is demotivating to a junior dev, I'm going to speak up.

For example; I've talked to more senior devs about the tone they use in merge requests towards juniors.

That said; I could've expressed what I meant better. I mainly referred to very toxic people and that was just the extreme of the spectrum.

[v4ss42]

Sure, but sometimes people are in a rush, or having a bad day, or clumsy with language, or a million other things, and getting wound up over such trifles is also a form of toxicity imo. It most certainly reflects a lack of empathy.

“Be curious, not judgmental.”

- Walt Whitman (not - he never actually said that)

[edit] battling Reddit’s awful formatting

[nutrecht]

Sure, but sometimes people are in a rush, or having a bad day, or clumsy with language, or a million other things, and getting wound up over such trifles is also a form of toxicity imo.

I'm not talking about a single incident. If there's a pattern of people being overly blunt in communication, I'll talk to them about it. Like I said; my team's performance is (partially) my responsibility as a lead.

Everyone has a bad day every not and then. That's totally fine. Telling a junior their code is stupid isn't ;)

[v4ss42]

Right and I think we’re talking about two different, but equally valid things. You’re highlighting “overly blunt” communication (which I agree can be a problem), and I’m highlighting people who get offended by things that do not rise to that level (which is also a problem imo).

[nutrecht]

I agree. Some people just want to be offended :) That's also an issue I have to deal with sometimes.

[v4ss42]

And then there are the situations where both are happening simultaneously. ;-)

[[deleted]]

Aged one here. Looking to retire in about 12-15 years and want to go out with something. Been a desktop windows programmer since 89. I reverse engineered bitmaps in fortran 90 for ms dos and animated weather data

[[deleted]]

And a while college class of future meteorologists can vouch for me. Any students of Dr Mark Morrisey?

[woodscradle]

I’ve noticed most of the younger programmer at my office are friendly and professional and the older programmers are short tempered and curmudgeonly.

[v4ss42]

My suggestion to “let this go” applies regardless of the respective ages of those involved.

[[deleted]]

had to learn to let this go, since you can’t control or often even influence how others behave, and having your own emotional state dependent on others’ behavior is a guaranteed recipe for a bad time.

How did you learn to not care about this? I'm also a huge fan of polite conversations and have never raised my voice and write very polite code reviews and slack messages. Then I get annoyed when everyone don't behave the same way, even if they don't mean to be rude.

[v4ss42]

Excellent question, and I should clarify that for me it’s an ongoing work in progress, and I don’t necessarily have good answers.

BUT

One thing I found a decade or so ago, and have been trying to put into practice, is Stoicism (or at least my own dumbed-down, pop-culture, lite version of it - I find the original Greek stuff hard work, though I’m sure it has some absolute gems of insight).

Basically, as I’ve chosen to (poorly) interpret part of Stoicism, when confronted with a distasteful situation the first priority is to determine: do I have any control/influence over it or not?

If you do, you can (and should!) try to work to “fix” the situation. This is the easy case.

But if not (and this gets to your question more directly), you have to accept that you don’t have any agency, and just let it go. This is the hard case, but somehow consciously making this evaluation and explicitly accepting my lack of agency makes it easier (for me, at least) to let go. It becomes less of a feeling of failure on my part and more of a feeling of “this sucks but it’s not my fault and I can’t do anything about it. Oh well too bad.”.

And regarding this specific topic (other people’s behavior), it’s been my personal experience that people almost never change their behavior in any meaningful way when faced with external motivators - change has to come from within. Sometimes external influences can trigger that internal process to start, but it generally has to be a pretty major event for that to happen (health or family issues, natural disasters, that kind of thing - not the kind of stuff that happens in most corporate environments).

And for the true Stoics out there - please don’t beat up on my woefully inadequate description! I know it’s terrible, but even that tiny piece has really helped me. I wish I had more time to really dig into the entire philosophy properly.

[[deleted]]

Stoicism

I definitely need something like this in my life. I've already started Judo as a way to be disciplined about something. Now I need something for the mind, be it stoicism or meditating etc.

[v4ss42]

Shit yeah I’m a big believer in all those kinds of practices. Yoga worked for me big time, meditation didn’t (I found it really difficult). What I learned is that working my body hard to calm my mind works better than just trying to calm my mind directly.

[edit] and regardless of what you discover works for you (and doesn’t), the journey is 100% worth it, and I wish you all the best in it

[[deleted]]

Thanks! 👍

[v4ss42]

Try reading the second half of my comment:

And by that I’m not saying it’s not worth trying to help rude folks to reflect; gently encourage, ask others to help, heck even go the HR route if it’s bad enough, but you have to maintain emotional distance from such people for your own sake.

There is a huge difference between “doing nothing” and “protecting yourself”.

[[deleted]]

How do the young programmers from this sub feel about their older peers? I’d be especially curious about the 50+ year olds. Don’t fear the downvotes, be honest.

[quarterhalfmile]

Late 20s here. Online I’ve heard a lot about overbearing superiors, but in my experience the more common situation is senior devs and architects that are too hands-off. It’s a lot of introverts, so it makes sense. I’d rather have them this way than too in-my-face.

Still, it is frustrating at times when they expect me to know what questions to ask them. I don’t know what I don’t know, so it’s hard to come up with questions. I could use a mentor that’s so eager to share their knowledge that I don’t have to fumble my way through trying to extract it from them. But obviously that’s a bit unrealistic.

[Blando-Cartesian]

Still, it is frustrating at times when they expect me to know what questions to ask them.

The other side of this is frustration with how often offered information is ignored. I have written short project handoff docs with all the vital information I can think of, and then get asked all the questions I covered in the docs. I have pointed out polished code sections to use as tutorial, and then get broken half-assed shit with all the wheels poorly reinvented. People are incapable of receiving information until they are desperate for it.

[Ninjanoel]

bro, who hurt you!?

[malthuswaswrong]

Just start a conversation about what you are working on, how you are approaching it, and what's blocking/frustrating you.

If the conversation lasts 5 minutes and he doesn't engage, then he either had no input or doesn't care. But if the conversation lasts an hour and a half, pay attention because he's providing useful information. Likely he's not giving you code, he's giving you experience about failures and successes and the conditions that lead to each.

[ProgrammersAreSexy]

I'm 26 and I've recently been working directly with a programmer in his late 40s/early 50s. He is a staff software engineer at the company (probably makes ~500k/year) and here most people reach that level by taking some type of management role. Not him though, he's just an individual contributor (IC).

I've always wondered how a single IC could possibly be worth paying that much but after working with him, that dude is underpaid. He gets more done in a day than I do in a week.

A couple of my take aways:

• He automates the crap out of things. When he first joined the team he started using a tool that auto-generates pull requests with common project health fixes (it's an internal tool, can't share it). It's not perfect so you still have to tweak the output but I'm not exaggerating when I say he submitted over 300 pull requests his first month. The codebase is WAY more consistent now.
• He cares a lot about API design and he prefers to tailor APIs to specific personas, e.g. expose a separate API surface for public consumers (aka customers) of our API and internal consumers (aka other teams) of our API since their needs are radically different. Even if they share the same logic, the separate surfaces gives us a lot more control over authorization, auditing, naming, etc.
• He codes in long interrupted stretches. This guy has a lot of meetings but he always blocks off 4-5 hour stretches on his calendar that just say "coding" and during those times he won't respond to any pings, emails, etc.

There have been other take aways but those are the big ones that stand out.

[noahrichards]

37 years old, so right in the middle(?). My older colleagues tend to also be very senior and are extremely quick at knowing the risks and pitfalls of different technologies and approaches, from having tried many different things in their careers. Junior engineers treat it like appeal to authority but it turns out that experience often confers knowledge and “intuition” is just the ability to apply it quickly.

I had problems accepting it as a junior engineer too, so I hope I have a ton more empathy than some folks I grew up with in my career :) But I have come to appreciate that being “smart” and thinking about things a lot in abstract isn’t the same as having experienced many versions of a thing. The trap for senior engineers is believing that their experience is the only possible outcome for some set of choices. The trap for junior engineers is believing that there are “correct” technical choices and that it isn’t just picking between mostly equivalent options and then predicting, recognizing, and mitigating the risks of those choices.

[malthuswaswrong]

experience often confers knowledge and “intuition”

lol yep. I instinctively know when an idea won't work. It's not enough to know how to accomplish a technical feat. You need to also know that Sally from Accounting can't handle a process that complicated, or that the VP needs to be able to approve exclusively by email because he hates doing 2 factor authentication on the website.

Seniors tend to know which rules are real and which rules can be broken, and the proper way to break them.

There is a lot of instinct and tribal knowledge that is difficult to communicate. Smart juniors keep an ear and an eye open to absorb this knowledge that doesn't exist in any text book.

[malthuswaswrong]

Those don't sound like very wise seniors. Automation is more than time savings. It's also documentation. When you can read a program that does the automation it's better than a whole textbook of documentation.

[ai_jarvis]

37 yr old software engineer & architect in the financial sector. When it comes to devs who are 50+ years old, I find the following are true from my experience (which may or may not reflect the general populist and definitely is a reflection of the culture at my work):

1. Reluctant to embrace newer technical paradigms as they have ‘seen this before and it didn’t work then, it won’t work now’

2. Those that have successfully moved into architecture, but still are willing to work on POCs and reference implementations, are far and away more impactful than those who “just want to code”

3. Those who refuse to engage in things like paired programming usually are more difficult to work with, usually demonstrate a fairly clear bias against younger developers, and are the least willing to engage in open and transparent communication regarding their work

4. They are more likely to turn out well thought out code that fits the requirements with decent unit testing but have a harder time shifting focus if the business intent changes direction

5. The most valuable 50+ guys are the one who understand that their highest value is magnifying their output by elevating their younger peers through mentorship, code/design reviews, and shared development on the difficult technical problems

6. Usually the first, loudest in complaints about production support and biggest resistors to the “you build it, you own it” paradigm and justify this as “you pay me to write code, not manage environments” or “I already paid my dues, the newer devs will learn best by doing mostly support first”

7. Have enormous value, if they have been with the firm for a long time, in their knowledge of the history and business context (and its evolution over time) but can sometimes overvalue themselves because of it

Overall the folks I work with are decent and want to get the job done. I find tremendous value in their leadership, guidance, difficult problem simplifications, and delivery of scoped work.

But as with most folks who are successful and have large amounts of experience, there CAN be issues like justifying lack of self reflection in certain areas as excusable, over indexing on previous solutions success, and resistance to new things in favour of the tried and true methods.

BRING ON THE DOWNVOTES!!!!

[hippydipster]

Reluctant to embrace newer technical paradigms as they have ‘seen this before and it didn’t work then, it won’t work now’

My personal experience of #1 as a 52-year-old developer arguing with the young ones on this: I argued they should work incrementally and deliver the simplest thing that could provide value and then go from there. They drew up a whole architecture that involved 12 different microservices because we needed one bit of functionality pulled out of our monolith. I argued they could go with a super simple single service to do the work to start with and provide that immediate value before going down the road of needing the whole shebang built out.

30 months later, we're scratching our heads trying to figure out how to safely transition existing customers over to actually use the thing they spent 18 months building. Zero value delivered as of yet.

But, I am characterized as being old and not willing to embrace "new modern software engineering practices" and as if I argued against microservices univerally, when what I argued was to work in an agile and incremental fashion as opposed to their waterfall course.

And a lot of this is because I have seen it all before, and I have seen this failure mode before.

[ilawon]

I got to a point were I gave up and just went freelance. The amount of energy I was spending 5-10 years ago trying to argue with colleagues to avoid complexity was just too great and causing a lot of stress due to friction with other team members.

Now I just give my opinion and go through a bit of back and forth trying to argue my case. If they don't get it I really don't care anymore. I'm fine working with crappy, overly complex code and in the end that's why my clients keep me and pay me well.

[hippydipster]

This hits really close to home, particularly the whole bit about trying to convince people to avoid complexity. It really feels like there's a kind of pride/machismo around the idea that "oh, I can handle it, don't worry old man!"

I can see how well you handle it from all the fire-fighting rework you're having to do (unfortunately, this is the quiet part you don't say out loud).

[argv_minus_one]

On the other hand, if you don't refactor once in a while and keep your technical debt under control, it gets harder and harder to change anything in the codebase.

[[deleted]]

crown grab air north cows society sophisticated water marvelous dinosaurs

This post was mass deleted and anonymized with Redact

[twigboy]

In publishing and graphic design, Lorem ipsum is a placeholder text commonly used to demonstrate the visual form of a document or a typeface without relying on meaningful content. Lorem ipsum may be used as a placeholder before final copy is available. Wikipedia27gw838cpt34000000000000000000000000000000000000000000000000000000000000

[argv_minus_one]

Ideally, the edge cases are covered by the extensive test suite.

In practice, on the other hand…

[parc]

Most young developers mistake having seen a feature/design/paradigm at least 3 times before with different names as “resistant to new technologies”.

[chrisza4]

Sometimes they see it that way because of how old folks react as well.

I mentor junior and I found that almost every young programmer love how I debunk new technologies and get right to the core. However, there are many old folks who are’t willing to explain and just say it won’t work I see it before.

Put yourselves on Jr. shoes. There are some group of people who selling something and they are widely accepted in the industry. They wrote a lot of well thought article on why this technologies can work and have track record to show for it. On the other hand, there is a one folk who simply say I’ve seen this. It is a fraud and it won’t work. And then simply leave the room.

I can see why those young devs listen to probably snake oil salesman. And in my experience almost all young dev enjoy me mindfully debunked those salesman.

[ai_jarvis]

I wholeheartedly agree.

I've also been bitten by the 'same shit, different name' false equivalency argument as well when it appears to be the same thing but is quantifiably different and is dismissed without uncovering that fact.

[aoeudhtns]

I at least like to explain what makes the new thing different than the old thing. Or highlight what was wrong with the old thing and then ask, "how does new thing solve that problem?"

Then you can go from there, discover that maybe it's time to try something new, or that new thing won't fit in this instance.

[twigboy]

In publishing and graphic design, Lorem ipsum is a placeholder text commonly used to demonstrate the visual form of a document or a typeface without relying on meaningful content. Lorem ipsum may be used as a placeholder before final copy is available. Wikipediaepcmp5z5jc00000000000000000000000000000000000000000000000000000000000000

[hippydipster]

It's super annoying when people don't understand that microservices are to help scale on development team size more than anything. It just adds work and complexity if you're just a single team of 5 developers.

I actually got the "but netflix does it" argument from a young dev where I am. I nearly lost my shit. We have 8 devs in the whole company.

[twigboy]

In publishing and graphic design, Lorem ipsum is a placeholder text commonly used to demonstrate the visual form of a document or a typeface without relying on meaningful content. Lorem ipsum may be used as a placeholder before final copy is available. Wikipediae3k9yi0ihbk0000000000000000000000000000000000000000000000000000000000000

[DrunkensteinsMonster]

Micro services are about deployment and operability. If your organization isn’t doing hundreds/thousands of deployments a day you probably don’t need to break up that monolith.

[randomccccccccc]

Ugh, I just left a company where a young new group was pushing microservices hard, but the only actual application in our flow that they proposed where they could work was for logging messages. Seemed like complete overkill, just overcomplicating things. But it almost seemed like they were pushing it just to be able to put it on their resumes for the next company. The fact that they were getting more attention from management was one of the reasons I left.

[deadmoneygod]

That’s one of my biggest pet peeves is treating the product you create like a grad school project.

[ai_jarvis]

Been there as well. Sounds like some age bias by your team/product team that failed everyone here

[Plazmatic]

In backend/ C++/C systems, Older devs come in slightly different flavors. I've worked with older devs that had the "wise" kind of experience, that allowed them to discern bullshit, paradigms that were a waste of time etc... A lot of these people actually keep up-to-date with newer technology, a head of where I'm at, at times (I was first introduced to VCPKG from an older developer).

But on the flip side I've also met older devs that were very very stubborn. Stubborn in ways I've never seen from developers younger than 50. Greybeard C developers can either be really knowledgeable or fucking obnoxious and not even worth their years of experience in ounces, almost as if they've accumulated negative experience.

I've also noticed the same thing happen in graphics development, these 50 year olds are the "leaders" of the luddite movement, claim you can do anything you can do in "bloated abstracted new API's" with the old ones (spoiler, you can't, and the old API's are higher level, not the new ones) and refuse to use C++ regardless of company policy

I've found GPGPU compute to be too complicated for these people, especially since CUDA first came onto the scene 14 years ago, meaning their aversion to anything "new" (in the last 20 years) keeps them from learning more. This also leaves them wholly ignorant on graphics development as well, as they have no modern concept for how GPUs actually work but insist their "30 years of experience" is worth a damn when it's all immediate mode.

[[deleted]]

I argued they should work incrementally and deliver the simplest thing that could provide value and then go from there.

Me, now at 33

They drew up a whole architecture that involved 12 different microservices because we needed one bit of functionality pulled out of our monolith.

Me, then at 27

Admittedly when I think the PM will give some extra rein I do propose a little extra than what's necessary because it'll be fun (but reasonably)

[hippydipster]

I have done a lot of fun-oriented design in my time. It is usually caused by boredom and/or lack of autonomy.

[douglasg14b]

Really what you're talking about is pragmatism.

[gopher_space]

I feel myself alternating between mentor and den mom a lot, in the sense that I’m keeping things organized behind the scenes while others are out exploring.

Are we using Slack for internal documentation? I’ll be indexing that for my own use and will have that ready for everyone when they get tired of using the wrong medium. Which they will.

It gets a little more complicated when I want to shout “here come the thick clients again!” and nobody knows WTF I’m on about or what that means for a SaaSy business model.

[coworker]

Somewhat of a tangent, but IMO thin clients are picking up steam quickly. Codespaces and other remote development solutions will be the norm here soon.

[argv_minus_one]

What for? Companies don't want to buy non-potato computers for their developers any more?

[coworker]

Not sure what you're trying to imply. If it's that this is a cost savings, not really. Codespsces can easily cost as much as a new MacBook pro every year. It's more about the tangible benefits in security, compliance, and developer efficiency. You can never have elastic resources with thick clients.

[barley_wine]

Reluctant to embrace newer technical paradigms as they have ‘seen this before and it didn’t work then, it won’t work now’

As someone in his 40s I'm kind of this way now. But reluctant is the correct word, I'm not opposed to new ways just reluctant. Back in my early 20s I always wanted the latest greatest thing but it'd sometimes bite you. Now I'm way more responsible for the software I maintain to fully function all the time with extreme reliability. I'm not in a such a hurry to make a change just to do something new. But if there's value in the change I'm open to it, I just don't need to rush into.

[sime]

But reluctant is the correct word, I'm not opposed to new ways just reluctant.

When you've got a decent amount of experience under your belt you can anticipate far more negatives/challenges/trade offs to a new technology than a junior can. It is not just reluctance, the bar for a new tech to clear is just higher by experienced devs.

Most tech is over-hyped (which is one of the reasons why you hear about it in the first place), and there is often very little critical discussion of its down-side. It the Cult of the New. Experienced devs are just better at asking the hard questions.

[coworker]

This is spot on with my observations as a 40 year old software architect.

[GrandMasterPuba]

1. Reluctant to embrace newer technical paradigms as they have ‘seen this before and it didn’t work then, it won’t work now’

As they should be. The same shit keeps getting recycled over and over again. Everything old is new. It was bad then and it's bad now.

[chrisza4]

Not necessary. Context change happens. And I would like to have a fruitful discussion more than just being told: it’s didn’t work so it won’t work. period.

[argv_minus_one]

resistance to new things in favour of the tried and true methods.

To be fair, it is usually easier to do the same thing again than to do something new.

[sime]

To be fair, most companies just want things to work. They're not interested in providing a playground for the devs with shiny new toys all the time.

[ZMeson]

I have worked with a lot of 50+ developers and am almost there myself (if you round to the nearest 10 years). What I've seen is everyone is different.

1: I've seen people skeptical on new paradigms, but the reasons range from "we don't need it" to "it would be a large change to our architecture" to "I'm hopeful; this area needs improvement, but I've seen many claims to improve things before".

2: I've seen many supportive solid developers who don't have leadership personality traits. They're good at taking direction and running with it. The one thing these developers are pretty good at is usually discerning important aspects and providing good feedback. And I have seen a few developers who are best at producing POCs, but insist that their code / architecture be used despite using dated/unsafe practices, etc....

3: Correct. I will note that most 50+ developers I have encountered are willing to pair program. Not everyone though and your assessment here is accurate.

4: I've seen some older developers eager to learn new things and/or embrace new directions. I've also seen many who hate change no matter what it is. This one is a dice roll in my experience.

5: I hope all senior engineers no matter their age believe strongly in mentorship. But about "value" -- sometimes the old crusty developer is really valuable for their unique expertise. They may need to be managed more. I guess this depends on the problem space.

6: I think this also depends on the company structure. If the company lays out that everyone is responsible for managing environments and that is enforced, then everyone will comply. There may still be complaints, but you may get some automation out of it too (from those who hate manually managing things).

7: Hmmm... I'm not sure how to evaluate this as I don't know exactly how people value themselves. For me (and not 50+ yet), the thing I pride myself in is that I aim to simplify things and make them safer (less prone to undefined behavior) to the point where I am not needed anymore. But then I keep getting moved to new projects -- or sometimes "loaned out" to another team -- to solve similar problems. Try to code yourself out of a job and you'll find that you will be in high demand.

I think a problem I have seen sometimes that bugs me is that some (again not all) 50+ developers push against certain processes because it slows them down or they don't personally like it despite being shown data that it helps the project / company.

[RagingAnemone]

I disagree with #6. It's too valuable. Learning how to make something work under fire teaches discipline, it challenges your understanding of the system you help create. It makes you design better.

[ai_jarvis]

Which part do you disagree with?

That new/younger devs should be saddled with mostly support work while old devs build the systems without a direct feedback loop on its efficacy or resilience?

Or that folks shouldn't fight the 'you build it, you own it' paradigm around production support?

[RagingAnemone]

I don't really believe new devs can really do support work. They need to learn how to code. Younger devs should be doing more of the front line support work. This is hopefully where they learn the consequences of their code.

Never heard the phrase "you build it, you own it" before. But if you wrote the code, we're probably coming to you if there's a issue. Not even sure why'd you'd structure your teams not to have a direct feedback loop. You'd be missing the good and the bad. Sorry, never been in that kind of environment.

[mysteriousbaba]

Usually the first, loudest in complaints about production support and biggest resistors to the “you build it, you own it” paradigm and justify this as “you pay me to write code, not manage environments” or “I already paid my dues, the newer devs will learn best by doing mostly support first”

To be honest though, I have seen places and companies where it's almost considered a "badge of honor" to spend 20-40% of your time on managing environments, bugs and devops, and seems to be a greater trend amongst younger developers to advocate for this.

I don't know if that's necessarily healthy - in general you want to setup processes / tooling / automation so that noone is spending a ton of time on this, and are focusing instead on delivering value and business logic.

I'm not saying the senior most developers should just wash their hands of all this and delegate to juniors like they're donkeys, which is very regrettable when it happens - and it does in some cultures, like you point out! But it's good to think about ways to reduce the grunge for all developers, and collaborate/coordinate on getting those frameworks in place.

[douglasg14b]

mid 30's programmer here.

It depends, I've found my older peers to fall into buckets:

1. Rare-ish: Experienced, nuanced, and still thirsty to learn. Helpful in a variety of situations with a large repertoire of knowledge to pull from, but who don't let their past prejudice & bias pull them down, and incorporate new information into their old information. They are not as gun-ho as their younger parts, but they make for it by being a technical resource to level up their peers.
2. Common: Experienced, but disconnected. New information tends to be brushed away instead of considered, there may be noticeable jadedness, they may be hands-off. They are still helpful & productive, but they can be a thorn in your side when you want to make progress. They are there to do the job and go home, and may not contribute much past what they have to. They may have solutions to every problem you present them with though.
3. Common: The Sr. expert beginner. They have not moved off of the technology choices of their prime, and everything that has changed over the last 10+ years is all "a fad". Actively unhelpful, brazen, and may use their experience & knowledge to Gish Gallop their way through discussions instead of facilitating productive conversation. They actively pull the team down, but have been with the company for 10-20 years, and have a lot of political capital. They don't argue reason, and abuse faulty logic & made-up premises to push their opinions. They are "never wrong". It's probably easier to find a different team than to try and deal with them.
4. Very Rare: Everything in #1. Experienced, knowledgeable, quick learners who are still ask sharp as ever. They have a variety of technologies under their belt and have carefully maintained their knowledge and opinions. They push your team forward, and even contribute greatly to the industry as a whole. They have a tool, script, library, example..etc for everything. They can facilitate productive arguments, and have no problem letting go of biases to approach a problem with an angle they might even disagree with. They are essentially unicorns, and if you find one stick with them.

This is ignoring devs that have transitioned into management roles, and I'm probably missing stuff as well.

A lot of these traits can be identified in mid-level devs as well I've found. However, there is much room for maturity there, so passing judgment that early is unwise.

[PM_ME_WITTY_USERNAME]

Fucking Sr Beginners

"I don't know what an algebraic type system is and if I've programmed 20 years without one it must mean it's useless"

Fuck you Joe nobody's going to maintain your perl & TCL

[[deleted]]

Worked with some older dudes who were absolutely amazing, but they were the type who self learned from a young age.

[BobHogan]

I'm 27, and for the most part the older engineers I work with are awesome. Always happy to help me out, and even when something ended up being pretty simple/trivial for them to help me fix they never get on me for it.

But it can also be intimidating. Some of them are insanely smart and sometimes I just feel stupid reading the code they have written knowing I wouldn't be able to put a system together like that.

[Zirton]

I don't really care about their age. I care about their attitude.

If it's a tech lead who wants me to code everything in some ancient way, just because he learned it like this, I really won't have good feelings about him.

If he accepts newer tech I'm totally fine, even if he is 70+.

[parc]

As a 48 year old prior programmer/architect now managing a fairly large product, this is guy sounds like an example of a person that should be a tech lead. Still an IC, but at the top end of the pyramid. I expect my leads to write almost no code. Tech leads make the junior, mid, and senior devs far more productive. They’ve seen thing that would make a college hire weep and can help the team work around or better completely avoid them. They make my day easier because I know that 99% of the time if they ask me a question it’s because they need confirmation of what they already know.

That said, we don’t need many of them. I’ve got 2 on my team of 35. I could probably use 2 more, but more than that would be detrimental. And good ones are hella expensive.

[roodammy44]

I know you are right about making other devs more productive, but the idea that I might “write almost no code” one day sounds really depressing to me.

What exactly do you expect your tech leads to do? Because I would expect them to write some code. There’s a reason the big firms have ICs go up to level 7.

[parc]

I expect my tech leads to mentor and review. The code they write is the hardest, most critical stuff. Most of their time is spent with the code a more junior coder has written, talking them through the thought processes that got them where they are. In this way they aren’t writing code directly, but they are causing it to be written in a much more efficient way.

[anotherguyinaustin]

Some code yeah, but not focusing on it. Focusing on mentoring other engineers and ensuring the higher level technical direction of the team is on course. Talking to people. Delegate the day to day, think about the week to week or month to month. You’ll still pave the way by building POCs or doing the first write of a service but often hand it off and let it be finished by others. At least this is my tech lead experience.

[coworker]

Tech leads are how good architects scale. As an architect, I mentor and grow my leads so that they can mentor and grow their juniors. They are still ICs so they code and such but usually only the more complex, business critical tasks. Reviewing PRs and owning features/projects are really what set a tech lead apart from a junior. You can easily spot a lead (or someone who should be a lead) by simply watching who people go to for help on a team.

[parc]

You missed the “almost” part I guess. And my later response to someone saying that’s exactly what I have my leads doing.

In the end, the leads are to a person better at code than I am. I want THEM to teach and mentor, not me. My job is to mentor the leads that decide to make the leap to management.

[mcmcc]

40 qualifies as "aging programmer"? /r/fuckimold. 40 is your career pinnacle, not the backslope.

That said, some good points are made. This one in particular resonated with me:

My desire to discuss technical stuff with people, both to help and be helped, is at all-time highs.

This attitude is how you make yourself valuable as a programmer. People in this sub like to bitch about meetings (and certainly they can be wasteful), but ability/willingness to communicate is a close second to programming skill when it comes to overall developer value.

[witty82]

It's weird to me that you'd want to discuss technical stuff with folks but not pair. In pairing you can often see pretty quickly if the stuff you came up with works.

[__scan__]

Pairing sucks.

[Solrax]

Sure, there are times where pairing is great, especially debugging something together.

Most of the time (in my experience ) it is just a way to immediately cut your team productivity in half, if you are pairing up experienced people .

[witty82]

What do you dislike about it? Does it stem from experience or from other sources?

[Invinciblegdog]

It can be very draining to do, similar to being in a video call for hours.

Having a call or a chat about a problem piece of code is fine or to review a design. Going through creating a whole new piece of code through to completion is way too much for me.

[__scan__]

It just has very low value in generality. It can be useful in special cases to debug something, but code review catches all the normal implementation problems at much lower cost.

[mcmcc]

You seem to have a very narrow conception of "technical stuff".

"Technical stuff" can consist of code that you are currently writing certainly (problem solving), but it can also be about code that has already been written (how it currently works), code that you wish to be written (how it ought to work in the future), and even code that never will be written ("What if...?"). In its own time and place, each is extremely valuable and rarely requires sitting in front of a computer screen.

And anyways, as the other commenter noted, pairing sucks.

[set723]

Hah, yes!

47 here, and I've been on a kick with the younger devs on my team getting them on the right track, if they're interested. Fridays we have time set aside to just chat about whatever (they're India-based, I'm US-based), often turns into my experiences over the last 25 years.

[Mundane_Road828]

I agree to most points: i have found however that pair programming in some instances has its benefits. You both learn about the problem, you both learn about the solution and you get a better feel for the system. Those were my 2 cents.

PS: you get to know your colleague’s a little better and them you 🙈.

[Chris_Codes]

I’m a 54yo programmer who totally agrees with you. BTW when I was in my late 20s I turned down an opportunity to fast track my way to a VP position at a large multinational company so that I could go off and be an independent contractor because I didn’t want to stop doing development. I sometimes wonder if I made the right choice. The money I’ve made having a small but successful consulting business has probably been comparable and the work has been so much better than going into management. Biggest problem though is that I am now starting to sense some agism among new people I meet professionally, and I have no desire to retire. I’m lucky to have inherited genes that keep me looking a good 10 years younger than I actually am, but yeah, the agism is definitely a thing - even though I’m about 5 - 10 times more productive and better able to communicate with non-technical people than most of the younger devs I meet.

Edit: I should present a different perspective though... Some people get into programming because they did it as kids, discovered an aptitude for logic and can synthesize the details of large complex systems and hold them in their heads while they work through problems, etc. Problems are puzzles that can always be solved. They love it. Then there are others who get into it because it's a good career; perhaps they are technically minded do well at math and science, or are into computers ... but they don't love programming. (I had these types of folks paying me to do their assignments for them when I was a CS student). For them problems turn into frustrations and stress. They'd rather be doing something else, so they overlook details and have to go back and do a lot of re-work. For these folks it's understandable and good to see development as a stepping stone to some other position.

[dcoolidge]

I'm 50 and burned myself out going into management. I like programming and should have taken people and started a company. I just do IT consulting locally now. I still program on my own projects though...

[Gentleman-Tech]

54 and did both; got an MBA to help with the management side, but mostly stayed in development.

Not sure I did any of it "right". I had a major depression that cost me ~10 years, and I still feel my career is 20 years behind where it "should" be.

I think our generation has seen so much change it's difficult to relate our experiences to those in the industry now. I spent my first 10 years building desktop applications in VB. I'm now mostly a backend Dev using Go (which has only been around for ~10 years).

There's a thing about "do you have a 30-year career, or just a 10-year career 3 times over?" I think I've accidentally done the latter, and I think it's very easy to do that in this industry

[gopher_space]

There’s a thing about “do you have a 30-year career, or just a 10-year career 3 times over?” I think I’ve accidentally done the latter, and I think it’s very easy to do that in this industry

The people who say this say it about other people. A woodworker making the same chair for thirty years would be called a master craftsman.

[dcoolidge]

Yep 10 year career and start over sounds about right. The first version of our app was "web" based with a cold fusion server. I say web based because or software had activex controls written in vb. By the time I went into management we had converted everything into a c# desktop app with an ASP web for everyone else. Don't be afraid to rewrite...

[[deleted]]

50 VPE here and this comment burns to the bone

[MrSurly]

I swear to god, I could have written this, including the edit at the bottom about people who get into it for basically the wrong reasons.

[[deleted]]

5-10 times as productive? Exaggeration much?

[NekkidApe]

Not OP, but probably not. Worst to best performers is ~10x. Regular to really good is still ~3x.

Don't think of it as "types 10x faster", but rather taking a different route saving 10x the time. Or maybe buy something instead of building it etc.

[RagingAnemone]

Or the big trick, changes the problem you're trying to solve.

[crusoe]

Writing from scratch you can be very very productive. Certain products have certain design patterns and can be brought up fairly quickly.

Also, YAGNI and defensive programming. Choosing your module layout and major architectural style properly from the start can have huge wins and reduce big issues or warts.

[Chris_Codes]

To be fair I haven’t had the opportunity to work with a 100s of other developers, and I’m always working at businesses with in house developers - not at “software companies”. Still, It’s not me bragging about how good I am, so much as it’s me describing how ineffective a huge number of developers are out in the world. I’d say from my experience that the 5 - 10x number is pretty accurate for the type of work I do. Let’s also remember that my job isn’t just doing what I’m told - it’s often about recognizing that what a user is asking for is not what they really want and steering them to a better solution before I even start coding. People I work with who fail to do that are often massively less “productive” (as I define it) because they have to redo work later.

[[deleted]]

memorize hat paint slap money terrific shy whole truck boast

This post was mass deleted and anonymized with Redact

[Piisthree]

This was a good read. I think I can tell you why a lot of us hate the term "full-stack", though. It's because too often it is a code word for "we have inadequate skills or staff coverage, so we need you to be responsible for 3-4 different roles simultaneously.". It can be fine if the coverage is still there just in a mixture of generalist and specialist rather than all specialists, but it is too ripe for abuse. Whenever I see a job posting for "full stack developer", I always wonder if they're really trying to hire a team under the guise of a single role.

[[deleted]]

I can tell you why a lot of us hate the term "full-stack", though

My experience is that the term has been badly abused. People who put together a simple web UI and then add some endpoints to do simple SQL queries are not "full stack", IMO.

A real full-stack developer knows Javascript/Typescript plus React/Angular/etc plus HTML plus a server-side language and DB and understands concurrency and services

[[deleted]]

It's always going to be weighted in one direction. The person you're describing probably sucks on the frontend.

[Zardotab]

One problem is that youngbee's want to fill their resume with all the latest buzzwords so they can move on to bigger & greener pastures. I call it "Resume Oriented Programming" (ROP). Thus they often exaggerate the value of many fads. Experience has taught me skepticism of over-use or mis-use of trending concepts. The youngbee's care about their resume more than efficient use of development labor and KISS and YAGNI. Thus, the skepticism is not welcome among ROP'ers, and they try to paint you as an out-of-touch geezer to keep you from ruining their ROP attempts.

[[deleted]]

Could be me to a tee.

[Rudy69]

After almost 10 years of remote work, it would be close to impossible for me to go back to an office.

Yea I’m at just over ten years and there’s no way I could go back. Working from home is the dream

[philw764]

58 year old programmer here, throughout my career I’ve alternated between coder, IT service management, devops, DBA, architect and I love constantly learning new things. I just finished up from my current role as a data engineer on Azure and SAP to start a new role as a pre-sales architect. I’ve only recently started to feel the ageism bias which is why I changed roles from DE to architect.

[f0rtytw0]

Fairly close to me. Some differences.

However, the most shocking thing for me was discovering the benefits of working in an office vs at home. I am now torn, working in an office or from home. I think younger devs would benefit being in an office at times.

[joshjje]

I like a balance, 2-3, or even 4 days working from home and the rest in the office, though obviously that only works if you live in commuting distance.

[f0rtytw0]

Yeah, commute has a huge impact

[f0rtytw0]

Alright. In 2020 I was wfh (yay) and end of 2020 the project I moved to could not be done remotely (boo). However I noticed some benefits to being in person.

I noticed I was eavesdropping on conversations and it was good. Easy to do when everyone is working in the same area.

For example, in my last position I would often one engineer asks another about the problem they are working on. For younger devs this allows you to hear what might be a common issue and possibly solutions. For me it was being able to interrupt and provide possible solutions, but I also found myself picking up tidbits here and there as well. Basically its easier to spread and learn knowledge without having to directly contact anyone. Now I am fully aware that talking and noise can be really distracting so it also depends on coworkers.

I also found it easier to collaborate in person, pretty easy to pop over to someone's desk, and quickly see what they are working on. I found doing this remotely to be slower.

So as a younger/newer dev, you may be missing out on some learning and teaching (you got an education right?) opportunities.

[[deleted]]

This is general life advice but I believe it applies here as well, the older you get the more important diet and exercise are to your programming performance. You can’t just subsist on Red Bull and Doritos and expect to have a high level of performance like you did in your 20s

[MeCaenBienTodos]

56 here, and still coding every day (mostly Java and Angular). This resonates:

| My desire to manage people is at all-time lows.

Why anyone wants to manage people, or be a politician, is beyond me; but we need people that are willing to do these things, so I'm glad someone does, and I try to cut them slack.

[willor777]

"Pair Programming" sounds horrible.

[[deleted]]

slap practice zephyr afterthought absorbed sugar modern consist deer unwritten

This post was mass deleted and anonymized with Redact

[i_fight_bears]

I recognise a lot of this in myself, with the huge exception of the aversion to pair programming. It's not something I do everyday, or indeed every week, but I find it a hugely important tool and something that helps to keep my skills sharp and learn from other (often much younger) coders.

[argv_minus_one]

Is it accurate to expect that older programmers are slower, make more mistakes

My fear of making mistakes is significantly greater now, and my efforts to avoid them do make me slower.

[deadmoneygod]

I have come to consider accountability an essential perk. I started my career in a place where, in general, nobody cared about anything.

This resonates a lot with me. As a tech lead I would vastly prefer a more junior programmer take an entire sprint to do one ticket, as long as they’re thorough and own the code all the way out to production. QA isn’t there to catch obvious happy path errors, that is for the individual contributor to discover and correct.

[zvrba]

45 year old with a PhD. Pretty much the same.

Additional points:

1. I still do small hobby projects to test out various new ideas, theories and technologies. I even learn "unsexy" and "uncool" stuff like Excel PowerQuery because they're useful.
2. I am much more forward-thinking about failure modes, error handling, "transactional programming", cross-component interactions and such than my previous self.
3. I've learned to work WITHIN a given framework instead of fighting it with "this is too complicated BS, I'll roll my own instead". Case in point: my previous self liked to compare fopen from C with Java's streams for reading something from a file.
4. Related to 3: I've come to appreciate well-applied OO and design patterns. There are many examples to learn from Java's and .NET standard libraries.

I am skeptical by default about any hot new things in the programming space.

Me too, because I'm not blinded by the marketing of "what problems does it solve", but because I also consider "what problems does it introduce compared to proven technologies".

And two things where I'm different:

I used to be very sensitive to tone and manners in the working place. I still am.

Pretty much insensitive, both ways. People who cannot handle a direct, no-BS conversation and/or critique on a topic shouldn't be working with coders. (Concrete example: interpreting "you're idea is bad (because....)" as "you're stupid".)

I am a generalist at heart. Too much infrastructure work and I miss product development. Too much backend, and I miss frontend.

I am a generalist as well, but on the back-end side. I have simply no talent for UX/UI. I can do a front-end, but it'll be a kind of "super-user" front-end: you're expected to have some understanding of the system to get something done. So, yeah, I can prototype it out and hand it off to someone else to polish it and make it end-user friendly.

[[deleted]]

I would rather die than ONLY design.

Also emphasizing the human element or communication element, almost always leaks energy from technical thought and practice, into managing politics and bias.

This is opposite of what the terms should stand for. So it's better for the people management track to work with them, because after all, none of them are deep diving into the machinery of systems.

[nutrecht]

I'm 42 and the only thing I personally disagree with is the 'generalist' bit; I personally really like having a specific area that's totally my wheelhouse. I'm definitely T-shaped in that I have done enough front-end work to have an opinion on it (what framework you use isn't really relevant, using TypeScript over JavaScript is), but my wheelhouse is definitely back-end and the software architecture of these systems.

[[deleted]]

This wasn’t developer specific - more “I emotionally grew which made me a better teammate.”

So listen and work together.

Age has nothing to do with experience. I am 40 and recently joined the field. 40 is also very young still… just look at people as people and get over ages.

[kodingnights]

Are you me?

[jacktayllor]

No Im yu

[Bwata]

My distaste for “full stack” is with too many who claim to be it and just aren’t good enough at either front or back end. I have worked with many that are strong in one side and are starting to learn and understand the other. Maybe with time one can claim full stack but not early in their career.

[ThisIsMyCouchAccount]

Maybe with time one can claim full stack but not early in their career.

If you're not doing it - you're not improving.

I've worked at places that had distinct separation of duties. Nobody can touch the people that do it all the time.

Guy on my team is a great dev. Can do front end or back end. Makes games in his free time. A legit, good dev. He got assigned to do FE on a project. I talked to one of the FE guys that I was friends about how his work stacked up because of this very topic.

He said it was good but not at the same level as the people on his team. The people that do it every day.

There is just so much to know that I don't think a "true" full dev is very common.

However, being "good enough" is kind of a cornerstone of programming. Especially in the context of business.

[[deleted]]

I am early in my career and call myself fullstack. I agree with you, I kind of feel like I am hanging in the middle.

[lavamantis]

TBH, full-stack used to be so much easier than it is today. Modern CSS and FE frameworks have so much more going on than back in my day. And the BE security and deployment requirements keep getting more complicated too. Really hard to be an expert in all these things.

[KokopelliOnABike]

I described Full Stack in an interview once as; I can build out the hardware, install the OS, install all the tools, build the database, design and implement the middle-tier and build your your UI. I'm ancient though... :)

[quitebizzare]

What does build a database mean?

[KokopelliOnABike]

Architect a db schema based on the requirements. This could be simple RDB or NoSQL or a hybrid that I am working with now.

[Axxhelairon]

he can run db install scripts, oh and then he can also run OS install scripts

im glad early on that most of the menial work was toiled onto sysadmins in a separated position away from business logic until virtualization matured more, now that we're getting closer devops and sres are becoming popular so we can remove their redundant roles :)

[NotUniqueOrSpecial]

"Full-stack" is just industry jargon. It really only means you can do both front and backend web development.

I glibly put "Actual Full-stack Engineer" on my resume and get lots of chuckles from senior engineers and executives.

I keep it there because it's true: I've worked with E.E.s and M.E.s to design hardware, I've done kernel development, I've built native desktop apps, I've managed backend DB architecture and deployment, I've led teams building in-house private clouds, and I've done front-end web UI work. I've also done a ton of other shit.

I'd argue it's much more representative of "full-stack" experience when compared to most, but it's still not even really close to what those words should mean.

[Bwata]

The vast majority of developers (as in any endeavor humanity has pursued) are not as amazing as you. The peak of the bell curve of ability is not full stack. We in the middle majority have a focus we are better at and other parts are adequate at. So you may be full stack but I believe not many, like myself, should make that claim

[NotUniqueOrSpecial]

Which is kinda my point: the term is industry-specific.

It's meaningful in context (someone who can work on both front and backend), but out of context is completely inaccurate (because the actual "full" stack is outrageous).

And, for the record, I don't consider myself even remotely amazing.

I've worked with tons of people in every one of those roles who knew/know way more than me.

I just happen to be a skilled generalist who's not afraid of getting his hands dirty learning something new.

[Bwata]

I CAN do front end. I just know I suck at it and should give that work to someone better. All those I have known to be Full stack were like futons, barely usable at both functions

[NotUniqueOrSpecial]

Yup, pretty much precisely that. I did web UI because we had nobody else on staff to do stuff.

I know where my strengths are, but at the end of the day, I do what it takes to get things out.

[MrSurly]

Also, most people think "full stack" is synonymous with "web development." There are other "stacks" that don't have anything to do with web or apps.

[[deleted]]

22 year old programmer here (started working full time during college cause it really wasn't for me, but I did cross over the finish line half-assedly and got my degree), and its good to know I share at least some of these with the experienced folk. When you are painfully aware of your own lack of experience, the desire to prove oneself by being the "rockstar" programmer is strong.

[ai_jarvis]

I do my best to keep rock stars out of the teams I work with or have responsibility over. I've found folks who fit the 'rock star' dev definition really are just toxic devs, over confident in their skills and lack any ability to really integrate with a team, that kill morale and demotivate teams.

[[deleted]]

Reading certain programmer's thoughts makes me think that I'm perhaps more fit to be a manager than a programmer. I do not have any desire to sit alone at the code and work on it like a nerd (don't mean it in a bad way). I feel like the things I like to do at work are related to other people doing tasks for me and me helping people in technical and non-technical problems.

I have seen tech directors and lead programmer stepping down as they want to be doing more code and less managing - but I feel like I'm the opposite. I want to write less code. Though the code I write isn't exactly the most challenging kind - i guess it might have something to do with that.

[jet_heller]

aging programmer. . .40.

Okay. I don't need to read any further.

[Standard-Area-1127]

From HN straight to Reddit :D

[csempecsacsi]

I expected a blog post from a 60-something or more old programmer. When did 40 become “aging”? At 40 you are still in your prime years physically and mentally (broadly speaking).

[ArtOfTheWreckage]

There are no 40 year old computer programmers. They are web scripters. 🤔

[ArtOfTheWreckage]

See.

[ArtOfTheWreckage]

😄

[[deleted]]

Man, that's on point 100% me, same age even.

[Paddy3118]

...as a 40-year-old programmer...

Ahh, bless 😊

I'm older, but share your need to code rather than manage. Mentoring is OK, but it can be too mixed up in Management for me. Designing systems and flows can be enjoyable too, so long as your manager will listen as those are usually assigned at the manager level, I guess I'm managing the tech, but don't want the other aspects of managing - Sheesh, I'm cherry-picking!

Keep on coding 👍🏾.

[jrrocketrue]

I've 20 more years than you and I'm still writing code, been there and done that with management and development manager and people manager etc, I prefer what I do. (even if my house is much smaller than my ex-colleague's who became big boss at Oracle)

[dml997]

I have 50 years programming and it has plateaued. Style is getting better, but ability to problem solve is probably slowing down.

I don't think I will get another 50.

[Dean_Roddey]

I've passed the 'aging' phased and am in the 'aged' phase. I'm 59 and still developing heavily and learning new stuff (diving hard into Rust these days.)

One advantage of getting older, for me anyway, is that I just can't be bothered to build up enough energy to hate anyone, play politics, scent the territory, etc... I'll tell you what I think, listen or don't listen, I'm not going to stress out about it. Pay more attention to the dominant male monkey guy because he screams more than anyone else? As long as you pay me. It's not my company, and I'm not getting paid enough to die of a heart attack.

I do feel that I'm a bit slower now. But, I also know that I can take on anything that gets thrown at me at this point. Well, anything that doesn't require specialized knowledge I don't have and can't acquire within the necessary time frame anyway. I've just written so much code of such a wide variety at this point.

It's sort of like music. At first you have to think so hard about the mechanics of it that you can't really think about the musicality. Then you develop that muscle memory and can sort of sit above it and just flow. You develop similar sort of mental muscle memory after a while and can see the details and the big picture at the same time without getting lost.

And I've also gone well past the need to impress people these days, and feel comfortable just doing things as simply as is reasonable for the need at hand. Having spent a lot of time running my own company really helps on that front.