Hacker News new | comments | show | ask | jobs | submit login

Not really related to your main point, but speaking as a greying "old guy", one of the things that's really hard is to gracefully allow the next generation to contribute. I still vividly remember starting out and being incredulous about some of the stupid ideas the senior guys on the team had. I was proven right quite a lot of the time too. It's easy to build that inner narrative of the hero righting wrongs.

But then fast forward to the back end of your career and you've got a kind of weird dilemma. The vast majority of ridiculous things that the young guys try to push is absolute crap. They read about it in a blog post somewhere and don't have nearly enough experience to understand the nuances. Or they have yet another stupid f-ing framework that they just know is going to revolutionise the industry. Yeah... been there, done that, my closet is overflowing with T-shirts, thank you very much.

You sit there thinking, "I spent 20 or 30 years fighting my way through this crap and when I finally have a good handle on it, these new guys are just going to throw it all away". But... Dammit. You absolutely know that one of them has a great idea and you're not quite sure which one of them has it. Because they all think they have it sorted (even when none of them do). They feel they are completely sure that "this is the best way and only a moron couldn't see it". But you know that it's always more subtle than it appears. If you let them all run with their ideas, then 90% (99%???) will crash hard... Let's face it -- just like you did when you had that stupid idea that you were absolutely certain was "the way forward".

Anyway, I belabour the point. From my vantage point, it's pretty difficult to let go. Some people just can't do it. In my position now, I have a lot more sympathy for the "old guard" than I did when I was younger. To be honest, I think it is technically impossible for me to have less sympathy than I did -- and I think this is pretty common in the industry. Probably both sides of the equation are in a similar situation -- neither side feels comfortable letting the other side make decisions.

Just talking out of the hole in my head right now, but I think the main thing is that programmers generally like to program. They like to have freedom to try approaches that they think will be successful. As much as possible, it's probably best to allow your teammates, whoever they are, to have the freedom that they need. At the same time you should expect to have your own freedom. Getting the balance is not easy and sometimes you have to change jobs in order to get into a team where you are allowed the freedom to do your best. In my experience, teams that take this seriously are the best teams to work on (even if they sometimes do stupid things).




You know, I really appreciate this response and perspective; because it makes total sense. It's human to want to stick to what you know and only natural to be hesitant of the unknown, especially when you have the tenure to have seen it all over the course of a career. That experience is valuable and it's why in many cases I do lean upon this senior guy for input on specific topics I know he is the best resource for.

That said, in this specific context of tech (or at least in my wheelhouse of Ops), this is surmounted by creating and fostering a culture where it's okay to experiment and fail.

Where we've been handicapped in this regard is specifically not doing that, and the particular individual who makes this difficult having the mentality that any new approach spells doom and actively working against initiatives to put us in a better posture of experimentation in environments that don't sacrifice stability and reliability of our stack (hence the sarcastic comment about giving up my first born child for server immutability--I don't even have kids, haha).

But that said, I think you're absolutely right. I'm not quite greybeard yet-mostly because I yank out every grey hair I see trying to establish residency on my chin, but nonetheless your point is accurate, well taken and definitely that has immense merit.


And if you allow experiment and fail, you end up with 20 different frameworks in your app.

And that means a huge cost of inconsistency. Every time you need to make a little tweak you have to learn how that part of the app works.

When you just want to get shit done, being able to go into any part of the app and knowing it's built exactly the same way as every other part means you don't have to spend any time learning insert X framework, you spend time doing, implementing business rules and fixing bugs.

A lot of programmers want to spend time playing with tech, not doing because playing with tech is more fun then doing the job.

Worst still, juniors (including me back then) are woefully unaware of just how clueless about programming they actually are, as alluded to by the parent, and that means they have massively over-inflated opinion of their views. They also tend to be wildly optimistic about how long a change will take and totally disregard the human cost (the cost of re-training and loss of productivity) of changing a piece of tech.


This is something I think about a lot nowadays. You have to try and fail a lot to develop an intuition for good design. How do you give people the room to experiment without paying for all the mistakes? It is tremendously expensive to produce a senior developer yet vital to do so because junior developers mostly produce crap. We could only assign them projects off the critical path, but we can't really afford to have anyone working on anything but the critical path. Plus it's a lot to ask of someone's ego to say, here work on things that don't matter for 5 or 10 years and we'll talk.


I was randomly watching Youtube the other day and there was an ad for Herbie Hancock's Masterwork class (ha ha -- not a referral, no idea if it's any good). Anyway, in the ad he mentioned that he was playing with Miles Davis one time and that he made what was technically a mistake. Miles listened to it, picked it up and made it right. Suddenly I realised: "That's it! That's what I want to do." But, of course, it's much easier said than done. I won't pretend that I'm able to do it yet :-)


You do it by modularising code into smaller parts that communicate in well defined ways and enforce that. Then you can take whoever and have him make one module with a lot of autonomy. If he fails and make mess of it, someone else (or even more experienced himself) will rewrite it relatively easy.

Meanwhile, you let him make decisions in his module/plugin/part/web service/whatever while you enforce rules between them.

Also, the work off critical path matters too, it would not be done at all otherwise, so treat it like it matters. It won't take juniors ego if older collegues take that job seriously.


That's what "side projects" are for. Go and experiment as much as you want. Then after you've succeeded, make a presentation to technical management showing what you've learned.


I'm the oldest guy on my team and have an architect title, yet I'm having a very hard time getting my younger colleagues to adopt CI/CD, microservices and agile. Some of them know what they are and that they sound cool, but don't know how to do it. Some of them actively oppose it.


"Sound cool", do you have a better reason to change the way your colleagues make a living other than it sounds cool?


I'm saying the team knows they "sound cool". I have lived them all and know exactly what they're good for and why.


Usually, if you define requirements you can make an objective choice. The old guard is too attached to stuff they are fluent and young people follow hype too much.

As the technical field, we do not follow the scientific method.


> As the technical field, we do not follow the scientific method.

Surely we should be looking to engineering here, not to science.




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

Search: