I agree you don't need to learn a new programming language for what you're trying to do.

In general, I like learning programming *paradigms*. For example: if you are familiar with Java, learning C# won't really change how you see programming. Learning Haskell will because it forces a functional view of the world vs Java's object-oriented. I have never used Haskell at work, but it did introduce me to property-based testing via [QuickCheck](http://www.cse.chalmers.se/~rjmh/QuickCheck/manual.html). Python has a property-based testing [library](https://hypothesis.readthedocs.io/en/latest/quickstart.html) and that was once useful for a work project.

Senior SWE + Researcher, 23andMe

Andrew Stiles

I agree it really depends on what you want to do.

If you don't know HTML, CSS, JS I would start there.

A bit off the beaten path: I would check out <https://elm-lang.org>. I'm not suggesting implementing your SAAS in Elm, but learning Elm if you want to learn a mental model for React. IMO, Elm uses the same concepts (declarative updates, explicit side effects) without the boilerplate of React.

I work with scientists and don't have a bio or stats background. I do this:

- assume questions related to jargon are fair-game. If you don't know, you don't know.
- continuously build a mental model of the domain. With each new concept, try and fit it into the mental model.
- after a talk or presentation, I sometimes have several questions. I mentally rank my list of questions by perceived importance and ask the most important question. i.e. "is there a question whose answer will allow me to figure out the answer to several other questions?"
- book time or 1-1s with experts. You may know something about a related domain (in my case, software engineering) that may help the expert in their day-to-day life. The information exchange may be mutually beneficial.

I once had a mentee (intern) who was an amazing C coder but had trouble with "dev ergonomics" things like UNIX utilities. I tried to help her with the non-core-C tasks so she could maximize her time doing C coding. As Alex said, I would teach her a mental operating model for the non-C tasks and she did become more proficient by the end of her internship. I recognize your situation may be a little different.

I agree with what Alex said about written documentation. Maybe you can bring this issue up (constructively) in a 1-1 with your manager. If the meetings are small & recurring, I would also reach out to the individual participants and see if they’re open to moving the meetings. 

I’ve found posting a link to the PR in a forum like Slack can help. If there’s a team channel, posting there can still allow others to read at their leisure. Definitely agree with what Rahul said about providing context. 

I agree with what Lee said about waiting too long. Even a busy manager should be able to check in every few weeks. Something that may help is figuring out your manager’s communication preferences and tailoring your doc to that. For example, if your manager prefers email, I would use email. If they prefer a wiki like Confluence, I would write the doc in that medium. 

Alex's comment about moving away from product matches my experience. I moved from a product team to a research team.

I still feel like a generalist, but the research team offers an opportunity to dive into technical problems on a months-long scale.  

The sub-team I'm on within the research team functions as an engineering team embedded in a team of scientists. I like being exposed to the domain of the scientists (biology, stats) while being able to offer engineering experience.  

If you work at Capital One, I'd guess there's a fraud detection team. Maybe there's a team that builds infrastructure to run the anti-fraud models at scale. A team like that intersecting two domains could have interesting technical problems.

I used to work on a consumer-facing team and did some pair programming there. It was useful when working through subtle concurrency issues during a major site re-design.

I don't pair program today but sometimes do interactive "let's look at code" Zoom sessions.

I've gone to <https://www.ashg.org/> a few times. My background is in CS, not biology. I've been to *many* talks where I did not fully understand the material. What has helped me is focusing on the application and getting a gist of "what is the main idea this person is trying to express?"

Once I have that, I fill in the knowledge gaps more leisurely.

Here is how I may restate this question:

>My slack messages are too long.  
How can I shorten them while retaining detail for PMs?  
The only feedback my manager gives me is "Keep it short!"  
I now review my messages, but would like to improve.

Often I find value in omission. If somebody wants to know more, they ask.