This will be a short blog post - shorter than my usual posts anyway.
I'm excited about some things. First, work is great. They day job has the usual interesting challenges and problems that any day job has. The team I am working with though is great and works together very well. The most cool part with them is they are constantly looking to learn, try and apply new approaches. This makes dealing with challenges that appear much less painful and more rewarding that they might otherwise be.
Second, there is a conference coming up. I know, conferences are everywhere these days, right? This one is different. This one is focused on testing in an Agile environment. Logically enough, it is named Agile Testing Days. The 2016 edition is occurring in Potsdam, Germany THIS DECEMBER! Yeah - if you have never been to Germany just before Christmas, this is a bonus! Conference is astounding. The host city is astounding. Environment is astounding.
Best part of this conference though, when you strip away the "Ooooooh! Look! Fun activities and cool stuff!" and look at the core of the conference it self - Look at the people. There are some fantastic speakers - recognized experts who are talking about ideas and what they actually do and use in their day-jobs. There are practitioners talking about what has worked for them - and what has NOT worked for them. There are people who are attending the conference who are willing to discuss ideas and ask questions and grab a corner and debate an idea into the wee hours.
There are people from all over the world attending, participating and deeply engaged.
If you are reading this BEFORE 3 October, you can get the Early Bird discount. If you miss the window for the early bird, and you still want to go (and the conference is not over!) leave a comment and I'll see if I can still get you some level of discount.
I'm going to be there. I'm going to be speaking. I would not take the time away from my work - my day job - for a week and travel to Germany if I did not think I'd be learning something of value. I've been there several times and always come home with something I can use at work the first day back.
I bet you will too.
Monday, September 26, 2016
Sunday, September 4, 2016
On Ego and False Dichotomy
I apparently have a memory that stretches back to the dark ages. Aside from my now-23 year old grandson asking me what King Arthur and I talked about when we had lunch (he was 5 or so at the time) a fair number of my younger colleagues firmly believe that my start working in software, on mainframes, with COBOL and RPG and JCL and other arcane (to them) things must mean I have been working with software shortly after code was written by hammering 1s and 0s into stone tablets with a hammer and chisel.
My response? "Not quite, but close.Not as old as dirt, but I do remember when fire was a new-fangled idea."
Really. I've used that recently. This last week.
I wonder if anyone else remembers the "dark ages" where "programmers" talked with people outside of tech? You know, like, people who would actually USE the software being worked on? People who were currently using it and had an idea that might make it better? You know, an "enhancement"?
I wonder if anyone else remembers the "dark ages" where "programmers" talked with those same people and figured out things like "requirements" and "expectations" and when pieces might be available, if not the whole thing
I wonder if anyone else remembers the "dark ages" where "programmers" looked at application and system models and did the design work for how their changes, the ones they talked with non-tech people about, would fit into the whole scheme? Like, did the design and architecture work?
I wonder if anyone else remembers the "dark ages" where "programmers" looked at file systems and databases and came up with solutions that would work for their needs and not step on the toes of any other systems or the people who used them.
I wonder if anyone else remembers the "dark ages" where "programmers" figured out how to test the software they made? Figured out what the expected behavior was and how to handle situations that would, almost certainly arise when something went hay-wire or "pear-shaped." (Yeah, that is still kind of my favorite euphemism for SNAFU.) Or how about, worked hard to find faults in their presumptions?
I wonder if anyone else remembers the "dark ages" where "programmers" sat down with other programmers and worked with each other on their code? Where they went beyond "I'm stuck" and looked at "is this the best way?" Where they reviewed each others code to look for potential problems or inconsistencies - like weird variable handling or dangling If-Then constructs - or worse - random periods - dots - that might get missed?
I wonder if anyone else remembers the "dark ages" where "programmers" carefully worked out what data they needed to test with before running the first test? What conditions they needed to meet and what combinations they needed to cover - and how to cover them?
I wonder if anyone else remembers the "dark ages" where "programmers" had other "programmers" look over their shoulder as they were running tests to help them see if they missed anything?
I wonder if anyone else remembers the "dark ages" where "programmers" worked with other "programmers" before testing the work of those other "programmers"?
I don't remember when this all changed.
It was gradual. It seems like it was getting tweaked and nudged and "improved" for some time. Before long, there was "designers" and "architects" and "business analysts" and "developers" and "testers" and... yeah. Next thing I knew, people needed special treatment. They were "specialists" in something. It seems that some needed to feel "special" - more "special" than others that were not as cool as them.
People began not talking to each other so freely - or at least not as colleagues - equals. People who were "testers" seemed less at-ease to talk with "developers" as equals. Instead of working towards solutions together, they saw themselves as part of a hierarchy - a pecking-order.
There were extremely formalized models to developing software that were put in place - models to prevent people from working together (as far as I could see.) Some were focused on "maximizing individual skills" and "reducing distractions," as far as I could see then, and still see, they were about asserting power and control.
People began to see their work as more valuable than the work other people did. They felt, possibly believed but I find most beliefs to be reassured/asserted feelings, they were better than those "others" and had greater skills than those "others" and so were worth more to the company than those "others" and so they deserved to be paid more than those "others."
This was also about the time I began noticing there were fewer women working in software shops than there used to be. I don't know if they left because they got tired of dealing with jerks or is they simply had found something better to do. I suspect one led to the other.
I began seeing more "frat-boy" behavior on teams I worked with. Behavior that would have gotten you fired a few years ago was now the norm. I did not stick at those shops very long. I apparently was not a "cultural fit." So I quit or was transferred to another team of "old people."
At the time, I was not sure what was going on. I did not like it very much. I spent my time honing skills I saw were missing in many of the "developers" I worked with. I became good at testing. I became a "tester."
A rebellion started.
People began looking for "rapid software development" and "light development methods" and ways to make software get written and developed faster, without the huge overhead imposed by the control and power folks.
I remember reading articles, then a book, on this new cool approach called "Extreme Programming."
Then I remember reading about this cool newness called "Agile." At the time, I shrugged. I still kind of shrug, frankly.
I'd seen too many "hot trends that would revolutionize software development" come and go.I did my job to the best of my ability and helped other people work better.
Then some folks got the idea that "Agile" might really be a thing. There were suddenly loads of books and papers on it. There were people talking about the "whole team" being responsible for "quality."
Whatever. For some of us, that had been the way we worked years before. Back in the "dark ages."
Now, don't get me wrong. Back in the "dark ages" there always were "programmers" who wrote code pretty well, but were better at designing solutions or figuring out file systems and structures or looking for ways to exercise the software. Everybody was expected to do some pieces of all of this - and everybody was expected to contribute in ways that made sense.
Now, people have decided that "whole team" means "everyone must learn to code."
It took 30 years (or so... ahem) for things to come almost full circle.
I'm watching people freak out over changes where "everyone is a developer" and "developers" being made the same as... everyone else. People are freaking over that. Why?
I'm not sure. Maybe ego? Maybe there is a bit of resentment - everyone is suddenly "equal" - everyone is suddenly the same - no one is special anymore. Or worse, maybe they are not better than other people any more?
What I tend to see is this...
There are legions of people with a shallow understanding of what "whole team" means. There is a huge, potentially intentional, misunderstanding over what "whole team" means.
If everyone "learns to code" do you really expect people to be able to write production facing code in a matter of days or weeks or months? Do you really expect people to be able to develop meaningful test approaches to that code in a matter of days or weeks or months if they have never had to do so in the past?
Even in the "dark ages" there were people who were better at something than others. That is still true. Make use of those differences in skills, abilities and viewpoints.
Don't let your ego get in the way. Don't let manufactured differences and false dichotomies play on your ability to work together.
If you are not sure what I mean, consider the list of items at the beginning of this blog post.
In short:
Developers - put the ego in check and realize you can't do it all yourself;
Testers - look, you'll be treated like second-class citizens as long as you act like second-class citizens;
The rest of you - chill - do what you know how to do and help everyone else do their thing.
Act professionally. Perhaps more importantly, act as a mature adult.
Contribute to the team's success.
If your ego can't handle it, go tell your mummy I hurt your feelings.
My response? "Not quite, but close.Not as old as dirt, but I do remember when fire was a new-fangled idea."
Really. I've used that recently. This last week.
I wonder if anyone else remembers the "dark ages" where "programmers" talked with people outside of tech? You know, like, people who would actually USE the software being worked on? People who were currently using it and had an idea that might make it better? You know, an "enhancement"?
I wonder if anyone else remembers the "dark ages" where "programmers" talked with those same people and figured out things like "requirements" and "expectations" and when pieces might be available, if not the whole thing
I wonder if anyone else remembers the "dark ages" where "programmers" looked at application and system models and did the design work for how their changes, the ones they talked with non-tech people about, would fit into the whole scheme? Like, did the design and architecture work?
I wonder if anyone else remembers the "dark ages" where "programmers" looked at file systems and databases and came up with solutions that would work for their needs and not step on the toes of any other systems or the people who used them.
I wonder if anyone else remembers the "dark ages" where "programmers" figured out how to test the software they made? Figured out what the expected behavior was and how to handle situations that would, almost certainly arise when something went hay-wire or "pear-shaped." (Yeah, that is still kind of my favorite euphemism for SNAFU.) Or how about, worked hard to find faults in their presumptions?
I wonder if anyone else remembers the "dark ages" where "programmers" sat down with other programmers and worked with each other on their code? Where they went beyond "I'm stuck" and looked at "is this the best way?" Where they reviewed each others code to look for potential problems or inconsistencies - like weird variable handling or dangling If-Then constructs - or worse - random periods - dots - that might get missed?
I wonder if anyone else remembers the "dark ages" where "programmers" carefully worked out what data they needed to test with before running the first test? What conditions they needed to meet and what combinations they needed to cover - and how to cover them?
I wonder if anyone else remembers the "dark ages" where "programmers" had other "programmers" look over their shoulder as they were running tests to help them see if they missed anything?
I wonder if anyone else remembers the "dark ages" where "programmers" worked with other "programmers" before testing the work of those other "programmers"?
I don't remember when this all changed.
It was gradual. It seems like it was getting tweaked and nudged and "improved" for some time. Before long, there was "designers" and "architects" and "business analysts" and "developers" and "testers" and... yeah. Next thing I knew, people needed special treatment. They were "specialists" in something. It seems that some needed to feel "special" - more "special" than others that were not as cool as them.
People began not talking to each other so freely - or at least not as colleagues - equals. People who were "testers" seemed less at-ease to talk with "developers" as equals. Instead of working towards solutions together, they saw themselves as part of a hierarchy - a pecking-order.
There were extremely formalized models to developing software that were put in place - models to prevent people from working together (as far as I could see.) Some were focused on "maximizing individual skills" and "reducing distractions," as far as I could see then, and still see, they were about asserting power and control.
People began to see their work as more valuable than the work other people did. They felt, possibly believed but I find most beliefs to be reassured/asserted feelings, they were better than those "others" and had greater skills than those "others" and so were worth more to the company than those "others" and so they deserved to be paid more than those "others."
This was also about the time I began noticing there were fewer women working in software shops than there used to be. I don't know if they left because they got tired of dealing with jerks or is they simply had found something better to do. I suspect one led to the other.
I began seeing more "frat-boy" behavior on teams I worked with. Behavior that would have gotten you fired a few years ago was now the norm. I did not stick at those shops very long. I apparently was not a "cultural fit." So I quit or was transferred to another team of "old people."
At the time, I was not sure what was going on. I did not like it very much. I spent my time honing skills I saw were missing in many of the "developers" I worked with. I became good at testing. I became a "tester."
A rebellion started.
People began looking for "rapid software development" and "light development methods" and ways to make software get written and developed faster, without the huge overhead imposed by the control and power folks.
I remember reading articles, then a book, on this new cool approach called "Extreme Programming."
Then I remember reading about this cool newness called "Agile." At the time, I shrugged. I still kind of shrug, frankly.
I'd seen too many "hot trends that would revolutionize software development" come and go.I did my job to the best of my ability and helped other people work better.
Then some folks got the idea that "Agile" might really be a thing. There were suddenly loads of books and papers on it. There were people talking about the "whole team" being responsible for "quality."
Whatever. For some of us, that had been the way we worked years before. Back in the "dark ages."
Now, don't get me wrong. Back in the "dark ages" there always were "programmers" who wrote code pretty well, but were better at designing solutions or figuring out file systems and structures or looking for ways to exercise the software. Everybody was expected to do some pieces of all of this - and everybody was expected to contribute in ways that made sense.
Now, people have decided that "whole team" means "everyone must learn to code."
It took 30 years (or so... ahem) for things to come almost full circle.
I'm watching people freak out over changes where "everyone is a developer" and "developers" being made the same as... everyone else. People are freaking over that. Why?
I'm not sure. Maybe ego? Maybe there is a bit of resentment - everyone is suddenly "equal" - everyone is suddenly the same - no one is special anymore. Or worse, maybe they are not better than other people any more?
What I tend to see is this...
There are legions of people with a shallow understanding of what "whole team" means. There is a huge, potentially intentional, misunderstanding over what "whole team" means.
If everyone "learns to code" do you really expect people to be able to write production facing code in a matter of days or weeks or months? Do you really expect people to be able to develop meaningful test approaches to that code in a matter of days or weeks or months if they have never had to do so in the past?
Even in the "dark ages" there were people who were better at something than others. That is still true. Make use of those differences in skills, abilities and viewpoints.
Don't let your ego get in the way. Don't let manufactured differences and false dichotomies play on your ability to work together.
If you are not sure what I mean, consider the list of items at the beginning of this blog post.
In short:
Developers - put the ego in check and realize you can't do it all yourself;
Testers - look, you'll be treated like second-class citizens as long as you act like second-class citizens;
The rest of you - chill - do what you know how to do and help everyone else do their thing.
Act professionally. Perhaps more importantly, act as a mature adult.
Contribute to the team's success.
If your ego can't handle it, go tell your mummy I hurt your feelings.
Subscribe to:
Posts (Atom)
