10 more things professional software developers do

Since my last post about 12 things I believe professional software developers should do, in August, I started to take note of other behavior, skills, and characteristics I like or miss in the people I run into while working on complex software projects. Next to that, I received quite a few suggestions through Twitter. So let's discuss some more of these.

They don't write code for themselves
A very common response I get when I ask an experienced developer to refactor some long method is that they have no problems reading their own code. It gets even worse when you work with one that is interested in functional programming and who loves to write pages of nested lambdas calling other lambdas. Just search for some OWIN middeware code and you'll get my point. When a told a guy like that about my objections, he responded by saying that his code was meant to be maintained by the best only. I guess there might be some code out there that requires special skills to understand, and extracting that in a separate component is probably wise. But I still believe that high-quality code starts with accepting you're not alone.

They do not cherry-pick the fun work. They do what needs to be done.
A very common situation is to see the technical lead in the team do all fun and challenging work and delegate all the repetitive work to the 'common folks'. Although the tone in that is wrong, it's not that surprising to see. The lead probably became the lead because he's proven to have great skills in adopting new technology within an existing code base. He's probably the best guy to analyze the hardest problems as quickly as possible. But I don't think it's a surprise that this attitude is not the best for the team's morale nor for knowledge sharing.

If I look at my current role as lead architect, I'm sure I've been guilty of this myself. But next to an occasional 'fun' spike to prepare some work for the team, I regularly fix quite a lot of hard bugs, both in the development pipeline as well as those reported by clients. These tend to be ignored by teams because they are difficult to reproduce or because they are not directly related to the work they are doing. If I believe these need structural fixes (rather than patches), and my team members are occupied, I pick them up myself, even if that keeps me from working on the fun stuff.

They work hard to share their knowledge with less experienced developers.
Some would say that knowledge is power, and at first, it may sound like a good idea to be the one who has all the knowledge. But with great power comes great responsibility (yeah, I know, it's cheesy), the responsibility to share that knowledge with the less experienced developers. And I'm not talking about showing them how much you know. No, you need to make an effort to explain them how you think, how you approach complex problems, where you get your information, how to structure their work, who to talk to and for what topics. I'm quite an impatient person, so I sometimes have to make an effort to really explain how I came to a certain conclusion. Being able to do that, makes a world of difference. It's not the specific knowledge at that point of time that counts for them, it's the process on how you got there.

They can place themselves in the feet of less experienced developers.
This is something different than sharing your knowledge. The point here is to be able make decisions that take into account the lack of experience of your fellow developers. Just assuming that they will understand is not enough. One example is to overwhelm them with technobabble. Even if they do appear to understand what you’re saying, try to get some confirmation by asking the right question. They might be afraid to tell you they don't know something or are just overconfident. But don't ask questions like "Do you understand what I mean?". Instead, ask questions like "Is there any part of what we've just discussed that require more clarification?", or "Did I miss anything?". These are open questions that might put them at ease. And once again (I'm now talking to myself) , be patient…

They give credits to those that deserve it
In my opinion, one of the most annoying habits a software developer, architect or anybody else in our profession can have, is to pretend he or she came up with an idea themselves. If I post an interesting article on Twitter, I'll try to include the Twitter handle of the author. If I got that article through somebody I know, I include a "via @whoever". This is my way of saying thank you to the author or referrer. I do the same in my blog posts. For instance, I learned a lot about OWIN from my colleague Damian Hickey. Similarly, Yves Reynhout has been my go-to-guy on Event Sourcing and Domain Driven Design. Even the reboot of my blog was inspired by the book Soft Skills by John Sonmez. Within the scope of a client, I try to give credits to individual developers in our internal blogs or FlowDock discussions. And that is particularly important for the confidence of less experienced developers. Being appreciated for an idea or an accomplishment can make a world of difference.

They adhere to coding conventions
It should not come as a surprise that I'm a strong advocate for coding guidelines (or standards if you will). I've been involved in these for years, and in the light of the points I've discussed above, I still believe they are very valuable. They don't exist to annoy developers or restrict them in their creativity. Instead, they are there to help them to prevent making common mistakes, promote object-oriented development and ensure a code base with consistent naming conventions and layout. Some architects believe that each component or project should be able to define their own conventions, but I don't agree with that. In reality the same people move from one project to another so consistency between different code-bases can be very helpful. And between the two of us, I'm pretty sure they don't agree with me because they want to use their own conventions…

They know that not every problem is a nail if they have a hammer
It's incredible how often you read about some new technique, framework or library that is supposed to solve all your problems. I still remember when KnockoutJS was introduced. Then AngularJS came along as the ultimate client-side framework. And now we have Facebook's React. No single tool, framework or library will solve all your problems, nor will it solve a specific problem in every situation. Exceptions such as Git or OWIN exist and they have had a profound effect on the way we build software, but be realistic. Just make sure you understand the added value of such a solution, e.g. the context it applies to, the situations where it is a no-go, and keep an eye open for alternatives.

In general, you may notice a pattern whenever something new pops up. At first, you treat it as another solution to the same problem, and kind of refuse to use it or see its added value. Then you start to get excited about it, you notice you're telling everybody about it, and it turns into that well-known hammer. In the next phase, all problems become a nail on which you can use your new shiny hammer. You try to use it everywhere, simply because you haven't figured out yet the limits of the technology. But there light at the end of that tunnel. Eventually, you learn where and when that new thing is the right thing to use, and when not. It becomes just another tool in your toolbox. This is where you become effective. I'm pretty sure this pattern has been coined by somebody, but I can't recall the name of that person anymore. If you do, let me know.

They are not afraid to share their accomplishments
So you've been working on some awesome project for a couple of months and it's supposed to be a next-level foundation for some other project or product. Now is the time to share your work and do a bit of (internal) marketing. Being able to effectively 'talk' about your accomplishment is just as important than building the thing in the first place. The worst thing that could happen is that your beautiful shiny new toy is not going to be used by anybody, simply because you failed to create awareness. And you don’t need to necessarily do a formal presentation to a large audience. Instead, you could ask for feedback in some kind of demo session. Or you could write a couple of (internal) blog posts about it, including a similar invitation. Heck, you could even ask somebody else in your team to do that part of the work for you. The point is, sharing your work is a crucial part of your profession.

They refrain from criticizing the status quo until they understand its nature and history
One of the biggest mistakes I think I've made is to join an organization and criticizing the way they did their work or build something in a certain way without really, really understanding how they ended up that way. Since then, I've learned that people generally try to do the best they can under the circumstances they're in. So if they made decisions that you disagree with, consider the fact that it might be more than just lack of experience. I didn't realize this until I was the one being criticized (or to be more specific, my work was, not me personal). In some cases, your criticism might be correct and changes are needed. But in a lot of other cases, they might have made plans to the take right actions, but those got side-tracked by project or commercial pressure. Even worse, they might got overruled by management that quite often doesn't really understand why software development involves more than just adding functionality.

They think by themselves
A blog post that is about how you should behave but tells you to think for yourself. Ironic isn't it? But I concluded this post with that on purpose. There are so many people in our profession that tell you how to behave, how to code, how to design, what practices to use, or what technology to use. So even though I really believe the 10 things mentioned here represent the habits of highly effective professional software developers, it's up to you to decide whether to agree or not. I just hope I made you (re)think about your own habits and how you participate in your profession.

So what do you think? Does this resonate with your opinions as a professional software developer? Did I miss anything? Do you object with anything I said? Let me know by commenting below. And follow me at @ddoomen to get regular updates on my everlasting quest for better solutions.