Ubuntu Global Jam - Lessons I Learned

Ubuntu Cupcakes from Stacy Skaggs

The Ubuntu Global Jam was last Friday through Sunday and on Friday some Florida LoCo members got together at Chris Johnston's house in Orlando.  I've never been so I thought I would go, though it was on a Friday I could use the break.

I learned quite a few little things to make life easier working on Ubuntu Websites.  The first is a way of keeping the same development environments across project branches.  This has always been an issue for me because with bzr you can't just bzr checkout branch-name and the code changes like git.  Thats not its workflow.  Michael Hall pointed me to this post which is the method he uses for all his bzr repositories.  Basically, create a blank repository.  Inside the repository you create a trunk with the code from launchpad.  Then you branch the local copy into your feature/bug/issue branch.  Finally you lightweight checkout that branch to a working repo folder.  Sound confusing?  It does at first.  First off lightweight checkout doesn't import the code, just links to it.  Meaning when you modify code, push code, commit code its happening from the named branch not from work.  When you create your development environment around work, those files reference the work directory.  So when you change to a different feature, bug or issue the environment files still point to work and you don't have to rebuild.  Example commands:

bzr init-repo project-name
cd project-name
bzr branch lp:launchpad-bzr-name trunk
bzr branch trunk issue-specific-name
bzr checkout --lightweight issue-specific-name work

The second thing I learned was virtualenv for python.

sudo apt-get install python-virtualenv 
sudo apt-get install virtualenvwrapper

These separate the required environment for the ubuntu community websites from the installation of python you have installed and keeps everything nice and clean.  Now little did I know I was using this sort of with the make commands, however, with knowledge comes control and understanding.

I also got to see a bit of python dbugging as Michael Hall and Chris Johnston worked on that for a bit. Ate some fantastic cupcakes, and had a great time getting to dedicate some time to Ubuntu with some pretty awesome people.

Whose to blame for the misunderstanding ...

The incident I refer to is one happening more and more at work (and not just for me).  Examine the scenario:

A junior engineer has been given a feature to develop.  A senior engineer has built the basic mockup of the page, hooked it into the framework, but as the engineer attempts he runs into issues.  He asks, through email, how do I save to the database.  Its a project from a different development group, but the senior engineer has been through their code so he suggest looking into one part of the site and view specific controller and view files.  The junior engineer acknowledged and life moves on.  A week later the junior engineer comes to the senior engineer and says he is still having issues, so they open his code.  The junior engineer has created a new file (instead of following editing the files already apart of the application structure) and is attempting to drive logic that belongs in the controller in a file in the view.  He has ignored the structure of the site and is basically fighting against the natural flow of the program.  At first glance I'd say this is a lack of understanding of MVC.  However, this is not the first MVC project for this junior engineer.

Its a story playing itself over and over again in different ways.  At first glance, I'd assume the engineer never looked at the example files and project flow, instead they just looked up "PHP connect to database".  His code suggest that perhaps he looked at it, but didn't understand how the application uses the files.  Perhaps the senior engineer should have called the junior engineer over and shown them the files and explained the various methods in play to save and how they work with the view.

A friend of mine once mentioned a similar issue with contractors in the corporate landscape.  When he worked with them, over time he found himself practically programming the feature in the documentation to get the functionality he needed.  Inevitably they fought the existing application and built extraneous files.  At one point thier source had 4 different time classes that returned the time.

So how do we fix this without resorting to writing the program on a piece of paper and turning our junior engineers into a programming steno pool?  Is this a hiring issue, should we let junior engineers like this go?  A communication issue, did we not explain the solution completely should we have diagrammed it out?  A language barrier?  A training problem?  An experience issue?

At this time ... I'm lost, perhaps time will bring insight.

Passion Breeds Collaboration While Lack of it Breeds Indifference

I'll put the user in a box

Ever go to the doctor's office full of questions and ideas about a long term illness you may have?  Perhaps that's only me.

How did the doctor act?  Did he engage you in conversation?  Did he seem to ignore you?  Did he dismiss your questions?  Did he answer everything you asked and perhaps ask some of his own?

Have you ever been apart of an open source project?  On a mail list with other eager users and developers?  How did you react the last time someone sent in a question or suggestion?  Did you give them feedback?  Did you bypass the email based on subject?  Did you request more from them, perhaps code or testing?  Did you taunt them with your superior knowledge?

A friend of mine and I were talking about doctors and we came to the conclusion that the best doctors were the ones that wanted your input on your care.  It felt like it was because they were passionate about their jobs.  It seemed to us that the doctors who weren't either had lost the spark, or were only interested in medicine for the prestige, money, or perhaps family history (my father and his father and his father's father, etc).  That somehow led us to talking about open source projects and our time on one.  I came to realize that my passion for the project and for my career affected my involvement with the project.

When I was a developer I loved to hear from everyone.  I read every email, I was always on IRC.  As I moved into a manager role I became more remote.  I was hardly on IRC, I usually ignored listserv email.  Tickets from users were no longer wonderful feedback but annoying things that they could have fixed themselves.  My attitude dropped as I moved from that which I'm passionate about to something that I'm not.  So, I've stopped managing that project and tried to go back to engaging and coding.  The passion, its coming back, a bit slowly but only time will tell.

So the moral of this story?  When you are dealing with some a-hole professional don't be quick to judge.  Perhaps he made a wrong turn and is in a position that he has no passion for.  Instead of cursing him, say a little pray hoping he'll find his way to a profession he is passionate about. 

Engineer, Developer, Programmer, Analyst ... pick one?

I remember a while back my old boss mentioning he had chosen the working title of "Software Engineer" for positions at work because Engineers are not "web masters".  When I started this article I had been looking at positions on-line and I noticed a mix of definitions for the same work: Programmers, Software Developer, Software Engineer, Analyst.

From Dictonary.com

• Software Engineer - a person who designs and writes and tests computer programs 
• Software Developer - No Definition
• Analyst - a person who analyzes 
• Programmer - a person who writes computer programs.

Researching this post has lead me to the following conclusion.  A Software Engineer and a Software Developer are modern terminology for Analysts and a Programmers as Software as a field gets older and understands itself better.

Long ago we compartmentalized the field.  Analysts analyzed the needs of the customer and came up with the design then handed it off to programmers who actually created the application.  As the field has matured we learned a little bit about ourselves, we all like to design but secretly need to create too.  Software Engineers and Developers have come to embody a unified process of design, development, and implementation.  As you go up the technical ladder you design and mentor more than you write and test, but those things do not go away absolutely.

What is the difference between engineers and developers?  At first glance an engineer is a highly exact individual from a school of engineering.  However, in reality the difference is field of work.  Web companies, business groups, and application centered hardware agnostic positions tend to be described as Software Developers.  Technology companies and hardware centered positions tend to be described as Software Engineers.  As members of the software field both have to design the application to the users specification, write the application, and develop tests of that system.  Its the nature of the field.