Something about my line of work, from day one, is that every day is a learning day. Part of the reason I believe I never made that jump from post-doc researcher to a lecturer was that I never focused on one particular field of chemistry. I never looked for a niche to make just my own, and then jealously guard and become a gatekeeper to. That happens a lot in science research. Just try to replicate some work you see in papers. It's not an easy thing, and this is either because there is an element of luck involved, the software is poorly maintained, or worse, there is the "secret ingredient" that the researcher left out. Reproducibility: expect less of the scientific paper (nature.com) I never carved out my niche. I was a chemist, who did programming, and programming for many different applications. I designed code for machine learning-based simulations of water, peptides, materials, and algorithms for extracting structural information from simulations (finally being published soon). I was learning a new niche of chemistry each time I moved post-doc. I was learning new programming skills. And when I became a Research Software Engineer that context switching increased a lot. My niche was now not on one particular area of chemistry, but as a programmer who could tackle mathematics, chemistry, AI, physics, biochemistry, and also teach programming to non-experts. In the last 2 years in academia, I learned more than I did in the years proceeding it, as I discovered cloud computing, Python, and other computational techniques, along with becoming a team leader on projects.
Now at Leighton, that approach of every day is a learning day continues. My context for programming is widened, to industries I have never worked in before. It's exciting and always relies on one thing. Honesty. Being able to say "I don't know", but also "I am willing to learn".
Learning new skills is pretty much the life of a freelancer. And for that side of my work in writing and making games, it requires the discipline to sit down, practice, and realise that good enough is often fine, as perfect is something you will always be chasing. In the last few years I have picked up audio editing, video editing, layout for publishing, and I hope I am constantly improving on my own writing, communication skills, and text editing so I can produce high-quality writing. Another part of this process relies on getting feedback, listening to feedback, and not taking it personally. Whether it is code reviews, performance analysis, red-lines. These should in principle be about helping you do better. People want to help, for the most part. And gaps inability can be filled easily if the working relationship is good.
Comentarios