DEV Community: Tori "Code Mom" Brenneison

The Hidden Heroes of Software Development: Software Testing & Quality Assurance

Tori "Code Mom" Brenneison — Tue, 05 Mar 2024 18:34:34 +0000

Considering a career in software, but unsure of which path to take? When folks think about working in tech, they often think of software developers–a career path which has skyrocketed in popularity thanks to the star power of big tech companies (Google and Microsoft, anyone?), TV shows such as Silicon Valley and Halt and Catch Fire, and celebrity CEOs like Elon Musk and Jeff Bezos. In reality, though, programming’s starring role in popular imagination is actually only one part of the software development lifecycle. Another big part of that lifecycle is the role of quality assurance and software testing. In this article, we’ll explore what a QA/testing position looks like, the significance of the role, and what skills are required to do it successfully.

What is software quality assurance?

Just like a traditional quality assurance role involves checking products for correctness before they’re released to customers, software quality assurance analysts ensure that appliances meet a company’s standards for reliability and performance before being released to users. A software tester dives into an application and identifies defects (or, “bugs”), and works with software developers to fix those bugs and make sure the software provides a good experience for the user.

The importance of software testing and quality assurance cannot be overstated. Although programming may enjoy the limelight, users expect software to function flawlessly–and software developers are pretty susceptible to introducing bugs in the code. Companies rely on skilled QA professionals to catch those bugs and help them deliver software products that meet users’ expectations.

What careers are there in software testing?

Software testing offers a myriad of opportunities for quality assurance professionals: manual testing, automated testing, security testing, usability testing… there’s a wide range of roles that fall under the domain of quality assurance. With the adoption of Agile software development practices and DevOps, QA professionals are usually integrated in cross-functional teams where they collaborate with developers, product owners, Scrum Leaders and other team members through the software development lifecycle. This close collaboration gives quality assurance workers many opportunities to broaden their skill sets and learn about other roles in software development as well.

Entry-level roles, usually denoted as “QA Tester”, “Software Tester”, or “Quality Assurance Analyst”, are a great starting point for a career in the software industry. These jobs provide hands-on experience with software from an insider perspective, and allow candidates to quickly learn testing methodologies and tools. Some testers only do manual testing, some only do automated testing, and there are plenty of QA folks who do both! From entry-level, it’s only a matter of time and experience before gaining eligibility for senior QA roles, such as “QA Engineer", “Lead Tester”, or “Quality Assurance Manager” (if you enjoy managing people as much as you enjoy managing software!).

Manual Testing

Manual testing refers to the process of interacting directly with an application in the same way an end user would, exploring various parts of the application’s functionality to find defects, inconsistencies, and usability issues. Before testing commences, a QA worker creates a “test case” or “test plan” based on requirements for use of the application. A test case outlines the steps to be performed during testing, including expected inputs and outputs, as well as any other verification that needs to happen during the test. The tester then executes the test case by using the software just like a user would, following the steps outlined in the test plan. When a defect is found, the tester documents it, including a detailed description of the problem, the steps to recreate it, and any screenshots or supporting information a developer might need to fix the code.

Automated Testing

Automated testing is done using tools and scripts to execute test cases and compare actual outcomes with expected outcomes. Unlike manual testing, which relies on a human interacting with the software, automated testing is software testing other software. Scripts, testing frameworks, and specialized tools automate the testing process to make testing faster and more efficient while being less prone to human error. In automated testing, a tester writes code that, when executed, calls the functionality of the software being tested and evaluates whether the results of running that functionality are correct. QA professionals who work in automated testing may be referred to as “Test Engineers” or “QA Developers” to denote a difference in their role from professionals who do manual testing.

What skills do I need to work in software testing?

To work in software quality assurance, you’ll need a diverse skill set that includes both “hard” (technical) and “soft” (people) skills. Successful QA professionals will need to be proficient in computer usage, including typing, interacting with the file system, and installing and running applications. An ability to analyze computer systems and processes, identify potential defects and issues, and come up with effective test cases is a vital skill for QA workers, as this allows them to ensure they are doing comprehensive testing.

Testers also need to be creative problem-solvers, effective communicators, and have a knack for paying attention to detail, which allows them to carefully inspect software applications and detect even the smallest problems and discrepancies. There’s a great amount of creative thinking involved in finding bugs, troubleshooting issues, and proposing solutions that enhance software product quality. Effective communication is also a key skill, as testers need to articulate issues with the software clearly to collaborate with developers and to convey technical information in a way that is understandable to both technical and non-technical team members.

Conclusion

A career in software testing can be a rewarding option for those interested in working in the tech industry. Professional testers and quality assurance analysts are a vital part of the software development lifecycle and an important asset on development teams. For those seeking to make an impact in the world of software without necessarily having to write code, working in QA is often an exciting option that can lead to a wealth of opportunities for growth and advancement. If you’re an analytical thinker with a great attention to detail who enjoys working as part of a team, quality assurance might be the career you’re looking for. Happy testing!

This article was originally published at CodeMom.net!

Ace Your Virtual Interview: Best Practices for Remote Conversations

Tori "Code Mom" Brenneison — Thu, 22 Feb 2024 18:55:51 +0000

Virtual interviews have become increasingly popular in the wake of the Covid-19 pandemic, especially with the rise in remote and work-from-home jobs. Remote interviews are especially popular for HR screenings and behavioral interviews, making it essential for modern job seekers to adapt their interview skills to the virtual landscape. Here are some tips and strategies to help you ace a virtual interview:

Prepare Your Technical Setup

Before the interview, make sure that you have a stable internet connection and that the computer or phone you’ll be using for the interview can run the video conferencing software being used for the interview. Popular software for remote interviews include Zoom, Skype, and Microsoft Teams. Check that your webcam angle, lighting, and background give a professional impression and that your video does not appear too dark or too light.

When setting up the interview, arrange with your interviewer or HR contact to have a backup plan in case of any technical difficulties, such as having a contact number to call in order to continue the interview via phone if necessary.

Dress Professionally

Even though you may be interviewing from the comfort of your home, and will only appear on the video feed from the shoulders up, you should dress as you would for an in-person interview. Dressing professionally will help you feel more confident and prepared during the interview.

Pay attention to your clothing choices from head to toe, and resist the urge to wear sweatpants with a dress shirt! You never know when you may need to stand up or move during the interview, and if you’re not prepared to stand up suddenly, it will definitely happen.

Choose a Suitable Location

Select a private, quiet, and well-lit area for your virtual interview, where you won't be disturbed by pets, roommates, or family members. Let your roommates and family know that you’ll be interviewing remotely, and ask them not to disturb you during the interview time. Avoid any loud background noises that can be picked up by your computer’s microphone, such as cleaning appliances, landscaping equipment, barking dogs and TVs. If you can't find a suitable location, try a professional-looking virtual background or a blurring filter.

Practice Non-Verbal Communication

Non-verbal cues play a big role in virtual interviews. It is important to make good “eye contact” with your interviewer by looking directly at the camera, rather than at the interviewer's video feed. Sit up straight, maintain good posture, and use natural hand gestures, making sure that your hands appear on camera. Be sure to smile and nod to express engagement and interest in the conversation during the interview, but don’t force or exaggerate your facial expressions just because the interview is being conducted virtually.

Avoid fidgeting or looking away from the camera, as it may come across as disinterest or lack of confidence. If you are prone to moving around in your chair, make sure that you do not have a spinning office chair or chair that rocks–you may not even notice how much you are moving, and the movement can be very distracting for your interviewer.

Minimize Distractions

Turn off or shut down all other applications, notifications, and sounds on your computer or phone before the interview. Close all irrelevant tabs and programs, and avoid multitasking during the conversation. You need to give the interviewer your undivided attention in order to show respect for their time and effort in conducting the interview.

Remove anything that may distract you from your field of vision so that you can focus on the interview, including your mobile phone, pets, paperwork, and hobby items–anything that could remove your focus from the interviewer.

Prepare Relevant Materials

Keep any materials you may need during the interview–such as your resume, cover letter, reference material and paper to take notes–easily accessible, but out of view of the camera. Put the files for your resume and cover letter on your computer desktop or another easily accessible location, in case your interview asks for you to send them via email or through the conferencing platform during the interview.

Although it is tempting to refer to any notes you have for STAR responses and technical interview questions during the interview, be aware of any time you are looking away from the camera. If the interview suspects that you are reading directly from notes or prepared answers, they will be less likely to move you forward in the hiring process. If you look away from the camera to take notes, let your interviewer know that is what you are doing.

In Conclusion...

A virtual interview can be a nerve-wracking experience, but with proper preparation, you can ace it! Remember to test your equipment, dress professionally, choose a quiet and private space, be mindful of your body language, and have a backup plan in case the conferencing software fails. With these tips, you can ensure that you are well-prepared, professional, and engaging during your remote interview. Good luck!

This article was originally published at CodeMom.net, and is preliminary material from a book tentatively titled “HIRE ME: A Workbook for Getting to Work”, by Tori Brenneison.

Debugging Stress: A Tech Worker's Guide to Protecting Mental Health

Tori "Code Mom" Brenneison — Wed, 14 Feb 2024 21:06:59 +0000

We’ve all been there: tired, overwhelmed, feeling like the walls are closing in. In the tech industry, it’s not uncommon to find yourself working under pressure that can significantly up your stress levels. Even if your job is usually stress-free, sometimes things don’t go as planned, and you can quickly find yourself facing extended work hours and tight deadlines. Effective stress management is essential to maintaining your mental health and keeping yourself productive when the going gets tough–so, in this article, we’ll explore some stress-relief strategies for those working in the tech industry.

Recognize Stress Triggers

The first step in managing stress is to understand what’s causing it. You may be feeling overwhelmed because of rapidly-approaching deadlines, complex problems that seem unsolvable, or a need to quickly understand a new technology or programming language in order to get the job done. Identifying the root cause of stress will often help you come up with appropriate ways to handle that stress.

Once you’ve identified the source, you can take steps to mitigate it: break down complex work into smaller, more manageable tasks, prioritize the tasks that have to get done first, and set realistic deadlines for work (realistic being the key word). Software developers often strive for perfection, so it’s very important that you are setting realistic expectations for how much work you can accomplish in a given time period.

If you’re feeling like you don’t have control over prioritizing work and setting deadlines, speak to your senior developer, team lead, manager, etc about how you’re feeling. Open communication is a key part of healthy work environments, and letting your leadership know that you (and perhaps other team members, as well!) are struggling to keep up will give them some insight into what’s going on and allow them to find ways to help, such as pushing back deadlines, delegating tasks in a different way, or hiring temporary employees to distribute work more efficiently.

Use a schedule app or paper calendar to plan out manageable units of work to do each day
Create to-do lists based on project tasks
Talk to your manager or a more senior employee about managing stress at work
Ask for help from peers or senior employees when working on complex tasks
Beware of imposter syndrome

Make Time to Take Breaks

It may seem counterintuitive to take breaks when there’s a lot of work to be done, but don’t fall into the trap of overworking and stressing yourself out even more. The average adult human sustained attention span is not very long, so if you find yourself struggling to stay on-task or tying yourself in mental knots trying more and more convoluted solutions, you need to take a break. Continuing to focus on a problem for far longer than you should will only lead to more stress.

Light exercise, like stretching, calisthenics, or a short walk, can be a good way to mentally and physically reset. As we all learned from Elle Woods in Legally Blonde, exercise gives you endorphins, and endorphins make you happy. In addition to getting your circulation going and relieving physical discomfort from sitting at the computer for too long, taking a break to exercise can actually help you regain focus and improve your ability to concentrate.

Go for a short walk (even a walk around your office building counts)
Look away from your computer to relieve eye strain
Take a short catnap if you’re feeling very tired (set an alarm so that you don’t oversleep!)
Leave your desk to get a drink and/or snack before moving on to a new task

Practice Self-Care & Maintain Work-Life Balance

When you’re stressed, it can be tempting to skip meals and replace sleep with energy drinks… but that’s not a good idea. It’s very important to take care of yourself when you’re under stress: eat full meals at normal meal times, drink water to stay hydrated, and don’t stay sitting at your workstation for too long. Do your best to avoid crutches like convenience food, alcohol, and recreational drugs, especially if you find yourself coming to rely on them for a “quick fix”--they will absolutely not benefit you in the long run. You can also try adding meditation to your daily routine: techniques such as intentional breathing, guided visualization, and mindfulness meditation can help you stay in the moment, reduce anxiety, and develop a positive mindset.

It is also crucial to maintain some separation between your work and your personal life. Establishing a clear boundary between work time and personal time puts you back in control of your own schedule and will help you to relax and not focus on work in your “off hours”. If you work at home, leave your laptop in another room or put it away out of sight when you’re not working, and silence any work-related apps installed on your mobile phone.

Do your best to eat foods with decent nutritional value, and not just convenience food that is quick and easy to eat
Watch out for reliance on junk food, alcohol, caffeine, and recreational drugs–it can sneak up on your when you’re feeling stressed
Go to bed at the same time each night, and set an alarm to wake up at the same time each morning
Add meditation to your daily routine to reduce anxiety–you can use an app or free online videos to learn how

Conclusion

It can be tough to keep up with the demands of a fast-paced work environment, which means that stress management is an important skill to have! Tight deadlines and complex problems can easily lead to elevated stress levels, even in the chillest of workplaces. Being able to break large tasks down into manageable steps, setting realistic expectations for work, and having open communication within a team can help us gain a sense of control over our work environment. Taking care of ourselves and maintaining a separation between work and personal life also helps tech workers to stay resilient and prevent burnout and poor mental health. When it comes to working in tech, stress-relief strategies are a necessary and proactive approach to being successful–so, do your best to stay calm, carry on, and… happy coding!

This article was originally published at CodeMom.net!

How Do I Give Great Code Review Feedback?

Tori "Code Mom" Brenneison — Wed, 14 Feb 2024 21:01:13 +0000

You got the job, went to work, and now you’re being asked to review someone else’s code! For the first time, code that someone else wrote depends on your thumbs-up to be pushed into production. It’s nerve-wracking, to be sure. You want to make sure the code is good–but it was written by someone with more experience than you, so how could you ever possibly critique it?! How do you give great code review feedback?

...or...

You got the job, went to work, and now you’re opening your very first pull request. For the first time, code that you wrote will be pushed into production–but first, it’s got to get the thumbs-up from other developers on your team, including your boss. It’s nerve-wracking, to be sure. You want to make sure your code is good before putting it out there–but you’re not exactly sure what “good” looks like. How do you put your best food forward?

There are a few things to keep in mind when reviewing someone’s code, or even when reviewing your own code. The things on this checklist are common things to look for when reviewing code, and answering these questions may be helpful to you when you’re asked to leave feedback on pull requests.

Comments should be helpful, specific, and actionable

It is important to remember that you are not your code. If someone leaves you a nasty comment on a pull request, it’s not a comment about you as a person or about your programming ability; the commenter may only be having a bad day or they might be a poor communicator. Take a deep breath, fight the urge to be nasty right back, and ask for clarification on the issue with your code, as politely as you can manage. Similarly, you should do your best not to leave nasty comments on others’ pull requests. Always try to find at least one positive to say about the code you’re reviewing, even if you have plenty of critical feedback to provide.

Comments should always be about the code, not the developer, and any feedback given should be helpful, specific, and actionable. “Fix this” is not a helpful comment; instead, point out exactly what the issue is and try to suggest another way to approach the problem. If your comment is nitpicky, you can still offer advice, but others will appreciate it if you acknowledge when you’re simply having a difference of opinion–and don’t push for a change to the code based solely on your personal preferences for how something should be written.

What to do if something is hard to understand

If something in the code review is hard to understand, say so! If you can’t understand a piece of code at all, the code review is your opportunity to ask how something works (or how it is supposed to work). Remember, the purpose of a pull request is to catch any issues before it is integrated into the rest of the codebase. As a new developer, your fresh pair of eyes and willingness to ask questions is a valuable asset to the team when it comes to reviewing code!

Questions to help you come up with great code review feedback:

Readability

Are there a lot of comments in the code that could be removed, or are there unnecessary comments left in the code?
Are names descriptive and accurate? (This includes variable and property names, class names, method/function names, and file names.)
Is a consistent coding style used throughout the code? Does it match the accepted conventions used in your workplace?

Security

Are connections properly closed/disposed of?
Is input properly validated and/or sanitized before being used?
Are passwords or other sensitive data being properly encrypted or hashed?
Does the code provide any noticeable avenues for security attacks?

Architecture & Design

If the code is object-oriented, are OOP principles followed? Is code properly encapsulated and functionality abstracted?
Does the code utilize modular components or services? Are methods written in such a way that they only do one thing? Is code repeated between components?
Are any design patterns or other programming conventions implemented accurately?

Automated Tests

Are unit tests included in the code review?
Are the tests accurate to the expected functionality of the code?
Are there other test cases that should be included in automated testing for this functionality?

I hope these questions help you come up with great feedback on your next code review! After a while, answering these questions when you review code will become second nature, and you’ll be giving feedback on pull requests like a champ.

This article was originally posted at CodeMom.net!

How to Pick Your First Programming Language

Tori "Code Mom" Brenneison — Wed, 14 Feb 2024 19:06:51 +0000

According to the US Bureau of Labor Statistics, about 9,600 job openings for computer programmers are projected each year over the next decade, and about 162,900 openings are projected for software developers, quality-assurance analysts, and software testers. Programming is an extremely valuable skill, and these projected numbers show that it is very likely to stay in-demand for a long time. If you’re interested in learning how to program a computer, your first step will often be to pick a programming language–but which one do you start with? Does it matter?

What do you want to accomplish by learning to code?

Do you want to develop phone apps, create websites, or work with large sets of data? Different programming languages are best suited for different purposes. For example, JavaScript has become the de facto language of the internet, but languages such as Kotlin or Swift are mostly used for creating Android and iOS applications.

Do you want to get a job in programming?

If your goal is to get a job in computer programming, you need to consider the job market. Some languages are more in-demand than others. Keep in mind that you will be a beginner when you first start out: that COBOL job making $250k a year may sound great, but learning COBOL as your first programming language so that you can bug-fix mainframes is probably not the best idea. Look at job postings to help you figure out which languages are most in-demand in your area.

What kind of support is available?

I often tell students that programming is a team sport, and recommend choosing a first programming language with a large, active user community (bonus points if there is an active user group local to you!). Picking a language with an active user community can help you find a mentor and provide you with documentation, support, learning resources and even opportunities to collaborate with other developers as you learn.

How do you learn the best?

Everyone has a different learning style–do you learn best by reading books or watching videos, following tutorials, or are you a “learn-by-doing” type who decides on a project first and learns how to do something as they go along? Are you going to self-teach, go to a bootcamp, or enroll in a degree program? It’s important to pick a language that has a lot of resources for you to utilize as you learn. Additionally, some programming languages are easier to learn for beginners than others, and my personal recommendation is to avoid using a lot of frameworks and libraries until you have a solid foundation of the basics.

I usually recommend a handful of third-generation, object-oriented languages for beginners: C#, Java, Python, JavaScript, or Ruby. All of these languages are very popular, have been around for a long time, and have a lot of learning resources that you can choose from.

Picking your first programming language can be a daunting task–but, if you consider your goals, the job market, community, and your learning style, I’m sure you’ll set yourself up for success. Learning to code takes a lot of time and effort, but it is a valuable skill that can open up many opportunities for your future, even if you’re not a full-time programmer!

This article was originally published at CodeMom.net!

10 Things You Should Never Say to Junior Developers

Tori "Code Mom" Brenneison — Wed, 14 Feb 2024 18:45:38 +0000

Hey, experienced developers–this one’s for you!

When coaching juniors, it’s important for senior developers to be mindful of what they say. Your choice of words may affect a mentee in ways you don’t anticipate, even if your intentions are good. The ultimate goal of mentoring junior developers is to build confidence, foster learning, and encourage professional growth; one of the ways we can help our mentees become successful developers is by using supportive and constructive language–i.e., not the phrases in this article!

If you have said one of these phrases to a junior in the past–well, we all make mistakes, and sometimes we don’t even realize we've done it. The important thing is to be better next time, and try to remove these phrases from your vocabulary.

“This is easy/simple,” or, “It’s not that hard.”

It is really tempting to say this–because, with years of experience, a certain task may be really easy! (I know I have accidentally said this more often than I should have.) Remember, even though something may seem simple to accomplish to you, that doesn’t mean that someone who is new to programming won’t find it difficult. It’s important to acknowledge that certain tasks may be a challenge for new programmers!

“You should already know this,” “You should figure it out on your own,” and “Why don’t you understand this yet?”

These phrases can set expectations way too high and create an atmosphere of pressure that can undermine a junior developer’s confidence, lead to imposter syndrome, and discourage them from asking for help. Juniors are learning on the job, and they might not be familiar with certain concepts–it’s far more helpful to explain things and share resources to help them learn than it is to criticize.

“How could you make this mistake?”, “That's not how I would have done it,” or, “Maybe you’re just not cut out for (insert task here).”

Criticisms like these can have lasting effects on a junior’s self-esteem. Instead, focus on giving constructive feedback and offer suggestions for improvement. Being overly critical or expressing a preferred personal approach can discourage juniors and make them hesitant to share ideas or solutions.

“You’re taking too long", “It's faster if I do it,” or “I don’t have time to explain this to you.”

Okay, Big Bad Senior Developer–we get it, you’re busy. However, while it can be tempting to take over a task that a less experienced developer is struggling with, they won’t learn if you take opportunities away. Instead, offer to guide juniors through complex tasks by helping them break down those tasks into smaller steps and offering your assistance in completing them. Also, dismissing a junior’s request for help can discourage them from asking again in the future–which can lead to poor performance due to stress and fear.

“Just do it this way,” or, “That’s not how we do things around here.”

While maintaining standard procedures and best practices is important, don’t dismiss ideas from juniors out-of-hand, as they can bring new ideas and fresh perspectives to work. Encourage critical thinking and creativity in the workplace by having discussions about the whys and hows of processes, and explain the rationale behind preferred practices.

“You’re too new for this,” “You’re just a junior developer,” or, “You won’t understand until you have more experience.”

Comparing juniors to seniors, often unfavorably, can not only undermine juniors’ confidence, but lead to an unhealthily competitive work environment as they desperately try to “prove themselves”. Instead, try to focus on individual growth by helping juniors set professional goals and coaching them toward reaching those goals, celebrating all the progress they make along the way.

“You’re lucky to even be here.”

This one’s a doozy–implying that a junior should be grateful for their job can easily come off as diminishing their accomplishments and contributions, and make them feel as though they don’t belong.

“That’s a dumb question.”

Discouraging questions or labeling them as stupid is an obvious no-no, but it still happens. Doing this can make juniors hesitant to ask for help. Instead, try to focus on collaboration and create a safe environment where juniors can ask whatever questions they have and receive quality answers and feedback. Emphasize that learning is a continuous process, and encourage professional development for both your junior and senior teammates.

“Real programmers don’t use ,” or, “That’s not how it’s done in 'the real world'.”

Developers have preferences, and we hold to our preferences so strongly that sometimes we start believing that our preferred way is, in fact, the one true way of doing things. I know that I can be guilty of this one, too! (Cough, cough… "Just use git through a bash shell, like nature intended.") However… disparaging a junior’s tooling or technology choices can contribute to imposter syndrome and destroy their willingness to explore new things.

You need patience and empathy to coach junior developers, as well as a genuine desire to help them learn and grow professionally. Coaching is an opportunity for senior developers to guide newbies toward success–and most of us still remember that one senior who mentored us in the beginning, don’t we? We owe it to juniors to try and create a positive and supportive work environment that sets them up for long-term career success.

This article was originally published at CodeMom.net!

3 Common Object-Oriented Programming Mistakes Junior Devs Make

Tori "Code Mom" Brenneison — Wed, 14 Feb 2024 18:38:34 +0000

As a bootcamp instructor, I’ve reviewed a lot of junior dev code… like, a lot. There are a handful of errors I see new programmers run into over and over again when creating OOP projects, so I wanted to write an article about them! In this article, I’ll discuss 3 common object-oriented programming mistakes junior devs make, and why they’re mistakes. Making these mistakes can lead to poorly-designed, tightly-coupled code and a difficult-to-understand, hard-to-maintain codebase!

Mistake 1: Poorly-Designed Classes

Photo by Anete Lusina

When you’re new to OOP, it’s common to write classes that are too big or that “do too much”. It’s also common to write classes that have unclear responsibilities, or classes where the properties and methods of the class aren’t clearly connected. If you find yourself adding properties or behaviors to your class that are only loosely related, take a step back and think about what the class's instantiated objects will need to do in your application. If your class contains too many unrelated things, it will make it more difficult to use the resulting objects in your program later on.

Ideally, classes should only “do one thing”. This is the Single Responsibility Principle (SRP), originally coined by Robert "Uncle Bob" Martin. Each class in your application should have a single, well-defined responsibility or purpose. When a class has multiple responsibilities, they can become tightly coupled with other classes, resulting in codebases that are difficult to maintain. Think about it this way: if you are going to change something about your program, will you have to re-write many classes with dependencies on each other? If so, you haven’t followed the SRP very well.

Another class design issue I see with new developers is including a lot of methods that don’t return anything. If a method does not return a value, what is its purpose in the class? Returning “void” is perfectly fine if you have a reason to do so, but if none of the methods in your application return a value, how will you write comprehensive unit tests to verify the behavior of your objects? When a method produces a result, you can easily test the output and compare it to the expected outcome of the method call.

Mistake 2: Misusing Inheritance

Once you’ve learned how to use inheritance, it can be tempting to create a lot of base classes and subclasses–even if you don’t need them. If you find yourself creating deep, nested class hierarchies, take a step back and consider if you really need them. Inheritance should only be used for “is-a” relationships, and not simply to reuse code in another class. If you have unrelated classes that use the same or very similar code, you may need to go back to the paragraph above and rethink your class design!

On the other hand, some new developers don’t use inheritance enough. If you have related classes and don’t inherit repeatable code from a base class, you may not be writing “DRY” code. DRY stands for “Don’t Repeat Yourself”, and reminds us that we shouldn’t be duplicating code across multiple classes–doing so can make code maintenance an absolute nightmare when a block of code has to be updated in multiple places. What happens if (when!) you forget one?!

Mistake 3: Treating Encapsulation As Optional

Photo by Ketut Subiyanto

A very common thing I see with devs new to OOP is the overuse of the “public” access modifier. While the majority of things in your code can probably be public, it’s important to keep an eye out for properties and methods that don’t need to be available outside of their class. For example, properties of an object should be accessed and modified via getter and setter methods, and not by direct access to the properties. This helps avoid a tight coupling of code when working with objects.

Similarly, if you find yourself relying on global variables, you probably need to take a step back and reconsider your design. “Global” refers to variables that are accessible from anywhere in an application, and overusing them can lead to very tight coupling of code, reduced maintainability, and lots of problems debugging. If you rely on a piece of information being available from anywhere in your application, any changes to that information can result in bugs cropping up in several different parts of your program.

Another mistake I see often is liberal use of the “static” keyword, mostly because a lot of IDEs will suggest it as a “fix” when a new developer is trying to directly use a class instead of instantiating objects from that class. If you don’t fully understand why something would need to be static, it probably does not need to be static! Remember, it’s “object-oriented programming”, not “class-oriented programming”.

Conclusion

Does it take some time to fully get your head around OOP? Yes, absolutely! Making these object-oriented programming mistakes is extremely common and they’re all part of a new developer’s learning process. If you’re a new dev, be on the lookout for these mistakes while you’re programming, and actively seek out ways to improve your code: ask a senior for review, make practice projects, and write unit tests as you go! By learning from the challenges you encounter along the way, you’ll become a more object-oriented developer quickly. Happy coding!

This post was originally published at CodeMom.net.