Reflection allows you to process what happened, increase self-awareness and challenge your thoughts and ideas. You can then acknowledge what you have learnt and how you can take those lessons into the new year.

Below are a set of questions you can use to help you reflect on your year and plan ahead for growth.

Find a quiet space and spend some time answering the questions without interruptions.

Looking back:

1. What were your career highlights for the year?

2. What went well this year?

3. What did not go well this year?

Your current skills:

1. What are your strengths? How do you know that?

2. What do you need to work on improving? How do you know that? How are you working on this area?

Looking ahead:

1. What is your desired long term career trajectory? Role and the type of work you want to be doing? (Think 5 years from now).

2. What are your goals for the upcoming year? What would you like to achieve?

Motivation:

1. What kind of work / work-related things give you satisfaction?

2. What kind of work / work-related things irritate you?

Final thoughts

That is all. The above questions are one of the best ways I have found to reflect on your year and plan ahead.

Reflection and goal setting are powerful tools for thinking about your ideal future, and for motivating yourself to turn your vision of this future into reality. The process of setting goals helps you choose where you want to go in life.

By knowing precisely what you want to achieve, you know where you have to concentrate your efforts. You'll also quickly spot the distractions that can, so easily, lead you astray.

Wishing you all the best for 2022!

Having good communication skills will help you work well with your team and others through communicating your messages across effectively.

Software development is a technical field and developing your technical skills often takes priority over other skills. However, it can be argued that communication skills are equally as important as technical skills. Failures in software teams result more often from communication issues than from technical problems.

Software developers are often expected to naturally have good communication skills. However, this is not the case in reality. Most software developers have poor or underdeveloped communication skills. Similar to technical skills, you have to work on improving your communication skills. Both written and spoken communication skills are important to develop.

In this article you will learn different approaches you can use to improve your communication skills as a software developer.

Learn to listen

Listening is the most important skill to develop if you want to become a good communicator. This is because great communication happens when all parties reach a point of mutual understanding.

In a highly technical job such as software development, reaching a mutual understanding is even more important. Differences in understanding of an implementation can lead to errors and bugs, extended project timelines, and disappointment from unmet expectations.

As human beings we often rush to express our thoughts and opinions without allowing the person we are communicating with to finish speaking. We stop listening the moment we think of an opposing point or what is we believe is a better idea. This leads to bad communication habits.

To improve your communication, you must learn to not interrupt others when they speak to you. Listen carefully to what the other person is saying. Give them time to say everything they want to say before you add to the conversation. When you are ready to add your own thoughts to the conversation, one thoughtful technique is to quickly rephrase what the other person just said so it is clear that you have understood what they are communicating.

Your body language also plays an important role when you are listening to someone else speaking to you. Being engaged in the conversation shows you are interested in what the other person has to say and is also a sign of respect. Have a comfortable amount of eye contact, stand/sit with a good posture, focus on the conversation (don’t look elsewhere or use your phone).

Listening is fundamental to good communication and should be the first skill you work on improving as a software developer.

Present your work to others

As a software developer it is important to be good at communicating about your work and ideas with others. This is how good collaboration starts. You have to be able to express yourself clearly when talking about what you built, why you built it, and how you built it.

You have to be able to determine how to communicate appropriately depending on context. Most of the time you will be communicating with other developers and you can communicate in a very technical way. Other times you will be communicating with a non-technical audience and you will need to communicate in a way people understand what you are saying without using technical jargon.

One of the best ways to practice improving spoken communication is through presenting your work to others. Present your work to your team and other people. Volunteer to be the presenter at team demos, code reviews, stand-ups, and any other opportunities that are available in your workplace.

Always ask for feedback from a few people after you have presented your work. Use the feedback to help you improve your future presentations. Over time you will become better at expressing your ideas and talking about your work. It will also become less stressful when you have to present your work to others.

Speak at meetups and conferences

Public speaking can be a nerve wrecking experience for software developers. One of the best ways to improve your public speaking skills is by committing to speak at a software meetup or conference.

Identify some meetups of conferences in your area and apply to speak about a topic you are passionate about. Once you are selected as a speaker for a meetup or conference you will have to practice so you can deliver a great talk. This is where all the learning happens.

You will need to develop skills such as making good eye contact with the audience, speaking at a volume everyone can hear you, using good body language and posture, and speaking with clarity. All these skills that are useful for delivering a great talk will improve your general communication skills as a side-effect.

If you constantly practice public speaking you will improve your spoken communication skills.

Write documentation

Writing some documentation will provide you with an excellent and free written communication exercise. As a software developer working in a team there will be many opportunities to write some required documentation.

Examples of documentation written by software developers includes, deploy notes, code review notes, user instructions, API documentation, incident reports, product / project proposals and many others. All these documents need to be written with clear communication for their audience.

To improve your written communication skills, volunteer to write some documentation when the opportunities present themselves. Always ask for feedback from the audience of the documentation that you write. This will help you improve any future documents that your write.

The documentation that you write can be technical or non-technical. Both are important aspects of day-to-day software developer communication.

Start a blog

Starting your own blog is also another great way to practice and improve your written communication skills. Having your own blog will give you a public audience and you will need to learn how to write your blog posts so they communicate topics in a simple way with clarity.

On your blog you can write about any topics that you are passionate about. This will help with your motivation for starting a blog and publishing blog posts consistently. Remember writing consistently is the best form of practice and over time your writing skills will improve.

If you keep comments from the audience open on your blog you will also be able to receive feedback from your audience. Use the feedback to improve future posts and improve how you communicate back-and-forth with the audience.

Over time you will become more confident about how you express your thoughts publicly which is a skill all software developers require as they work in teams over their careers.

Final thoughts

As a software developer, being able to communicate in a clear and concise way is fundamental to having a successful career. Software developers rarely work in isolation. There are other parties involved, other developers, stakeholders, users and many others.

Technical skills development is often given priority by software developers, however, improving communication skills is also very important. In this article you learned about different approaches you can use to improve your communication skills as a software developer.

I am interested to hear what other approaches you are using to improve your communication skills? Let me know in the comments.

I hope you enjoyed this newsletter! Share it with a friend or colleague if you found it helpful. 👋

Coding is a skill that can be improved with consistent disciplined practice. Using the correct approach to learning will make you a better software developer and you will appreciate the difference within a short space of time. Improving your coding skills will create many opportunities for you.

The question you may be asking yourself is - How do you improve your coding skills daily?

In this article, you will learn how to improve your coding skills daily. You will learn how to build a daily learning habit and the different practical approaches you can use daily to improve your coding skills.

Build a daily habit

Your starting point for improving your coding skills should be to set some goals for yourself. Your goals will be constant reminders for why you want to improve your coding skills. They will serve as constant motivation for you to keep learning and growing.

To set your goals you can ask yourself the following questions:

1. Why did I become a software developer?

2. What software development skills do I want to improve?

3. What do you want to achieve with the improved software development skills?

Write down your answers to these questions and use them to set some goals for your coding improvement journey.

After setting your goals it is important to establish a daily learning habit that will improve your coding skills. Start small, it is easier to build a new habit and be consistent if it is simple to do. As an example, you could start with 15 - 30 minutes of learning per day.

Try to schedule the learning for the same time daily. Habits form more easily if they are repetitive. Your mind gets used to doing the same task at the same time each day. As an example you could schedule for your learning to start as soon as you wake up each day, or after eating dinner each evening. You can use a calendar invite or alarm as a reminder/trigger to start your learning sessions so you don’t forget and skip them.

Once you start building your daily coding learning habit, be consistent. Show up every day for the learning sessions. You may skip some days, that is ok, you are human and things may come up. However, try to avoid skipping consecutive days as you might break the learning habit and struggle to rebuild it.

Now that you know how to build your daily coding learning habit, in the following section, you will learn about practical approaches you can use to improve your coding skills.

Improve your coding skills

There are many different practical approaches you can use to improve your coding skills. A suggestion is to start with one approach and build the habit of doing it daily. Once you are consistent with the learning habit you can then add other approaches to enhance your learning.

Read books

If you want to be a good software developer you have to be constantly learning. One of the best ways to learn is through reading good books. Reading expands your mind and there are plenty of good books you can learn from. Select books that teach the coding skills you want to improve and read them during your scheduled learning time daily.

Listen to podcasts

If you want to be a good software developer you have to be constantly learning. One of the best ways to learn is through listening to good podcasts. Podcasts have become more popular as a learning medium. The great thing about them is that you can listen to them as a secondary task: such as while you are on your commute to/from work or while exercising. Select podcasts that teach the coding skills you want to improve and listen to them during your scheduled learning time daily.

Read open source code

Authors of books become better writers through becoming better readers. They achieve this through reading more books. Similarly, you can improve your coding skills by reading more code and learning/understanding different code design approaches from multiple codebases. You can learn a lot by reading code written by other good software developers. One of the best places to read code is in open source projects that are written in the programming language you want to improve your coding skills in. Find these open-source projects and read their source code during your scheduled learning time daily.

Follow coders you admire online

Many inspirational software developers have a presence online where they share their knowledge. They are on platforms such as Twitter, LinkedIn, Dev.to, Hashnode, and many others. You can follow these software developers on these platforms and you will be notified when they share new content which you can learn from. You can also actively visit these platforms daily during your scheduled learning time.

Work on a personal project

If you want to become a better software developer you have to solve more coding problems in different contexts and codebases. A personal project is something you do aside from your main job. It is a project you create for yourself in pursuit to learn something new or completely outside of your day-to-day activities or even comfort zone. Personal projects allow you to learn new patterns, programming languages, and concepts you otherwise would have ignored. The theory is just theory until you practice. Identify a problem you would like to solve for yourself and work on it during your daily scheduled learning time.

Play online coding games

There are online platforms that allow you to improve your coding skills through gamified learning. These platforms will help you grow your programming skills and increase your confidence as you solve puzzles and progress through multiple levels. This keeps your learning journey interesting. Examples of such platforms are - Codewars, HackerRank, and CodeGym. Find a platform that teaches the coding skills you want to improve and use the platform during your daily scheduled learning time.

Final thoughts

Improving your coding skills will help to create future opportunities for you. The most effective way to improve any skill is through consistent daily practice.

In this article,

you learned how to build a daily learning habit and the different practical approaches you can use daily to improve your coding skills.

You may be thinking about how you can measure if you have done enough testing on your code. Are you confident your tests cover all the different scenarios your code will run? This is where code coverage comes in.

You may have heard the term code coverage mentioned already in your workplace and you are not quite sure what it means or where it fits in.

In this article you will learn what code coverage is, how code coverage is calculated, and how much code coverage to aim for in your tests.

What is Code Coverage?

Code coverage is a metric that can help you understand how much of your source code is tested.

A program with high code coverage, measured as a percentage, has more of its source code executed when you run its test suite, which suggests it has a lower chance of containing undetected software bugs compared to a program with low code coverage.

Code coverage is a very useful metric that can help you assess the quality of your test suite.

How is Code Coverage Calculated?

To measure what percentage of your code is tested, one or more coverage criteria are used. Coverage criteria are usually defined as rules or requirements, which a test suite needs to satisfy.

Code coverage tools will use one or more criteria to determine how your code was exercised or not during the execution of your test suite. The common metrics that you might see mentioned in your coverage reports include:

• Function coverage: how many of the functions defined in your source code have been called.

• Statement coverage: how many of the statements in the source code have been executed.

• Branches coverage: how many of the branches of the control structures (if statements for instance) have been executed.

• Condition coverage: how many of the boolean sub-expressions have been tested for a true and a false value.

• Line coverage: how many lines of your source code have been tested.

These metrics are usually represented as a coverage percentage - the number of items actually tested divided by the total items found in your source code (items tested / items found).

A good code coverage tool will give you the percentage of the source code that is tested, and also allow you to dig into the coverage reports to see the actual items that weren't covered by tests and then use that to identify critical parts of your application that still need to be tested.

There are many code coverage reporting tools. Examples such as Istanbul for the Javascript programming language and SimpleCov for the Ruby programming language.

A simple search for your “[programming language/framework] code coverage” will present you with options. You might find several options to create coverage reports depending on the programming language/framework you use. Select your preferred option for your project.

You can then integrate code coverage into your daily development workflow - when you run your tests locally, and in your Continuous Integration (CI) reports on pull requests or merge requests.

Is 100% Code Coverage the Goal?

Having a high code coverage means most of your source code is tested. This is a good thing, however, you need to be careful about only looking at code coverage in isolation. A high percentage of code coverage could still be problematic if critical parts of your application are not being tested, or if the existing tests are not robust enough to properly capture failures upfront.

It is generally accepted that having 80% code coverage is a good goal to aim for. Trying to reach a higher coverage might turn out to be costly, while not necessarily producing enough benefit.

If you are just starting with testing and you run your code coverage tool you will likely find that you have a low percentage of code coverage. This is normal and you can gradually increase the coverage over time. As you add new features or are refactoring existing code, make sure you are adding tests to cover your code and increase your code coverage.

While code coverage is a good metric of how much testing you are doing, it is not necessarily a good metric of how well you are testing your product. Achieving great coverage is an excellent goal, but it should be paired with having a robust and high-quality test suite that can ensure that the source code behaves as expected.

Conclusion

To recap - In this article, you learned that code coverage is a measure that tells you how much of your source code is tested. It helps you measure the efficiency of your test implementation.

The five code coverage methods are - Function coverage, Statement coverage, Branches coverage, Condition coverage, and Line coverage.

You should aim to have a high code coverage, however, 100% coverage may not be realistic or necessary. You should also ensure that your tests are good quality tests that give you confidence about your source code.

Are you measuring code coverage in your day-to-day work? How is that working for you?

1. Through automating test scenarios using frameworks and libraries. We covered some of this in our “what is unit testing?” article.

2. Through a human manually executing test cases from a test plan.

Modern advances in technology have made automation frameworks and libraries more available and easier to use for software teams. It would be normal to assume that manually testing is obsolete. This however is not true.

This article will explain what manual testing is, how to do it and, why we need it.

What is manual testing?

Manual testing is the process of manually testing a software application to identify the bugs, issues, and defects in the software application. Manual software testing is the most primitive technique of all testing types and it helps to find critical bugs in the software application.

The tester plays the role of an end-user and they use most of the application’s features to ensure correct behavior. To guarantee the completeness of testing, the tester often follows a written test plan that leads them through a set of important test cases.

Usually, manual testing is carried out by a professional involved in software testing. However, even a novice can do it without any knowledge of any particular tool. Even a student, who has a basic understanding of the application or testing of a system, can perform manual testing.

How to do manual testing

Testers analyze whether or not there are differences in the observed and expected output of a software application; any differences found are outlined as defects. Thereafter, the software developers need to fix these defects and the software application can be retested.

Software manual testers plan and implement test cases for all the core features of a software application while also generating test reports manually.

Below are a set of example steps a tester may go through to perform manual testing:

1. Understand the requirements and expected functionality of the software application that will be tested.

2. Draft test cases that cover all the requirements and expectations.

3. Review the test cases with the software developers and client (if applicable).

4. Execute the test cases on the software application.

5. Report any defects that are identified.

6. Once the defects are fixed, execute the test cases again to ensure they are fixed.

Testing requires high analytical skills and can be challenging at times, especially for larger and more complex software applications.

Manual testing benefits

1. Manual testing is less extensive and has a smaller immediate cost when compared to automated testing. There are no software tools used to set up and execute the test cases.

2. Humans observe user interfaces and judge better than automated tools. The basic usability and look & feel of a software application can be better evaluated by humans. Humans can do better justice of validation of a software application from a user experience perspective.

3. Manual verification always gives a broader perspective of a software application. As the human mind will always be in an exploratory form, instead of a coding mechanism that executes the same steps each time. So, it will provide more expansive coverage for the system validation.

4. A majority of bugs/errors in a software application will be caught by manual testing.

Manual testing limitations

1. Manual testing execution is slower than automated test execution. Code executing on a computer is always going to be faster than humans performing actions manually.

2. Manual testing has to be repeated each time a change is made to the application and this is very time-consuming when compared to easily re-running automated testing scripts.

3. Manual testing can also easily become boring for the testers and may lead to their testing work dropping in quality.

4. Just like any other form of testing, manual testing cannot guarantee you 100% coverage of every scenario a software application can go through. There will be some gaps and the more detailed a manual tester is the longer the testing phase is.

Final thoughts

Manual testing is a vital part of user-friendly software development because humans are involved in testing software applications and end-users are also humans. It judges software from the most important metric: User Experience.

One of the software testing fundamentals is "100% Automation is not possible". This is why manual testing cannot be avoided altogether. Some companies do manual testing as support for automation testing. Although technology has advanced and shifted software teams towards test automation, manual testing is still essential.

As a software developer, you want the programs you write to work as expected. You want the programs you write to be bug-free so that only the best product reaches the end-user. Testing can help give you confidence that your code works as expected.

In this article, we are going to discuss a testing approach known as unit testing. What are unit tests? How should you implement them? What are their benefits and limitations?

What are unit tests?

The goal of unit testing is to isolate each part of a program and show that the individual parts work as expected.

Unit tests are automated tests written and run by software developers to ensure that a section of an application (known as the unit) works as expected.

A unit is the smallest piece of code that can be logically isolated in a system. This may be an individual function, method, procedure, module, class, or object. Generally, a unit has a few inputs and a single output.

Unit testing is done during the development (coding phase) of an application by the software developers.

The entire system will only be able to work well if the individual parts are working well. By writing tests for the smallest testable units, software developers build confidence that the entire system will work as expected.

Once a software developer writes a unit test they can run it on their local machine to check if the test passes. They can also run all the other pre-existing tests to check if they are still passing.

Software developers generally use a unit test framework to develop automated test cases for unit testing. Unit test frameworks are software tools to support writing and running unit tests, including a foundation on which to build tests and the functionality to execute the tests and report their results.

There are unit testing frameworks for most popular programming languages. Some examples of popular unit test frameworks are Jest for Javascript, JUnit for Java, and NUnit for all .Net languages.

During test case execution, frameworks log tests that fail any criterion and report them in a summary. Depending on the severity of a failure, the framework may halt subsequent testing. 

Unit tests can also be set up to be executed on each new build before code is released to a Staging or Production environment. In this way, software developers can ensure only code that passes all the unit tests makes it to a live environment. If any unit tests fail during the build process software developers can fix the issue first before attempting to release again.

Unit testing example

Below is a very trivial example of how unit testing could work in Javascript.

We have a simple sum function that receives two numbers as arguments and returns the result of adding the two numbers together.

function sum(a, b) {

return a + b;

}

module.exports = sum;

Our very simple first unit test of the sum function could be as follows.

const sum = require('./sum');

test('adds 1 + 2 to equal 3', () => {

expect(sum(1, 2)).toBe(3);

});

The above unit test documents its expectation ('adds 1 + 2 to equal 3'), then executes the sum function with test input arguments 1 and 2. We expect the result to equal 3 after the function execution.

If the result is not equal to 3 the test will fail and we will know our implementation of the sum function has a bug somewhere. ❌

If the result is equal to 3 our test will pass. ✅

We can then add more unit tests for the sum function with other example inputs to cover different cases, such as negative numbers or invalid input arguments to check if errors are handled correctly.

This is a very trivial example, however, it showcases in practice how unit tests work.

Unit testing benefits

Unit testing is a software testing method in which individual units, components, or modules of software are tested to determine if they are fit for use. As a result, it has many benefits. As a software system grows, software developers benefit more from having unit tests in place. If proper unit testing is done in early development, it will save software developers time and money in the end.

Unit testing finds problems early in the development cycle. This includes bugs in the software developer’s implementation. The cost of finding a bug before coding begins or when the code is first written is considerably lower than the cost of detecting, identifying, and correcting the bug later.

Unit testing helps software developers create better software designs. Code can be impossible or difficult to unit test if poorly written, thus unit testing can force software developers to structure functions and objects in better ways. The process of writing a thorough set of tests forces the software developer to think through inputs, outputs, and error conditions, and thus more crisply define the unit's desired behavior.

Due to the modular nature of the unit testing, software developers can test parts of a software system without waiting for others to be completed. This will help software developers create their software in small agile increments.

Unit testing allows software developers to easily refactor code or upgrade system libraries at a later date, and make sure the existing code still works correctly. Any changes software developers make that cause existing unit tests to fail can be identified quickly and addressed. Unit tests detect changes that may break existing working code.

Unit testing creates documentation of the system as a positive side-effect. Software developers looking to learn what functionality is provided by a unit, and how to use it, can look at the unit tests to gain a basic understanding of the unit's interface (API).

Unit testing limitations

Despite the valuable benefits of unit testing, it has some limitations.

Unit testing will not catch every error in the software system. It is very difficult to evaluate every execution path in a software system unless it is a very simple system. Unit testing is limited to only testing the functionality of the units themselves. It will not catch other errors such as integration errors or performance errors.

It can be difficult to set up unit tests if a core function of the unit at test is to interact with something external to the system. Something external such as a database, the file system, or an external API, can present a challenge when unit testing. Software developers will likely have to mock interactions with the external party and this may be challenging and not exhaustive enough as a test.

Final thoughts

Writing unit tests as part of the development of a system can often feel costly and slow. More code needs to be written and it takes time and effort to write good unit tests. A common mistake development teams make is to skip unit testing.

As most software systems grow they will benefit from a wide unit test coverage. Unit tests help make it easier to add new features, refactor existing features, and understand existing individual components of a system.

Adding unit tests early on will save software developers time and money in the end.

Are you writing unit tests in your codebase?

Test Driven Development (TDD) is a software development approach in which test cases are developed to specify and validate what the code will do. It is an established technique for sustainably delivering better software faster.

Test-Driven Development is based on a simple idea: write a failing test before you write production code itself. Test cases for each functionality are created and tested first and if the test fails then the new code is written in order to pass the test and make the code simple and bug-free. However, this deceptively simple idea takes skill and judgment to do well.

This article will help you understand the Test-Driven Development cycle and will also highlight the benefits of Test-Driven Development.

Test-Driven Development Cycle

When applying the Test-Driven Development approach you write a failing test, write the code to make it pass, then make the code better. That set of steps has led to the “red/green/refactor” mantra where red means fail and green means pass.

Test-driven development constantly repeats the steps of adding test cases that fail, passing them, and refactoring.

The red, green, refactor cycle, by Nat Pryce.

The following sequence forms the Test-Driven Development cycle:

1. Write a single unit test describing an aspect of the program

   Adding a new aspect to your program starts by writing a new test that will pass if the production code for that new aspect is implemented. This will help you focus on the requirements before writing the implementation code.

2. Run the test, which should fail because the program lacks that feature

   The new test you added should fail because the code has not yet been implemented. This shows that new code is actually needed for the desired feature. It rules out the possibility that your new test is flawed and will always pass.

3. Write just enough code, the simplest possible, to make the test pass

   Implement the new feature that you wrote a test for. At this point you should just write the bare minimal code that will make your test pass. Inelegant code is ok at this point as it will be cleaned up in a future step. Do not add any other code beyond the code that makes your new test pass. All your other tests should also now pass, if any existing tests fail it means the new code you added has broken some existing functionality. Fix any broken tests before proceeding.

4. Refactor the code until it is clean and simple

   Clean up your code by refactoring for readability and maintainability. Run your test suite after each refactor to help ensure that no existing functionality is broken. Some examples of refactoring include:

   • Moving code to where it most logically belongs

   • Removing duplicate code

   • Making names self-documenting

   • Splitting methods into smaller pieces

   Don’t skip the refactor step. Skipping the refactor step means you're not taking full advantage of what the TDD process has to offer. Having all your tests passing lets you change your code with confidence. Don't pass on this opportunity.

5. Repeat, accumulating unit tests over time

   Repeat the cycle above for each new piece of functionality you add to your codebase. Your tests should be small and incremental. That way, if new code fails some tests, you can easily revert rather than having to debug excessively.

Test-Driven Development Benefits

Test-Driven Development brings many benefits to your software development approach. It should encourage simple software designs and inspire your confidence.

Test-Driven Development allows you to focus on writing only the code necessary to pass tests. As a result your software design can often be cleaner and clearer than is achieved by other methods. By focusing on the test cases first, you must imagine how the functionality is used by clients (in the first case, the test cases). So, you are concerned with the interface before the implementation.

Test-Driven Development can lead to more modularized, flexible, and extensible code. This effect often comes about because the methodology requires that you think of the software in terms of small units that can be written and tested independently and integrated together later.

Test-Driven Development helps ensure that your application is written for testability, as you must consider how to test the application from the outset rather than adding tests later.

Test-Driven Development helps you develop good code test coverage as it ensures that tests for every feature get written. Large numbers of tests help to limit the number of defects in the code.

Writing tests first leads to a deeper and earlier understanding of the product requirements.

With Test-Driven Development, each test case fails initially: This ensures that the test really works and can catch an error. You will have good quality tests in your codebase.

The early and frequent nature of the testing helps to catch defects early in the development cycle, preventing them from becoming endemic and expensive problems. Eliminating defects early in the process usually avoids lengthy and tedious debugging later in the project.

Conclusion

One constant in the software world is change. As your product grows and scales there will be many changes you will need to make to your codebase. The easier your codebase is to change the easier your job will be. Test-Driven Development is a great approach to help you keep your software easy to change.

Are you practicing Test-Driven Development in you day-to-day work?

Test-Driven Development Resources:

1. Test-Driven Development by example - https://www.amazon.com/gp/product/0321146530/

2. Test Driven Development is the best thing that has happened to software design - https://www.thoughtworks.com/insights/blog/test-driven-development-best-thing-has-happened-software-design

3. The art and craft of test-driven development - https://increment.com/testing/the-art-and-craft-of-tdd/

Here is a list with some of the best podcasts new software developers can learn from.

CodeNewbie podcast

This is good choice for those who are interested in web development but don't know where to start. The CodeNewbie podcast covers stories and interviews from people on their coding journey. Every week, you can meet new developers and many other experts who work in the tech industry and have built their careers in coding. Each episode will provide newbies with many useful facts that will get them closer to the web development world.

Soft Skills Engineering podcast

Soft Skills Engineering is a weekly advice podcast for software developers. The show's hosts are experienced developers who answer your questions about topics like: pay raises, hiring developers, technical leadership, learning new technologies, quitting your job, getting promoted, code review etiquette and more.

Coding blocks podcast

Coding Blocks is the podcast and website for learning how to become a better software developer. They cover a wide variety of topics that range from good programming practices which are language agnostic all the way to specifics for particular languages.

Programming by stealth podcast

Programming By Stealth is a collaborative series created by Bart Busschots and Allison Sheridan. They discuss real programming in small easy steps, using the allure of the web as the carrot to entice people forward.

Frontend Happy Hour podcast

A podcast featuring a panel of Software Engineers from Netflix, Twitch, & Atlassian talking over drinks about all things Front End development. This podcast will tell you about new tools and libraries that appeared in the web development world. Frontend is a necessary skill for every web developer. It is impossible to create a good website without a proper understanding of frontend.

Cynical Developer podcast

This is a podcast that helps you to improve your development knowledge and career, through explaining the latest and greatest in development technology and providing you with what you need to succeed as a developer.

Complete Developer podcast

Will and BJ first met in college and have been friends ever since. You can tell this through their dynamic conversations. Will brings a wide knowledge base to the conversation through his years of experience as a senior developer and aspiring software architect. Whereas BJ being a journeyman developer is learning as he works in the field. He shares those lessons and more each week. Because of their varied experiences topics range from the technical to the every day life of a software developer. You'll find something useful and informative on Complete Developer Podcast. There are plenty of podcasts out there focused on languages and coding. What they are doing with the Complete Developer Podcast is to also cover the other areas of life as a developer.

freeCodeCamp podcast

The official podcast of the freeCodeCamp open source community. Learn to code with free online courses, programming projects, and interview preparation for developer jobs.

Learn to code with me podcast

Interviews and advice for learning how to code and building your technology career. The Learn to Code With Me podcast, created by Laurence Bradford, is for aspiring techies and self-taught coders looking to transition into the tech industry. Want actionable insights on how you can get paid for your coding skills? Then listen to this podcast.

Developing up podcast

A podcast focused on the non-technical side of being a developer, because your career is about more than the code you write.

Hanselminutes podcast

A weekly commute-time podcast that promotes fresh technology and fresh voices. Episodes feature talk and tech for developers, life-long learners, and technologists.

Final thoughts

Listening to good podcasts is one of the best ways to learn and grow as a software developer. It complements your day to day learning at work.

Have you listened to any of the podcasts on my list? What did you think?

If you could recommend one podcast for new software developers, what would it be and why? Let me know in the comments.

In this article, you will learn why it is important to understand your company’s product and how to get better at it.

To be a well-rounded software developer you must provide input into the product your company is building. You should have a good understanding of your company’s different business models. Understand how your company makes money. What parts are most profitable, what parts of the company are expanding the most? Who are the customers of your company’s product? Why do they buy it? How does your team fit into all of this?

Understanding all these product-related questions and more will help you make better decisions with your teams on how technology solutions can serve the product in the best way. It will help you to focus on customer needs and strive to develop the necessary technology by creating efficient solutions both in relation to the speed of execution and the cost.

Understanding the why is important before you can decide on the what and the how.

Below are some suggestions on how to become better at being a product-minded software developer.

Build a good relationship with your Product Manager

Your Product Manager is responsible for WHAT gets built by your team. Their role requires them to have a strong understanding of your company’s product. Building a good relationship with your Product Manager is important as they can help teach you about the company’s product and answer any questions you may have in the future about the product. Let your Product Manager know that you would like to grow your understanding of the company’s product, so they are aware that they can mentor you when opportunities present themselves.

Suggest product ideas when you have them

Product ideas should not only come from business stakeholders or your Product Manager. They can come from you. If you have an idea that can improve your company’s product you should share it with your team and Product Manager. Do some research to provide backing for your idea. It will also give you the confidence to share the idea if you have some data backing it. The main takeaway here is to not wait to be asked for ideas but proactively share any product improvement ideas that you have.

Always ask WHY when requirements are unclear

You should always ask for further explanation if you are asked to build something that you are unclear on its impact on the company product. Your goal should always be to understand WHY you are building something and how it is supposed to make the company’s product better. Avoid defaulting to writing code just because you are told to do so. Always start from a point of understanding the WHY.

Get involved in user research and customer support

As a software developer, it is important to understand your customers. Who are they and what are their needs? What frustrates them and what delights them about your product? One of the best ways to do this is to be involved in user research and customer support. Find out how you can be involved in these activities at your company and ask to allocate some of your work time there. It will help give you a better understanding of your company’s product and customers.

Being a product-minded software developer will help you become more well-rounded. You will have a better understanding of the work you do and the impact it makes on the company’s business. You will have a better understanding of why your company exists and the impact it makes in the world.

Start working on improving your product mindset today.

Most companies have performance review cycles, however, these may only happen a few times in a year, depending on the cadence. You should aim to receive feedback more frequently than the performance review cycles. Feedback that is more immediate to your day-to-day work and actions is much better.

Do you find asking for feedback uncomfortable? It may be stressful if you are not used to it, but constant feedback is an eye-opener, it is definitely worth asking for it from people you work closely with.

In this article, you learn about how to ask for feedback effectively. This involves, what to get feedback about, whom you should ask for feedback, how to ask for feedback, and how to respond to feedback.

What to get feedback about

It is important to understand the different things you want to get feedback about. These will help you with identifying whom to ask for feedback and what questions to ask. As a software developer here are some things you should be getting feedback about:

1. Your technical ability: the code you write and the tools you use.

2. How you communicate: written and verbal.

3. Your participation in meetings. 

4. How you present ideas and work. 

5. How you collaborate with your team.

Getting better in each of these areas will help you become a more accomplished software developer.

Whom you should ask for feedback

The best people to ask for feedback from are people you work closely with. They have enough context about your work to give you valuable feedback. As a software developer here are the suggested people to ask for feedback:

1. Your manager.

2. Other software developers on your team.

3. Non-software developers, you work with frequently. Such as your team’s Product Owner, Designer, or Scrum Master.

This group of people will be able to give you valuable feedback from different perspectives.

How to ask for feedback

After identifying whom you should ask for feedback, your next step is to approach them and ask if they would be happy to give you some feedback. Let them know why you have chosen them and that their feedback will be useful and contextual information to support your growth.

Give the person you choose to provide your feedback some notice so they can think of concrete things to say.

Prepare good questions before your feedback session with each person. Try to keep your questions less generic. Ask more narrow questions. Ask short questions that directly address specific aspects of your work or behaviour. As an example, instead of asking “What can I do to become a better software developer?”, you should instead ask “What is one thing I can do differently to improve my backend coding?” or “What is one thing I can do to improve my presentation skills for software demos?”. This will help people give you feedback that is actionable and aligns with your career goals.

It is helpful to ask for feedback in context and promptly, it can make it easier for the person you've asked for feedback to recall specific behaviours and examples that can facilitate your learning.

Feedback doesn't always have to be in person, you can use a digital platform to ask for feedback from several people at once and then follow up in person if needed.

How to respond to feedback

Positive feedback is awesome, you learn that you are doing well at something.

The feedback you receive from people will not always be positive. Some of it will be constructive criticism. It is important that you do not get defensive as you are asking for honesty from the people that give you feedback.

Once you have received feedback from people you should make an effort to apply the learnings from the feedback to get better. Making changes based on the feedback you receive will help others to see that you are not only open to criticism but willing to adapt, to become a better developer.

Always show your appreciation when others spend time sharing their perspective and providing constructive insights. This also encourages people to give you more feedback in the future.

Conclusion

Asking for feedback is a great way to help you grow professionally and personally. The feedback you receive will help you to take more control of your career development and to get an accurate idea of what is expected of you.

Proactively asking for feedback will help you learn faster. Avoid relying only on company performance review cycles to receive feedback. Start asking your team for feedback today!

Useful resources:

Feedback book - https://feedback.impraise.com/resources/ebook/how-to-give-effective-feedback/

When you start learning how to code your main focus is writing code that works correctly for the problem you are solving. Yes, code needs to work correctly and that is a good place to start learning. However, in a real work environment, you also want to ensure you write clean code.

Clean code is readable, extensible, changeable, and maintainable. These are all important qualities for code to have.

In many professional settings, you are not writing code in complete isolation. There are other people you work with on a team. Your teammates need to be able to easily understand the code you write. They need to understand what it does, how it works, and why it was written that way. It may also be your future self coming back to code you wrote in the past and you will also need to easily understand your code.

Code is read more than it is written. To write code we are constantly reading it. So even if readable code is harder to write we should invest time to do it instead of writing easy unreadable code. Writing clean code is an important skill for any professional developer.

Functions are the basic building blocks of any system. They are the verbs of a system, while classes are the nouns. We want to write our functions in such a way that they are easy to read, understand, maintain and refactor.

There are some recommended rules for writing good clean functions in code. Let us discuss these rules for the rest of this article.

Functions should be small

“The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.” — Robert C. Martin

“Coding like poetry should be short and concise.” ― Santosh Kalwar

One of the simplest ways of writing clean functions is to keep them small. Small functions are easy to understand and their intention is clear.

Functions that have hundreds of lines of code or more are usually complex and messy functions. There is no hard defined rule of how small functions should be. Generally if you can keep your functions to a maximum of 10 to 20 lines of code they are going to be easier to understand. Anything longer than that can likely be split into multiple functions.

Function arguments

Another way to ensure you are writing clean functions is to keep the number of arguments to your functions small. If a function has too many arguments it is either doing to many things or there is an encapsulation missing.

If the function is doing too many things you should split it into multiple functions that each receive the arguments they require.

If the function is doing one thing but requires many arguments then an encapsulation of a concept is missing. Extract the arguments into a class and pass in the object as the argument to the function.

There is no hard defined rule of how many function arguments are too many. Generally if you have 3 or more function arguments, check if your function can be cleaned up with the suggested solutions above.

Code blocks and indenting

The rule of keeping our functions small also implies that we keep the code blocks inside if, else and while statements minimal, preferably up to one line and that one line should be a function call. Extract the logic inside the code block into a function. Similarly, we should avoid nesting such structures inside functions by moving the nested logic into another function.

You can also keep your function code clean through indentation. Indent your code in a neat way that subscribes to your team’s agreed standards. Make it easy to read.

The stepdown rule

The author's stepdown rule is very helpful for writing easily readable code. According to this rule, you should write functions in such a way that function calls should be followed by their definitions in the code below. In this way, while reading a code file, when you see a function call you don't have to scroll up to find its definition because you will find its definition down below while reading through the code at a constant pace.

Do one thing

“Functions should do one thing. They should do it well. They should do it only”.

“DOTADIW: Do One Thing and Do It Well” — Unix philosophy

The functions you write should apply the Single Responsibility Principle. One function must do only one thing. If a function is doing more than one thing, the function should be split up into more functions.

Use descriptive names

“You know you are working on clean code when each routine turns out to be pretty much what you expected.” - Ward Cunningham

The name of a function should answer all the big questions. It should tell you; Why it exists? What does it do? How it is used? If a name requires a comment, then the name does not reveal the function’s intent.

A function‘s name should explain what exactly it is doing. Functions with names like do(), action(), for example, are not very useful, because we don’t know what their reach is.

A few examples of good descriptive function names: createNewLoanApplication(), getAllCustomers() and readFileToStream().

Remove duplicate code

DRY - Don’t Repeat Yourself

Make every attempt to prevent duplication of code. Duplication of the code is bad since it means that if you need to change a concept, there is more than one place to change things. If you forget to change other places it will easily result in bugs in your code.

There is a nice rule to maintain DRY - If this is the first time, code it. If this is the second time, copy it. If this is the third time, extract it to a function.

Avoid side effects

Side effects are mutations or actions that happen in our code environment that we cannot make an account of. There should be no hidden changes that a function name does not suggest.

An example is a readFile() function that reads the content of a file then deletes that file without notifying the user.

Side effects can lead to a lot of problems in our code and some bugs that are difficult to debug.

Remove dead code

Dead code is code that is unused or has no execution path that leads to it. It is usually never updated. It causes confusion to developers working in the codebase. They are unsure whether the code is used or not. Any time you find dead code in your codebase delete it. If you ever need it you can find it in your source control history.

Command query separation

A function should either ask something or do something, but not both. This creates confusion for your colleagues and your future self.

Either your function should change the state of an object, or it should return some information about that object. Doing both often leads to confusion.

Closing thoughts

The basic building blocks of any system are functions. When you write your code the functions should be clean and clear.

This article was about writing functions in such a way that they are easy to read, understand, maintain and refactor.

By following the above principles and practices your functions will be descriptive, clean and beautifully organised.

References/Resources:

Clean Code: A Handbook of Agile Software Craftsmanship by Robert C Martin.

Clean code is readable, extensible, changeable, and maintainable. These are all important qualities for code to have.

In many professional settings, you are not writing code in complete isolation. There are other people you work with on a team. Your teammates need to be able to easily understand the code you write. They need to understand what it does, how it works, and why it was written that way. It may also be your future self coming back to code you wrote in the past and you will also need to easily understand your code.

Code is read more than it is written. To write code we are constantly reading it. So even if readable code is harder to write we should invest time to do it instead of writing easy unreadable code. Writing clean code is an important skill for any professional developer.

In this article, we are going to learn about the importance of Naming in writing clean code.

Naming is a crucial and daily task for developers in any programming language. It can either make code very hard to understand or if done well, easy to understand.

Names are all over the software developers write. When coding, you should consider naming variables, functions, arguments, classes, packages, source files, and directories that contain those source files, etc.

Below are some popular quotes on naming in programming.

“There are only two hard things in Computer Science: cache invalidation and naming things.” - Phil Karlton

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand” — Martin fowler

Names are the smallest building block of code. Names are the basic building block of clean code. There are some recommended rules for good naming in code. Let us discuss these rules for the rest of this article.

Use intention revealing names

The names you use in your code must be clear and understandable. Choose descriptive and unambiguous names. You should focus on the principle of least surprise. Aim to write code that other people would expect and try not to surprise them with some clever complexities.

The name of a variable, function, or class, should answer all the big questions. It should tell you why it exists, what it does, and how it is used. If a name requires a comment, then the name is not intention revealing.

Below is an example of code that is not intention revealing that requires a description comment and a cleaner version with better naming that does not require a description comment.

let rf = 5000 //the rental fee paid by the tenant

use the cleaner version below

let rentalFee = 5000

Classes and objects should have noun or noun phrase names

Classes and objects describe things so their names in code should be a noun or noun phrase. Names such as User, Student, Account, and ErrorLogger are good names for classes and objects. Avoid words like Manager, Processor, Data, or Info in the name of a class. A class name should not be a verb.

Methods/Functions should have verb or verb phrase names

Methods/Functions perform an action in the code so their names should be a verb or verb phrase. Names such as deleteApplication, createUser, or save are good names for methods/functions. By design, a function should have only one responsibility. If the name is anything other than a verb, then either you are naming it wrong or there are some problems in the architecture.

Make meaningful distinctions

You should try to use the same word for the same purpose across the codebase. Avoid using different but similar words to define the same concepts. The three method/function calls below could mean the same thing as an example.

FetchResult() vs GetResult() vs RetrieveResult().

For instance, don’t use fetch, get and retrieve in the same project for the same responsibility.

Use pronounceable and searchable names

When naming things in your code use words that can be pronounced rather than using non-pronounceable words.

Below is an example of a variable name that is not easily pronounceable and a cleaner version with a more pronounceable name.

Date modymdhms;

use the cleaner version below

Date modificationTimestamp;

Replace magic numbers with named constants

When you are using some constant values define them using searchable words. It makes them more understandable to other developers.

Instead of writing code like this:

let totalLoanDays = gracePeriod + 7;

create a named constant and use it like this:

const NUMBER_OF_DAYS_IN_WEEK = 7;

let totalLoanDays = gracePeriod + NUMBER_OF_DAYS_IN_WEEK;

Don’t append type information

When you name your variables avoid appending type information to them. It should be clear from the name of the variable what data it stores and developers can infer the type from there. There is no need to mention the data type in the name.

Instead of writing code like this:

let firstNameString;

let lastNameString;

use the cleaner version below

let firstName;

let lastName;

Don’t Be Offensive / Don’t Be A Comedian

Remain professional in how you name things in your code. Do not be offensive or try to be a comedian by giving a variable a funny name. Remember you are writing production code that other future software developers will need to understand easily. Your naming conventions should be generic and should not include any cultural slang.

Avoid writing code like this:

function killThemAll();

use the cleaner and professional version below

function deleteAllUsers();

Closing thoughts

In this article, we have explored some of the best practices for naming things in your code, and some things you should avoid doing. Naming may appear a small part of a software developer’s job but it is very important and can be the main difference between having a clean codebase that is a joy to work with or a complex codebase that is difficult to understand and navigate.

"One difference between a smart programmer and a professional programmer is that the professional understands that clarity is king. Professionals use their powers for good and write code that others can understand."

You should never ignore the importance of naming practices in your codebase as bad names will become a big hurdle in future development plans. Changing the codebase at that point is unnecessary overhead and can be avoided in the very beginning by following good practices.

References/Resources:

Clean Code: A Handbook of Agile Software Craftsmanship by Robert C Martin.

As a software developer, a large amount of your learning will happen during your day-to-day job. You spend a majority of your time at work so it is not surprising that most of your learning happens there.

To grow your skills even further you can also try learning outside of work.

If you want to be a great software developer you have to be constantly learning. Having multiple approaches to learning about software development will help you up-skill from different perspectives.

In this article, I would like to share different approaches you can use to grow your software development skills outside of work.

Reading books

Reading good books will help you grow as a software engineer. A good book written by an experienced author can cover topics in great detail and help you understand them easily. A book can allow you to gain years worth of knowledge in a few days/weeks.

Books are super important to develop skills, learn about best practices, and acquire general knowledge.

Reading books alone will not make you a great developer. You must apply some of the lessons you learn from the books in the real world. You have to remember to put the things you learn into practice for your reading to be useful.

Reading is much easier to take up if you build a reading habit. Try to schedule some time each day that is dedicated to reading. You can start small by only committing to thirty minutes a day of reading and then increasing the reading time as you get more used to it.

There are a lot of books out there and it can be overwhelming to decide what to read. Limiting your scope when presented with many options always helps. Select one or two books that align with the most important thing you want to learn. Start there.

In this article, I shared a list of books every new software developer should read.

Enrolling in video courses

Online video courses are another way to learn and grow as a software engineer. They can be a great way to receive reliable and trustworthy lessons from experienced coders or university instructors.

You may prefer to learn through video instruction instead of reading books. Online video courses are a great alternative or complement to reading. Many online learners opt for video-based learning because it’s similar to the traditional lecture format used at university.

Video courses help you learn how to articulate coding ideas. This is useful learning for how you communicate with your teammates and for job interviews.

There are now many online video courses for software developers out there. They cover a wide range of topics in the software development space. Some of the platforms are paid-for and some are free.

Again it can be overwhelming to be presented with so many options of online video courses. Start by understanding what software development skills you want to learn and improve. Then search online for courses that cover that skill and select the best one you find.

Listening to podcasts

Podcasts are a great way to learn more about software development. Most of them typically have short episodes and can be listened to on the go. You can listen to podcasts while doing the dishes, on an airplane, driving, or commuting. 

Podcasts often provide a fresh perspective on new up-and-coming technologies or some great advice from an expert who is invited as a guest to the podcast. Podcasts offer a wealth of resources and support backed by industry experience, so you can always find something new to learn.

Podcasts do not require a lot of commitment and you can always drop off an episode or the whole podcast if you find it is not useful to you. Most podcasts are free too.

There are also now many podcasts for software developers out there. They cover a wide range of topics in the software development space. You can find a podcast on virtually any topic, the only question is whether it still produces fresh content or not.

Selecting a podcast that matches what you want to learn and is interesting becomes important. Start by understanding what software development skills you want to learn and improve. Then search online for podcasts that cover those skills and select the best one you find.

Attending conferences and meetups

I’ve been fortunate to attend many conferences and meetups in my developer career. I have always left them having gained some new useful knowledge.

Conferences and meetups are a great way to get out of our comfort zones, open ourselves up to new possibilities and stimulate our minds with new approaches and solutions that will help us with our software projects.

Conferences and meetups are great environments for learning, sharing, networking, and collaborating. They allow you to learn something new, about either a specific topic or just something new that you might not have heard about.

You get to learn from the best. Most of the time, speakers and attendees are people that have been working with technology for a while and have experienced the good and bad. Learning in this environment is very different because everyone is there to learn or share their knowledge, whereas at work you are mostly there to get the job done most of the time.

You don’t only learn from the speakers’ talks. People share a lot of useful information about a specific topic in the questions they ask after the talks. The conversations that happen after the talks can be vital to the problem you are trying to solve in your workplace and the ideas shared afterward can be more helpful than the content provided in the talks. The transfer of knowledge during these events can help with your career growth.

Identify local software development conferences and meetups that take place in your area and commit to attending any that interest you.

Subscribing to software development newsletters

There are now many software development newsletters out there. Most of them have curated content about different software development topics. They are usually pushed out on some regular cadence the creator sets.

Software development newsletters are very useful for keeping up with the latest trends in the software world. They are also a great cue for you to learn as each email that comes in your inbox is a reminder to read and learn.

Identify a topic you are interested in learning more about or keeping up to date with the latest trends. Search online for newsletters around that topic. Subscribe to a few of them and see how it goes as they start to come in. Over time you will know which are the best newsletters you prefer and you can unsubscribe from the ones that do not add value to you.

Contributing to open-source projects

Open-source refers to software with source code that can be accessed and modified by anyone. The intent is to make the applications freely sharable with and by the public.

Contributing to open-source projects can greatly improve your coding skills and make you a better developer.

Contributing to open-source projects allows you to solve different problems from day to day work. This broadens your mind as you work in different codebases and you see different coding approaches/solutions from other contributors in the open-source project.

When you contribute to open source you get in touch with other experienced people working on the project, giving you valuable insights and feedback, as well. Especially when you go through the code of projects with hundreds or even thousands of contributors, you can gain immense knowledge about best practices and code quality.

Plus, working on open-source software can improve other key skills aside from coding. It is an effective way to improve your communication and teamwork skills.

Find an open-source project you are passionate about. One of the advantages of open-source projects is you can start with beginner-level tasks and gradually progress to more complex ones. Start making contributions slowly to gain some confidence and understand the workflow in open source projects. Over time you will be able to make bigger contributions to the open source projects and learn more from them.

An added benefit of contributing to open source projects is that it helps you build your developer profile external to your company. Which is always useful for any future recruitment opportunities you may have.

Building side projects

A side project is something you do aside from your main job. They are projects you create for yourself to pursuit to learn something new or completely outside of your day-to-day activities or even comfort zone.

Having a side project outside of work can be one of the best ways to grow personally and professionally.

Side projects allow you to learn new patterns, programming languages, and concepts you otherwise would have ignored. The theory is just theory until you practice.

Since you will be spending your evenings and weekends working on this, it helps if it's related to a topic that you are passionate about. Start small. The easiest way to start is to pick a small project you will find interesting, or will solve a problem you have. Then break it down into smaller components until one of them looks easy to implement. Keep it simple at the beginning so you can remain motivated by the progress you will be making.

There are many benefits to having a side project:

• You learn how to come up with ideas and add customer value to a product.

• You learn how to focus. Side projects teach you to show up consistently.

• You learn more about taking self-directed action.

• Encourage creativity. Side projects enable you to work without constraints.

• Mastering different technologies to the ones you use at work daily.

• Solve different problems from day-to-day work.

• Benefit your career. You will have more chances of getting a job if you can show a variety of personal projects that are real, interesting, and meaningful, rather than a simple CV or résume.

All those benefits are encouraging reasons for you to spend some time trying side projects. Working on side projects in your spare time can be fun and helpful in developing your coding skills.

Remember to start small, be patient, and improve it while you learn. Your side project doesn’t have to be an enormous global success, but it can certainly help you learn and grow your software development skills.

Final thoughts

I’ve shared a collection of ways to grow your software development skills outside of work. You don’t have to take up all of them at once. You could start with a subset or just one.

At the end of the day, your personal needs and comfortability should dictate your learning tools. No platform can offer the perfect way to learn software development for everyone.

The important thing is that you are constantly on a learning journey and keep growing your skills.

Here is a list with some of the best books new software developers can learn from. I’ve selected books with long-lasting advice that will remain relevant many years from now.

The Tech Resume Inside Out: What a good developer resume looks like and how to write one

This book helps you craft a developer resume that represents you fairly, plays to your strengths, and increases your chances of getting hired. A practical guide written by the people who do the resume screening: engineering managers and technical recruiters working at tech companies. Free for developers out of a job.

Cracking the Coding Interview: 189 Programming Questions and Solutions

Cracking the Coding Interview gives you the interview preparation you need to get the top software developer jobs. This is a deeply technical book and focuses on the software engineering skills you need to do well your interview. The book is over 500 pages and includes 189 programming interview questions and answers, as well as other advice.

Things they don't teach you in software school: Letters from a mentor

This book contains the top things that any junior developer should know when starting their career in tech. It is a quick and easy read.

The author spent two years mentoring a young developer, who was just starting their career. After having countless conversations together, he decided to gather all of the advice he ever gave and published it in this eBook.

Letters to a New Developer: What I Wish I Had Known When Starting My Development Career

Learn what you need to succeed as a developer beyond the code. The lessons in this book will supercharge your career by sharing lessons and mistakes from real developers.

Wouldn't it be nice to learn from others' career mistakes? "Soft" skills are crucial to success, but are haphazardly picked up on the job or, worse, never learned. Understanding these competencies and how to improve them will make you a more effective team member and a more attractive hire.

This book will teach you the key skills you need, including how to ask questions, how and when to use common tools, and how to interact with other team members. Each will be presented in context and from multiple perspectives so you'll be able to integrate them and apply them to your own career quickly.

Soft Skills: The software developer's life manual

Soft Skills: The software developer's life manual is a unique guide, offering techniques and practices for a more satisfying life as a professional software developer. In it, developer and life coach John Sonmez addresses a wide range of important "soft" topics, from career and productivity to personal finance and investing, and even fitness and relationships, all from a developer-centric viewpoint.

For most software developers, coding is the fun part. The hard bits are dealing with clients, peers, and managers, staying productive, achieving financial security, keeping yourself in shape, and finding true love. This book is here to help.

14 Habits of Highly Productive Developers

You can learn the most popular frameworks, use the best programming languages, and work at the biggest tech companies, but if you cultivate bad habits, it will be hard for you to become a top developer.

This book doesn't offer a straight path or pre-defined formula of success. This book is a result of a quest. A quest to uncover what habits can be cultivated to become a better software engineer.

Extreme Programming Explained: Embrace Change

Software development projects can be fun, productive, and even daring. Yet they can consistently deliver value to a business and remain under control.

Extreme Programming (XP) was conceived and developed to address the specific needs of software development conducted by small teams in the face of vague and changing requirements. This new lightweight methodology challenges many conventional tenets, including the long-held assumption that the cost of changing a piece of software necessarily rises dramatically over the course of time. XP recognizes that projects have to work to achieve this reduction in cost and exploit the savings once they have been earned.

Clean Code: A Handbook of Agile Software Craftsmanship

Even bad code can function. But if code isn't clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn't have to be that way.

In Clean Code the author has teamed up with his colleagues to distill their best agile practice of cleaning code on the fly into a book that will instil within you the values of a software craftsman and make you a better programmer but only if you work at it.

The Pragmatic Programmer: From Journeyman to Master

The Pragmatic Programmer cuts through the increasing specialisation and technicalities of modern software development to examine the core process - taking a requirement and producing working, maintainable code that delights its users. It covers topics ranging from personal responsibility and career development to architectural techniques for keeping your code flexible and easy to adapt and reuse.

Refactoring: Improving the Design of Existing Code

Refactoring is a controlled technique for improving the design of an existing code base. Its essence is applying a series of small behavior-preserving transformations, each of which "too small to be worth doing". However the cumulative effect of each of these transformations is quite significant. By doing them in small steps you reduce the risk of introducing errors. You also avoid having the system broken while you are carrying out the restructuring - which allows you to gradually refactor a system over an extended period of time.

This book describes the process of refactoring and spends most of its time explaining how to do the various refactorings - the behavior preserving transformations.

The Nature of Software Development: Keep It Simple, Make It Valuable, Build It Piece by Piece

This book leads you from the desire for value down to the specific activities that help good Agile projects deliver better software sooner, and at a lower cost. Using simple sketches and a few words, the author invites you to follow his path of learning and understanding from a half century of software development and from his engagement with Agile methods from their very beginning.

The book describes software development, starting from our natural desire to get something of value. Each topic is described with a picture and a few paragraphs. You're invited to think about each topic; to take it in. You'll think about how each step into the process leads to the next. You'll begin to see why Agile methods ask for what they do, and you'll learn why a shallow implementation of Agile can lead to only limited improvement.

Final thoughts

Reading good books is one of the best ways to learn and grow as a software developer. It complements your day to day learning at work.

Have you read any of the books on my list? What did you think?

If you could recommend one book for new software developers, what would it be and why? Let me know in the comments.

Pair programming with more experienced developers will help you get past these challenges.

Pair programming is your answer to learning the codebase faster, being connected and engaged and, having fun in the process.

What is pair programming?

Pair programming essentially means that two people write code together on one machine. One person is the driver and they write code. The other person is the observer and they review each line of code as it is typed in.

The two programmers switch between the driver and observer roles frequently as they pair program.

Pair programming is a very collaborative way of working and involves a lot of communication. While a pair of developers work on a task together, they do not only write code, they also plan and discuss their work. They clarify ideas on the way, discuss approaches and come to better solutions.

Why should I pair program with experienced developers?

Many benefits come from pair programming with more experienced developers.

When you pair program you get to observe the more experienced developer and learn a lot of things as you go. You can pick up how the experienced developer uses keyboard shortcuts or tools that you are not aware of. You can learn tips on programming language rules or overall design skills. It is an opportunity to learn their routine and how they use the same tools you use but in a more productive way.

The more experienced developer is likely to know about topics and techniques you do not know about. This eliminates delays in building solutions and builds up your knowledge of those topics than when compared to you working alone.

Pair programming allows you to receive more immediate feedback on your work from an experienced developer. You do not have to wait until another developer does a code review on your work at a later time. The feedback is immediate and you can learn and correct any issues in real-time which helps reinforce your learning. Receiving immediate feedback is also less frustrating than finding out much later that you need to re-do some work.

Pair programming allows you to examine a more experienced developer’s code and provide feedback, which is necessary to increase your ability to develop monitoring mechanisms for your learning activities. Pair programming helps you get better at learning.

Pair programming helps you practice the team skills that are central to good software development. You learn about the importance of good communication and collaboration. You learn about collective code ownership with your team. You learn about knowledge sharing between developers on a team. These are all important team skills to master along with your technical development.

Pair programming helps you remain focused on completing your work tasks. When you are working with another developer it is more difficult to get distracted and procrastinate with other unimportant tasks. The more experienced developer becomes your accountability buddy on the task you are working on.

How to pair program

The first thing you should do is identify experienced developers on your team and make them aware that you would like to pair program with them when they are available.

Most experienced developers will be willing to help you in your learning journey. Be patient with them as they can be busy with other work.

Once you have found an experienced developer to pair program with, you must identify the task you are going to be working on together. Before you start writing any code you should both understand the problem, come up with a draft solution and plan your approach. Write any steps to your solution down, they will be useful as you are coding the solution.

Once you start coding the task, you should take up one of the pair programming roles described earlier: driver or observer.

The driver is the person at the wheel, i.e. the keyboard. In this role, you will be focused on completing the tiny goal at hand, ignoring larger issues for the moment. You should always talk through what you are doing while doing it.

The observer is in the watching position, while the driver is typing. In this role, you will review the code on-the-go, give directions and share thoughts. You should also have an eye on the larger issues, bugs, and make notes of potential next steps or obstacles.

Rotate between the driver and observer roles with your pair programming partner. The suggested rotation formats are as follows:

• Ping Pong Pairing

• Pomodoro Pairing

Ping Pong Pairing - Software Developer A writes a failing automated test, Software Developer B writes the implementation to make it pass. Then they rotate and Software Developer B writes the failing automated test, Software Developer A writes the implementation to make it pass. And the cycle goes on, it is great for Test Driven Development (TDD).

Pomodoro Pairing - The driver is on the keyboard, writes the code focused on the tiny goal at hand while the observer reviews code on-the-go and keeps an eye on the bigger picture. The driver and observer switch roles in a defined amount of time like every 30 minutes.

The best way to learn is by doing. In the case of coding, that means typing and moving the mouse. So if you had to lean more into a pairing role as the less experienced software developer you should take up the driver role more often. Yes, it may be slow and frustrating sometimes but it will be beneficial for your learning.

Ask a lot of questions to the experienced developer during your pair programming sessions. Don't shy away from pair programming on tasks when you have no idea about the technology involved or the problem. If you keep working in the area that you feel most comfortable in, you will miss out on learning new things and ultimately spreading knowledge in your team.

How often to pair program

There isn’t one official answer to how often you should pair program.

Some companies pair program all the time - every line of production code written must be written by a pair. Other companies never pair program.

You will know what the culture is at your company and you can use that as a baseline of where to start. My advice is that given how beneficial pair programming is in your learning, you will want to do it as often as you can. So lean on the side of pair programming more often than not.

Things to watch out for

Paring forces you to be focused for longer periods, find common ground, and share a good wavelength with the other software developer. This is intense and gets you tired quickly. Exhaustion is one of the main challenges you will face as you pair program. Ensure you take frequent breaks with your pairing partner so you can keep your energy for a longer period.

Another thing to remember is to be considerate about your pairing partner’s personal space during your pair programming sessions. You will be working very closely together for possibly a long time so it is always important to be a great pairing partner.

Final thoughts

A note on remote pairing - Are you part of a distributed team, or some team members occasionally work from home? You can still practice pair programming, as long as both of you have reasonably stable internet access. Use video calling tool or shared IDEs. Being remote should not stop you from pair programming.

The best way to learn more about the benefits of pair programming is to see it in practice. So start today, identify an experienced developer on your team and ask them to pair program.

Pair programming with experienced developers will help you get up to speed more quickly than most other methods I have seen. It also helps to keep you connected and engaged.

When I started my first job, one of the senior developers at the company I worked for, offered to help me learn and grow into a good software developer. He was a more experienced guide who had overcome the same problems I was facing and provided an inspiring example to follow.

If I needed any useful tips on coding I went to him. If I needed any advice on navigating a career in the technology industry I went to him.

That senior engineer became my mentor and without him, my software development career would have been difficult at the start.

Most people have to find a mentor themselves. Most people, however, don't know how to find a mentor. What should you do? Where should you start?

What is mentorship?

Before we talk about how to find a mentor let us understand what mentorship is and what role it plays in your career.

Mentoring is relationship-oriented and occurs when a person who has years of experience in a field provides guidance on career progression to an individual with less experience.

The needs of the mentee are important in this relationship, and the mentor helps wherever possible in this development-driven relationship.

It is a long-term relationship as opposed to on-the-spot advice.

There are many benefits of having a mentor: boosting your confidence, helping you get control of your career, and teaching you important life lessons.

Before searching for a mentor

It is helpful to ask yourself what you want from a mentor before starting your search. Identify clearly what you think are the reasons you need a mentor. Write these reasons down as a list. This list will be useful in your early conversations with potential mentors.

Setting short term and long term career goals for yourself will also be useful. It will help give your mentor an idea of the direction you want your career to go. As an example here is what my list looked like in the early days of my career:

• Short term - Learn how to write clean code.

• Short term - Learn how to write good automated tests.

• Short term - Take good ownership of solutions from my machine to production.

• Short term - Develop a deeper understanding of the programming languages and frameworks our company uses.

• Long term - Able to input and drive architectural decisions.

• Long term - Learn about technology leadership.

• Long term - Build a profile external to the company (start a blog, speak at conferences)

Don’t leave things open-ended. As you will learn later in this article you will be responsible for driving the relationship between you and your mentor. They are there as a guide to support you and your career.

Where to find mentors?

When you start your search for a mentor look for someone who has been where you want to go. Identify people who are good at teaching and are always keen to share knowledge.

The first place to look for a mentor is within the circle of people you already know. It's much easier to find a mentor among people you already know than from among total strangers.

These are the places that I would recommend you try and identify your potential mentor:

1. Your current company.

2. Meetup communities, conferences, and coding workshops.

3. Open-source community.

4. Contacts of friends.

5. Online mentorship platforms.

Your current company

Your current workplace is usually the most ideal place to look for a mentor. There are likely to be some experienced software developers working there. They already know you, have visibility into your work and will be easier to access when you need help. I highly recommend looking for a mentor within your current company if the situation allows.

Meetup communities, conferences, and coding workshops

Meetup communities, conferences, and coding workshops usually have people who are keen to share their knowledge. Especially people who are speakers at the events or facilitators of the workshops. You should identify groups that align with your goals, join them, attend the sessions frequently and establish good relationships with the members. Eventually, you will be able to identify potential mentors who you could approach.

Open-source community

Getting involved in an open-source project can help in the search for a mentor. Identify an open-source project that you are passionate about and start making contributions to move the project forward. Your contributions to an open-source project do not have to be complicated coding solutions. Most people start at the basics - perhaps contributing to the documentation of the project. Once you are part of the open-source project you will start interacting with other contributors of the project or the project maintainers. Eventually, you will be able to identify potential mentors who you could approach amongst this group.

Contacts of friends

If you cannot identify anyone who could be your potential mentor, your next best approach is to ask your friends if they know any software developer who would be a good mentor for you. Your friends are likely to have contacts that work at their companies that they can connect you with. It may be someone you don’t know but your friends can help with the introductions.

Online mentorship platforms

There are now some online mentorship platforms that exist. This is also another way in which you can find a mentor. Some of these platforms are paid platforms and some of them are free. Examples such as CodeMentor, Coding Coach, and MentorCruise exist. A quick online search for “software developer mentorship” will give you many of these platforms and you can choose the one that suits you.

Asking someone to be your mentor

Once you have identified your potential mentor you must ask them to set up a formal mentor/mentee relationship. It is important to first build a relationship with the potential mentor. It will become easier to ask that way. Take it slow, some trust-building may be required before you start. 

To build a relationship with your potential mentor offer to take them out to coffee or find a time to get on a call with them. Make it as easy as possible for them to connect with you. Build rapport. Find something you have in common.

Once you’ve built up a relationship with your potential mentor you should ask them formally to become your mentor. When you ask you can say something along these lines - “You're someone I look up to. I’m new in this software development journey. I’ve enjoyed the discussions we’ve had in the past and felt your opinions are always really insightful. I would highly appreciate it if you could help me in my software development journey. Can I set up some time to talk about areas I'd like to grow in and how you could potentially help, as a mentor?”

If the response from the potential mentor is positive and they are happy to chat then you can try it out with one or two meetings and see if both of you would want to continue.

If the response from the potential mentor is negative and they are unavailable don’t give up. You might not succeed on the first try and that is completely understandable, people are busy. Just keep going. Repeat the process and find another potential mentor.

I have a mentor now. What next?

Once you have a mentor you must interact with them on a regular cadence. You can discuss and agree on the time commitment with your mentor. As the mentee, you will have to own and drive the scheduling and meetings.

Set defined goals to work on with your mentor. These are great motivators for constant improvements. Do the work, follow up, commit to it. Give feedback on the advice you receive from your mentor.

Always come to your mentorship meetings with questions. Part of being a mentee is being energetic and clear about what you are seeking to understand.

Once someone agrees to be your mentor here are some things they can do for you:

1. Set time aside to respond when you have questions.

2. Do some code reviews of your code.

3. Pair program with you. 

4. Send you resources (books, courses, podcasts) that align with your goals. A mentor can be an incredible resource when it comes to finding the best courses, books, sites, and projects. Instead of having to figure everything out from scratch, you’re getting a competitive advantage by getting the landscape of resources laid out for you.

5. Be an accountability buddy for your goals. 

6. Help you plan your career.

7. Going deeper in the discussion of technologies, languages and frameworks, basic concepts, and so on

8. Help you stay focussed in the complex world of software.

Be cognisant of your mentor’s time and be as prepared as you can for your meetings. Always be on time for your scheduled meetings with your mentor, offer to pay for coffee if you can, and do anything else you can to say you appreciate their time.

Over time you will want to review if the mentorship relationship is still working. To constantly check if it is still providing value for both of you.

Final thoughts

I've been mentored, been a mentor, and have observed software developers around me grow through mentorship. Having a more formal mentoring relationship can help you grow faster and in a more focused way.

Whether you're just out of university, just graduated from a coding bootcamp, or self-taught, you'll need all the help you can get to become the best developer you can be.

Many people want to help and share their knowledge. All you need to do is ask.

I still remember the confidence I had when I completed my Computer Science degree. Having done well in my studies I thought I knew it all and I was ready to succeed in the software world.

That confidence all dropped in the first few weeks of my first job as a software developer. I realised there was so much about building software in the real world that I did not know about. It was a wake up call and a realisation that I was starting a whole new learning journey again.

University had given me a foundation but there was so much more to learn about the software world.

I was fortunate enough to have good mentors around me who patiently taught me a lot about building software in the real world as a team. Over the last ten years of my career I’ve often thought it would useful if software developers were better prepared for the real world. It is from that thinking that this newsletter has been developed.

The New Developer helps new software developers navigate the often challenging and complex journey of building a career in technology. The goal is to help new software developers prepare themselves for the real world - working in a real team at a real company.

The first “real” issue will drop in a couple of days. Stay tuned and for now you can forward this to your friends so they can sign up!!

Subscribe now