My sifu would tell us that he loved to teach the Beginner classes. He believed the most important sash to earn was the first one, and that the introduction and initial classes were paramount to the success of each student. He trained his assistants relentlessly so they would not only teach true technique, but also that they be friendly and high-energy and helpful. The result was an excellent culture of encouragement and trust in each other.
I recently started a new job with a new company, and while sifting through onboarding documents I found this sentence in a preamble: "And, if you are a new
(company name) developer: welcome aboard!"
So simple. At first I barely noticed it as I skimmed, but my eyes caught on it and now I'm thinking about it. When I was in high school, I surrounded myself with tutorials and documentation that not only provided the important information but was friendly. Because of my inexperience, I needed to be told it was okay to not get it, to be slow, for things to be confusing. That by completing a tutorial I had somehow achieved something, that my effort had value.
I think about this developer and a small decision, years ago, to be friendly to someone they didn't even know. What that says about their nature and the culture they wanted.
2012-08-28
2011-01-25
You Will
Two items crossed in my mind to form tonight's post. I was watching a PyCon video about Tests and Testability in which Ned Batchelder said "You will write testing framework code. It's okay, it's really not a big deal. Just do it." This was followed a few days later by a Riding Rails article by David Heinemeier Hansson (from 2005 no less) about his dislike for componentized login systems.
Underneath DHH's argument is that you will be spending time implementing the solution to your problem of needing to track user authentication and authorization. This time and effort would probably be better-spent implementing a custom design that takes into account YOUR needs rather than trying to coerce someone else's solution into a half-solution. In reconfiguring, altering or encapsulating your use of the component you are going to end up writing authentication and authorization framework code.
Something that's pushed me towards automated testing and continuous integration topics is this same idea: if you're already going to hand-test the application after you've made a change, why not encapsulate that test into something automated? This drive alone, however, leads to the realm of components (or middleware or JARs or whatever it is in your system) that results in the weeks that I've wasted trying to get some software package or another, dictated by my employer, to work for us.
I'm usually not a champion of the school of thought labeled "Not Invented Here syndrome" but I do feel that homegrown solutions tend to be shaped by the particular problems of that home. If you work in a place that has weird firewalls, your solution will probably deal with firewalls better (for your value of "better") than something else. If your developers include some that use Linux, Windows, and Mac, the development tools you use will either come prepackaged as multi-platform or you will grow your own development tools that can survive each system gracefully.
The trick is to not get hung up on whatever your work environment's curses are. I run into this in regular life too: my teenage son gets really upset that he has to have his work checked, and then to re-do any work that's incorrect. To him, that's not part of the contract. When he finally accepts that checking the work and fixing it if it's wrong ought to and WILL happen every time, he'll have an easier time with it. Does that sound like what you've heard about unit tests?
But I'm a tester! I don't write code!
You will.
I'm a software developer, I don't deal with customers!
You will.
Alternate answer: You do! My customers are the support staff of my company.
I'm the President of the company, I can't deploy the website.
You ought to. What if Mutt & Jeff are on vacation? See the PyCon video "Why not run all your tests all the time?" by the excellent Dr. C. Titus Brown. He convinced me.
Underneath DHH's argument is that you will be spending time implementing the solution to your problem of needing to track user authentication and authorization. This time and effort would probably be better-spent implementing a custom design that takes into account YOUR needs rather than trying to coerce someone else's solution into a half-solution. In reconfiguring, altering or encapsulating your use of the component you are going to end up writing authentication and authorization framework code.
Something that's pushed me towards automated testing and continuous integration topics is this same idea: if you're already going to hand-test the application after you've made a change, why not encapsulate that test into something automated? This drive alone, however, leads to the realm of components (or middleware or JARs or whatever it is in your system) that results in the weeks that I've wasted trying to get some software package or another, dictated by my employer, to work for us.
I'm usually not a champion of the school of thought labeled "Not Invented Here syndrome" but I do feel that homegrown solutions tend to be shaped by the particular problems of that home. If you work in a place that has weird firewalls, your solution will probably deal with firewalls better (for your value of "better") than something else. If your developers include some that use Linux, Windows, and Mac, the development tools you use will either come prepackaged as multi-platform or you will grow your own development tools that can survive each system gracefully.
The trick is to not get hung up on whatever your work environment's curses are. I run into this in regular life too: my teenage son gets really upset that he has to have his work checked, and then to re-do any work that's incorrect. To him, that's not part of the contract. When he finally accepts that checking the work and fixing it if it's wrong ought to and WILL happen every time, he'll have an easier time with it. Does that sound like what you've heard about unit tests?
But I'm a tester! I don't write code!
You will.
I'm a software developer, I don't deal with customers!
You will.
Alternate answer: You do! My customers are the support staff of my company.
I'm the President of the company, I can't deploy the website.
You ought to. What if Mutt & Jeff are on vacation? See the PyCon video "Why not run all your tests all the time?" by the excellent Dr. C. Titus Brown. He convinced me.
2010-08-04
Low-hanging Fruit
I'm not the first to write about this, but I was out picking blackberries today and wanted to chime in on an oft-used phrase: "low-hanging fruit" I've often heard it used as a way to describe something easy to accomplish, perhaps meaning that if all things are equal you should choose to do the thing that's easiest.
While picking berries, however, I noticed that the berries that were higher up were riper. This means a lot of things, most of them good. They were sweeter and juicier which means they were the better fruit. They were also, counter-intuitively, easier to pick: the less ripe berries at eye-level were more firmly attached to their stems and took more force to pull them off. Because they were higher up, I did have to stretch to my limit. I also got pricked by some thorns and bled a little. Still, it meant I was able to fill my bucket and get some really tasty fruit for dinner.
Sometimes the "easy" thing to do won't get you closer to your real goal. At work, we've identified an area that could use a half-dozen minor fixes, but all acknowledge the real solution is to rewrite the section and be done with the patches. All things being equal, you should pick the thing you don't have to stand on your tip-toes to do... but if things aren't equal, you should just pick the right thing.
While picking berries, however, I noticed that the berries that were higher up were riper. This means a lot of things, most of them good. They were sweeter and juicier which means they were the better fruit. They were also, counter-intuitively, easier to pick: the less ripe berries at eye-level were more firmly attached to their stems and took more force to pull them off. Because they were higher up, I did have to stretch to my limit. I also got pricked by some thorns and bled a little. Still, it meant I was able to fill my bucket and get some really tasty fruit for dinner.
Sometimes the "easy" thing to do won't get you closer to your real goal. At work, we've identified an area that could use a half-dozen minor fixes, but all acknowledge the real solution is to rewrite the section and be done with the patches. All things being equal, you should pick the thing you don't have to stand on your tip-toes to do... but if things aren't equal, you should just pick the right thing.
2010-07-15
Grumpiness
As laid down by Larry Wall, the three virtues of programming are laziness, impatience and hubris. Yesterday I was caught up in all three, in a state I call grumpiness.
I've started on a project that currently has two really excellent programmers... who have been struggling to keep up with the firehose flow of bugs and new features. I was hired on partly to cut down the size of our backlog, and to help push forward on a development initiative that will allow the company to cater to a wider audience. Those two activities have been slowly turning me into a Grumpy Gus.
We have source control, but it's all in trunk with no branching. We have three levels of development (dev, test and prod) but running dev on a local machine is... um.. tricky. There is One True Database, and no revision history on its schema changes. The database isn't normalized at all. There is no ticket tracking of development features (only bugs created by Support), and no way to tie revisions to tickets. There are no automatic tests, unit or otherwise.
And so on. We're making improvements, but sometimes when I blow a whole day trying to get my local server to run is really frustrating. Impatience is by far my default state, waiting for Subversion to get back to me with some information or having to restart my dev server just to see a small change. Laziness is a factor, because I don't want to work very hard to implement my changes and deploy them upstream. Hubris is ever-present, because implicit in my complaining is that I could fix these problems if I had a week and couple pots of coffee.
Luckily in the next 3-6 months I will be directed to spend most of my time directly improving many of these problems. And really, that's why grumpiness is useful: being dissatisfied with the way things are provides the energy needed to fix it. If I didn't have a mandate to act upon this impulse, I might not last very long in this environment.
So I blow of steam by complaining to my project teammate, and repeat to myself laziness, impatience, hubris.
I've started on a project that currently has two really excellent programmers... who have been struggling to keep up with the firehose flow of bugs and new features. I was hired on partly to cut down the size of our backlog, and to help push forward on a development initiative that will allow the company to cater to a wider audience. Those two activities have been slowly turning me into a Grumpy Gus.
We have source control, but it's all in trunk with no branching. We have three levels of development (dev, test and prod) but running dev on a local machine is... um.. tricky. There is One True Database, and no revision history on its schema changes. The database isn't normalized at all. There is no ticket tracking of development features (only bugs created by Support), and no way to tie revisions to tickets. There are no automatic tests, unit or otherwise.
And so on. We're making improvements, but sometimes when I blow a whole day trying to get my local server to run is really frustrating. Impatience is by far my default state, waiting for Subversion to get back to me with some information or having to restart my dev server just to see a small change. Laziness is a factor, because I don't want to work very hard to implement my changes and deploy them upstream. Hubris is ever-present, because implicit in my complaining is that I could fix these problems if I had a week and couple pots of coffee.
Luckily in the next 3-6 months I will be directed to spend most of my time directly improving many of these problems. And really, that's why grumpiness is useful: being dissatisfied with the way things are provides the energy needed to fix it. If I didn't have a mandate to act upon this impulse, I might not last very long in this environment.
So I blow of steam by complaining to my project teammate, and repeat to myself laziness, impatience, hubris.
2010-01-28
Flow
Currently I'm not using any IDE for development. I find this to be remarkable, that in the 21st Century I don't use code-completion, refactoring tools, in-line debuggers, or integrated change management tools. I use VIM for my text editing (which does have syntax highlighting), and the command-line for the other needed tools like pylint, git or subversion, unit tests, uploaders/managers and the like.
Why am I using a bicycle instead of a jet pack?
In the past I've really enjoyed how it feels to work within a really slick IDE like IntelliJ IDEA or Eclipse, especially for Java development. I miss having lots of information given to me, like the code tips that pop up to tell you the method's signature or that automatically infers what type a variable needs to be cast to. Supposedly Microsoft's tools are the best in the world for this type of information and integration.
Up until a few years ago, I did all of my personal development in Eclipse: C++, Java, Python, Ruby... everything. But eventually I stopped. There's more friction in testing an idea (which I do a lot of in Python) if you have to set up a project, configure the repository, and write build scripts. Many of the special tools are weaker in my preferred languages: I've never felt comfortable using refactorings in a Python IDE (though syntax highlighting has gotten LOTS better). I got tired of downloading Eclipse and its extensions for every new computer I was working on.
So, I'm writing this because it seems a bit lazy and unprofessional to just using a text editor. I still feel that using a good IDE is the mark of a truly professional programmer, whether that's true or not. I have this image that a "real programmer" has their Tool Of Creation ready to go each day, humming with power yet easy to use. This is probably very similar to friends who've lamented about not having the perfect place to write a book, or my wife having to do landscape drawings on the kitchen table with an extra lamp from the living room. It just doesnt feel... perfect.
I've learned a lot in the last month as I've made the effort to mediate every day. One of the barriers to this goal seems to be my desire to have everything "right" before I sit down. Sometimes I've eaten recently and my stomach is full. Sometimes I feel too tired. Sometimes I'm getting ready for the next errend and don't want to spend 10 minutes on that. If I wait for conditions to be perfect, I never get around to it.
On the other hand, the projects I'm working on are increasing in complexity. I keep having to look up the URL for the Subversion repository for my new contract job, or spend a lot of time looking up API information. The tools I'm using are really powerful, but I'm running into trouble employing them all, and employing them as regularly as I'd like. When all of my code fit comfortably in two files, with a single command to run them, it made much more sense to keep the infrastructure small. Now that a lot of my currently-shunned tools have had time to advance and my project complexity is increasing... I'm reconsidering my position.
I'm going to give Eclipse another try, but not because I think it'll be perfect. I think I've matured a little in practice and in needs, and my flow is starting to be disrupted by the quality of my tools. These hammers haven't worn out, but if I need to frame a house by myself in a day I need to employ something a little quicker that requires less physical force from me.
And that's really okay.
Why am I using a bicycle instead of a jet pack?
In the past I've really enjoyed how it feels to work within a really slick IDE like IntelliJ IDEA or Eclipse, especially for Java development. I miss having lots of information given to me, like the code tips that pop up to tell you the method's signature or that automatically infers what type a variable needs to be cast to. Supposedly Microsoft's tools are the best in the world for this type of information and integration.
Up until a few years ago, I did all of my personal development in Eclipse: C++, Java, Python, Ruby... everything. But eventually I stopped. There's more friction in testing an idea (which I do a lot of in Python) if you have to set up a project, configure the repository, and write build scripts. Many of the special tools are weaker in my preferred languages: I've never felt comfortable using refactorings in a Python IDE (though syntax highlighting has gotten LOTS better). I got tired of downloading Eclipse and its extensions for every new computer I was working on.
So, I'm writing this because it seems a bit lazy and unprofessional to just using a text editor. I still feel that using a good IDE is the mark of a truly professional programmer, whether that's true or not. I have this image that a "real programmer" has their Tool Of Creation ready to go each day, humming with power yet easy to use. This is probably very similar to friends who've lamented about not having the perfect place to write a book, or my wife having to do landscape drawings on the kitchen table with an extra lamp from the living room. It just doesnt feel... perfect.
I've learned a lot in the last month as I've made the effort to mediate every day. One of the barriers to this goal seems to be my desire to have everything "right" before I sit down. Sometimes I've eaten recently and my stomach is full. Sometimes I feel too tired. Sometimes I'm getting ready for the next errend and don't want to spend 10 minutes on that. If I wait for conditions to be perfect, I never get around to it.
On the other hand, the projects I'm working on are increasing in complexity. I keep having to look up the URL for the Subversion repository for my new contract job, or spend a lot of time looking up API information. The tools I'm using are really powerful, but I'm running into trouble employing them all, and employing them as regularly as I'd like. When all of my code fit comfortably in two files, with a single command to run them, it made much more sense to keep the infrastructure small. Now that a lot of my currently-shunned tools have had time to advance and my project complexity is increasing... I'm reconsidering my position.
I'm going to give Eclipse another try, but not because I think it'll be perfect. I think I've matured a little in practice and in needs, and my flow is starting to be disrupted by the quality of my tools. These hammers haven't worn out, but if I need to frame a house by myself in a day I need to employ something a little quicker that requires less physical force from me.
And that's really okay.
2010-01-17
Cloudy With A Chance Of Compassion
I'm still waiting to see what comes of the "cloud computing" idea. It's certainly the direction that most server operations are going in, but I'm not convinced the abstraction hides all of the details.
Anyways, CloudCamp is one of the more popular un-conferences on the subject, and one of my Twitter follows posted a link to CloudCamp 2010. This is a virtual conference, occuring online via GoToMeeting, with proceeds going to the Red Cross and its efforts in assisting Haitians recover from the earthquake.
When I first read "CloudCamp Haiti" I thought it was a sick joke, but after reading their page I think it's a really novel set of ideas. Cloud Computing espouses that it doesn't matter how/where the software runs as long as the service meets certain limits. That this conference shouldn't really matter where you are so long as you have a browser and a decent series of tubes is kind of amazing. I'm also imagining all sorts of cost savings: no hotel bookings, no plane tickets or jet fuel, no rented cars and gasoline.
The only topic on the agenda right now is "How Cloud Computing Can Help in a Crisis." I'm not sure how much it can help compared to the USNS Comfort, but perhaps the ideas of decentralization can help mitigate the effects of events that often cause large infrastructure failures.
No matter how it is expressed, compassion for suffering people is top-notch in my book and I'm proud of seeing the creative ways aid is being mustered.
Anyways, CloudCamp is one of the more popular un-conferences on the subject, and one of my Twitter follows posted a link to CloudCamp 2010. This is a virtual conference, occuring online via GoToMeeting, with proceeds going to the Red Cross and its efforts in assisting Haitians recover from the earthquake.
When I first read "CloudCamp Haiti" I thought it was a sick joke, but after reading their page I think it's a really novel set of ideas. Cloud Computing espouses that it doesn't matter how/where the software runs as long as the service meets certain limits. That this conference shouldn't really matter where you are so long as you have a browser and a decent series of tubes is kind of amazing. I'm also imagining all sorts of cost savings: no hotel bookings, no plane tickets or jet fuel, no rented cars and gasoline.
The only topic on the agenda right now is "How Cloud Computing Can Help in a Crisis." I'm not sure how much it can help compared to the USNS Comfort, but perhaps the ideas of decentralization can help mitigate the effects of events that often cause large infrastructure failures.
No matter how it is expressed, compassion for suffering people is top-notch in my book and I'm proud of seeing the creative ways aid is being mustered.
2009-11-28
Version Control and Mental Flow
I'd like to admit that I'm at a very difficult time for a programmer: somewhere in the vast wasteland between reading "in 24 hours" books and writing them. I'm the target market for Cookbook style books, for webinars and city-wide sprints. A few years ago I was really happy with myself for really starting to use API documentation or being able to figure out some arcane syntax. Now I blow through the initial structure of my program in an hour, then spend an hour reading dozens of blog posts, a couple mailing list threads from three years ago, and a full wiki; at some point after this hour I can add a few more lines of code.
I'm pretty good at handling threading and at handling TCP sockets, but I get confused when putting them together. I can put together a UI really quickly, then weeks ensuring everything behind it is happening the way I expect them to. I'm at the point I can figure out how to use all manner of development tools: I just need to use them.
In the last few months I've really been pushing myself to use version control consistently and constantly. I've fallen in love with git, and am starting to notice interesting things about how my development process is changing. Right now the most important thing it gives me is a short-term memory. As the concepts I was working with grew in complexity, I began to lose track of what code I was working on. Like oil that thins out as it spreads out on the surface of water, I had a really hard time thinking deeply about a particular topic. My thoughts just got fuzzy and I'd find myself drawing boxes and lines but not achieving better understanding.
Git has helped me change this because my process involves me checking my diff regularly. When I start work each morning it's nice to be able to read my work history and remember the stories I was telling the previous day. After I've made several small changes, checking the diff lets me see each piece together and reassure myself I've done what I intended.
Now, diff comes in many forms and it has always been available to me. But because I've really been solidifying a process for building things, my brain now trusts me with more control. This is the promise of many formal processes: freedom through control. David Allen, when speaking about the joy of the GtD system, likes to remind that [you] won't believe how it feels to have your head clear to respond to what comes up through the day.
Formal methods provide this clarity. Unit testing does this, too. Being able to use a debugger does this. Task tracking does this. Refactoring does this. There are a huge number of intermediate-level skills that I'm encountering that, when mastered and integrated into one process, produces an advanced programmer.
I really like how I'm using Git now, but I'm excited about where I see it going. Once I really figure out how branching works, I look forward to some really excellent ways of keeping my changes straight. Many times while adding a feature, I see a small bug in the code. Before I would simply change it and move on. Now I hesitate, write it down, then continue making my atomic edit and return to the bugfix when I can make that an atomic edit. Perhaps in another year or two I would instead stop working on the feature branch and check out the trunk to make the bugfix then merge it into my feature branch.
My college professors couldn't teach me these things. My team leads in previous jobs couldn't impose this on me. Only I could piece together new behaviors into a better process.
I'm pretty good at handling threading and at handling TCP sockets, but I get confused when putting them together. I can put together a UI really quickly, then weeks ensuring everything behind it is happening the way I expect them to. I'm at the point I can figure out how to use all manner of development tools: I just need to use them.
In the last few months I've really been pushing myself to use version control consistently and constantly. I've fallen in love with git, and am starting to notice interesting things about how my development process is changing. Right now the most important thing it gives me is a short-term memory. As the concepts I was working with grew in complexity, I began to lose track of what code I was working on. Like oil that thins out as it spreads out on the surface of water, I had a really hard time thinking deeply about a particular topic. My thoughts just got fuzzy and I'd find myself drawing boxes and lines but not achieving better understanding.
Git has helped me change this because my process involves me checking my diff regularly. When I start work each morning it's nice to be able to read my work history and remember the stories I was telling the previous day. After I've made several small changes, checking the diff lets me see each piece together and reassure myself I've done what I intended.
Now, diff comes in many forms and it has always been available to me. But because I've really been solidifying a process for building things, my brain now trusts me with more control. This is the promise of many formal processes: freedom through control. David Allen, when speaking about the joy of the GtD system, likes to remind that [you] won't believe how it feels to have your head clear to respond to what comes up through the day.
Formal methods provide this clarity. Unit testing does this, too. Being able to use a debugger does this. Task tracking does this. Refactoring does this. There are a huge number of intermediate-level skills that I'm encountering that, when mastered and integrated into one process, produces an advanced programmer.
I really like how I'm using Git now, but I'm excited about where I see it going. Once I really figure out how branching works, I look forward to some really excellent ways of keeping my changes straight. Many times while adding a feature, I see a small bug in the code. Before I would simply change it and move on. Now I hesitate, write it down, then continue making my atomic edit and return to the bugfix when I can make that an atomic edit. Perhaps in another year or two I would instead stop working on the feature branch and check out the trunk to make the bugfix then merge it into my feature branch.
My college professors couldn't teach me these things. My team leads in previous jobs couldn't impose this on me. Only I could piece together new behaviors into a better process.
2009-10-17
VirtualBox and Integrating Systems
When I first started programming, it seemed that the most important and problematic portion of a project was the project: getting an idea shepherded through design and programming and testing. Many small projects fell by the wayside because I couldn't focus on it long enough to complete it.
Now, finishing a single item is not too hard; what's hard is doing something useful with a single system. All of the really good data is on the web, inside Facebook and Twitter and Amazon. I recently decided to start exploring the world of Google Wave. I installed a Wave server inside a Turnkey virtual appliance running on VirtualBox. Like many things, Wave is based on something else: the OpenFire XMPP server. I spent most of my time downloading each item (Turnkey appliance, OpenFire server, Wave server) and a bit of time following some instructions online.
I feel this is really what modern development has come to: install a big pile of frameworks and paste your layer on top. Or in the middle. Or wherever it goes. Most of the time is integrating the many systems involved or figuring out which piece choked during this particular bug. Not that there's anything wrong with that... there's just a lot that needs to happen before anyone's able to do what they've set out to do (like writing a Wave client).
Really, most of my work today was documenting the process so that the folks over at Turnkey can produce a full Wave server appliance. Then most of the work for deploying a production Wave server would involve downloading a live CD, changing some settings, rebooting it, and allowing the traffic through the firewall.
VirtualBox and Turnkey are really changing how I view servers in general and development in particular. Now I can set up a clean LAMP server in about 45 seconds and start writing code. I can provide a high level of support to my clients or explore ideas without much up-front effort. I've even looked at some really exciting things, like a fully-configured Android SDK virtual device. Then you can fire up a whole new development toolchain without having to muck around with your development computer.
I'm really amazed at where things like virtualization has gotten us, and really looking forward to where we're going.
Now, finishing a single item is not too hard; what's hard is doing something useful with a single system. All of the really good data is on the web, inside Facebook and Twitter and Amazon. I recently decided to start exploring the world of Google Wave. I installed a Wave server inside a Turnkey virtual appliance running on VirtualBox. Like many things, Wave is based on something else: the OpenFire XMPP server. I spent most of my time downloading each item (Turnkey appliance, OpenFire server, Wave server) and a bit of time following some instructions online.
I feel this is really what modern development has come to: install a big pile of frameworks and paste your layer on top. Or in the middle. Or wherever it goes. Most of the time is integrating the many systems involved or figuring out which piece choked during this particular bug. Not that there's anything wrong with that... there's just a lot that needs to happen before anyone's able to do what they've set out to do (like writing a Wave client).
Really, most of my work today was documenting the process so that the folks over at Turnkey can produce a full Wave server appliance. Then most of the work for deploying a production Wave server would involve downloading a live CD, changing some settings, rebooting it, and allowing the traffic through the firewall.
VirtualBox and Turnkey are really changing how I view servers in general and development in particular. Now I can set up a clean LAMP server in about 45 seconds and start writing code. I can provide a high level of support to my clients or explore ideas without much up-front effort. I've even looked at some really exciting things, like a fully-configured Android SDK virtual device. Then you can fire up a whole new development toolchain without having to muck around with your development computer.
I'm really amazed at where things like virtualization has gotten us, and really looking forward to where we're going.
Subscribe to:
Posts (Atom)