Forrest Brazeal on Twitter about their your process for learning a new technology or framework on the job
Posted by jpluimers on 2025/03/03
Interesting responses to [Wayback/Archive] Forrest Brazeal on Twitter: “People who’ve been software engineers for awhile: what’s your process for learning a new technology or framework on the job? (I want the beginners who follow me to read the replies carefully)”.
Not just interesting for beginners to read, but for any developer: understanding how other people acquire new technology helps you to compare your own way of learning to others.
Forrest keeps these simple steps as “[Wayback/Archive] For me:
- Have a use case (underrated)
- Read the docs
- Build until stuck, then goto 2″
My comment was that this is fine for side projects, but fail for on-the job projects as for those step 2. often means “what documentation?” so I effectively make that “2. Ask lots of questions, browse lots of code.”:
[Wayback/Archive] Jeroen Wiert Pluimers on Twitter: “@forrestbrazeal Not on the job, those are correct. On the job usually 2. is either “what docs?” or “how old are these docs?” so it then becomes “2. Ask lots of questions, browse lots of code.” (usually I make notes and docs out of those; similarly to why I write
wiert.metoo).”
Later I realised, that I learn by doing, so step 2. and 3. are often almost simultaneously.
There are far more interesting posts in the responses, so I encourage reading more than just the few I am quoting below.
First a series of 5 steps in 3 tweets:
- [Wayback/Archive] LukasM 🤯 on Twitter: “@forrestbrazeal 1/2 Assuming I have a concrete problem and a candidate technology”
- Read – documentation, blog posts, etc. to see if it’s a high-level fit
- Ask – go to where the experts are, describe use case and my current understanding to see if there are any gotchas
- [Wayback/Archive] LukasM 🤯 on Twitter: “@forrestbrazeal 2/3 …”
- Prototype – play around with it, see how it actually works (docs are often incomplete)
- Iterate – steps 2 and 3 in parallel
- [Wayback/Archive] LukasM 🤯 on Twitter: “@forrestbrazeal 3/3 … Good question, it made me think about my process 👍😀”
- Propose solution/discuss with team – summarize trade-offs, propose pragmatic overall solution or raise need to investigate alternatives if I found a deal breaker or a risk that is too high
Then an interesting approach of a starting point (which is how I learned bash, PowerShell, bits of Python and git).
[Wayback/Archive] Daniel (dB.) Doubrovkine on Twitter: “@forrestbrazeal Do something outside of the critical path. …”
[Wayback/Archive] How I Learned Rust by Accident – code.dblock.org | tech blog
In a business environment, getting started is often much harder than one things as Chris shows in [Wayback/Archive] Chris Swan 💙💛 on Twitter: “@forrestbrazeal Similar, but… “:
- Have a use case
- Read the getting started guide
- Find a whole world of missing dependencies where it ‘works on my laptop’ for the creators
- PR getting started guide
- Wade in deeper, with possible recourse to stack overflow and GitHub issues.
The most important lesson that I learned decades ago is to keep asking questions and teach others, just like [Wayback/Archive] Jonathan Baker on Twitter: “@forrestbrazeal “:
- There must be a purpose to learning it
- Look at open source / example code
- Modify working code from (2) to explore and learn
- Start building, docs at hand
- Don’t be afraid to ask for help from peers or the community
- Share and teach others any lessons you learned.
--jeroen
The Wiert Corner - irregular stream of stuff 
Leave a comment