Explore JPMorgan Chase on Taro

In this , Alex mentioned that his technical documentation stood out because no one wrote docs in that much detail.

Are tech docs mainly for how you plan to accomplish a project and are they useful for junior engineers? If so, how do you write good technical documentation?

I feel like it's more joyful to positively impact the life of others vs. only getting a really high title/pay. The latter also has high stress, and I don’t want work to be everything. I believe that teaching is a way to improve communication skills and software engineering skills overall, and I would like to mentor more junior engineers than myself at work. Another option I'm considering is going back to my bootcamp App Academy bootcamp to teach others how to code.

I'm currently moving a bit slower than other engineers on my team. Here are some of the problems I'm facing:

• I talked to the manager and he said that if you get stuck after 30 minutes, just ask for help. I will often spend many hours to an entire day working on a problem before asking for help.
• I feel unmotivated to do work until I actually start it. I need to get into the zone, and it takes a while to overcome the initial hurdle.
• How do I feel more uncomfortable in the unknown? The uncertainty is discomforting for me.

For people who work on side projects: I was wondering what is your system when it comes to coding at work and then coding after work? How do you divide your time effectively between the two?

I want to be able to plan my work better for sprints, so that I can avoid spillovers or call out anything that might lead to that as soon as possible.

Sometimes I feel like I didn't get 40 hours "worth" of productivity after a week, and it didn't make sense to physically spend 40 hours working that week. Is it possible to succeed as a software engineer working less than the traditional 40 hours? I imagine it requires being able to get the work done faster - What are some techniques to do that?

How can we identify what are the core in-demand "Legos", especially in the context of what we do commonly on our day to day job?

As software engineers, we are tackled with new things to build regularly, so I was wondering how I could focus on the components (i.e. "Legos") that are built more regularly and learn to build them with high-quality.

I don't have a concrete need for this right now, but I want to be more efficient at work and keep this in mind for when I do get into a new technology. As a web dev, a core in-demand Lego will be like responsive design or something like that right?

For context, I mainly work on the web-side, building customer-facing surfaces. I don't want side projects to be something like DSA where it's good for interviews and that's it.

The concept of side projects makes me think of Flappy Bird when it came out. It seems like it started off as a side project, so this is all interesting to me and would love to learn more about the benefits.

I want to start incorporating habits to benefit myself as an engineer.

I see a lot of engineers get excited by new frameworks, and I can’t emulate that same enthusiasm. There are some exceptions (e.g. when I learned about Storybook.js, I was excited to pick it up as it was applicable to my work), but for the most part, I'm just not as excited as other software engineers about picking up the latest and greatest tech. If I’m not going to get my hands dirty with a new framework or use it at work, I just don’t really care for it. What can I do to be better about this kind of learning?