This will be a short post with an update on my journey and some resources that I want to share, that might help someone out.
Yup... I'm a junior dev
Yes, I consider myself a junior dev. Those years at college don't change the fact that there is a large amount of stuff I don't yet master. With time, I'm starting to realize how good of a choice it was to start working for a company after finishing my bachelor's, and not waiting until I do my masters first... it's incredible because some stuff you'll just learn from seeing software that is in production. Like you might ask yourself and your colleagues "why do some properties in our DB have an underscore"?
Maybe you don't really know how to structure your application or scale it, whether it's a web app, mobile app, whatever it may be. I've heard Uncle Bob say something along the lines of you know what good, clean code looks like. We all do... then why don't we do it? I think that without seeing and being face to face with a real code base that works in production, you can't really know some things. This is mostly knowledge that will come to you with experience.
One of the difficulties I recently had was with using the aggregate method in MongoDB. I spent an entire morning (so about 4 hours) to make a query work, somewhat close to what was intended. But I also have to realize that it's okay to learn, and I mean... just using your time on the job to learn. My boss literally gave me a book about MongoDB to help me out with this query and said: "Read this chapter about aggregate" 🙂. To put you in perspective, I used about 10 stages on the final pipeline, mostly $lookup, $group, and $project. But the reality is that $group gave me some trouble to understand, and then I spent more time figuring out what I had to write, to get the expected output.
Keep a Devlog
One tip I can give other devs (of any level of expertise), is to have a notebook to keep your devlog. You can write down your current problem and spend some time thinking about at least 2 solutions. Why two? Because I believe it's better to have a choice at the very least, not just going with the first thing that came to your mind. I use my notebook to write those problems, alternative solutions with their pros and cons, and some questions (and respective answers). For me, the main reason to write (anything really) is to force myself to put on paper a description of the problem and think about solutions. When you want help from others, it's ALWAYS better to come prepared with some solutions or other ideas, than empty-handed.
Resources
Git branching model
I follow this model at work and it mostly helps tracking what features are being developed and separating them in branches. Also if the QA team comes back with feedback on what was delivered in the previous sprint, we can make a hotfix branch dedicated to fixing bugs or something else.
Learning Flexbox with froggy 😄
This website helped me learn the basics of CSS flexbox and how amazing it is, so check it out if you are interested. It doesn't mention topics like flex-basis and flex-grow which I had problems with when I used the max-width and width properties.
Git commit standards 💯
I've found this convention to be very helpful throughout my coding journey so far. This has truly made me be more careful and think about what I'm committing. Can someone (possibly me in the future) understand what was done in this commit, why and how? If there is a problem, can I easily backtrack through the Git history and find what is causing it, and then solve it? I don't know about you, but I spend some time reading commit messages, especially to kind of review what was done.
I'm trying to do more of a "self retrospective" at the end of each week, just to keep tabs on the code I'm pushing to the codebase. So by following this convention, I make my life easier because I can sort of guess what was done by the format of the commit. For example, if I see docs, test, chore I can presume they don't contribute with code that implemented a feature, and this allows me to quickly filter out commits.
Naming event handlers in React
This might sound obvious and small, but at the start, I didn't follow a strict guideline to naming events and their handlers. Which led to some confusion when my colleagues read my code.
React Datepicker
This npm module helps you when you need a variety of UI components for dealing with dates. For example, you can have an inline calendar; input fields to pick date, date and time or just time.
Finally, here is a cool parody song about REST that I absolutely love 😁.
Conclusion
I'm currently working on a post about hypermedia, just an introduction to building an application with it in mind. Also, I'm researching more on OpenSearch because it seems to be very useful and cool in some scenarios.
Top comments (0)