How to become a better software developer

How to Become a Better Software Developer How to become a better software developer

Today I would like to share some thoughts on ways a software developers can improve their professional skills and become better at their work. The topics raised here are universal and not specific to any technology stack. Most of them are not even specific to IT, for that matter. These are general advice on how to develop your personal traits, improve collaboration with colleagues and clients, and advance your career as a software developer. Today I want to share with you some ideas on how software developers can improve their professional skills and work better. The topics presented here are generic and not specific to any technology stack. Most of them aren’t even IT-specific at this point. These are general suggestions on how to develop your personal qualities, how to improve collaboration with colleagues and clients, and how to advance your career as a software developer.

Some of the things in this article are subjective and reflect my personal experience, while others have been adopted and successfully used by others. Some of the things in this article are subjective and reflect my personal experience, while other things have been adopted and used successfully by others.

Understand the Process End to End Understand the process from beginning to end

A lot of developers think that software development is all about coding, and everything else is just people trying to be annoying and wasting their precious time. This cannot be further away from the truth. Before you get to code a piece of software, it undergoes a process of transformation from a vague idea into a carefully designed solution ready for implementation. And after you pushed your latest changes into Git the software is being tested, deployed, monitored, analyzed and improved on. Coding is just one of the many steps of the process. Many developers think that software development is all about coding and everything else is people wasting their precious time. This couldn’t be further from the truth. Before you start writing a piece of software code, it will go through a transformation process from a vague idea to a carefully designed solution, ready for implementation. After you push your latest changes to Git, the software is being tested, deployed, monitored, analyzed, and improved. Coding is just one of many steps in the process.

So why does this happen? Frequently, especially when working in larger organizations, different phases of the projects are handled by different teams or even departments. It all starts with the business analysts, who gather requirements. The requirements are then handed over to the designers that produce the mockups for developers. The developers code away and give the results to the QA engineers. If everything is OK, the artifact is sent to the operations teams that deliver it to the end users. departments, their representatives often don’t really understand the goals of others and this leads to misunderstandings and even conflicts. Why does this happen? Often, especially when working in large organizations, different phases of a project are handled by different teams or even departments. It all starts with a business analyst gathering requirements. The requirements are then handed over to designers who generate prototypes for developers. Developers write code and hand the results to QA engineers. If everything is OK, the artifact will be sent to the operations team who will deliver it to the end user. The process is viewed as a set of discrete steps without any feedback. Due to a lack of communication between departments, their representatives often do not truly understand the goals of others, leading to misunderstandings and even conflicts.

Often the process of software development is treated as a set of discrete steps with no feedback. Often, the software development process is viewed as a set of discrete steps without feedback.

For many people nowadays this might sound too exaggerated. With the rise of agile methodologies, more companies move away from such a rigid approach towards smaller teams consisting of people of mixed specialty. But even then we see that people don’t really try to understand the work of others. How often have you been irritated with your designers because they want you to implement a custom checkbox that is just too time-consuming? And vice-versa, received criticism, because you forgot to use the correct font. To many people today, this may sound like an exaggeration. With the rise of agile methods, more and more companies are moving away from this rigid approach and instead employing small teams of mixed professionals. But even then, we see that people don’t really understand other people’s work. Are you constantly annoyed with your designers because they want you to implement a very time-consuming custom checkbox? Or vice versa, you get criticized because you forgot to use the correct font.

A lot of these differences can be overcome by just paying attention to the work of others. Sit down with your designer and explain him, that implementing a custom checkbox takes a while and that there’s a library that offers a different similar checkbox you could reuse. In return, learn the basics of typography and understand why choosing a correct font makes a difference. Develop the same attitudes toward managers, business analysts, QA engineers, support and marketing specialists. Quoting T. Huxley: These differences can be overcome simply by paying attention to the work of others. Sit down with your designer and explain to him that implementing a custom checkbox will take a while and that there is a library that provides another similar checkbox that you can reuse. In return, learn the basics of typography and understand why choosing the right font makes a difference. Develop the same attitude towards managers, business analysts, QA engineers, support and marketing specialists. Quoting T. Huxley:

Try to learn something about everything and everything about something.By learning something from everybody, you will be able to anticipate their needs, shorten the feedback loop and enable more frequent deliveries. Plus it will earn you a lot of love and respect from everybody else. By learning from each individual, you’ll be able to anticipate their needs, shorten feedback cycles, and make deliveries more frequent. Moreover, it will win you the love and respect of many people.

Understand Your Client’s Needs Understand your client’s needs

There’s one important thing that you need to understand about your customers: they don’t understand most of the stuff that you’re doing. Agile, functional programming or non-relational databases is all dark wizardry to them. Even the ones that closely follow your work and are genuinely interested are still mostly in the dark. This has a couple of consequences. There’s one important thing you need to understand about your customers: They don’t understand most of what you’re doing. Agile, functional programming or non-relational databases are all dark magic to them. Even those who follow your work closely and are genuinely interested are mostly in the dark. This has several consequences.

The face of most clients when talking to software developers. The look on most customers’ faces when talking to software developers.

Hiring software developers for them requires a certain degree of trust. People often tend to feel uncomfortable about having to pay a lot of money for something they don’t understand. Remember last time you walked into an unfamiliar car repair service and weren’t sure if you could trust them with your ride? Well, your clients have the same feeling. Except there’s no car, there’s just a whole bunch of abstract non-tangible concepts which are supposed to somehow materialize into products and revenue. When working with new clients it’s important to earn their trust. Make sure they understand how you operate and aim to deliver results in smaller but frequent iterations. That way they can see the progress of your work, assess the intermediate results and provide their feedback. Hiring software developers for them requires a certain level of trust. People often feel uncomfortable having to pay a lot of money for something they don’t understand. Remember the last time you walked into an unfamiliar auto repair service company and weren’t sure you could trust the service they provided you? Your customers feel the same way. Except there are no cars, just a bunch of abstract intangible concepts that should somehow materialize into products and revenue. When working with new clients, it’s important to gain their trust. Make sure they understand how you operate and aim to deliver results in smaller but frequent iterations. This way they can see your work in progress, evaluate intermediate results and provide feedback.

Often clients tend to come up with their own solutions instead of sharing their problems. Since they have little idea of your capabilities, their solutions are often misjudged, under- or overambitious. Remember the old (and maybe fictional) quote by Henry Ford: Customers often tend to come up with their own solutions rather than share their problems. Because they don’t understand your capabilities, their solutions are often misjudged, insufficient or overly ambitious. Remember this famous (perhaps apocryphal) quote by Henry Ford:

If I had asked people what they wanted, they would have said faster horses.

Instead of going with the flow and silently implementing whatever the client wants, it’s sometimes useful to invite them to take a step back and discuss the problem that they wanted to solve in the first place. When combining their domain knowledge and your technical expertise, you’re are likely to arrive at a better solution. Rather than just going with the flow and silently implementing whatever the customer wants, sometimes it’s useful to invite them to take a step back and discuss the problem they originally wanted to solve. When you combine their domain knowledge with your technical expertise, you may get a better solution.

Keep in mind, that not everybody likes having their ideas questioned and this tactic requires you to have some tact and inspire confidence in the client’s eyes. You will also need to leave your comfort zone and immerse yourself in their business, to be able to understand the problem and suggest a better solution. This can be challenging if you’re are working in complex industries such as finance or health care. But if you pull this off once, it’s likely that next time the client will return with a more open mind. Remember, not everyone likes to have their ideas questioned, and this strategy requires you to have some tact and inspire confidence in the eyes of your customers. You also need to get out of your comfort zone and immerse yourself in their business to be able to understand the problems and come up with better solutions. If you work in a complex industry like finance or healthcare, this can be a challenge. But if you can do this, the customer may come back with a more open mind next time.

Pick the Right Tools for the Job

If all you have is a hammer, everything looks like a nail.

Often developers that learn only a single technology rush to apply it to every problem they encounter. Unsurprisingly, this kind of approach leads to sub-optimal results. Instead, when tackling a new problem, pause and think whether the tools at your disposal are really suitable for this kind of work. If you have doubts, investigate a bit and come up with a list of likely superior alternatives. To make it easier, compile a list of questions and assess different options one by one. The questions can be different for each assessment, but it can go along the way of: Often, developers who learn only one technology rush to apply it to every problem they encounter. As expected, this approach leads to suboptimal results. Instead, when you’re working on a new problem, stop and think about whether the tools you have are actually right for the job. If you’re in doubt, do your research and come up with a list of alternatives that might be better. To make it easier, write a list of questions and evaluate the different options one by one. The questions may be different for each assessment, but may look like this:

• What platforms or devices must it support? What platforms or devices must it support?

• What are the non-functional requirements, such as performance or memory usage? What are the non-functional requirements, such as performance or memory usage?

• Is buying a license an option, or do you need something free or open-source? Is buying a license an option, or do you need something free or open-source?

• Does the solution provide everything you need out of the box, or will you need to write something yourself? Does the solution provide everything you need out of the box, or will you need to write something yourself?

• Do you have any other limitation, like company policies, legal considerations or a lack of specialists in your team? Do you have any other limitations, like company policies, legal considerations or a lack of specialists in your team?

Answering these questions should help you structure the options in your head and narrow them down to a shortlist of candidates. Answering these questions should help you structure the options in your head and narrow them down to a shortlist of candidates.

Experiment Safely Experiment Safely

So what happens if you none of the things you know are a particularly good fit in your case and you want to try something new? The fact that you don’t experience with something doesn’t automatically mean that it’s out of the question. It just means that you need to consider some additional things: So what happens if nothing you know works particularly well for you, and you want to try something new? Just because you haven’t experienced something doesn’t mean it’s impossible. It just means you need to consider a few extra things:

Do you have enough time for preparation? If the timeline of the project is not stressful, you can learn as much as possible before you begin the implementation and pick up the rest along the way. Or at least adopt the “fake it till you make it” approach and convince the client that you know what you’re doing. Do you have enough time to prepare? If the project’s timeline is not stressful, you can learn as much as you can before starting implementation and learn the rest along the way. Or at least take a “fake it 'til you make it” approach and make your clients believe you know what you’re doing.

Identify the things you need to test first. Take the “fail fast” approach and identify the crucial things that you need to evaluate before you can conclude the experiment. Having doubts about the performance of a system? Build a minimal prototype and run a load test. Uncertain about a particular library or integration with an external service? Implement that separately and then build the rest. Start by determining what needs to be tested. Use a “fail fast” approach to identify key factors that need to be evaluated before the end of the experiment. Have questions about the performance of your system? Build a minimal prototype and run load tests. Not sure about a specific library or integration with an external service? Implement that individually and then build the rest.

Keep in mind that going down this road is still risky both for you and your client, and they need to be aware of both the risks and the potential benefits. After all, a two-week investigation that might save months of work in the long run, this sounds like a pretty good deal. Even if the experiment fails, you only lose two weeks. The more trust you have with your client, the more they are likely to agree to something like this. Remember, doing this is risky for both you and your client, and they need to be aware of the risks and potential benefits. After all, a two-week survey could potentially save months of work in the long run, which sounds like a pretty good deal. Even if the experiment fails, you’ve only lost two weeks. The more trust you have in your customers, the more likely they are to agree to something like this.

Build on the Shoulders of Giants Stand on the shoulders of giants

Reinventing the bicycle often leads to weird results. Reinventing the bicycle often leads to weird results.

IT people often have two common characteristics: we are inventive and we enjoy our work. This sounds like a good thing, but it comes with an awkward side-effect: we tend to come up with our own solutions to problems that have been solved before. So whenever we’re faced with a choice of whether to use a framework, library or service or to implement it on our own, we tend to choose the latter. And this takes us on the futile journey of reinventing the wheel. Some of the common misbeliefs that lead to this are: IT people often have two characteristics in common: we are creative and we enjoy our work. This may sound like a good thing, but it comes with an awkward side effect: We tend to come up with our own solutions to problems that have been solved before. Therefore, when we are faced with the choice of using a framework, library, service or implementing it ourselves, we tend to choose the latter. This puts us on a futile journey to reinvent the wheel. Some common misbeliefs that lead to this result are:Implementing something yourself is easier than learning a 3rd party solution. While this may be a perfectly valid reason, it’s important not to oversimplify the task at hand. Often, something seems simple in the beginning but turns out to be much more difficult with progress. Eventually, you could end up spending a whole bunch of time handling bugs and edge cases that someone could have handled for you. It’s easier to do it yourself than learn third-party solutions. While this may be a perfectly valid reason, it’s important not to oversimplify the task at hand. Often, things seem easy at first but become more difficult as they progress. You may end up spending a lot of time dealing with bugs and edge cases that someone else could handle for you.

This solution does more things than I need. Unless there are specific reasons why this is a bad thing, such as increasing the size of the resulting artifact, adding potential vulnerabilities or considerably slowing down the build, this is not usually a bad thing. You might end up needing it later. On the other hand, adding a whole library to use just one function might be an overkill. This solution does more than I need. This is generally not a bad thing unless there is a specific reason why it is a bad thing, such as increasing the size of the artifacts produced, adding potential bugs, or significantly slowing down the build. You may need it later. On the other hand, adding an entire library to use just one function might be overkill.

We can do it better. Although there are some successful projects that started with these words, this is not usually the case. Quality third part solutions are maintained by teams that have experience and resources devoted to solving this particular problem. To compete with them you need to be able to invest even more. Most projects have neither the resources nor the need to do that. We can do better. While there are some successful projects that start with these words, that’s usually not the case. High-quality third-party solutions are maintained by teams with the experience and resources to solve this specific problem. In order to compete with them, you need to be able to invest more. Most projects have neither the resources nor the need to do this.

Code ownership and long-term maintenance will become a problem. Some people fear that if you go with a third party solution, you risk that the project at some point might become abandoned or unusable for whatever reason. on whether it’s worth the risk. Code ownership and long-term maintenance will become an issue. Some people worry that if you go with a third-party solution, you might abandon or be unable to use the project for one reason or another at some point. The risk of product lock-in is real, and you should consider a possible mitigation strategy. If this is an open source project, is it possible for you to develop and maintain it yourself? Or if it’s a private project, how much will it cost to replace it? Based on these inputs, you can make a conscious decision whether it’s worth the risk.

Learn Through Reimplementing

There’s another side to this story. Reimplementing something yourselves is actually a great way to learn. While writing your own framework for a production project is almost always a bad idea, creating it as a learning exercise can be highly valuable. What better way to familiarize yourself with the problems that it solves by taking a crack at the same problems. Don’t go too deep into the rabbit hole, a simplified crude implementation will be enough to give you an understanding of the situation. There is another side to this story. Re-implementing your own stuff is actually a great way to learn. While writing your own framework for production projects is almost always a bad idea, creating it as a learning exercise can be very valuable. What better way to familiarize yourself with the problem it solves by trying to solve the same problem? Without going too deep, a simplified rough implementation will be enough to give you an idea of ​​the situation.

While you’re at it, don’t shy away from peeking into the sources of similar projects. Studying the code of open-source projects will allow you to benefit from the experience of more seasoned developers. While you’re at it, don’t be shy about checking out sources for similar projects. Studying the code of an open source project allows you to benefit from the experience of experienced developers.

Work on How You Work Learn how you work

Strive for improvements not just in technological aspects, but in methodological as well. Just like properly designed and optimized software, a well-established workflow will allow you to work with fewer effort and stress while producing better results. Establishing an effective and efficient work process is not an easy task and there are numerous books and materials available on this topic. But for a start, consider the following areas for improvements: Strive for improvements not only in terms of technology, but also in terms of methods. Like properly designed and optimized software, a sound workflow will allow you to work with less effort and stress while producing better results. Establishing an effective and efficient workflow is not an easy task, and there are many books and materials on the subject. But first, consider the following areas for improvement:Team and project management methodologies. Since most of us work in teams, it’s important to adopt a process that improves collaboration and establishes a common work rhythm for everybody. The agile movement in software development has given birth to a number of widely adopted methodologies, such as Scrum or Kanban. They help organize the overall work structure but don’t cover everything. There are other methodologies that help you make estimates, prioritize issues, improve communication, etc. You’ll need to identify the areas you are struggling with and look for best practices that help address your struggles. Team and project management methods. Since most of us work in teams, it’s important to adopt processes that improve collaboration and establish a common work rhythm for everyone. The agile movement in software development has given rise to many widely adopted methodologies, such as Scrum or Kanban. They help organize the overall work structure but do not cover everything. There are other ways to help you conduct assessments, prioritize issues, improve communication, and more. You need to identify the areas you are struggling with and look for best practices to help you solve them.

Personal processes. Like an orchestra, an effective team must have the same rhythm, but it doesn’t mean that everybody must work in an identical manner. Each person has their own preferences and should work in a way that makes them more productive. For example, a lot of people don’t like to be disturbed for hours when coding, but I, personally, like to work in short one-two hour bursts with breaks in between (a less strict version of the pomodoro technique). I also don’t like to work at home to avoid household-related distractions and prefer to work from an office or a cafe. Find out what works for you and stick to it, but also make sure that your habits don’t create problems for other team members. personal process. Just like an orchestra, an effective team must have the same rhythm, but that doesn’t mean everyone has to work the same way. Everyone has their own preferences and should work in a way that makes them more efficient. For example, many people don’t like to be interrupted for hours while coding, but I personally like to work in short bursts of 1-2 hours with a break in between (this is a less rigorous version of the Pomodoro Technique). I also don’t like working from home to avoid family-related distractions, I prefer working in an office or coffee shop. Find what works for you and stick with it, but also make sure your habits don’t cause problems for other team members.

Engineering practices. A lot of practices lie on the border between technology and methodology and focus on improving the actual development process. For example, test-driven development and behavior-driven development help keep your code base well structured and tested. Code reviews help reduce defects in the code and also spread knowledge in the team. Continuous integration and continuous delivery ensure an easier and safer deployment process. Use these practices in combination with other organizational methodologies to achieve maximum results. Engineering Practice. Many practices sit on the boundaries of technology and methods, focusing on improving the actual development process. For example, test-driven development and behavior-driven development help keep the codebase well-structured and tested. Code reviews help reduce defects in the code and spread knowledge among the team. Continuous integration and continuous delivery ensure an easier and more secure deployment process. Use these practices in conjunction with other organizational methods to achieve maximum results.

Remember, that there’s no process that will work for everybody, you need to trial it in your own environment. Also, make sure that you understand the process completely and implement it correctly. Seek advice from teams that have already gone through the process and benefit from their experience. Don’t neglect the software and material tools that will help you to adopt a process. do an evaluation of whether things have improved. Keep in mind that there is no one-size-fits-all process and you will need to experiment in your own environment. Also, make sure you fully understand the process and implement it correctly. Seek advice from teams who have been through this process and benefited from their experience. Don’t overlook software and material tools that will help you adopt your process. Get a true Kanban board and a modern platform for continuous delivery. Adopting new processes requires effort and may even result in short-term productivity losses. Give it some time and evaluate whether things have improved.

Remove obstacles Remove obstacles

A separate thing has to be said on addressing obstacles. It’s a common mistake to neglect small nuisances that might not seem important but can actually have a toxic effect on your work. Is your product designer sitting in a separate room or building? This means that it takes a bit more efforts to come over and have a conversation and some things will not be discussed. Is writing a new test difficult? Then a lot of things will not be tested. There is one more thing to say about addressing obstacles. It’s a common mistake to ignore small annoyances that may seem unimportant but can actually have a detrimental impact on your work. Do your product designers sit in a separate room or in a building? This means you need to put more effort into talking to them, and some things won’t be discussed. Is it difficult to write a new exam? Then a lot of things won’t be tested.None of these things are particularly dangerous by themselves, but they tend to pile up and cause serious consequences. And the nasty thing is, that you often don’t notice them until it’s already too late. Especially when there are always more serious perils to address. Remember the fable about the boiling frog and the notion of creeping normality. None of these things are particularly dangerous on their own, but they often pile up and cause serious consequences. The worst part is, you often don’t notice them until it’s too late. Especially when there are always more serious dangers to deal with. Remember the parable of the boiling frog and the concept of crawling normality.

Stay vigilant and fight these things at their roots before they get to you. Be vigilant and fight these things to the core before they happen to you.

Focus on the Fundamentals Focus on the fundamentals

Fundamental concepts are the building blocks of your career.

IT is an extremely fast-paced industry. Every week new tools are released into the market. I’ve already mentioned the infamous “JavaScript fatigue” syndrome in my previous post. A lot of developers have been stressed and felt forced to re-evaluate their JS tech stack with each new project and that drove them nuts. Indeed, always being on the edge can be challenging, but there are a couple of ideas that can make it easier. This is a very fast-paced industry. New tools are released to the market every week. I already mentioned the infamous “JavaScript fatigue” syndrome in my last article. Many developers feel pressured to re-evaluate their JS stack with every new project, and it drives them crazy. Yes, it’s challenging to always be on the edge, but there are some ideas to make it easier.

First of all, focus on the fundamentals. Even though new technologies appear quite frequently, new fundamental concepts are much more seldom. When learning something new, make sure you understand the underlying ideas that lead to this implementation. Chances are, these ideas are used in other projects as well, and once you encounter something similar, it will be easier for you to get a grasp of it. In a similar manner ideas of Redux found their way into Angular, and reactive state management from Angular was implemented for React as MobX. First, focus on fundamentals. Although new technologies appear frequently, new fundamental concepts rarely emerge. When learning something new, make sure you understand the basic ideas that led to this implementation. Chances are, these ideas will be used in other projects as well, making it easier to grasp it once you come across something similar. For example, modern JavaScript UI frameworks are component-based, and once you understand how to construct component-oriented applications using React, you can use this experience when working with Angular. Similarly, the idea of ​​Redux has also been introduced into Angular, which implements responsive state management for React as MobX.

Take some time to familiarize yourself with the classical books on the topics of common patterns in software development such as “Enterprise Integration Patterns” by Gregor Hohpe and Bobby Woolf, the famous “Design Patterns: Elements of Reusable Object-Oriented Software” by the Gang of Four or different works of Martin Fowler. Although some of the things described in books may be outdated, you can use them to learn how the patterns evolved till today. Spend some time familiarizing yourself with classic books on common pattern topics in software development, such as Gregor Hohpe and Bobby Woolf’s Enterprise Integration Patterns, and Martin Fowler’s famous book Design Patterns: Elements of Reusable Object-Oriented Software. While some of the content described in the book may be outdated, you can use them to understand how the pattern evolved to where it is today.

Secondly, don’t rush to learn about every new thing out there. I understand that it’s tempting to follow every new thing that appears on Hacker News, but a lot of these things are just noise. Rather keep an eye out for things that have been circling in the community for some time now and have matured beyond the hype of initial discussions. Don’t give into FOMO. If you pay at least some attention to what’s going on, no important thing will pass unnoticed. Second, don’t rush into learning every new thing. I know it’s tempting to follow every new thing that comes out on Hacker News, but a lot of it is just noise. Instead, focus on things that have been around in the community for a while and have matured from initial discussions. Don’t give in to “social control”. If you at least pay attention to what’s going on, nothing important will go unnoticed.

Bonus Tips Bonus Tips

We’ve already talked about a lot in this article, but there are a few other points I would like to highlight before we wrap up. These few tips are focused more on your personal traits rather than professional, but I still believe that they have a high impact on your work life. We’ve covered a lot in this article, but before I wrap up, I’d like to highlight a few additional points. These pieces of advice are more personal than professional, but I still believe they can have a big impact on your work life.### Share the knowledge Share knowledge Often people think that hoarding valuable knowledge will make them indispensable. Having people like this in your team exposes you to the “bus factor” and can put you in a tough spot if such a person were to leave the project. If you are one of these people, consider that in addition to making you indispensable, your expertise also makes you unpromotable and “unvacationable”. You might miss out on other career opportunities in your organization because you are tied up in this role. Instead, share the knowledge with your colleagues, if possible delegate part of your work to them and use this collaboration to build even greater things on top of their work. People often believe that storing valuable knowledge will make them indispensable. Having such a person on your team exposes you to “bus factor” and can leave you in trouble if such a person leaves the project. If you’re one of these people, consider that in addition to making you indispensable, your professional skills will also make you ineligible for promotions and “unable to take time off.” You may miss out on other career opportunities within the organization because you are locked into this role. Instead, share your knowledge with your colleagues, delegate parts of your work to them if possible, and use that collaboration to build something bigger on top of their work.

Don’t blame yourself or others

I remember a long time ago we had an incident in one project that was by my mistake. We’ve managed to recover from the incident quite quickly and I remember the client telling me: I remember something happened to us on a project a long time ago and it was my fault. We recovered from the incident very quickly and I remember the client telling me:

You don’t judge a team by how they perform when everything goes according to plan, but by how they operate when the shit hits the fan.

No matter how good you are, sometimes things will go wrong and in such moments it’s important to be able to keep your cool and handle the situation with dignity and mutual respect. After the fire is put out, don’t focus on finding the scapegoat. This won’t help you avoid mistakes in the future, but will spear fear and doubt across the company. improve your system or workflow to avoid this problem in the future. No matter how good you are, sometimes things go wrong, and in those situations it’s important to stay calm and handle the situation with dignity and mutual respect. Once the fire is out, don’t focus on finding a scapegoat. This won’t help you avoid mistakes in the future, but it will fill the entire company with fear and doubt. Instead, conduct a joint autopsy with all affected parties. Focus on what caused the problem, figure out why it happened, and then brainstorm ways to improve your system or workflow to avoid this problem in the future.

Don’t be an asshole Don’t be an asshole

The developer community is a funny thing. On one side we see a lot of driven open-minded people that contribute to the community by working on open-source projects, giving speeches at conferences or writing articles. On the other side, we encounter people that troll new ideas, disrespectful newcomers and demonstrate rude behavior to everyone around them. Don’t be one of those people. Be nice and spread the love. The developer community is a funny thing. On the one hand, we see many active and open people contributing to the community through open source projects, speaking at conferences, or writing articles. On the other hand, we also encounter people who turn their noses up at new ideas, disrespect newcomers, and behave rudely to those around them. Don’t be that person. Be kind to others and spread love.

A lot of professional advice can be summed up with just four words.

Wrapping it up Wrapping it up

The best thing about our work is that it doesn’t have a limit. There’s are always new roads to travel and dragons to slay. Whether you’re just at the beginning of your journey or an experienced professional, keep these things in mind. They should help you find your way and become a better developer with each step taken. The best thing about our job is that there are no limits. There are always new paths to take, always new dragons to slay. Whether you’re just starting your career or you’re an experienced professional, keep these things in mind. They should help you find your own way and become a better developer every step of the way.

Do you have different advice to share with others? Feel free to post it in the comments and start a discussion! Do you have any different suggestions that you can share with others? Feel free to post them in the comments and start a discussion!

Are you interested in learning web development or further improving your skills? Check devtrails.io for a collection of helpful guides to help you figure out your way around web development. Are you interested in learning web development or further improving your skills? Check out devtrails. io’s set of helpful guides to help you find your way around web development.

Article from: https://medium.com/devtrailsio/how-to-become-a-better-software-developer-dd16072c974e