2 ms·

But personally, I don’t like to be “taught”. I prefer to learn on my own. I had this view for a long time, and it seems common among engineers I've worked with

But personally, I don’t like to be “taught”. I prefer to learn on my own. I had this view for a long time, and it seems common among engineers I've worked with and mentored. It's such a common view that I was advised never to use the word "teach" or "training" and instead say "knowledge share". And to some extent it is impossible to teach what can only be learned by doing. But more and more I feel like the self-teaching learning curve is an S curve and we all approach diminishing returns. I suspect that in the right group of self- and mutually-motivated, highly talented people (not just engineers), one could level up significantly faster through coaching and interaction than through self study alone, no matter how much of an autodidact one is.

scarface74 6y ago
My favorite way to learn is iterative. 1. Proof of concept 1 or 2 people depending on the scope 2. Get Feedback 3. Iterate 4. Get Feedback 5. Is there consensus (either agreement or “disagree and commit”) to move forward? If no, go back to step 3. 6. Document process and best practices in the Wiki along with a model implementation. Of course this also goes through a continuous improvement process. At the end of the day, results beat theory. This is how we introduced most of our “cloud native” initiatives, security, logging, monitoring, a better configuration process, a CI/CD pipeline,Lambda, Fargate (serverless Docker), moved toward a more performant data store for OLAP processes (Redshift) etc. There was just way too much theory and nothing to show for it before I and one other “architect” on another team basically pushed the issue with the backing of our then new CTO. We started to get a number of other people onboard. Amazingly enough, despite the stereotypes, our off shore contractors (who had been at the company for years before they started adding on developers in the US), were more aggressive about changing the status quo and doing things “the right way” when they had cover from us than the newly hired team leads right across the room. When you have too many people trying to learn at the same time, some learn at a slower pace, some have different interest (I won’t go near the clusterf%%% of modern frontend development) and some don’t want to learn at all and just want to coast.

scarface74 6y ago

My favorite way to learn is iterative. 1. Proof of concept 1 or 2 people depending on the scope 2. Get Feedback 3. Iterate 4. Get Feedback 5. Is there consensus (either agreement or “disagree and commit”) to move forward? If no, go back to step 3. 6. Document process and best practices in the Wiki along with a model implementation. Of course this also goes through a continuous improvement process. At the end of the day, results beat theory. This is how we introduced most of our “cloud native” initiatives, security, logging, monitoring, a better configuration process, a CI/CD pipeline,Lambda, Fargate (serverless Docker), moved toward a more performant data store for OLAP processes (Redshift) etc. There was just way too much theory and nothing to show for it before I and one other “architect” on another team basically pushed the issue with the backing of our then new CTO. We started to get a number of other people onboard. Amazingly enough, despite the stereotypes, our off shore contractors (who had been at the company for years before they started adding on developers in the US), were more aggressive about changing the status quo and doing things “the right way” when they had cover from us than the newly hired team leads right across the room. When you have too many people trying to learn at the same time, some learn at a slower pace, some have different interest (I won’t go near the clusterf%%% of modern frontend development) and some don’t want to learn at all and just want to coast.