DEV Community: Banda Works

Learning resources 📚 for understanding Javascript async nature 🔮

Vitaly Krenel — Wed, 14 Oct 2020 19:19:50 +0000

Over my mentoring practice, I often see the stage of learning, when an aspiring developer starts tackling the asynchronous nature of the Javascript.

And over the last year, I've built a small, though an unbelievably helpful collection of resources for learning the asynchrony concepts and the concurrency model in JS well enough.

It should be enough to let you work with asynchronous javascript in your day job (and demonstrate the knowledge in tech interviews before that).

Specifically, this collection can be helpful in learning:

Promises, callbacks
Event Loop model and queues
async/await operators

These are not obvious as they might seem and sometimes may be difficult to crack.

Learning resources

🔮 "Async & Performance" book from You Don't Know JS series by Kyle Simpson (aka. getify). Specifically, take a look at chapters 1,2, and 3.

❗🏋 The book is relatively harder than other recommended resources, but it covers the whole theory behind asynchronous concepts in Javascript.

If you are a junior javascript developer going through interviews, you should explore it, despite the difficulties - with that, you'll ace any async related questions on the interview and will impress the interviewing team.
🤞 "Javascript Promises: an introduction" by Jake Archibald - great explanation of Promises, friendly and not shallow at the same time.

There are many useful examples (but they take time to understand fully, sometimes) - and I recommend you to play around with them in a Codesandox so you really feel comfortable with them.

By the way, the article author - Jake - posts quite friendly and interesting articles in general, so you might want to check out those later as well.
➰ Talk "What the heck is the event loop anyway?" by Philip Roberts - one of the best talks about Event Loop model which is what is the foundation of the concurrency in JS. It's a must-watch. The talk is both fun and enlightening.
➿ Talk "In The Loop - JSConf.Asia" by Jake Archibald (the author of promises introduction at the top) - it's related to the Philip Roberts talk, and is a great follow-up.

On top of that, it covers aspects of the Event loop that are important to the actual understanding of Promises (which Philip Roberts didn't cover).
🦄 "JavaScript Visualized: Promises & Async/Await" by Lydia Hallie - this article should help you solidify the learnings so far.

The visualizations there are especially helpful to keep your knowledge in the long-term. Those visual images not just ease the learning but also reinforce your memories in the brain, so you are less likely to forget.

And it also covers async / await concept - synchronous like syntax to write Promises-based code in a more straightforward way. Async / await are essential tools for writing readable and maintainable logic based on Promises in modern projects.

In what order to learn using this collection?

In the beginning, try to use the default order - as they go in the list above.

But if you find yourself struggling with the 1st item - as I said, it's relatively harder than other recommendations - use the alternative order:

Start with the article series by Lydia Hallie: 5
Go through the 2nd to 4th items: 2, 3, 4
After that come back to the 1st to deepen your knowledge and help yourself to ace the tech interviews 😉: 1

Why I don't use the alternative order as the default in my mentoring practice? It's easy: to challenge the mentee.

The book "Async & Performance" really makes you go through the complex concepts that stay in the basement of JS asynchrony. If you can handle those - there will be fewer subjects in JS that will be able to make you break a sweat, that's for sure 🙂

And so that's all, my friend. Hope these resources will help you on your Javascript learning path!

What's next?

If you like these resources, you might also be interested in BandaWorks twitter community.

Every day we post valuable content for junior developers there, among those:

Daily advice to help you become a stronger developer
Learning resources for web development
Overview and our own thoughts on the development articles by other authors

// Detect dark theme var iframe = document.getElementById('tweet-1313829364103077890-325'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1313829364103077890&theme=dark" }

Join us if you are the same as we - focused on continuous improvement! 😉

Job hunting 101 for junior developers

Vitaly Krenel — Tue, 13 Oct 2020 21:56:04 +0000

Photo by Gerald Schömbs on Unsplash. Modified by Vitaly Krenel

It's okay, Shark, I've got you covered.

The job looking process can be split into 2 stages:

Preparation
Job looking

1. Preparation stage 👨‍🍳

This is finishing part of your learning path on the way to junior position. Keep in mind, that the actual learning should never end, just you'll be investing some spare time to learning while having an official developer position.

Usually, together with my mentees, we take around 2-4 weeks (rough estimation, it may vary, depending on your skills) and after that proceed to the job looking (and improving any weak side on demand, after getting feedback from a company).

During the preparation stage 🍳

Build your portfolio.

I usually suggest creating a website that features your strongest projects, but these days there's also a GitHub Profile option.
- If you choose to build your own portfolio website: https://dev.to/emmabostian/how-to-build-a-great-technical-portfolio-53bb
- For Github Profile, take a look: https://dev.to/m0nica/how-to-create-a-github-profile-readme-1paj
Start exploring how the interview process looks like.

Find out questions and assignments that you can be asked to answer/solve during interviews.
- I strongly recommend exploring the interview handbook during this step - it contains both typical questions (HTML, CSS, JS) and theory you need to know to answer them: https://github.com/yangshun/front-end-interview-handbook
- For more javascript specific questions, take a look at this collection https://github.com/ganqqwerty/123-Essential-JavaScript-Interview-Questions
- Don't forget to practice coding challenges. There's a bunch of resources Chris Choyer gathered here: https://css-tricks.com/front-end-challenges/
I suggest you spend invest some time practicing CSS challenges, as an addition to JS-specific problems.

This way, you will less likely to struggle if interviewers ask you to stretch elements over the screen or position one small block inside a scrollable container.
Set up your profiles on job searching platforms and LinkedIn. It increases your visibility for recruiters which may invite you to interviews if you match one of their posting descriptions.

I do not recommend counting on this strongly, but it may provide few opportunities to get an interview, so it's definitely worth considering the time required to set up accounts there (spoiler: it's not that long 😁).

2. Job looking stage 🕵️‍♀️

It takes time

Be ready to persist for 1-2 months if you intend to get an offer tailored for you — this stage is truly about patience and persistence.

If you hurry too much, you may end up getting an offer in a team you don't want to work with or deal with the projects you aren't thrilled about.

Carefully assess the terms

On top of that, employers are often offering you less than you are really worth, as they imply you don't have much experience as thus they will be taking on more risks than with a regular developer.

While this is true, you still need to assess carefully whether the company offers you a reasonable payroll: it's an investment for them.

It for sure has risks, but the return on investment may be much quite impressive as well, especially if you are diligent, hardworking, and focused on continuous learning (which, I believe, you are! 🙂).

Wait for a few offers to choose from

So, instead of agreeing immediately to the first offer you get, I usually recommend reaching the point when you have a few ones (at least 2-3).

With that, you will not feel like the job terms were forced on you: you'll be the one choosing and you could also negotiate a little bit as you have a few offers and you will be able to have a more reasonable career start (both financially and professionally).

But please, don't leverage the company just for the sake of money - if you feel the terms are reasonable enough, don't squeeze from the hiring team a few extra bucks.

It's wiser to start in good faith and discuss the raise after getting on board when you'll prove your hard work and determination. 😉

During the job looking stage 👀

Everyday screen for job offers on the market and send at least 3 replies (the more the better, but send at least 3).

Why? Because many of your job applications may be easily ignored or declined with a typical message.

Take a look at the numbers from one of the bootcamp graduates' article: https://www.freecodecamp.org/news/5-key-learnings-from-the-post-bootcamp-job-search-9a07468d2331/

It is really an important thought to keep in mind so you don't discourage yourself.
Use Google Spreadsheet to keep track of all the job postings you applied to.

Store all relevant information there: your thoughts about the company, current status, and so on. It is easy to lose track of them when you reach just 10-15, not speaking of 200 😅
- Search for companies that are hiring using the job searching platforms, like indeed.com, Glassdoor, and definitely, LinkedIn - a lot of HRs and companies post job offers there.
Also, take a look at your country's local platforms if there any. For example, in Russia, we heavily rely on hh.ru and I believe in many non-English countries there are also local job search platforms that have a huge market share.
Target a company, not a vacancy.

Look for the information on the company you are applying for and craft a tailored response showing you are actually interested in the company. A few examples of things you might be interested in:
- What products company has built?
- What product do you like the most?
- Did the company participate in meetups or confs? Are there any interesting talks for you?
Imagine a situation, when you were researching all that and found that one of your personal projects in the portfolio is similar to one of the company's projects - you should share that when applying. That's exactly how you should use this information.

Show that you have the relevant experience, can quickly get into the work, and bring fresh thoughts to the product(s) there.
Find real people behind the company.

Instead of (or on top of) straightforwardly applying through job postings on those platforms, find real people that work in the company. Devs, HRs, even CEO - doesn't matter.

Many companies reward their employees when they bring new people on board, so if you reach out to someone real from the company, you have a higher chance to get an invite to an interview 😉

It's also that the job posting is managed by an external head hunter that goes over dozens of job applications. If you go to a person from the company, you'll have more chances to grab their attention as they do not deal with that many candidates on a daily basis.
Continue practicing.

Specifically, make more projects that showcase your skills.

It's much easier to grab a team's attention and to start wanting you onboard when you actually have a relatively complex project that is relying on a modern stack - even better if the tech stack is the same as the one used in that exact team.

For example, a React project that relies on

Redux Toolkit/MobX for store management,
React-router for routing,
Styled Components as CSS-in-JS solution,
Integrated with Firebase Cloud Firestore storing the data
Deployed on Netlify or Heroku

is a good showcase that proves that you can use production-ready tools for building something relatively complex.

It proves that you have real experience with frontend tools and can solve technical problems using them.

Moreover, in such a project the team looking for a teammate will be to assess your architecture skills, design patterns, find what coding principles you follow (and what you yet ignore), how you approach testing, and many other relevant aspects.

Basic applications won't suffice. They don't let you shine, they merely prove you have programming skills and development expertise - but that's not enough.

You need to make them feel you have reliable hard skills - you are not an expert yet, but do not need your colleagues full-time teaching you.

By the way, if you don't have any strong projects yet, take a look at Housework Undoer - it's a complex project that is inspired by our development experience.

It's story-based, so you'll be not just practicing how to code, but also practicing how to think about the product and its users in the first place.

So, what the interview is really all about?

That's an important question. If you think wrongly about interviews, you won't use a proper strategy.

Always remember: the interview is not about finding the almighty-problem-solver — it is about finding a reasonable teammate.

Teams are looking for a person that can reason about the problems clearly, investigate them, and can either figure out how to solve those or openly discuss the issues with the team.

Because of that, you need to show how you think, approach and react to problems.

So show that: during challenges, talk and explain what are you thinking about, why it is relevant, how you could try dealing with the suggested problem, what caveats do you see, which person you would consult on the question, and so on.

And that's it with job hunting 101. Hope this guide will help with the challenge of finding a suitable developer position.

Ganbatte, my friend, and you'll get a great job offer!

What's next?

If you like our articles, subscribe to our @BandaWorks community on Twitter so you don't miss the next ones 😉

On top of our article announcements, we post valuable content there every day:

Daily advice to help you become a stronger developer
Learning resources for web development
Overview and our own thoughts on the development articles by other authors

Banda Works

@bandaworks

#BandaDaily #1:

When #coding something, always approach the problem iteratively.

That means that as #developer you go through roughly 5 stages:

1. Make a straightforward solution
2. Cover edge cases
3. Improve the performance
4. Improve the design
5. Reduce complexity

🧵👇

13:11 PM - 07 Oct 2020

2 4

Housework Undoer — a meaningful challenge for aspiring junior developers

Vitaly Krenel — Sat, 10 Oct 2020 18:48:35 +0000

Do you remember, the time one of your friends asked you to build a website? What were your feelings?

Chances are you were excited, as you knew that you would be creating something, not for the sake of practice, but to bring value to someone else. To help someone.

Your work at that time had a context. You knew why you are doing it, you knew the reasoning behind the project, the problem.

Have you ever noticed, that is the exact missing piece with most of the project ideas out there on the internet?

They often are sophisticated, technology-savvy, and full of design delights. But at the same time, they lack context for the project.

They lack a concrete user problem — which is the exact reason why some projects may be built in the real world!

You may argue, that you are doing that project to practice engineering - why do you need to know all that stuff in such a case?

You are right. But now I'm not surprised why many companies devalue personal projects in juniors' portfolios and focus on looking for those that have actual work experience instead.

Because while you were working on those projects you were just practicing, not concerned with anything in mind, but the code.

At BandaWorks we like meaningful work. We value helping our community. And we are passionate about professional growth.

These three were the reason why decided to create our own project.

It's called Housework Undoer.

So, what is Housework Undoer?

Well, it's a project (your captain 😉). More specifically, it's a self-paced challenge split into multiple tasks through which you'll have to build a frontend application using your framework (React, Vue, Angular or Svelte).

Tasks define what you need to build, why, but not how.

Each one has a structure quite similar to the one used by development teams. They all include:

User story
Design mockup
Jack's comments
Acceptance criteria
Yoda's tips

Some of these might be new concepts to you, but as those are used by development teams, we decided to adopt them, even though you may not be comfortable with them in the beginning.

To flatten the learning curve, we prepared a quick introduction that should help you get a basic understanding of these concepts:

Housework Undoer is made in a way to let you'll get a similar experience while working on the project that we've been getting through our development careers.

You'll work in the development workflow that is strongly inspired by the development process in tech teams.

And as there's a context, it will truly make your work more meaningful, fun and entertaining while still teaching you how to think about your users first.

Technical stack

To complete the project you would need to use your UI framework of choice.

Of course, there's nothing stopping you from implementing using plain JS, but in the real world, it would be unsustainable.

So we recommend a few stacks, but you may complete the project in your framework if didn't include it:

React
Vue
Angular
Svelte

But to complete the project, you most likely will need to pick a few more packages on your own: routing, state management, testing, CSS-in-JS solution (or alternatively use a preprocessor), etc.

These will be left in your hands as you are the code owner of the project — you make the decisions there which later will affect how you build the project.

What if I want my own backend?

The project assumes usage of Firebase as a backend. But there's nothing that stops you from making your own backend, let's say using Laravel (PHP) or Ruby on Rails (Ruby).

There will be a few tasks where you'll need to integrate your project with:

Authentication to provide a sign-in for your users
Cloud Firestore - persistency, i.e. storing data in the database.

Only keep in mind, that at the time of writing "Yoda's tips" are providing only recommendations and insights on how to improve for frontend (but we may add backend later if there's some interest 🤓).

Skills requirements

There are 2 basic requirements:

Be confident in your skills with plain technologies like HTML, CSS, and JS. You need to use Git in your daily work.
Be familiar with one of the UI frameworks (Vue, React, Svelte, etc.) or be ready to put the hard work and learn it on the way.

If you don't match these, we recommend you wait and not work on the project right now: the difficulty may result in frustration which will kill the learning process.

Instead, continue learning and practice over a few small projects and after those get back to the Housework Undoer.

This way, you'll get more valuable experience from the project and will have only the necessary amount of frustration 😉

Frequently asked questions

How to start?

There're 2 options to start:

A. If you are not ready to set up a project locally and just want to give it a try, use one of our Codesandbox templates
B. If you already have decided, fork our starting repository on Github and follow our instruction for your framework

To pick either one, go to the Getting Started page straight away.

What if I get stuck or need help during the project?

It's easy: tweet your question with #BandaHelps and your Banda will be right there to help.

What to do when I'm done with the project

First of all, post the link to your repository with @BandaWorks mention on Twitter - we will definitely take a look and may even bring you a few thoughts on how to improve your code!
And don't forget to add the project to your portfolio - it will be a great addition showcasing your development skills to potential employers 😉

Are there any code review or mentoring on the project?

Right now, we do not provide mentoring on the project, but we offer the code review of your project when you complete it.

Where to send my feedback?

If you have any thoughts for us to improve, please send them to us.

The easiest way would be to use our feedback form.

But you could use other ways instead:

Post your thoughts right on Twitter with @BandaWorks mention - this way more people will be able to see your thoughts and this will help us improve even more. Even if the feedback is negative. We strongly respect transparency.
You can also reach us using our email: team@banda.works

What's next?

Subscribe to our twitter community @BandaWorks and stay notified on Housework Undoer updates and future project announcements!

We also post valuable content there:

Daily advice to help you become a stronger developer
Recommendations and thoughts on development articles by other authors
Our own articles announcements

// Detect dark theme var iframe = document.getElementById('tweet-1313829364103077890-465'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1313829364103077890&theme=dark" }

Thank you for your time and have a productive day! 😎

Principles for a junior developer to succeed in your first development team

Vitaly Krenel — Wed, 23 Sep 2020 11:19:25 +0000

While sitting in the deep nights behind the screen, practicing your craft, building projects, and learning new libraries, you were putting your best into mastering technical skills.

For sure, those skills are the primary pillar of the developer. The pillar that makes you a great engineer.

It didn't make you a great team player though.

To be a great team player means a lot of things. But probably the first one is to be reliable.

Unfortunately, I've seen many engineers misunderstanding the idea of being "reliable" as being able to solve any technical problem alone.

And that is exactly the opposite.

Let me share two principles, that I've been advising junior developers to stick with during my mentoring practice.

You may find many other principles, but these are a good starting point to make you a little bit better team player.

Which is what will help you to succeed in your first (and all next) developer job.

Principle #1: don't listen to your ego — talk to your team

You and your team trying to find solution together

Let's say, you got through the onboarding process in your first tech company, started your first task. You created a PR and got approved by your colleagues.

Enjoyed your first lunch with the team. Maybe got in love with a cool QA girl (or a boy) along the line. 😉

In the next few weeks, you were successfully closing tickets, finishing tasks with confidence. Had a few One-on-Ones with your manager or team lead.

Team lead
— The team likes you. We believe you are really competent - you solved all the problems without much intervention from your mentor. On top of that, you have a great personality, I believe you are a great match for the team.

You
— I'm glad to hear that! Thanks!

Finally, feeling proud, you start taking on more challenging tasks. And here you stumbled upon a hidden issue.

During the ticket, you discovered a problem you can't figure out how to solve. You going through it that day. The next day at the morning meeting, you say that "I encountered an issue, but I should be able to solve it today and continue with the rest of the task". Well, how could you not?

You tried again but couldn't crack it.

Maybe you found a probable solution, maybe you didn't. But the second day is getting to the end and there's still no clear progress on the task.

Let's stop here for now, as tomorrow you can just as easily say "I'm almost finished" again.

The problem in the exaggerated example above lies in your ego. Don't get offended, we all have that.

Well, it is your first developer job after all. You've finally got appreciated for the efforts you've put so far! For sure, you want to meet the expectations of your teammates.

At the same time, you likely want to have a successful career with rapid professional growth that shatters the assumptions about career advancement.

There's nothing wrong with those thoughts. But let them overrule you and you end up losing the ability to think critically in that situation. And we've seen what happens if you lose that ability: you won't ask for advice and instead, you will deal with the problem on your own.

But the thing is, if you care about not losing the credibility and actually proving that you are exactly who the team believes you are, you need to do exactly the opposite — you need to solve the problem together with your team.

Speaking from a business perspective, when you do not have a huge piece of responsibility for a product, if you take 3 days to build a feature instead of 1, you will not cause any harm — or at least any unsustainable harm that may make people think you are not right for the job.

Instead, you will show that in front of a challenge, you don't speak - you wait, hide, and play solo. Not a kind of team player anyone wants.

Notice, that we do not talk where is the team lead or your senior colleagues and why they do not intervene. We talk about your responsibility here as a team member.

You have to be reliable.

Being reliable means that you address any problem head-on, transparently discussing an issue and sharing your thoughts, especially if you are not sure how to solve the issue.

The takeaway: try as hard as you can to ignore the ego and always go and talk to your team. Tell about a problem, ask advice or start a discussion — anything to make it clear that you encountered some issue and not sure how to deal with it efficiently.

Don't get yourself to be blindsided by the feeling that asking for help will belittle your professionalism in the eyes of others. It won't.

Principle #2: Be braver — say (nonsense) aloud

Share your idea, even if it seems to look like this weird thing

The second principle is closely related to the first one.

Being part of the team also means taking a part in team meetings. Those may be brainstorm sessions, tech discussion, product meetings — as they say, meetings for everyone on the house!

Those meetings may be barely 3 people in one place or a room full of different specialists. No matter where you are, you might get afraid of sharing something as you don't want to end up saying a silly thing instead of the next brilliant idea.

Unfortunately for you, I'm about to say something you might not like: when you have an idea, a thought, or a feeling — even if it seems bold or unusual — say it aloud.

Yes, you may find yourself saying something obvious, inaccurate or even ignorant. If that's the case, people will say what's the issue with your suggestion and will move to the next thought.

They may do it roughly or more professionally, explaining what's the issue with the suggestion, but they will.

No matter how they do it, you end up learning about your product or technology a little bit more. And what's even more important, the chances of you bringing a meaningful and valuable opinion to this and future discussions have increased. That's super great!

Moreover, your thoughts do not have to miss the target all the time — and they actually will not.

First of all, you have fresh, bold, and full of raw potential mind of a junior engineer — this something companies are stacking on. This mind enables you to see the problem, without being restricted by knowledge of subtle nuances and tangled technical details of the product or technology.

You are looking at the "naked" problem, so to speak. It doesn't only mean that you are unaware of edge cases — it also means you are not limited by them.

And finally, you are closer to the user of the product so far than any more experienced engineer: they have been working in the tech field for quite a while and are super biased. Yes, you're biased too. But immensely less than anybody else. 😉

So my takeaway here: Don't hold on yourself back - speak up your mind, even if you think your idea might be nonsense. The more you do that, the more valuable ideas you bring to your team and your company.

Final thoughts

To shine in the workplace, especially in your first tech team, don't just bury your head in the code.

1. Look out for your team, talk with your colleagues and, when in trouble, ask for help — it does not make you unworthy of your job, it makes you a more mature and reliable engineer which knows how to control his or her ego (which we all have after all, but not all know how to control).

2. When participating in discussions and meetings (product and technical ones) be brave enough to share your thoughts, no matter how silly they seem. Firstly, you may find yourself sharing an idea which another team member may iterate on and improve it. And secondly, with each thought you share, you are making yourself better through feedback, by learning the product and tools behind it.

What's next?

There's one more primary principle that I usually explain and advise to stick with — take on responsibility proactively. But I'm intending to share it in a separate article.

In the meanwhile, I invite you to share your own principles, rules, or advice that a junior developer should keep in mind to become a great engineer and a reliable team member.

I also want to share a project that I and my partner have been working on for a while.

We came up with a challenging project to help junior frontend developers that need to showcase their skills and want to build a portfolio to ease the problem of getting a job in the industry.

You can check out it at https://banda.works/housework-undoer.

Houseworkd Undoer is a project organized into separate tasks through which you will build a frontend app to help our (imaginary) friend Jack.

We prepared a nice-looking design and a background story so we hope it should be enjoyable and interesting for you to build, while still providing enough challenges to display your skills to possible employers.

Housework Undoer's app screens.

See this in full size for more details 😉

To finish the project, you need some skills in one of the major frameworks/libraries (React, Vue, Svelte, Angular, etc.), though the project can be completed without any of those, just with plain JS (but keep in mind, employers usually expecting you to have knowledge and experience in one of those mainstream technologies).

In the upcoming future, we want to create a few more projects, including backend and mobile related ones. But we could really use your help as well: if you try on the project, send us feedback, your thoughts, and questions. The project is completely free and we will really appreciate you spending a little bit of time to share with us your thoughts over team@banda.works.

See you next time! 😉

A few more techniques to help you become a self-taught developer

Vitaly Krenel — Wed, 15 Jul 2020 13:16:16 +0000

Cover photo by Annie Spratt on Unsplash

Intro

Self-learning is the skill that changes people's futures. Sounds shocking, I know.

But jokes aside, being able to consistently and rigorously learn a subject without strict supervision, in my opinion, one of the most helpful skills you can acquire.

I always admired people who have been able to learn a language themselves, pick up the woodcraft, or learn how to play the piano. It seemed natural for them to stick with their activity for 8 hours straight without taking a break to eat something.

Unfortunately, I was slightly different. From a young age, I was quite good at "switching activities" or, let's face it, at quitting. I tried swimming, painting, volleyball, athletics, dancing, electrical engineering, piano (and some other classes and courses that dropped after a few trials).

Whatever course I'd take, I would usually quit it within 2 to 3 months. If I ask my parents, they most likely will admit that they were having bets on what date I would quit a new course.

Imagine now how my self-learning looked like.

Still, I was curious, young, and hungry. I easily could get engaged in new activities. And through exploring new things, I get to know how I can compensate my innate unwillingness to stick with the skill long enough that stoping makes no longer sense - I have already acquired it.

These days I'm involved in mentoring upcoming junior developers to help them steadily build skills that they feel confident with, no matter what challenges are in front of them.

In my practice, I noticed that some learners are struggling with the same problem I did when I was young: how to stay consistent, determined, and focused on learning without dropping again and again.

Today, I'd like to share a few techniques I advise you to adopt to increase your chances of learning the web development successfully and becoming solid self-taught developers, doesn't matter whether it is a frontend, backend, or any other part of the development world.

The inspiration for the article became a recent post on a similar subject from Desiré. Make sure to check that one out, there are more valuable recommendations you could try as well.

My learning method💡: what worked for me. ✍📖

Desiré 👩‍🎓👩‍🏫 ・ Jul 13 ・ 6 min read

#codenewbie #career #beginners #learning

1. Set up minimal daily learning time. 30 minutes per day is optimal. 📅

Quote by Shinichi Suzuki

One of the most essential rules that I recommend is to practice every day. And I mean it when I say every day.

The first few months of your learning, especially when you do not have any tech-related background, are fundamental as you are laying down the basis on which every follow-up piece of knowledge will be stacked.

This rule has a real benefit: it speeds you up in the long run as you rarely need to revisit the old subjects. You may still need to do it occasionally (some things are slipping from the memory, it is natural), but you less likely will need to spend several hours trying to grasp again the details you lost. Chances are high that a quick skimming through your notes or subject's summary will suffice.

In the beginning, people sometimes freak out hearing this rule. It may be related to the fact we got used to having 2 weekends where normally we can ignore the work. Initially, It may just seem "wrong".

But this rule is simply an adoption of distributed practice learning strategy that has numerous study based evidence that it is more effective than the massed practice (when you basically learn something in one session for a longer period of time).

It also does not force you to practice 4 hours per day every single day. Sticking to such a schedule may be extremely difficult, after all, many of us have work, family, or some responsibilities we have to focus on regularly.

This rule merely requires you to set up a minimal amount of time you will invest every day, including weekends, holidays. And, yes, on grandma's birthday as well.

Half an hour (30 minutes) in my practice proved to be the optimal number, but it may be as well 20 minutes or 40 minutes.

It is possible to find that time almost any day almost for everyone. Unfortunately, you may need to wake up a bit early some days or go to sleep slightly later, you may have to skip the lunch with your friend and eat it quickly alone instead.

And when you feel you have more energy and time reserved, go on and practice longer, the rule should not limit you and your passion to practice more, it only makes you stay disciplined 😉

2. Track the learning time in an app. "Toggl" is a good option. ⏱

Report by one of the developers I've been helping to. She's been really determined to master the frontend.

Tracking time may seem controversial. The benefits of this technique may not be apparent, so let me explain.

It helps you to identify inconsistent learning (see the first rule). You open the timer's report on Sunday and now you have a pretty clear picture of how the week went for you.

Did you manage to practice consistently? Which days did you put more time? Why? Which days less? Why? What topics were the most challenging? Should you go over them again in the upcoming week? This way you not only make sure you work hard but also guarantee you are working smart.

But above all, it may stop you from quitting. For someone like me, it is a dealbreaker.

One day you may get to a point when you feel like you want to quit. It is okay, it's common. In my practice, it often happens when a learner (me included) already gets to some logical "midpoint" of the learning process.

It is a stage when you already have quite a few knowledge on the subject, for example, frontend development, but it is not enough to let you achieve your primary goal (i.e. find a job, build some specific project, finish a coding challenge, etc).

On that day, opening the timer app, and seeing how bloody many hours you put into the craft so far can be exceptionally refreshing to the degree that you get a thought like "Screew it! I invested so much time and effort into this, the heck I will make that time wasted for nothing."

3. Find a mentor. Going to local meetups or joining Slack communities (pandemic way) is helpful for that. 🧔👱‍♀️

Do. Or do not. There's no try.

This advice helps immensely. But I would like to say that having a mentor does not make you less or more self-taught. It is true if you properly consider who the mentors are and what they here for.

— Mentor is not supposed to teach you. Yes, you still supposed to learn on your own. There are many experienced and qualified teachers for that, and, frankly speaking, your mentor may not have strong skills in teaching itself (though it is helpful when they have). Rather expect this person, when asked, point you to Google if he or she knows that the subject is trivial and you are capable of finding an answer yourself. It is actually a pretty important skill you need and your mentor most likely thinks the same.

— Mentor is not your curriculum developer. A mentor can advise you which subjects you should focus on or which to ignore temporarily. They can help you prioritize building some skills beforehand (for example, get a touch of Git after familiarizing with HTML & CSS), but they are not responsible for building your learning plan. They may give you a hand on that, but I wouldn't expect them to do everything here for you. To be self-taught, you need to learn how to plan your learning.

So, what are the mentors for?

They are here to help to dissemble challenging concepts after you tried to grasp them through courses, books, or articles. Some topics, e.g. the mentioned Promises or async/await syntax, are harder than the other, e.g. if statement. The mentor may ask relevant questions to understand how well you understand the subject, figure out where are weak points in your compression, discuss/explain those and provide you useful materials to defy the subject again ⚔

They also help you to stay engaged. For example, they can discuss with you the Javascript news, share a funny story from work - when they were addressing a recently introduced colleague by the wrong name the whole week... not so funny, actually. Or simply make a harmless joke on you about the last mistake you made during solving a coding challenge (a sense of humor is essential to high self-esteem).

And the last, but not least. The mentor shares with you his/her experience. It can be strictly related to tech, for example through code reviews and pair programming. Or it can be outside of the tech scope, like self-management traits, seeking for a job, writing articles.

It also may be related to highly personal things. But you need to trust your mentor with this, and vice versa, the mentor has to demonstrate trustworthiness. Work and your personal life are often so intertwined, that whatever happens in the one, affects the other. We are human beings and it is normal, but sometimes it may affect you quite strongly, so it is worth asking your mentor advice if you feel you trust them.

I want to share a project that I and my partner have been working on for a while.

We came up with a challenging project to help junior frontend developers that need to showcase their skills and want to build a portfolio to ease the problem of getting a job in the industry.

You can check out it at https://banda.works/housework-undoer.

Housework Undoer is a project organized into separate tasks through which you will build a frontend app to help our (imaginary) friend Jack.

Housework Undoer's app screens

See full size image

Thank you for your time and have a productive day! 💪

Do you need a portfolio to get a job as a junior developer?

Vitaly Krenel — Sat, 11 Jul 2020 04:54:17 +0000

TL;DR.

It depends. There are definitely some paths you could choose to go and start without a portfolio. But by having a decent portfolio (doesn't really matter pet or business projects) you making the task of getting an interesting and well-paid job significantly easier.

If you don't have any project yet or looking for it, below I have a personal story you may find something to learn from and a nice-looking project you could build to add to your portfolio (don't worry, it's free). See you around.

The beginning

Hey. My name is Vitaly. I've been working here and there as a developer for around 6 years. I started as an I-will-do-any-web-related-thing freelancer in my hometown (focusing mostly on design, PHP websites, and CMS engines) and later I moved to a more challenging backend and frontend development.

Initially, I had basic web development skills. I primarily raised those while making a few game-related websites with my friend (you could earn some money on those, especially when you like games yourself and know well game's audience). We had a few experiments but those weren't particularly successful, we split and I went for freelancing.

Later on, I found a mentor. The big guy helped me to hone my skills into something more tailored. Having such a person behind my back immensely boosted my determination and the desire to work hard. I wanted to impress him after all.

When I was starting my "freelancing career", I had neither enough experience nor outstanding projects to prove that I had a decent skillset. On top of that, I was quite young - barely 16 years old. Now you probably can imagine the skepticism people had when I was offering my services.

Still, I didn't care much and had enough reasons to ignore the doubtful looks. I would say that it is one of the most important lessons - to ignore skeptical people, - even though it sounds pretentious.

Lights, camera, action

With all those assets, I had a few strategies to get on the market: either doing random projects providing the best quality I could - I had to dump the price to lure companies in spite of high risks involved with schoolboy doing their projects - or ask people who already knew me (and trusted me) whether they had some work. I tried both. For sure, there were other options as well, but these two I was mostly focused on.

During that time, I was taking on any project (including design ones, like creating promo wall posters, etc.) that I could reach.

One day, my mentor introduced me to a guy that was a media website owner that occasionally had side projects with local companies, including web development endeavors. I ended up doing a few projects for him, which helped me to raise credibility in the eyes of local businesses eventually.

I was working as hard as I could (while still managing to study at school, so that would be I was working at nights) towards quite a reasonable goal for that time.

All those struggling were dedicated to building a stable source of income. I was trying to gather a pool of clients that trusted me and my work and would be willing to collaborate with me again in the future. I staked on the fact, that they would be willing to introduce me to their partners when those would start any web-related project (and with that expanding my client pool further).

As it often happens, that idea failed. But not in an apparent way I imagined it would.

Couldn't raise the bar

Taking on every possible project and at the same time keeping low prices got me locked into a nasty situation. I was spending my time resources quite inefficiently and even though I built a portfolio of projects, almost all of them were admittedly shitty (pardon me). I couldn't really impress a big company with those.

I built a client base and earned some status for being trustworthy, started collaborating with local web development studio, learned a lot of things, many of those were beyond development subject, like communication, design and especially common wisdom (you ask for advance payment when you don't know the client).

Nonetheless, I felt that I couldn't raise the bar. Neither professionally - getting on huge and challenging enough projects - nor financially - significantly increasing my income.

What's probably even worse, my skills were scattered around all areas. I didn't have any primary area of expertise. I was quite okay at everything but was great at nothing. I invested more than 2 years into that, but the return was not exactly what I expected.

Anyway, the school finished, I moved to another city, started a bachelor's degree. Next year and a half I'll keep behind the curtains (as they are irrelevant to the subject), but I have to say that throughout that time, I revised my strategy, quitted the university to have as many resources as I could and shifted the focus from the freelance market to tech companies.

Freelance was great. It still is, especially for people who love to have a lot of autonomy in their work. I'm occasionally taking on projects.

But at that time, I could find ways I would be able to go on without scaling (to meet my financial expectations) and I still wanted to get more of "hardcore" engineering experiences 🤘.

Interviewing process

I had worked for 2 companies so far, the one being a software development outsourcing company and the other being a startup. The startup gave me an especially valuable experience where I had quite diverse tasks to solve. That seems to be the nature of startups - diversity.

So if you are tolerable to risks (which I happened to be after working as a chaotical freelancer) and want to work with different things (quite often from scratch), I recommend you trying out a startup instead of a huge tech company. Though keep in mind, that I mentioned risks intentionally - there's a high chance of startup failing (they say, 9 out of 10 startups fail, never had a chance to check the stats behind this number).

In that startup, I have also had a chance to participate in the hiring process.

It was quite enlightening to see that there are quite a few junior devs that do not really have projects they can share to showcase their skill set. Instead of trying to impress through talking and persuasion, those developers could have taken out a few projects to eliminate the doubt in the looks of interviewers.

I do not diminish the ability to speak or the fact that you still should demonstrate your personal traits and character through the interview. But to prove your skills, a couple of well-built pet projects would work more efficiently and would more likely to increase your chances than letting interviewers examine you through their own assignments and questions.

You will be playing on your own field, so to speak, if you open your project and start telling what challenges you had to overcome while building it.

As I said that experience was quite enlightening for me and I sadly realized that I personally failed to build a decent portfolio at the beginning. I should have done it, but I didn't. And that hardened my life and I repeatedly had to learn how to persuade people, instead of focusing on building projects so companies would not be able to ignore me and would be willing to hire me.

Afterthoughts

I can conclude that It turned out well for me after all, but there had been so many trials and errors before I reached the financial and professional levels I was aiming for. It is not that I went the wrong path, but rather I chose the least optimal one if we consider my goal of getting into high paid but at the same time challenging engineering projects.

These days I'm involved in mentoring junior devs looking for jobs. I'm simply trying to share the experience I've collected so far as in the beginning my mentor did for me.

I'm again and again seeing the pattern when companies are less willing to hire devs (or even reluctant to invite for an interview) without some projects behind. Some are okay, they usually provide their own assignment as a part of their initial filtering process, but quite a few companies are not.

I won't bluntly say for HRs and the agency as I have mere experience with their screening procedures, but I believe it is much easier to catch their eyes as well when you have a couple of decent projects in your portfolio.

As a final note, I want to share a project that I and my partner have been working on for a while.

We came up with a challenging project assignment to help junior frontend developers that need to showcase their skills and want to build a portfolio to ease the problem of getting a job in the industry.

You can check out it at https://banda.works/housework-undoer.

It is basically a project assignment through which you will build a frontend app (called "Housework Undoer") to help our (imaginary) friend Jack.

Housework Undoer's app screens

Thank you for your time and have a productive day!