Good and Bad Developers

Intro

I'm Peter and this is the RoguePlanetoid Podcast where you will find insights about Microsoft or related platforms and technology, along with so much more whether you are beginner or an experienced professional or just interested in technology. Keep Current, Keep Coding!

Welcome

Welcome to episode seven of the RoguePlanetoid Podcast about Good and Bad Developers including what makes a good or bad developer along with stories about good and bad developers. First, I'd just like to announce by the release of this episode the RoguePlanetoid Podcast will have passed one-hundred downloads! I really appreciate those of you who have taken the time out of their day to listen to this podcast such as on the way to work or whenever or wherever you choose to listen! Recently I was offered the opportunity to be interviewed for Smart Cherrys Thoughts which features interviews with developers and others in the technology industry, many of whom I look up to myself so was amazing to see my interview alongside them, you can check out all the interviews including my own at smartcherrysthoughts.com or check out the link in the show notes.

Introduction

You may have encountered both good and bad developers, be one or know one or have a bit of good or a bit of bad. Many people will immediately think of examples of both good and bad developers and hopefully those balance out with the good offsetting the bad! I will be covering examples of both good and bad developers from my own experiences, colleagues, and others although details have been changed and names left out. Should you recognise any of the aspects of the good developers then that's great, but don't worry if you recognise the bad as sometimes the hardest thing for developers, or for anyone to admit is when they are wrong and to change accordingly!

What makes a Good Developer?

What makes a good developer, or even tester, designer, manager or in fact someone good in any creative endeavour? I think it would be someone who likes to explore new things in their line of work so are not stuck in their ways as in the technology sector things are changing all the time so you can't stand still so exploring new things makes sense. It can also be someone who shares what they know with others and encourages others to do the same and this can help both with understanding as well as allowing others to learn from that knowledge. Someone who knows to admit they are wrong and leads by example, you don't need to know everything but can be open to different ideas and opinions and maybe even change the way you do things based upon feedback. I think these are the traits of a good developer or any creative and should be strived for whenever and wherever possible.

What makes a Bad Developer?

However, what makes a bad developer, tester, designer, manager, or someone else in the creative and technology industry? I think that is someone who mocks the lack of skills in others without recognising that everyone learns in their own way, along with people if they share knowledge, they only do it to some and not others who could also benefit from this. Some bad traits may be those who actively suppress the idea of sharing with others and actively discourage or even prevent it from happening along with those who put themselves above everyone else and belittle the knowledge and skills of others. I think those are the traits of a bad developer or anyone in a creative industry and should be avoided or tackled whenever and wherever possible.

Good and Bad Developers

This first story is of a graduate who got their first job after being sure they knew the basics of what they needed and understood the concepts. However, they were finding applying those concepts more difficult than they expected, and a more experienced developer there asked them straight out if they understood the concept. It was hard for them to admit they didn't understand but when they did the more experienced developers explained the basics of the concept and told them to try a few examples on their own to see if they understood the concept. This suggestion really helped, and that graduate was able to come back and work on the project again with a better understanding of the concept. A good developer not only knows to give good answers but also knows to ask good questions such as what do you understand exactly? You can point someone in the right direction but still allow them to work it out on their own. Understanding many concepts in any industry can sometimes be hard, everyone learns something for the first time. This experience was a great way of pointing someone in the right direction, not just to explain a concept but to also make sure it was understood.

This next story is about a job opening for a developer at a company that needed to be filled, this needed someone with specific experience of developing for a particular platform. A prospective candidate came along on time and ready for their interview to see if their experience of this platform was enough for them to get the job, unfortunately they just didn't have enough experience. However, it turned out they weren't even a developer for that platform at all, they just used the platform and that was the sum of their experience. I admit this isn't necessarily a bad developer as sometimes it is worth going for something you might not be qualified or experienced in but in the case that candidate had no relevant skills. There was also a similar experience of a developer going along to an interview for a different role and finding there were more formal requirements for this position than they had expected. However, the interview experience itself was still valuable and helped with future interviews that enabled them to get a job in the future. The bad developer here would be one who doesn't try at all, many of us will have found early on in our careers it is hard to get on the career ladder and you just need to keep trying. However, once you get that first job the next one and the rest get a little bit easier, although you still have to aim for positions where you have at least some of the required skills for the job!

This story is about a developer who went into a company thinking they already had the skills they needed for the role and were able to demonstrate this quite well but as soon as their work went a little more advanced, they found themselves out of their depth. However, help was at hand with a couple of more senior developers who suggested doing some training to practice and learn those skills before coming back and be able to understand more specific things in context. This was a good developer experience, as a more experienced developer you can help those less experienced identify where the limits of their knowledge are and encourage them to fill those gaps. This helped that developer build up their knowledge so not only did they no longer need the help, but they could also better perform the rest of the work that was needed.

Developers can often face unusual issues when working, there was a story of a developer who was working well within their team but started to notice on some occasions that they wouldn't be told things they needed to know directly but started to have to hear things second hand. This even got to the point they had to overhear conversations they weren't involved with to know what to do as otherwise they were not spoken to about it at all. This is probably more of a bad management experience than a bad developer one. No one should have to overhear what others say to know what they need to do, or worse just not be spoken to or ignored. Communication is a key part of what it means to be a developer, or even any other role, whether that is communication to you or from you. It can be difficult to question when something like this happens, but the best thing to do is to look at the situation and understand the reasons behind it, then can take the best decisions, the bad developer outcome would be to do nothing which would just allow any situation like this to escalate and then reduce the options available even further.

Developers can sometimes lend their skills when it isn't related directly to their own work. There was a case of a website which had some performance issues, and the developers just couldn't resolve these without figuring out what was going on. Thankfully help was at hand when a more experienced developer was called in, who wasn't a paid consultant, to have a look and immediately identified many quick wins to improve performance along with some other strategies that could be worked on independently to help improve performance on the website. Sometimes you might have the opportunity to help with something where you have the answer immediately for someone else who just couldn't see that answer, that's what makes a good developer. If you see somewhere where you could be helpful somewhere else or at a coding club or workshop, then you should take that opportunity. Your contribution may help, or it might just help inspire someone to start their journey on the same path as yourself, nothing is lost when you share knowledge, only gained!

Another story is of a developer who was working on a project, but then another project about a new feature came up they were really interested in but were busy on the other project so couldn't work on the new feature directly. However, they did participate in group discussions along with chats about the feature. They also realised they could work on the new feature in their own time by taking an opportunity to submit a talk about it to an upcoming conference. This conference talk proved popular along with helping them understand the new feature more and discuss in person the new feature further with those working on it. However, when it came to reviewing what this developer was working on it was pointed out they had done nothing regarding the new feature! The developer pointed out the popular conference talk about the new feature but were told that didn't count as it wasn't work along with not using the collaboration tools available as they had been discussing it in person instead. This is a bad experience for anyone, often it isn't possible to work on a project directly, but some will find the time to contribute in a different way. This kind of contribution can often be unmeasured and there is value in discussions whatever the medium as not everyone works in the same way. Some people may like to talk, some may like to draw diagrams, or some may find other ways to express themselves other than using collaboration tools. Respecting these different ways of expression is an important skill as variety can add value to a team, also it is good to make sure that if there is something interesting about a project that can be discussed further this is encouraged, rather than discouraged!

Here's a story of a developer who took their experience they had gained in their own time and turned that around to their advantage. This developer was working on a project in their own time using a particular platform and had enjoyed the process and there was an opportunity to present about this at an upcoming event. They enjoyed talking about the process of creating their project along with the platform. This talk was well received, and a few people mentioned it was quite interesting to hear about the project, but one person there had need for a developer with experience of that platform and invited them for a meeting about their work. This led to that developer working for that company developing for that platform. It may not always be possible to have projects in your spare time, but you never know something you do may lead to an opportunity in the future. It is becoming increasingly more common for personal experience to lead to something more professional, something you work on in your own time may open doors you don't expect. So, if you have an idea then try it out whether it is something small that you find useful or something bigger and you never know where it may take you!

Experienced developers can help those who are less experienced but one situation to be avoided is saying something, while doing something else. In a large organisation there were some developers who were working on many different products, less experienced developers were assigned to some, and more experienced developers often assigned to the others. Those more experience developers would let the less experienced ones know what they were doing wrong, including how to do things better and generally improve their code, but you know the pattern by now, isn't this a good experience instead of a bad one? Well, it seemed so at first but as those more experienced developers moved onto other projects the less experienced developers were given opportunities to work on those projects. It was then the less experienced developers discovered many of the things that had been suggested to them hadn't been happening on those projects at the same time, which was deeply confusing! This is a bad developer experience, telling others to do something you don't do yourself doesn't make sense, it is helpful to improve the work of others but if you aren't doing that with your own work too then that can undermine any faith that others may have in what you are saying to do compared to the work you are doing. The best way to avoid this is to apply the same rules to your own work as you do with others, sometimes the best ways aren't possible but if things are consistent and fair others will understand that and everyone gets better and keeps them best at what they do, then they don't start to question reasonable suggestions or improvements that aren't backed with consistency and personal experience from those suggesting them.

Here is a story about dealing with how someone is coming across to others, we've all been there where things aren't going right, a project is going off the rails or there is some kind of issue, and you just want to bring up what is going wrong and why. However, the right approach to this is key and, in this case, they said all the right things but not in the right way so a developer on the project decided to do something about it and arrange a meeting where could discuss how the issue was raised but to point out that despite the way it was said being wrong they were right but they didn't need to quite put it like they did! Sometimes as developers or in other roles you might need to do something about an issue above your level and it is how you decide to deal with these is what matters, that issue was resolved and as it turned out later the project was cancelled in the end which fully resolved the issue. However, this was a decision that should have been made in the first place and would have avoided any confrontation and that is probably how it should have been dealt with!

There was a story of developer who started a new position as a C# developer working on website that would be interacting with an IoT device. However instead of this it turned out to be a Windows Forms application parsing documentation into something useful that written in Visual Basic, nothing like the work that they expected to be doing! Sometimes the bad experience can be things that aren't quite what was expected. Hopefully most of the time expectations and reality match in a position but when they don't then you can see what the best option is which could be looking elsewhere or should it be something more interesting instead than expected then you can stay, explore, and maybe learn something new!

Becoming a good developer can happen even if you feel that isn't you right now. There was a developer who started in a company with the basic skills and knowledge for the role but with none of the domain specific knowledge. That developer worked on many parts of the systems the company produced and slowly learned them, which of course included getting help from others. That developer gained more and more experience along with domain knowledge and started to answer questions of others, and with that grew in confidence. Over time this developer became the person to ask about various issues which would be either be answered or would point people in the right direction, just like many of the other good developers I've talked about. That developer also helped other non-developers to learn some of the development skills they needed in their role along with mentoring and helping others, basically hitting all the notes of a good developer as well as helping others on their path to becoming a good developer. You don't have to have all the skills or more to be a good developer overnight, you can build upon small moves on that path and the bigger ones will happen in time. If you don't have anyone like this in your team or company then be that person, you might just be the spark that lights up the whole team and company to follow your lead.

Here is a story is about a developer who worked at a company that although they had more content for the company website from when they started to when they finished working there, the company somehow lost progress on development! The reason for this was the company kept changing their minds on what to do or the other developers would decide to replace work they had already done to improve it. However, there was no coordination with the work, and the website became bit of a wild west. Without direction, any project can go wrong, but if things aren't running correctly then you could start running away, but if it can be overcome then can try that first but if not, you can always go back to the other option and run!

Good developer stories often don't stand out as much as bad developer ones, everyone has probably worked with or been someone who has done many good things in their role or helped others to do the same. This can be small with figuring out a problem with someone else or it can be something big where they inspired a team or encouraged others to improve their skills and learn. They may even share what they have learned with others to continue the chain of good developers, testers, managers, or any other role! Luckily the good things whether they be small or large often outweigh the bad things!

It isn't just developers that can be a bit bad sometimes, it can happen to testers there was a case of a team who were reviewing some failing tests and were dividing those amongst the other testers. When the team had a meeting to go through the fixes that had been performed to get the tests to pass, one of the testers said as their tests were failing, they had added the ignore attribute to make them pass! Well, I guess they were right an ignored test never fails but it also doesn't test anything either, although if you think about it, when it comes to failing tests that's a developer's job to cause, but sometimes an out-of-the-box idea or solution can work, but just not that one!

Summary

I'm grateful for all the stories from colleagues and others I had heard about that added to those I knew of or had experienced myself. Whether you are a developer, tester, manager, or anyone else you'll encounter people with bad traits, but it is those good traits that offset the bad. Even if something bad happens it is how you deal with it that matters and when doing something good you never know the impact it may have! You could help inspire the next generation who will continue to pass on the good traits and help reduce the bad ones, but hopefully there are very few or none who are wholly bad. However, if you do encounter anyone bad, then best the way to remove their power is to be good! Good and Bad Developers is something I also covered in my short talk “How sharing can make you a better developer for Scottish Summit on YouTube where you can also see other talks at youtube.com/@ScottishSummit or check out the link in the show notes.

Outro

Thanks for listening to the RoguePlanetoid Podcast where each episode you will find insights about Microsoft or related platforms and technology, along with so much more wherever you listen to your podcasts or at rogueplanetoid.com/podcasts for the RoguePlanetoid Podcast whether you are a beginner or an experienced professional or just interested in technology. Keep Current, Keep Coding!