Guiding the IT community: A Q&A session on how to become a better Software Developer
Through our business we are part of the Tech Recruitment world, so we have the responsibility to provide guidance and constructive feedback before and after tech interviews. We are also firm believers in educating and being open-minded enough to let yourself be educated.
Luckily enough, we often get the chance to connect and interact with great, inspiring minds.
Such is the case of Claudia Givan. Mentor. Senior Software Developer. Teacher.
She was kind enough to answer some of our questions and provide valuable insights into the struggles, milestones and risks you have to take in the learning process, as a Software Developer.
The following answers and advice might be exactly what you need to read in order to access new opportunities and professional adventures.
How important is to know best practices in software development and why? Which one do you consider to be the most important?
If you want to build a quality product, you should definitely take best practices into account. I find two major benefits in using best practices:
First, from the technical point of view, best practices will save you and your team time. The code will be less error-prone (so fewer bugs will come up), more open for extension, so developing, testing and bug fixing will be easier. If you want to build a project just to get the job done, you can do it, of course, and forget about best practices. But if you value quality, efficiency, and scalability, then your project cannot grow to the level you want without following best practices.
Second, best practices will help you write code in a more efficient way and find solutions easier. Because if you model your mind to follow best practices when a particular problem comes up which is not like anything you have seen before, you will be able to focus just on the particularity of the solution. The other parts of the implementation process like the design decisions or how it’s better to write your code to be efficient and scalable will come naturally from your previous experiences and practice.
I consider KISS (keep it simple stupid) to be the pillar of my coding approach. I noticed that the more I try to overcomplicate things in order to reach perfection or to have a sense of fulfillment from finding a “complex solution”, the less easy it will be to continue the implementation. Take into account what’s important for your project (e.g. scalability), but don’t overcomplicate things. Remember that using best practices is a means, not a goal.
Teaching programming made me value best practices more than I did when I was just writing software because when I had to analyze the work of so many students in a short time, I realized how cumbersome it is to review their code.
So go on and use best practices as much as possible and after you write any piece of code, don’t consider it done. Add one more iteration to see if your code follows best practices and do the necessary improvements.
Especially if you are in the early stage of your career, do this because it’s easier to build a good habit from the beginning instead of turning a bad habit into a good one later.
Is it important for a Back-End developer to know and understand what’s happening on the Front-End side and vice versa?
Not necessarily. A backend or frontend developer does not need to know and understand more than the contract between Back-End and Front-End. Full-stack developers intervene when a full understanding of both sides is needed.
It is important for every side to understand and agree on the middleware between them: the communication protocol, the API contracts, etc. If these things are clear for both sides, the work can be perfectly split.
Also, it is beneficial for you as a developer to switch from time to time in your implementation from analytical thinking to system thinking in order to see how your work integrates into the big picture. First, because it gives you a better understanding of how to actually implement the feature taking into consideration the whole system, and second because you won’t feel disconnected from the rest of the project. When you see how your work impacts other parts of the system, you will also understand its overall importance which gives you more satisfaction and drive to continue.
It’s better to develop your skills horizontally (play with different technologies, frameworks, libraries, environments — mobile, web, desktop) or vertically (become an expert in one ecosystem)?
I think it depends on your goals.
Switching from a java developer to a full stack developer made me discover so many interesting concepts in Front-End technologies and helped me develop other types of skills that probably I wouldn’t have acquired in Java. The switch also brought me more passion for technology.
In any case, I think you need to expand your knowledge and develop your system thinking because this will help you go to the next level. And there is nothing wrong to develop horizontally, and when you feel you need to insist on a specific area to develop vertically, and after that horizontally again and so on. Just know what your goal is and ask yourself what learning path suits you best at that moment in order to reach your goal.
What are the milestones you have to cross to become a Senior Developer?
I think there are some technical requirements you need to meet, but there is also a shift in mindset.
On the technical part, you need to have enough technical knowledge acquired from your experience. What “enough” means depends on the technology and project, but you should be able to work independently and use your knowledge to help others.
Regarding your mindset, as a senior developer, you might want to get to the stage where you:
- Overcome the fear that probably there is no one more experienced to help you
- Adopt a technical curiosity so you will not complain “why this doesn’t work”, but focus instead on “how can I make this work”
- Be a problem fixer and have the confidence that you will eventually solve any problem, without needing someone else to deal with your problems. Don’t try to pass the blame on the framework, computer, weather, government, or any other external factor.
Many times I noticed myself living for that pat on the shoulder and seeking validation from others for my work and I was able to recognize this pattern in my students when I mentored them. I was also finding myself stressing too much about “why this doesn’t work”, trying to find quick fixes to meet the deadline for some tasks. What I saw in some of my students was that they were also choosing this approach of getting things done quickly without embracing the process of learning or trying to understand and learn as much as possible from problems.
An unrealistic expectation is that an experienced developer knows every part of every technology in their field.
What’s more, no matter how experienced you get, you may still find yourself switching between feeling incapable (“Impostor syndrome”), and overconfident (“Dunning–Kruger effect”).
Ask your superior what does the role of “senior developer” mean from the technical point of view in your company and work also on your mindset to be able to get there.
When is someone ready to become a mentor, from a technical aspect?
From my perspective, ASAP !!! Why? Because when you become a mentor for someone, you at least double your level of understanding. I say this from personal experience as a mentor and a teacher. When I had to explain technical concepts to others, I understood some of them better and I correctly understood others only when explaining.
If you are one step ahead of someone else, you can start to mentor him on aspects that you know better. For example, I think it is suitable for someone who just starts his way into a programming career to be mentored by someone with one level of experience higher because the connection is easier and there isn’t such a big gap between the mentor and the mentee. From this perspective, it’s easier for the mentor to remember the obstacles which he faced early in his career and he will be able to use a suitable approach in the mentoring process.
So go on and practice your mentoring skills and remember: when one teaches, two learn!
How important is it to know design patterns and have experience in using them?
A design pattern is a repeatable solution to a commonly occurring problem in software design. Every developer could implement his own solution for the same type of problem, but design patterns have eliminated the time spent searching for a solution every time, providing you a template solution for design challenges or problems that you encounter.
But besides all the known technical benefits, they also help you model your way of thinking when it comes to solving non-repetitive problems because you will use the same clean way that you used when you applied design patterns. Put simply, patterns inspire solutions.
You probably often forget about applying design patterns in your own implementations, but you surely find them applied in the frameworks you work with. For that reason, I would say that design patterns constitute a common vocabulary for developers to talk about software solutions.
To gain some experience in using them to better understand the present solutions in the software world!
It’s better to work on smaller projects (up to 1 year) and diversify your knowledge or work on bigger, more complex projects (2–3 years) to perfect a specific set of skills? Is it necessary to do both and if so, when is the time to switch?
I started with a bigger project and then switched to smaller projects.
I think in the beginning it’s a good idea to work on bigger projects because you will understand the complete production process and the whole product ecosystem. Also, chances are that you will have many experienced developers around to learn from. The legacy code that you will probably find can be seen as an opportunity to learn from others and to train yourself to adapt to mature projects.
In smaller projects you will concentrate more on technical challenges, probably if the company is smaller you won’t rely as much on others, and the context will force you to learn faster and to implement harder tasks.
While this shouldn’t be taken as a rule of thumb, when you understand and learn all the parts in the software development process and maybe you hit a technical knowledge plateau, you can take what you learned and switch to a smaller project in order to challenge yourself more.
How do you approach technical problems or feature implementation?
For technical problems I have two useful tips:
The first one is an obvious one: if possible, use a debugger, or use some logs to have a clear idea of the process flow, so you can identify flaws at any step in the process.
Second, take advantage of the power of communities. Posting questions will clear your mind because you state your issue. At first, maybe you will create even more confusion, but with practice, you will clarify the problem for yourself and you may even find the answer before submitting the question. In general, communities are eager to help but don’t forget to give some value back.
For feature implementations I have another two tips:
First, use iterations! I always work in iterations, meaning that I write a minimum viable code and I make sure that it works. After that, every iteration is done by adding improvements to the existing code until there is nothing else to be improved, together with testing it.
Second, use test-driven development (“TDD”). I find it helpful to write your tests first and after that the implementation. By using “TDD” you will make sure that you cover all the test cases from the beginning. Even if accommodating this approach can take more time, in the long run using it can save you time.
How do you self-evaluate? Based on what criteria?
There are multiple ways to self-evaluate as a developer but I choose to evaluate myself from these four points of view:
- Way of thinking evaluation. How do you handle technical challenges and new feature implementations? For example, do you choose quick fixes instead of a complete understanding of the solution? Do you concentrate on “why it’s not working” instead of “how to make it work”? And so on.
- Knowledge sharing evaluation. How do you rate your ability to explain technical concepts to others?
- Technical evaluation on the area of expertise. What is your current level on the technology stack you work with?
- Technical evaluation on other fields of programming. What is your current level on more extended topics like architectural design, other programming languages, algorithms, other programming paradigms, etc.?
But self-evaluation without action is nothing. You can at the same time admit your knowledge gaps ( and choose to feel or not feel like an impostor) and still have deeply valuable expertise. Put objectives on improving your weak spots, allocate time within a deadline, measure your progress and be consistent. After that, self-evaluate again.
Is the code ever perfect? And if so, when does it reach that stage in your opinion?
No, because nothing is ever perfect. Perfect is a standard that nobody really knows what means because it’s subjective.
It is not a good practice in my view to compare your work with a “perfect” standard because from this comes the pressure to implement the perfect code and chances are that you will procrastinate or overthink. So strive for progress, not for perfection.
You should not skip the important steps from the learning cycle: implement, make mistakes, improve, implement again, and so on. This process will help you develop both technical skills and a healthy attitude.
Programming is creativity, in the same way, is painting. You can never say a painting or a code is perfect. But you can identify a “good enough” code by:
- The fact that it reaches its goal. Remember, the code is just a means to reach your goal.
- The fact that it is easily understood by other developers.
Have you ever created projects from scratch on your own? Where did you fail and what did you learn? Is it important to have this experience?
It is important to have this experience because it sets the context for you to learn all the steps in building an entire project. It puts you in the position of making complex decisions. You have to choose between technologies (programming language, database, build tool, framework). You have to decide how the infrastructure and deployment process should look like. All of these, help you understand the importance of all composing parts of a project. By doing such diversified tasks, you will understand the other technical roles in the project.
I created projects on my own for non-technical clients when I started my career as a freelance developer where I had to figure out everything, from what programming language suits best for the project to, how to deploy the project on a server. This way, I managed to work independently developing my knowledge in multiple areas. I failed multiple times when I worked with technologies outside of my area of expertise, like fixing UI bugs or managing infrastructure and deployment, which led me to pass the deadline.
But failures set the context for you to find solutions on your own without relying on someone else to help you. This builds confidence in your developer's capabilities.
Is it important to have clean code as an objective? Why or why not?
It is important to start programming with the clean code approach in mind, as a means to achieve a quality product that is easier to maintain and extend. By writing clean code every time, you start to develop this healthy habit which makes it easier for your subconscious to continue with the implementation. This is because you can focus only on how to continue as you have a clear structure and code conventions in place.
But using clean code doesn’t only benefit you, but also other developers that continue your work. This reinforces the continuous productive path of writing clean code.
If you want to have a clean state of mind and to find solutions easier, write a clean code!
Do you know what happens to your code when the task is finished? How does it fit in the bigger picture?
It is important for you to have a clear view of how your code fits in the bigger picture. Okay, maybe your code pays the bills right now, but if you don’t understand the contribution of your work, after a certain amount of time you will probably lose your passion or motivation because you lack a sense of belonging. Or you might notice that your progress will be small or non-existent.
It is also beneficial from a technical point of view because you will understand how your work impacts the whole system.
You need to like the project and the challenges that come up with it and to be aware of the whole team's achievement. There will always be problems, but I think the secret is to solve problems that you like and to understand what is the end goal. If this isn’t the case for you, maybe you should consider making a change.
How important is it for a developer to test?
Some developers don’t want to hear about testing because they don’t see the big picture and why tests are necessary not just for them, but also for the entire project. Avoiding tests can slow down the software development process. There is a higher probability for a bug to come up from an untested code and there will be extra time spent to solve it, review it, and test it again.
And there is one more psychological benefit for testing your code. Think about the moment when you tick a checkbox. You have a good feeling that your task is done. The same is when you test your code. You will get the confirmation that your code is working correctly and the peace of mind that comes with it.
Do you consider pair programming to be important? Why?
Most of the time you find yourself alone with the computer and maybe sometimes it’s more difficult for you to find the solution. You are caught up in your way of thinking and pair programming comes with the benefit that your colleague brings a different perspective. The work will be done faster, in a more qualitative way as two heads will validate the implementation..
I’ve rarely done pair programming when working in companies. It was not so encouraged because of the apparent resource allocation problem, that two people work on the same task.
But when I did it, I came up with the solution faster and got more confidence that I will find it.
I recommend pair programming on complex implementations, bugs, or design problems because two heads may do a better job and you will find yourself learning some stuff from your colleague.
Is theory less important than practice? Is practice enough?
Theory without practice is lost. Practice without theory is incomplete.
There are developers that don’t practice enough until they finish all the theory in order to start implementing something. It’s wrong.. Lack of action is worse than poor action. Meaning that as soon as you practice what you learned, you receive faster feedback and the learning cycle is faster. It is important to learn theory but don’t postpone the practice too much. And no, the practice is not enough.
Only practice is not sustainable long term, because if you don’t understand what happens in theory, in the future you will not have a clear understanding of how things work behind the scenes and you won’t be able to solve new problems. Maybe if you practice by copy-pasting solutions from Google will do the trick in the short term without knowing how or why, but using the same approach in the future does not guarantee that you will get the same result.
How much theory and how much practice? It depends on the area you are working on.
For example, when learning algorithms, practice is more important than theory because you want to develop algorithmic thinking, not to memorize all known algorithms. So adapt your learning according to your needs and don’t exclude theory.
Programming blindly will take you at some point when you realize that you don’t know enough and you have to take everything from the beginning.
Why is it important to stay up to date with new tools, languages, libraries?
Technological progress has the role of improving the tools (languages, libraries) so that newer technologies help you do your job faster and more efficiently than you did it before. This happens in any industry.
If you find yourself working in a company that still uses old technologies for some time already, you shouldn’t turn this into an excuse for not staying up to date with new technologies. Find out why this happens and what are the constraints for making a technology switch, and if the answer is something like “because this way was done until now”, don’t be afraid to make a change.
I’m not saying that you should pursue the latest technologies just because they are the latest. Remember that they are just tools that can improve your work process to reach your goals easier. You can stay up to date working in a company or on a side project, it doesn’t matter as long as you keep growing your developer skills.
Feel free to share your thoughts and feedback with us.
Hope you’ve found this useful and most importantly, we hope it provided guidance on how to implement change for the better!
Thank you, Claudia!