Quality feedback is an essential part of professional growth and we love sharing it not only within our team but also with candidates who get interviewed. In this article, we collected some tips from the real feedback given by our CTO Dima and Lead developer Andrew to junior developers. But we also believe that these thoughts can be a good checklist for more experienced developers.
Before asking for help, you should read the error messages carefully and understand them. However, there’s nothing bad about accepting the fact that you don’t understand something.
If you don’t understand the error message, you can tell honestly about this. It is a bad habit to send a screenshot with the text “I have an error here.” Instead, you can send an error message and write: “I’m rebasing and have resolved the conflicts but the git says that something needs to be committed while there’s nothing to commit. It says that I can skip the commit, but I don’t understand what it means to skip the commit.”
As the very first step, we advise you to study git so deeply that you understand every word in every command you write. We suggest you read the ProGit book or watch my talk about git.
It will be very helpful to learn the command line and CLI tools. What happens when you write a command in Linux terminal? How does Linux know what binary file to execute? How is it different if you run the same command on Windows? You can watch a video about shell on datarockets YouTube.
Junior developers often share many lines of code to chat or, much worse, a screenshot, with the comment “it doesn’t work, can we have a call”. However, they don’t say what exactly isn’t working. In such situations, it is impossible to help without a call and a pair debugging session.
Instead of asking for a call, it would be much more useful if you describe the problem in words, without pictures or screenshots. A good example, “after line 7 I was expecting to see <x>, but <y> occurred instead”, from the guide “How to ask questions the smart way”.
When you describe the problem in words, sometimes it happens that a good assumption about the problem’s cause pops up in your head and you may realize how to fix the problem yourself.
If you don’t understand how something works, read the error message, see exactly where it occurred, try to isolate it so you know exactly which piece of code is causing the error. Make a guess as to why the error might have occurred and try to fix it.
Your first inclination could be to fix the error as quickly as possible in any way you can, without getting to the root of the problem. Even though it might work sometimes it’s hard to learn from this experience and we may leave some hidden bugs unfixed.
Ideally, for every single word in the code you write, you should be able to answer why you wrote it. For example, in the code below, what for the CSS class “layout” is here? Where is the code for this CSS class written?
<Layout className={`layout ${css.layout}}>
Here’s a great book about debugging, which we highly recommend. One of our favorite tech writers, Julia Evans might publish a zine about debugging soon: Reasons why bugs might feel “impossible”.
Code review will help you to learn faster, think critically and adopt coding standards. It is a necessary element of developing your solution-design taste, it brings room for knowledge sharing as well.
Read about Code Review Best Practices and start following them. The Clean Coder book will tell you everything about writing maintainable code. The ideas from it will help you in code review as well.
There’s a more advanced level, but if you pump it up, it will make you a self-sufficient engineer who doesn’t need any guidance to complete features.
It includes discussing a feature with a client, breaking it down into tasks, self-assigning to the tasks, suggesting what you could do instead of asking others what to do next, and delivering with final deploy – the full thing.
Improve your architectural skills by facing technical challenges of higher complexity and learn more about design patterns. There’s no growth without a challenge, so don’t be afraid to take a more complex task even if it requires some support to complete.
One of the important skills for developers and engineers is curiosity. Curiosity drives us to learn new things and improve our skills.
Be curious about colleagues’ work. Do you know how they debug programs? Do they use UI debugger or debug output? What do they look first at during the code review? What do they dislike about the language you use and why?
Be curious about the tech you hear or read about. Did someone mention Kotlin Multiplatform Mobile? Try to learn how it works and what it offers. Apple released the M1 chip that you heard uses ARM architecture but you don’t know what ARM means and what other architectures exist? Ask your colleagues about this and engage them in communication. Saw that the output of git log looks different on your colleague’s computer? Ask them to share how they configured this.
Check out our newsletter
© 2024 Red Panda Technology (dba datarockets). All Rights Reserved.
