3 ms·

Thanks for your reply. Let me clear up some misunderstandings : I didn't mean to convey I have a "less broad technical background" or haven't kept up with the

Thanks for your reply. Let me clear up some misunderstandings : I didn't mean to convey I have a "less broad technical background" or haven't kept up with the bleeding edge, quite the opposite : my edge is a better-than-average understanding of the full picture from the kernel/networking layers up, and having seen the systems and development landscape evolve since the 90s. That's how I got the "big name" SRE jobs I suppose. In dev terms that means I know why and when you'd use Go, NodeJS, Rust or C, or why CQRS and 12Factor matter. What I lack is recent day to day "in the trenches" product development experience on a large software codebase using framework-of-the-day. I am still very much hands on, but in the DevOps space only (Kubernetes ecosystem tools basically), which isn't as immediately useful if someone asks me to prototype a product next week-end. "Being the adult" was a half-joke and I didn't mean to belittle my younger colleagues, who are awesome at what they do ! But more than a few times, I've seen them going head first into a well-known trap, not knowing what they don't know and undervaluing experience and words of warning, doing hacks their future self will hate them for, or poorly reimplementing something the industry has long had a solution for, thinking they're above that. These are all hallmarks of inexperience and young guy hubris, and it's been frustratingly hard sometimes to articulate to them why they were wrong. That's what I mean by "missing opportunities to less experienced engineers" : I might have the upper hand when it comes to tech vision and making good long term architecture decisions, but this isn't nearly as immediately useful (or appealing to a business partner) as their ability to actually get dev shit done and code a product prototype over the week-end. I'm aware of that and would like to remedy it, and this "Ask" is for getting tips from people who may have been in my shoes. Another way to phrase my question : "I have arguably valuable experience and tech vision, plus current hands-on skills in DevOps, but none of that is as immediately useful in a tech cofounder situation as being able to quickly whip together a front-end + back-end prototype with possibly dirty but working code. Any tips for getting there ?"

karmakaze 8y ago
That clears things up. I'm glad that my concerns were a misinterpretation. I myself have been in your shoes in terms of not being able to communicate hard-earned lessons to those less experienced. I don't have a remedy for that other than time. The problem is that if devs follow your advice at face value, they may not run into issues but they can't internalize what they never ran into. Only after they've learned enough can you communicate by analogy in a way that's meaningful. Another trap is that being an expert in one subject area is often dismissed in others which seems reasonable for those with singular depth of knowledge. I've encountered this with mobile dev where I had highly transferable desktop GUI experience to make mobile dev straight forward but until I demonstrated it others would have no clue. Also, the differences in languages tend to be mostly syntactic but some consider that you either know or don't know a language. Another thing that has helped greatly in my situation is pair programming in a small startup. I had already done some mobile & web dev tutorials but pairing on production code fills in the details. It shows how much of what you already know is relevant. Eventually they also pick up better ways of doing things when you either build it a different way but best when you're fixing an issue that was done a poor way. This pattern has repeated enough that I've come to terms with it--any time I'm at a new startup, I give it 6mo-1yr for the team and management to fully figure it out. > That's what I mean by "missing opportunities to less experienced engineers" : I might have the upper hand when it comes to tech vision and making good long term architecture decisions, but this isn't nearly as immediately useful (or appealing to a business partner) as their ability to actually get dev shit done and code a product prototype over the week-end. This is a key point, worth seeing from another perspective. Consider that delivering end-user visible features quickly is actually more valuable 'in the present' and long term architecture is for later. We've gone through 4 products/pivots in two years, having spent good architecture/engineering on any product but the last would have been a waste (and we did spend it on the second one). Thing is, we never know which product is the last one. The cadence that's been working out is that others develop new features on products and I pair with other devs sometimes building features but more often improving existing ones by extending them, refactoring them, or simply fixing bugs and making them more reliable/performant. Retros and the occasional Lunch & Learn to share with the extended team to round it out. The most important thing is that it's all done without pointing fingers (or right/wrong labels). Under the same circumstances I would likely behave similarly, so it's best to think of everyone being on a similar path, just at different points. Having written this I think the biggest change was in myself having more patience and seeing more experience/knowledge as just that to be shared and not any kind of superiority. [Less than perfect: I have been known to 'go rogue' on specific issues (not recently) though it's mostly worked out.] Edit: Do play with a newer framework or two. I chose Vue.js and Flutter/Dart. And you can sidestep much back-end coding with GraphQL.

karmakaze 8y ago

That clears things up. I'm glad that my concerns were a misinterpretation. I myself have been in your shoes in terms of not being able to communicate hard-earned lessons to those less experienced. I don't have a remedy for that other than time. The problem is that if devs follow your advice at face value, they may not run into issues but they can't internalize what they never ran into. Only after they've learned enough can you communicate by analogy in a way that's meaningful. Another trap is that being an expert in one subject area is often dismissed in others which seems reasonable for those with singular depth of knowledge. I've encountered this with mobile dev where I had highly transferable desktop GUI experience to make mobile dev straight forward but until I demonstrated it others would have no clue. Also, the differences in languages tend to be mostly syntactic but some consider that you either know or don't know a language. Another thing that has helped greatly in my situation is pair programming in a small startup. I had already done some mobile & web dev tutorials but pairing on production code fills in the details. It shows how much of what you already know is relevant. Eventually they also pick up better ways of doing things when you either build it a different way but best when you're fixing an issue that was done a poor way. This pattern has repeated enough that I've come to terms with it--any time I'm at a new startup, I give it 6mo-1yr for the team and management to fully figure it out. > That's what I mean by "missing opportunities to less experienced engineers" : I might have the upper hand when it comes to tech vision and making good long term architecture decisions, but this isn't nearly as immediately useful (or appealing to a business partner) as their ability to actually get dev shit done and code a product prototype over the week-end. This is a key point, worth seeing from another perspective. Consider that delivering end-user visible features quickly is actually more valuable 'in the present' and long term architecture is for later. We've gone through 4 products/pivots in two years, having spent good architecture/engineering on any product but the last would have been a waste (and we did spend it on the second one). Thing is, we never know which product is the last one. The cadence that's been working out is that others develop new features on products and I pair with other devs sometimes building features but more often improving existing ones by extending them, refactoring them, or simply fixing bugs and making them more reliable/performant. Retros and the occasional Lunch & Learn to share with the extended team to round it out. The most important thing is that it's all done without pointing fingers (or right/wrong labels). Under the same circumstances I would likely behave similarly, so it's best to think of everyone being on a similar path, just at different points. Having written this I think the biggest change was in myself having more patience and seeing more experience/knowledge as just that to be shared and not any kind of superiority. [Less than perfect: I have been known to 'go rogue' on specific issues (not recently) though it's mostly worked out.] Edit: Do play with a newer framework or two. I chose Vue.js and Flutter/Dart. And you can sidestep much back-end coding with GraphQL.