This is a very general guide for less experienced software developers. It took me some time to realize these over the years and I think it would be a great help to me back when I started with coding.
-
Your code should be readable. Why? This great quote will explain it all.
Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. ...[Therefore,] making it easy to read makes it easier to write
- Robert C. Martin
Tests... Some clients/project managers believe that spending money on testing is a waste. You don't need that kind of negativity in your life. Tests are very useful for a bunch of reasons! First of all, they check if your code actually does what it's supposed to do. Second, refactoring - have you ever tried to refactor a class and hoped that each method returns the same result as before? Tests are also a type of documentation that helps new teammates understand what how and why.
Even though code never lies and comments sometimes do, it's generally a good idea to comment your code. Try to shy away from comments that explain your complicated code (see point 1) and use comments as a way to explain the business logic. Why this piece of code does what it does.
As a developer, it's your responsibility to take care of your
childcode. You think that a refactoring is in place? Get your client or project manager and explain to them why refactoring is a good idea and is needed. Technical debt always comes back.Ever wonder what's with all the rubber ducks around developers? When you're stuck on a piece of code you can try explaining it to a rubber duck. This method is called rubber duck debugging and it's a very powerful weapon in a developer's arsenal. Talking about your code and trying to explain it to somebody will help you get unstuck and think differently about your code.
Sometimes even a duck won't help. Talk to other people, preferably other developers ;)Have you heard of Agile? There's this idea of a daily meeting where the team talks to each other and shares problems or issues. Give that a try, it's easier to share ideas and ask for help when everyone knows what you're doing.
Documentation. Even more dreaded then tests. Tell me this, how would you use your favorite API or 3rd party service without their docs? Keep your teammates and other teams happy when working with them and document public-facing things.
Remeber the principles of software development (DRY, KISS, SOLID, and YAGNI) and try to use them on a daily basis, e.g. extracting a class or a module (DRY) will help to keep your code maintainable.
Sometimes when you read through the code you can find some oddities or simply a bad piece of code. Sure it works, but if you can improve it easily then why not? It's called the boy scout rule - "Always leave the campground cleaner than you found it".
"Measure twice, cut once" - it's always better to think about (or write down) things before doing actual development.
It may come as a surprise to you, but you're human. Everybody makes mistakes. You make mistakes. Get it over with. Making mistakes is a part of the job, I'd say. Try to make the most of it and when you make a mistake, try to learn from it as much as possible.
Don't hesitate to ask questions and oppose ideas. Questions can spark a discussion on why this feature is needed, how we should implement it, and what are the risks of this implementation.
Be eager to learn and to spread your knowledge. Books, blog posts, RSS feeds, conferences, podcasts, local user group meetings. Those are great to learn new things and to talk about your experiences.
Always keep an eye out for new libraries and new versions of frameworks/libraries that you use. Newer versions bring new and exciting features!
Use your workflow to your advantage. You're using vim? Great. Atom? Nice. Sublime? Yay. Write down your code on pieces of paper and then scan them? Whatever floats your boat. You want to know which editor/ide is the best? The best is the one that makes you feel comfortable.
Try to be professional. Don't use phrases like "we'll see" and "hopefully". How would you feel if you took your car to a mechanic and he'd tell you that hopefully, he'll fix it?
Never be afraid to ask. If you don't know something or are not sure, for the love of god, ASK.
PS. Oh, and take Ballmer Peak into consideration! ;)
Top comments (4)
Good article mate! I would consider extending 10th: As a begginer tryin' things out and constantly rewriting POC will give you practice and sometimes knowledge on the solutions for future tasks you will compete with.
Great advice, thanks!
Thanks for the kind words! It's my first ever article and was anxious to post it.
Thanks allot!!!