Seniors or not-so-junior developers, what advice would you give to people just starting working as junior devs? The advice could be anything really...
For further actions, you may consider blocking this person and/or reporting abuse
Break. The. Project. Down.
Seriously though, do it, and learn how to. It's all too often you get a ticket or a project for someone which has 10,000 requirements (Ok a little exaggeration) and it may seem like a huge task up front and can cause excess stress. But breaking it down piece by piece, suddenly things become much simpler and easy to manage.
Albeit not directly developer advice but being able to look at a project and be able to break it down, but hey, being a developer is more than just programming :)
Very good point actually. I'm still in shock when I see experienced developers writing code on the fly like they know where they want to get and how they want to do it, but not having an actual written plan anywhere. I guess this skill comes with years and years of experience. I'm at the point where I makes schemas on pieces of paper, even for simple tasks :). Thank you for the advice.
I find your comment kinda funny Silvia :)
You really will learn to write code on the fly (which is a very bad practice TBH) when you start doing it.
You can get a portfolio and editing code directly on production from the hosting IDE or using vim (or whatever) through SSH, but there's no much adrenaline here.
Then you can edit the .htaccess or add a return true (or false) at the beginning of a method (for blocking this path, for example on a method that calculate some specific discounts, when you want to finish this promotion and marketing department tell you to do that quick because they didn't planned it properly), or for fixing a blocking bug. All of it on a web app that earn 10M a year and then the adrenaline appears (and your know-how to open the views where your changes will take effect on a secondary screen before saving changes and make a quick test to ensure you didn't broke it).
My best advice here is:
I'm conscious that supposedly we must never edit code on the fly or in production directly, but sometimes it's needed for a quick fix (it's instant while a deploy could take 10-15min at least). When you are in this situation ALWAYS add exactly the same changes on your develop branch, as the next time you make a merge from develop into master for a new feature, you will not face a manual merge).
Totally agree. This is a very important skill Im trying to masterize.
Sort of on topic I guess. But also teach them that yeh. Being a developer isn't just developing :). Writing documentation, specs, debugging etc. Lots to programming other than code :)
Don't be ashamed to ask stupid questions.
Everyone makes mistakes, if you don’t make mistakes, it means you doing nothing.
If something went wrong, 99,9% a problem exists on your code, but if it’s is 0,01%, and an information about that issue is not exists, it’s normal to write a bug report.
Valuable advice and I like the 3rd point in particular. Being that person who finds a bug and ignores it just because it's not related to their ticket is never the way to go. Thank you.
I think it's important to share experience to beginners for trying them for not doing the same mistakes than we did in the past, and to reinforce their knowledge (and so passion) about what they like more (or discovering new things that they like and passions). By the way, giving some advice and practical teaching at job or in posts makes people more secure and so more comfortable using a technology, which increases the motivation for keeping on and becoming better at it.
I usually add advice for beginners / juniors on all my posts for this reasons, you are free to check it out :)
Thank you for sharing, I will definitely check it out. I agree that people should share knowledge and honestly, this is one of the things I like most about our field, people are always eager to help and share.
I really like your advice. I'm still guilty of some of the things you mentioned (especially point 3) but I hope the day when the learning journey will come a bit easier is not that far. Thx for the nice words.
You're welcome!
I know it's easy to say, but guilt won't bring you anything good. Don't compare yourself to others, it's flawed. Somebody will always be better than you, or worse. Plus, it's very difficult to have a realistic judgment on your knowledge/skills, on the others skills, and even more difficult to compare both.
Compare yourself to your past self. See if you improved. It will take time, so be patient. Meanwhile, enjoy the journey! Whatever happens, you'll always learn something new.
On top of some of the things that have already been mentioned by other folks, I would add this,
I have encountered people who just push code to master and do not track/verify whether it actually got deployed to dev. If anything breaks in deployment, they literally don't know what to do next or how to fix it. This not only takes time of other person who now has to troubleshoot, that too only after someone realizes that the code is not getting deployed, but also when you are not tracking, it can create confusion for anyone who is testing that functionality.
Do you mean, in this case, try to understand the tools you are using? Thx for the advice, much appreciated.
Yup to most extend. As an example, if you have a Spinnaker pipeline which deploys the artifact, if everyone understood what different stages that pipeline has and what each phase does (what script/lib it uses), it would reduce time and effort in testing/troubleshooting/fixing. Not necessarily understand the script/lib itself code wise but atleast knowing/understanding what it does can help.
This thought can also be expanded to other areas as well. If you consume something internally, testing/troubleshooting becomes easy if we understand what that service/server, that we consume, is doing and what are some of its dev/deployement workflows.
On a different note, I especially agree with this one when it comes to learning frameworks but not having any clue about how the language actually works :).
As someone who actually just started my very first developer job 3 months ago here are the things that I tell myself when working:
1) Don't be afraid and ashamed to ask questions! Your team is there to help you, and some even appreciate you asking questions because it shows them you're putting an effort with learning the codebase/system
2) Ask your coworker how they would approach a problem or how they would start. This is actually something I do because it gives me insight on how they see it especially with the experience they have under their belt.
Thank you for point 8, it's refreshing to read it. Sometimes I feel like I don't want to be a software developer and I guess that's ok. It's a difficult relationship. Overall, great advice, especially point 11.
Hi Silvia - one thought that jumps out at me is this - I recommend that you not explicitly label yourself as 'junior' in your public profiles. So 'Junior front-end developer' --> 'front-end developer'. Here's why dev.to/bhumi/don-t-label-yourself-... hope that makes sense! :)
Thank you for your input.
1) Search for help.
Sometimes you're going to be stuck in a problem. That's ok. It's easy to lose sight when you're looking for so long to a problem. By searching for help you're opening up to learn more quickly and get things done faster. It's almost like taking a shortcut.
2) Ask for feedback and mentorship.
This is what is most important when you're starting, know your blindspots. Ask for code reviews, mentorship this will make you a better developer every single day.
3) Take Ownership of your journey.
You have to own your journey. Own your career. Don't expect people to show up to help you, go for it.
I believe having a mentor is something that can make or break a junior developer. Guidance is always necessary, no matter how good of a programmer you are - it's like having a talent but not knowing how to use it, so a mentor is there to show you the way. Thank you for your nice words.
Use a lot of console logs. Google stuff a lot. Read documentation before you start using a library. If you are really stuck, and can't find out how to fix an issue then ask for help on stack overflow, etc. Sometimes you might need to re-word your google search query, but most of the time searching by keywords is enough.
Oh yes, still use the old console.log()s and always forgetting to remove them when submitting code for reviews :). Stackoverflow is my next best friend, after my dog. Thank you for the input.
You might want to add pre-commit hook which will run eslint. If you have any console.logs it would prevent you from committing your code before console logs are removed.
Didn't know that's even a thing. Thx for the tip!
Protip 1: Don't just focus on coding. Coding is important as a developer - obviously - but getting inside people's heads and finding out what will bring them real value will be more important before you start coding a single line.
You can either choose to be someone who gets a pile of specs on their plate, and turns them into code
Or you become the person that figures out the best solution with the customer, help them define the problem and the solution and builds the best solution for them.
Protip 2: either code on something to learn, or code on something to build and ship it. If you choose the latter, choose a tech stack that you know (best) and build the best solution in order to ship it faster.
Thank you for your input, I am happy to see I'm already doing many of the things you mentioned.
I wrote an article about this topic :)
Here: medium.com/@mhkoca/pieces-of-advic...
Spend some time learning to use the IDE tools effectively. This means learning its shortcuts, debugger etc. This'll help in boosting productivity.
Have an understanding of the architecture of the project. This will help in understanding how it all connects and give you an idea of what to do and what not to do when working on your feature.
Learn to read code. Even the thought of going through a massive code base can be intimidating. But you need to dive in and figure out what the code does and how it behaves (at least for the parts relevant to you). The key would be to not fixate on every single line and just try to get an understanding of what it does (given that the code quality is good :P ).
Related to 2 and 3, setup and run the product. And then, use a debugger to trace through the execution and really see how it behaves and works.
Teach someone/answer questions (can even be on Stackoverflow or similar platforms). It can be a great way to really evaluate what you think you know. Sometimes when I try to answer someone's question, I realize I don't quite have a comprehensive grasp on that matter.
Blogging can be good too, for similar reasons as the above point and to create an online presence.
Read Clean Code. It's THE bible on writing quality code.
Related to the above point, try to keep it simple, without trying to be too clever. The code written is not just for the machine, other developers will be reading it too. If it is not easy to read, it'll result in a lot of dev hours wasted trying to decipher the code.
Be objective about your code.
I have had occurrences of junior developers who would get very defensive about their code as if it were their child. If someone's criticizing your code (politely), thank them for their advice. Then, either look into it or ask them for more details. At the end, either you or them will be right (or both!) - with valid arguments instead of tension.
Focus on actual tasks, or feature requests in other words. Understanding others and requests are primary, programming language skills come in second. There's huge amount of beautifully written, useless software that uses cutting edge technology.
Stick to one good company for as long as possible in the beginning. Good as in good developers willing to teach you. Switching can lead to "jack of all trades master of none", and from personal experience 7 years down that road is pretty depressing but you need to make a living so you fight as long as you can.
If switching companies, switch between small and big companies. You need to feel what is like to work with enterprise and with startups looking they're gonna hit enterprise but you need to put in a lot of messy code so you get funding :D - this is where ninja refactoring is practiced.
Just because majority is heading that way, or using that thing, or doing that way, doesn't mean it fits your software. Even if the big guys do it doesn't mean it will help you. When you're ordered to do it in a certain way like "unit test everything" try to see how much was it useful, in that example, how many "green tests" were in fact incorrect feature implementations because of unclear specs or poor communication, therefor useless and waste of time for writing.
Adapting to change is hard when limited to certain tools because someone likes it that way or because of finances, or limited to certain approach like 100% code coverage. This is visible mostly in startups when wanting to have feature change in 10 min during demo and you need to leave it there while working also on feature for next week demo :D.
Be patient, and most importantly less stressful. Enjoy the learning process and don't rush it 😊
Still need to work on my patience. The pressure to get up to date with everything is sometimes very big. Thx for the input.
Go and ask on Stackoverflow if you can make a question there, then you can deal with any a**ho*le and also you have proven yourself you can explain a problem properly to a peer.