Robert Martin defined "Professionalism" in the context of "professional software engineering" as the "disciplined wielding of power". You can catch the talk at a ruby conference in 2009 which is called "What killed Smalltalk could still kill Ruby". You could substitute "Delphi" or "Your Career" in place of the word "Ruby" there, if you think that having Ruby in the title of the talk means that anything in that talk is unapplicable to you, Delphi programmer. If you think that your use of Delphi makes you immune to the ill fates that befall other developers, other teams, using other languages, then you have the very disease at the heart of Bob's talk, and you are exactly the person who needs to watch the video here.
About 42 minutes into the talk, he switches from a passionate cry to developers to commit to test-driven development practices, to talking about Professionalism and gives the definition about "disciplined wielding of power". It's excellent, and I agree with everything he says.
I would like to give my definition of what a software professional, a member of a team, large or small, or even a single developer working on his or her own, should be doing, if they wish to be a consummate software Professional.
I would also like to hear your professional credo, if you have one. All of this presupposes, I think, that we are people motivated not purely by money, by power, by position, by a search for comfort and material things, but rather, motivated equally by a desire to do a job well, to do something that is objectively Good, worthy of the limited time we all have to do what we choose with. In the long run, we are all dead. So why are we doing any of what we do? I would say that to do a thing well, to do it professionally, as your career, your vocation, your job, from 22 when you graduate college, until you retire at 65, or leave this life, means, I hope that writing software is something you do because you love it, and you want to do it well.
Here are my five cardinal rules. Yours may be different. Mine flow from a common core conviction that everything I do has a moral component, and that I will be ultimately happy if and only if I do what is objectively morally good. Why I think that, is off topic for this blog. But the fact that I do think that way is what illuminates and ties together the five points of my personal credo as a software professional:
1. Do the work you get paid to do. I am a professional. Part of the meaning of that word is that I get paid to write what the people who pay me tell me to write, and I build it according to their rules, conventions, styles, and preferences. When I'm finished, I got paid, and I got the satisfaction of doing a job well and they own what I built. I respect their intellectual property rights. I don't steal, and I don't dissemble or delay. I also keep my employer's trade secrets and source code private. I also believe that wasting a day that I got paid to do software by doing nothing is stealing, and so I don't do it. When I'm out of ideas about what to work on next, I ask what I should do. I try to work on the most important stuff first, so that what I do in a day moves the ball forward as much as I can.
2. Tell the truth, and shine light, even when it's uncomfortable, but be kind to people, when you choose how to speak that truth. I try to be honest. I mustn't ever lie. I also try not to blame people. I try to take blame, accept responsibility. If I work in a team, either as leader or senior developer, I try to absorb blame and share praise. If someone praises me I'm likely to mention what another person provided that helped me. This helps me to work with other people, because they know I will accept responsibility for mistakes and will not throw a colleague under the bus. I also won't make up stories and try to lead people on merry chases, when they try to figure out what's going on in a project milestone, a team meeting, a product review, or a coding task or a bug. Lies can include omissions. Leaving something out of a commit comment could be a form of lies. I think that humility and honesty are only possible in tandem. When I become proud, and arrogant, which I sometimes do, because I am only human, it is the desire to be honest that helps me pop the bubble of pride. When I am able to be humble, I find that my conscience prompts me to mention things that are less than flattering. For example, "I fixed this bug, but I am worried that there might be a side effect and I don't know how to prevent this side effect, but if I tell someone now, I think it might be better to discover the side effect now, rather than try to hide the fact that I may have created a bug with this bug-fix, and I don't want people to blame me".
3. Model and reflect moral Goodness, and presume good will in other people. I try to expect the same virtues from other people, that I expect of myself, and if I do not see that happening I try to privately, and positively, encourage the behaviours in others that I expect in myself. I find it is possible to encourage fellow developers by modelling my willingness to accept blame, but not attacking people ever. If I see someone attack a person, instead of attacking a problem, or doing something that is making an issue personal instead of professional (we should fix this issue, versus, you are bad, and should feel bad, because you made a mistake or didn't realize that this is bad) I try to encourage a return to objective, practical solution of the actual problem. I try to preserve good will because it's very hard to get it back when it's gone. I think teams need good-will and goodness to each other even more than they need technical competence, and by gum, they need technical competence too.
4. Achieve technical mastery the only way it is ever achieved, by lifelong learning. You don't know everything, and neither do I, and even what you do know today, you will forget tomorrow. I don't know jquery. I don't know Big Data. I don't remember very much X86 machine language anymore. And you know what? I don't have to. The most important technical skills I have are how to learn something new, and how to bisect problems until I find their root causes. With the ability to learn new things, learning is a joy instead of a burden. If you don't like learning, and you don't like bisecting technical problems until you find the root cause, you chose the wrong career, my brother or my sister, I suggest you find another.
5. Follow the Boy Scout rule, even if you're a girl. Be sure at the end of the day that you leave the world you lived in, the job you worked at and the codebases you contributed to better after you worked on them, than before you worked on them. Bob Martin calls this the "Boy Scout Rule", referring to that "leave the campground cleaner than you found it", but pointing out that the "campground" Baden Powell was referring to was actually the whole world we live in. I think that the real Professional looks at the ends and the means, the goals, and the values involved in all the work he or she does, and asks "am I comfortable with this, is this the best we could be doing, and are we doing this the right way?". If I got paid to make a mess, and to contribute to a project or a company failing completely, I do not obtain any sense of wellbeing or personal pride of a "job well done" from that. I wish to do good, to be part of a team that does good, and which builds not only economic value for my employer, but also contributes to the complete wellbeing of the team, the company, its customers, and the wider world around me. This is all part of being a good human being.
Why do I share this with you? Because I want to do something with my life that is good. I want to be worthy of what I get paid, and more. I want to be the kind of person who anyone would hire, and hire again. Don't you? What do you think? I welcome your thoughts. Do you ever reflect on the meaning, and purpose of your life as a software developer? Because I do. Am I crazy for doing that? I think it's crazy not to do that.
Software development is not a profession in the sense that Medicine, Law, and Engineering are professions. Not yet anyways. But if we can learn how to become professionals, it will be good for everyone in the world. Even if the software you write doesn't cause airplanes to fall out of the sky, or accidental acceleration of your Toyota Corolla when it fails due to a lack of tests and testing, there are still many other good reasons to be a Professional who cares about the whole quality of the enterprise we are engaged in. That means caring about TDD, or any other thing, if and only if, it leads to the desired goal; To do good things, to do them well, and to be responsible in the use of the tools and the time we are given.
About 42 minutes into the talk, he switches from a passionate cry to developers to commit to test-driven development practices, to talking about Professionalism and gives the definition about "disciplined wielding of power". It's excellent, and I agree with everything he says.
I would like to give my definition of what a software professional, a member of a team, large or small, or even a single developer working on his or her own, should be doing, if they wish to be a consummate software Professional.
I would also like to hear your professional credo, if you have one. All of this presupposes, I think, that we are people motivated not purely by money, by power, by position, by a search for comfort and material things, but rather, motivated equally by a desire to do a job well, to do something that is objectively Good, worthy of the limited time we all have to do what we choose with. In the long run, we are all dead. So why are we doing any of what we do? I would say that to do a thing well, to do it professionally, as your career, your vocation, your job, from 22 when you graduate college, until you retire at 65, or leave this life, means, I hope that writing software is something you do because you love it, and you want to do it well.
Here are my five cardinal rules. Yours may be different. Mine flow from a common core conviction that everything I do has a moral component, and that I will be ultimately happy if and only if I do what is objectively morally good. Why I think that, is off topic for this blog. But the fact that I do think that way is what illuminates and ties together the five points of my personal credo as a software professional:
1. Do the work you get paid to do. I am a professional. Part of the meaning of that word is that I get paid to write what the people who pay me tell me to write, and I build it according to their rules, conventions, styles, and preferences. When I'm finished, I got paid, and I got the satisfaction of doing a job well and they own what I built. I respect their intellectual property rights. I don't steal, and I don't dissemble or delay. I also keep my employer's trade secrets and source code private. I also believe that wasting a day that I got paid to do software by doing nothing is stealing, and so I don't do it. When I'm out of ideas about what to work on next, I ask what I should do. I try to work on the most important stuff first, so that what I do in a day moves the ball forward as much as I can.
2. Tell the truth, and shine light, even when it's uncomfortable, but be kind to people, when you choose how to speak that truth. I try to be honest. I mustn't ever lie. I also try not to blame people. I try to take blame, accept responsibility. If I work in a team, either as leader or senior developer, I try to absorb blame and share praise. If someone praises me I'm likely to mention what another person provided that helped me. This helps me to work with other people, because they know I will accept responsibility for mistakes and will not throw a colleague under the bus. I also won't make up stories and try to lead people on merry chases, when they try to figure out what's going on in a project milestone, a team meeting, a product review, or a coding task or a bug. Lies can include omissions. Leaving something out of a commit comment could be a form of lies. I think that humility and honesty are only possible in tandem. When I become proud, and arrogant, which I sometimes do, because I am only human, it is the desire to be honest that helps me pop the bubble of pride. When I am able to be humble, I find that my conscience prompts me to mention things that are less than flattering. For example, "I fixed this bug, but I am worried that there might be a side effect and I don't know how to prevent this side effect, but if I tell someone now, I think it might be better to discover the side effect now, rather than try to hide the fact that I may have created a bug with this bug-fix, and I don't want people to blame me".
3. Model and reflect moral Goodness, and presume good will in other people. I try to expect the same virtues from other people, that I expect of myself, and if I do not see that happening I try to privately, and positively, encourage the behaviours in others that I expect in myself. I find it is possible to encourage fellow developers by modelling my willingness to accept blame, but not attacking people ever. If I see someone attack a person, instead of attacking a problem, or doing something that is making an issue personal instead of professional (we should fix this issue, versus, you are bad, and should feel bad, because you made a mistake or didn't realize that this is bad) I try to encourage a return to objective, practical solution of the actual problem. I try to preserve good will because it's very hard to get it back when it's gone. I think teams need good-will and goodness to each other even more than they need technical competence, and by gum, they need technical competence too.
4. Achieve technical mastery the only way it is ever achieved, by lifelong learning. You don't know everything, and neither do I, and even what you do know today, you will forget tomorrow. I don't know jquery. I don't know Big Data. I don't remember very much X86 machine language anymore. And you know what? I don't have to. The most important technical skills I have are how to learn something new, and how to bisect problems until I find their root causes. With the ability to learn new things, learning is a joy instead of a burden. If you don't like learning, and you don't like bisecting technical problems until you find the root cause, you chose the wrong career, my brother or my sister, I suggest you find another.
5. Follow the Boy Scout rule, even if you're a girl. Be sure at the end of the day that you leave the world you lived in, the job you worked at and the codebases you contributed to better after you worked on them, than before you worked on them. Bob Martin calls this the "Boy Scout Rule", referring to that "leave the campground cleaner than you found it", but pointing out that the "campground" Baden Powell was referring to was actually the whole world we live in. I think that the real Professional looks at the ends and the means, the goals, and the values involved in all the work he or she does, and asks "am I comfortable with this, is this the best we could be doing, and are we doing this the right way?". If I got paid to make a mess, and to contribute to a project or a company failing completely, I do not obtain any sense of wellbeing or personal pride of a "job well done" from that. I wish to do good, to be part of a team that does good, and which builds not only economic value for my employer, but also contributes to the complete wellbeing of the team, the company, its customers, and the wider world around me. This is all part of being a good human being.
Why do I share this with you? Because I want to do something with my life that is good. I want to be worthy of what I get paid, and more. I want to be the kind of person who anyone would hire, and hire again. Don't you? What do you think? I welcome your thoughts. Do you ever reflect on the meaning, and purpose of your life as a software developer? Because I do. Am I crazy for doing that? I think it's crazy not to do that.
Software development is not a profession in the sense that Medicine, Law, and Engineering are professions. Not yet anyways. But if we can learn how to become professionals, it will be good for everyone in the world. Even if the software you write doesn't cause airplanes to fall out of the sky, or accidental acceleration of your Toyota Corolla when it fails due to a lack of tests and testing, there are still many other good reasons to be a Professional who cares about the whole quality of the enterprise we are engaged in. That means caring about TDD, or any other thing, if and only if, it leads to the desired goal; To do good things, to do them well, and to be responsible in the use of the tools and the time we are given.
You forgot the best rule of thumb: KISS or Keep It Super Simple (I don't like the other means ;-)
ReplyDeleteYou have put this very well. I think the lack of comments reflects general agreement with what you have written. I couldn't think of anything to add. Thank you for writing it.
ReplyDeleteGood set of principles that apply equally well to life in general as they do to the work place.
ReplyDeleteSpeaking professionally, I especially appreciate #4. I make a point of attending at least one training course or technical conference per year. Even ones that aren't directly related to what I'm working on right now. I think I'd like to attend a Ruby conference. These guys sound like fun.
Are familiar with code katas? If so, I'd be curious to hear your thoughts on them.
One other practice I have adopted is that I work very hard for opportunities to be lazy. Whether it's finding a better/faster/easier way to do something or to automate it completely, freeing up time to do more interesting things.
Code Katas strike me as a way of "pedaling a stationary bicycle" in code, I would rather build something useful. There are so many little tools or utilities that would be really useful, or little apps that you could use to get something done. When I am learning something totally new like Pharo, I usually like to try to do simple things which are kind of like Katas. I will try to load a file from disk, parse it, and output it to another file. Try to find the equivalent for common everyday operations everybody needs. But as a tool to practice so you can get better at something, the idea of disposable "exercise" coding leaves me cold.
ReplyDelete