Suggestions for Junior Software Developers at the start of their careers

If you are just starting your career as a Software Developer, here are some things that you should consider doing. It is by no means comprehensive and not all points will apply to your situation. It's also written from my experience which has mainly been with small and commercial companies that use software to help increase profitability and efficiency. This is not an exhaustive list. It's just a start. If any Senior Developers have any more practical advice that can be added to this list, please email me. Andy.Coleman@UkSoftwareJobs.co.uk

Existing code

Make use of existing code. There is no need for you to create a new sorting algorithm. Work within the existing framework. You might not like the various layers and abstractions, but just go with it and you will be more productive and less disruptive than trying to refactor everything to your ideal architecture.

Ask for help.

If you are trying to fix a bug or implement new code and you are struggling to understand what to do, then ask for help. Quite often as you verbalise the problem that you are having you will suddenly understand it better. Try and have a rule such as not struggling for more than an hour before asking for help.

Keep up to date

Set yourself a study schedule that suits you.

Find communities, either local or online that you can join.

·         Pluralsight

·         .netrocks

·         Channel 9

Learn about the well-known software patterns and good practices, especially the SOLID principles.

Learn more than one language.

You will be more in demand if you learn more than one language. You could learn one or two back-end languages. A couple of front-end libraries and two database querying languages. This will allow you to move between teams and be far more valuable than someone who just knows one language.

Learn about your business domain.

Learn about the business domain that you are in. Ask team members including Testers and Business Analysts why things are done a certain way. You could even buy a book that gives an overview of the domain that you are working in.

Understand the project/solution

Get to know how all the parts of the application interact. If you are lucky, there might be some diagrams available. Otherwise, start at the UI and dig down to discover the data flow.

Business Terms Glossary.

If your company does not have a glossary of business terms, then start creating one. This will help you have a common language with the business users and product owners. It's a great way to learn about the product that you are involved with.

Understand your own code

Be able to explain what you have done and why. You'll need to be able to do this if your team has code reviews. Learn how to communicate with people outside your team who have no technical knowledge. Having unit tests help with this. If you are finding it difficult to add unit tests, then it is a good indication that your target code needs to be redesigned.

Feedback

Be able to handle feedback. This will occur during pair programming and code reviews.

Contribute

Don't keep quiet. If new work is being discussed, then join in. If something sounds wrong, then speak up.

Business focused

Remember that your team and whatever you are building is for the business. Keep focused on the fact that you are creating some sort of value for the company that you are working for. The code that you are creating is useless if it does not provide value in some way.