JPMorgan Chase & Co. is an American multinational investment bank and financial services holding company headquartered in New York City and incorporated in Delaware.
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:
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?
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 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?