Maybe this is a good place to articulate what's been on my mind lately regarding growth. I don't think there's much local opportunity for developers beyond starting their own businesses past the senior level. Instead you have to be willing to move. Individual companies will not be able to challenge you beyond their business needs.
The other thing I wanted to talk about is how I solve technical problems. The first thing I do is get a representation of what the problem is in my mind enough to where I can see a clear path forward. This leans on my ability to take a 10,000 foot survey of a problem space. My current role deals with microservice architecture. Microservices is right in my wheelhouse due to my better-than-average sysadmin skills.
But I end up having to learn a lot within a short amount of time. So in order to cut down on what I call the "sheer mass of information needed for mastery" any time I look at a new tool or tech, I make a beeline for the "architecture" or "concepts" page. This is where I work out exactly which concepts and which level of the architecture I'm working at.
I then use the problem statement and vision above to hone in on a perfect implementation. Then I look at the actual state of the system and work to bring it more in line with the perfect one.
I recently was tasked with getting one of our guys unstuck. He was having a tricky issue with aquasec that he'd been beating his head against for a week. It took me five minutes to understand the problem, then I went to my desk and spent twenty on obtaining a reproduction. I didn't want to redo his work, so I then asked him what happened when he did X and Y. From his answers I had a clear path to being able to demonstrate that it was aquasec throwing a false positive on a npm library, and was already in talks with our devops team about next steps. It took 30 minutes for me to move his issue forward.
I feel like this manner of solving issues with techs that you don't necessarily have full understanding of could revolutionize the industry. But I can't really grasp how to teach it. It looks like magic to people when I show it to them, they think it relies on years and years of experience. I mean, it kind of does, but I was able to avoid ever getting fully stuck on problems even as a teenager.
But stretching out the problem space and treating each barrier in turn, diving in a little bit into complex techs along the way, I don't see a lot of coders doing that. Instead they just kind of muddle around with what they know, believing they need perfect understanding of a tech before being able to solve problems effectively with it seems to be the norm. And we have this tech landscape where years of experience in technologies becomes the primary determinant behind how most employers judge candidates.
I think the increasing march of devops and other techs that purport to unite the whole world into one walled, splendid garden will eventually bifurcate the tech world into supermen who know everything, and the underclass who can only work in one garden. If that's not how things already are?
Maybe a secondary school for advanced coding or bringing guilds back.
The other thing I wanted to talk about is how I solve technical problems. The first thing I do is get a representation of what the problem is in my mind enough to where I can see a clear path forward. This leans on my ability to take a 10,000 foot survey of a problem space. My current role deals with microservice architecture. Microservices is right in my wheelhouse due to my better-than-average sysadmin skills.
But I end up having to learn a lot within a short amount of time. So in order to cut down on what I call the "sheer mass of information needed for mastery" any time I look at a new tool or tech, I make a beeline for the "architecture" or "concepts" page. This is where I work out exactly which concepts and which level of the architecture I'm working at.
I then use the problem statement and vision above to hone in on a perfect implementation. Then I look at the actual state of the system and work to bring it more in line with the perfect one.
I recently was tasked with getting one of our guys unstuck. He was having a tricky issue with aquasec that he'd been beating his head against for a week. It took me five minutes to understand the problem, then I went to my desk and spent twenty on obtaining a reproduction. I didn't want to redo his work, so I then asked him what happened when he did X and Y. From his answers I had a clear path to being able to demonstrate that it was aquasec throwing a false positive on a npm library, and was already in talks with our devops team about next steps. It took 30 minutes for me to move his issue forward.
I feel like this manner of solving issues with techs that you don't necessarily have full understanding of could revolutionize the industry. But I can't really grasp how to teach it. It looks like magic to people when I show it to them, they think it relies on years and years of experience. I mean, it kind of does, but I was able to avoid ever getting fully stuck on problems even as a teenager.
But stretching out the problem space and treating each barrier in turn, diving in a little bit into complex techs along the way, I don't see a lot of coders doing that. Instead they just kind of muddle around with what they know, believing they need perfect understanding of a tech before being able to solve problems effectively with it seems to be the norm. And we have this tech landscape where years of experience in technologies becomes the primary determinant behind how most employers judge candidates.
I think the increasing march of devops and other techs that purport to unite the whole world into one walled, splendid garden will eventually bifurcate the tech world into supermen who know everything, and the underclass who can only work in one garden. If that's not how things already are?
Maybe a secondary school for advanced coding or bringing guilds back.