My thoughts on your responsibility as a software developer

Intro, Software is everywhere

So much things in the world today is based on software. It's very hard to find any industry or area in life that is not affected by software. We have somewhere around 9 trillion devices in use today, devices that people use for insurance, health, socials, emergency, entertainment etc. Devices that fundamentally changes how people live their lifes.

Currently (as of 2019) there are an estimated of around 23 million developers worldwide that craft code day in and day out. It would be fun to see how many lines of code that are produced each day. I think that even though software becomes legacy and eventually "dies" and are removed from the market, we'll still increase the number of programs running in the world for quite a few years more. Since software is everywhere, it indeed makes sense to try craft the code with quality. Because really, who wants a friend to die because the software in the Uber's self-driving car decides to ignore your friend on the street? There's plenty of death examples caused by software.

My job is just to write code!

So what does all this have to do with responsibility? I feel that it gets more and more rare to meet responsible developers. It's easy to find tech-junkies, people comparing frameworks day in and day out, talking about database techniques or optimizing a LINQ query without even knowing where the performance bottleneck is. Every day people have dialogues about what programming language is the best to use. But in the end - is the language or framework really that important? On a high level, I get a feeling that we are getting so comfortable with our work that we're starting to underestimate how hard it actually is to write good code. And we're forgetting that software without a quality focus have a direct impact on other peoples lives. People might not necessarily die, but sure they can have economic losses or feel stressed/depressed. Some examples;

• When no notification is sent to you on your phone when you should take your medicine, you potentially can suffer a lot.
• When no invoice is being sent to you, it can screw up a lot for you if it happens during a time in your life when everything else already sucks. In these moments it's important that you can trust your bank. You cannot afford crappy software too, since most things in life suck at the moment.
• When you order 2 pants but they charge you for 10 then that's not a very nice feature.
• When you upload "private" pictures to your own account, but there's a bug so they can be seen by others, that's not a very fun experience.
• When your children are home alone it's not fun when the oven all of a sudden starts and goes to 250 degrees celsius and does not turn off, because the manufacturer has a bug in their platform so your oven activates instead of your neighbors. This is not just about bad software anymore - we're talking about lives here.

People rarely craft bad code with intention, that's not the issue here. The issue is that developers do have a responsibility in what they produce. And one of the things we are responsible for is the way we act as individuals. There's a lot of things we cannot control in life, but we can control our reaction and intention and what we do and how we act.

Examples of irresponsible behavior

Let's see a couple of examples or scenarios which are very common. The interesting part is of course how we respond to these scenarios and how we behave (it's very easy to be a code junkie and do the blame game). Let's consider the follow statements (and my reflections of them in bold):

"I'm done now with my part, now you'll do yours" Depending on your context, teamwork is not always a waterfall process, from one guy to another. What about instead asking your colleague if you by any way can assist with their stuff too now that you're done?

"It's your fault, not mine" Classic blame game. Who cares anyway who's fault it is? You shall together build a great product, and that's what matters. Irresponsible developers with low self esteem blame people, whereas responsible developers take account on what they've caused and focuses on solving problems.

"<being silent... hoping no one notices me>" If there is any act of comfort and laziness, this is it. How fantastic isn't it when people go silence and ignore the stuff that don't appeal to them. The worst thing with this that they don't realize is that it put more effort/burden on the rest of the team. Responsible developers speak up instead (in a constructive way).

It's so much about attitude. That's how a person not behaving professionally speaks.

Examples of responsible behavior

So consider on the other hand how a responsible developer talks:

"I don't know how to solve this. Me guessing won't help you. Let me forward your question to a colleague that I think know the answer." I.e. Admitting what you don't know increases trust towards you. No one is perfect, and neither is you. Responsible developers continually learn new stuff, and hence have little problem with admitting their weaknesses. They know they'll learn it anyway one day.

"We're too busy at the moment and won't have the time for what your asking. We cannot give you a date either because there are too many uncertain parameters at the moment." No responsible developer makes other people "hope" the future will be wonderful. We know we don't have time, and that's what we must tell. This is one of the ways you build trust. People will enjoy working with you when they realize you'r not saying "no" because you can, but because you care.

"I'll fix this bug and spread knowledge about the solution if you're interested to hear about it. Please do review my code and give feedback, however I take responsibility for that it actually works and I have tested it, that's not your job." Take responsibility for the code you write. Who would ever want to be on a battlefield where one person picks up the gun and fires, and the other are responsible that you hit the target? Everyone writes bad code from time to time. Even professional developers. The difference is that responsible developers can take feedback. Irresponsible developers take feedback very personally and feel a sense of criticism towards them, rather than a way to learn new stuff.

Of course, if you think about it, most of this applies to any role in your team. Trust is something beautiful, it's what make you leave the office with a relief knowing that your colleagues always got your back. It's beautiful when people acknowledge their lack of skills, and it's annoying when people tend to never admit that they don't know something when all they have to say "hey guys, I must read up on this because currently I know too little, and I cannot make a good decision as of now".

Think about it; what would you prefer? Someone who refuses to admit they lack the required skills for the task, or someone who would step up and say "sorry but i'm a bit stressed about this, is it okay if I take the day off and read up on these internals? I think I can handle these similar cases well better in the future then". It's obvious that most people would pick the second person for their team. That's responsibility.

Why responsibility matters

I think one of the best reasons that responsibility matters is because it's the foundation of building trust towards your colleagues. And I think this quote by Simon Sinek summarizes it well:

A team is not a group of people that work together. A team is a group of people that trust each other.

Who would ever want to work with someone that doesn't take responsibility for what they're doing? You cannot trust an irresponsible person. You might like them, because they're your friends, but it's not the kind of person you would build a strong team around. Teamwork is key to success, and trust is a vital part. You can be a rockstar developer in the short term by you own, but not in the long run. You need people around you for that. People that you have mutual trust with.

I'm not saying

I'm not saying "Our teams must be better and we need better QA to deliver great features".
I'm saying that developers need to realize that QA is not a person, and take more responsibility themselves to deliver working features. QA isn't there to catch easy bugs. QA should be hard, trying their best to find bugs but rarely doing so. We want them to really try hard to find bugs. I shouldn't have to say this - but when the minimum criteria of a task (or acceptance criteria) isn't even working properly but you've marked it as "ready for QA", that's when you as a developer should seriously ask yourself why you care so little, and then do something about it.

I'm not saying "write a few lines of code and let someone catch errors in the pull request (PR)".
I'm saying that whoever reviews your code should do it with pleasure. They know that since you wrote the code, it's crafted with well intention and does work. They  should know that you have tested locally and written all relevant unit tests and that they pass. Whoever reviews your code should feel like you really did care when you wrote it, and you took a reasonable approach towards boy-scouting and fixing old crap. From time to time even your PR's will look bad - and that's fine, it happens everyone - but overall, they'll be good and crafted with a clear intention solving a real problem.

I'm not saying "you as a developer must take more responsibility in every area".
I'm saying that you should commit to fewer features and ongoing tasks, if you already feel overwhelmed. People understand and have great compassion when others have a hard time, as long as you're honest about it. Commit to one or a few things and craft them well. You'll most likely learn more, feel healthier, and people will trust you more because you get things done.

Summary

Sure it might be fine to write really sloppy code sometimes. That will be up to you to decide when to do that. Maybe it's a tool just for you. Maybe a tool or site just for your team. But generally speaking - when building something for real customers and users - software deserves to be written with intention and quality in mind. We want software to empower us, not make us scared or feel insecure.

So have fun. Learn to say no. Enjoy building great products. Enjoy working with your teammates. And take responsibility!

... Software and biology, the future

If you're still not confident that responsibility is wonderful and we need more responsible developers, then take a step back again and see where the world is going. Software for the last decade(s) have been all about things external from our bodies. Physical things that are biologically separate from our bodies have software, like an iPhone, or a smartwatch. But that will likely change too soon. For this reason it's even more important we have more responsible developers. When software and biology "merges", you'll want to be damn sure you minimize the number of bugs. If you haven't yet (and have some time over) watch this video with Ray Kurtzweil on "The Future". It gives a hint of what the future might consist of. And Ray is not just a random guy, he's pretty respected for his knowledge.