So my last few blog posts got me thinking about how I personally approach programming and the job I do from day to day. In fact a sermon delivered by my Unitarian Universalist minister this morning solidified for me how I think about my approach to programming. The sermon was on Big P and little p politics. What struck me about the sermon was how well a conversation about our little UU community fit with the programming communities that we all work in (assuming that we do not work for ourselves or alone).
The sermon described Big P politics as things like espousing to vote for certain people, or telling people that they should think a certain way. While little p politics, our minister goes on to describe, are the things and actions that we take in our community. The important part of this second "little p" politics to me was how she described what was vitally important to the topic, the ideas of D and P.
In this case, she joked, she was not talking about Democrat and Republican and by using it I am not talking about Theory D and Theory P but rather she was speaking of DIALOG and RESPECT.
These two ideas should be one of the corner stones of what we do as programmers. We should all be capable of entering into a dialog with our fellow programmers in a mutually respectful way. How does this translate into the world? Any and all of us should be willing to have our minds open and be able to enter into any conversation about programming being willing to change our minds about a particular topic that previously we may have taken for granted. i.e. we should treat our community of programmers with respect and always be prepared to have our pre-conceived notions challenged and overturned by someone else.
This idea of dialog and respect can be powerful - and transformative (along the lines of Reg Braithwaite's post on blog postings he would love to read), but we must be careful about the definitions. By dialog we are not talking about flame wars (these are dialogs yes but not constructive ones in my opinion) - but rather an open and free conversation between people of mutual OR dissonant intent. This second idea (of speaking to non-like minded folk) is very important to the this topic of dialog and respect in the following way:
If we choose to spend our time only talking to people that we know hold the same ideals as us we are not challenging and we are not learning.
If we only speak to like minded people we are foolishly sticking to our guns and have become logically 'stuck'. We may also have stopped acknowledging that others may have something important and vital to contribute and as such are not respecting them and their learning. Only when we are open to having conversations with both like minded and dissonant thinking people, having our minds changed/challenged, are we approaching any dialog with respect. This is what can make us better, raise us all up a level, make our community stronger - help us All to get along.
The idea that little p politics can play this roll in our every day lives can easily be missed, but I encourage all readers of this blog not to ignore it. Take time to realize what effect you may have on people you work with from day to day. Pay attention to the effect you may have on the organization and community at large. Use the little p politics to strengthen yourself and our programming community - the large and the small - the world as well as the Big Co. programming group you work with.
Sunday, October 7, 2007
Friday, October 5, 2007
Learning (revisited) and Transformation
So my friend Reg Braithwaite over on his blog posed that he would like to see people make some posts about:
"1) What I learned from Language X that makes me a better programmer when I use Language Y
2) Something surprising that you probably wouldn’t guess about Language X from reading blog posts
3) My personal transformation about Idea X"
in his post: Three blog posts I'd love to read (and one that I wouldn't). So here I am attempting to take up the challenge, an blog about 1, and 3, starting with 3.
So the transformation that I went through was pertaining to all other languages (i.e. the ones the I am not currently working in) and it was simply that they ALL have something small to contribute when it comes to how I program from day to day. I previously felt about programming like I felt about doctors, it is better to focus in and be specialized then it is to have broad knowledge about a bunch of information about many different languages. When I finally started to gain knowledge in those other languages I finally realized how wrong a path this was. This THEN relates to item number 1.
So this transformation in my thinking (which is a bit of a gunshot in the head if you were thinking in this very one line type of way) brought about all the other things pertaining to what I learned in those languages that I could apply over all. The first new language that I picked up was Perl, and then I picked up Python and Jython. Each one of those languages had a large impact on how I thought about my java programming. Each of those languages does things differently and sometimes better. What I walked away from each one with was simple at first. Things like formatting and the need to document the code with comments (simple but needed). Then other simple things like structure of the code and flow control. Then GRAND things started to turn over in my head like if perl does it one way and it rocks in perl, how can I make my java code JUST as elegantly do the same thing. The transformation was a big shift for me. It then fed back into item 3 in the form of "If these two languages can modify how I think about what I am doing now in such large and interesting ways - what else is out there that can help me?"
So the learning now goes on with a much much more open mind, and a puzzle piece mentality that I think benefits both me and the people that I work for in immeasurable ways. Taking notes and ideas from many places to form a more holistic view of programming.
"1) What I learned from Language X that makes me a better programmer when I use Language Y
2) Something surprising that you probably wouldn’t guess about Language X from reading blog posts
3) My personal transformation about Idea X"
in his post: Three blog posts I'd love to read (and one that I wouldn't). So here I am attempting to take up the challenge, an blog about 1, and 3, starting with 3.
So the transformation that I went through was pertaining to all other languages (i.e. the ones the I am not currently working in) and it was simply that they ALL have something small to contribute when it comes to how I program from day to day. I previously felt about programming like I felt about doctors, it is better to focus in and be specialized then it is to have broad knowledge about a bunch of information about many different languages. When I finally started to gain knowledge in those other languages I finally realized how wrong a path this was. This THEN relates to item number 1.
So this transformation in my thinking (which is a bit of a gunshot in the head if you were thinking in this very one line type of way) brought about all the other things pertaining to what I learned in those languages that I could apply over all. The first new language that I picked up was Perl, and then I picked up Python and Jython. Each one of those languages had a large impact on how I thought about my java programming. Each of those languages does things differently and sometimes better. What I walked away from each one with was simple at first. Things like formatting and the need to document the code with comments (simple but needed). Then other simple things like structure of the code and flow control. Then GRAND things started to turn over in my head like if perl does it one way and it rocks in perl, how can I make my java code JUST as elegantly do the same thing. The transformation was a big shift for me. It then fed back into item 3 in the form of "If these two languages can modify how I think about what I am doing now in such large and interesting ways - what else is out there that can help me?"
So the learning now goes on with a much much more open mind, and a puzzle piece mentality that I think benefits both me and the people that I work for in immeasurable ways. Taking notes and ideas from many places to form a more holistic view of programming.
Tuesday, October 2, 2007
Why so passionate? Can't we all just get along?
OK, this might seem a little silly but I have now seen at least three separate posts on the very same topic. It all started with this post over on raganwald: Java is the right answer to the wrong question, Ruby is the wrong answer to the right question which opened up with a quote.
"Large code bases are the problem, not the language they’re written in. Find a way to break/decompose big code bases into little ones."
Which addresses a topic that comes up a great deal. This quote is used as a jump point to discuss the ongoing silliness that we all seem to occasionally get mired in, which is a discussion of why one language is bad and another good... or in some cases why a particular feature of a language is bad and another feature in a different language is good.
What if There is no One Answer to the question of which language to use, or if static typing is better then good unit testing? Is it really so hard to grasp that one should use the right tool(s) for the job at hand? As a for instance, if you were building a deck on your house you might pick supplies for that project that you like but you would balance that choice with the needed strength to make sure the deck does not collapse after it is built. Why does the discussion of things like Java vs. Ruby and Static Typing vs. Unit testing always have to break down into a feces throwing match?
Lastly Bejamin Stein asks How confident are you, the programmer, that the change you just made will work? In my opinion this is a sub question that SHOULD get asked after the correct tooling has been chosen. As a programmer I have a desire to know that my change isn't going to effect the world, lots of tools can help me with this (not the least of which is a simple grep). I would also hope that my chosen tool for a project can help me with knowing what a change may effect but that may not always be true because of the type of project or type of tool chosen. This question may also only apply to larger (i.e. Medium to Large) projects with multiple people because knowing your change doesn't effect everyone may reduce work someone else has to do making the teams you work on faster as a whole. If I know it is just me writing the code for me and no one else I may not care if I effect the world because in the end I have to fix it anyway.
All I want to do is get along - Choose the right tool for the job at hand, and have some good support as to why that tool was chosen. Be it statically typed, dynamically typed, easy to write a unit test for - or not so easy. Different projects, different tasks, DIFFERENT tools, perhaps even a DSL tossed in for good measure.
"Large code bases are the problem, not the language they’re written in. Find a way to break/decompose big code bases into little ones."
Bill de hÓra, calming a heated debate
Which addresses a topic that comes up a great deal. This quote is used as a jump point to discuss the ongoing silliness that we all seem to occasionally get mired in, which is a discussion of why one language is bad and another good... or in some cases why a particular feature of a language is bad and another feature in a different language is good.
What if There is no One Answer to the question of which language to use, or if static typing is better then good unit testing? Is it really so hard to grasp that one should use the right tool(s) for the job at hand? As a for instance, if you were building a deck on your house you might pick supplies for that project that you like but you would balance that choice with the needed strength to make sure the deck does not collapse after it is built. Why does the discussion of things like Java vs. Ruby and Static Typing vs. Unit testing always have to break down into a feces throwing match?
Lastly Bejamin Stein asks How confident are you, the programmer, that the change you just made will work? In my opinion this is a sub question that SHOULD get asked after the correct tooling has been chosen. As a programmer I have a desire to know that my change isn't going to effect the world, lots of tools can help me with this (not the least of which is a simple grep). I would also hope that my chosen tool for a project can help me with knowing what a change may effect but that may not always be true because of the type of project or type of tool chosen. This question may also only apply to larger (i.e. Medium to Large) projects with multiple people because knowing your change doesn't effect everyone may reduce work someone else has to do making the teams you work on faster as a whole. If I know it is just me writing the code for me and no one else I may not care if I effect the world because in the end I have to fix it anyway.
All I want to do is get along - Choose the right tool for the job at hand, and have some good support as to why that tool was chosen. Be it statically typed, dynamically typed, easy to write a unit test for - or not so easy. Different projects, different tasks, DIFFERENT tools, perhaps even a DSL tossed in for good measure.
Subscribe to:
Posts (Atom)
