Category: Work culture

organizational culture, work environment

The Ends do not Justify the Means: The Necessity of Code Review

Hopefully this post does not sound like just a rant as I admit that this post has come up from my frustrations from using other people’s work, but I think this is particularly symptomatic of areas where there are not always IT experts, as is the case with many libraries. I also do not boast that I always know what I’m doing, but that’s why I think it’s invaluable to have some kind of code review process.

Making it Simple

As a general rule, better to make things as simple as possible rather than using complex methods if they both achieve the same things. I’ve been told that simple and clean code is the best kind of code.

There may be efficiency concerns involved, but then that seems to be left behind in the cases I’m talking about anyway. (Case in point, our website had 5+ CSS files, not all which had clear purposes, many of which were overwriting each other’s classes, which I had to rework into two files.)

Document and Comment

While some of the simple things might be obvious and self-explanatory, I don’t think I’ve ever seen anything over documented/commented in the ‘real world’ (as opposed to school work), so more is (generally) better. I think it’s doubly important where the creation of a product/tool might be outsourced, but the maintenance of it is done in house (as frequently seems to happen), that the code can be understood by a new/beginner programmer-type person.

Too often I have looked at code recently and thought “what does this do?” or “how many pages does it affect?” While I admit that it’s not always easy to know what or how much needs to be documented, because you don’t always know who will look at it in the future and things you write yourself tend to make sense, but do at least a minimal amount of documentation and commenting.

On a side note, do not name files or functions after yourself (one former student’s name is now unforgettable for that reason and this was created months before I started).

Get Feedback

Ideally, there is someone who is an actual programmer on your team or in your unit who you can ask to take at least a quick look over what you’ve done and give you feedback on whether you’ve done it correctly. If there’s no one ‘inside’, consider asking someone on the ‘outside’.

Within a team or unit, if there is more than one programmer-savvy person, consider establishing a Review/Feedback step in the process as you typically see before code commits (if this doesn’t already exist of course).

If you really can’t get feedback from someone else, then much like editing your own writing, step back from it (for, preferably, a couple of days) and look at it with fresh eyes and ask yourself some of the important questions, but namely:

would someone else be able to step in and easily understand what your code does?

Supervising Students

I believe that all the above points apply when working with students too. It’s okay if you’re not a programmer. At least take a brief look at the code, see if commenting is done, ask about the general process/framework, ask if they think a beginner programmer would be able to understand their code easily, etc. If you ask, it will at least make him/her think about it!

My Point

The end product does not mean it is what you want. Other people also need to be able to maintain and customize/modify. This all seems so obvious, but I think it bears reminding sometimes.

Code4lib Day 3: Keynote #2 Lazy Consensus

by Bethany Nowviskie, University of Virginia

She began by expressing that it is great to have a speaker from the inside the community and lots of thanks to the invitation to talk. Then continued to talk a bit about her background and where she is coming from, including Blacklight and Hydra. She is now in the library world, where she was introduced to many issues such as open access, class issues.

Lazy Consensus

Frequently, lazy consensus gets formalized, such as in committees. When a decision needs to be made, a proposal is put forward. Some might agree, but the default answer is yes. If there are objections, then you go back, but usually just some adjustments. In order to object, people need to take the time to think and take the effort.

Some might think that there are fortunes for the bold. However, with this social contract where  we already agree that if you don’t say yes or no, “we’re not waiting on you,” inertia can work with you or against you.

Chaotic Good

Your team should work in lazy consensus. Use it to do what you know is right. How do you know what’s right? Make sure you’re one of the good guys. Act and speak up when you need to.

Ideal Conditions

  • skunkworks / R&D operations – trust them to have a plan
  • developer-driven 20% time
  • rabble-rouse… in disguise – organize smartly to fit in
  • knowing your enemies (trends, not people) – extract personalities, because usually fighting bad trends, not people
  • finding your friends (people, not just trends) – check data preservation, open access, digital humanities people

Your (Ethical) Obligations

  • always share information freely – it will fail otherwise
  • never shut out the public services and user experience
  • practice what you’d teach – think mentoring a promising novice
  • if you screw up, confess
  • try not to screw up in the first place

In Applying

If you have a bad technical plan, the library administration might not notice whether you implement it to the letter. They probably care more about the spirit than the letter of it. However, do genuinely try to explain to all levels of the organization.

Never do it alone. The word consensus is in there for a reason. You need enough people who agree on the direction to take that can be implemented reasonably and sustainably.

Keep talking to people.

Produce

If you produce, administration will have your back, but then you need to deliver a product that will make everyone look good, even the dead weights.

Involvement

The library is not involved enough in larger issues at the university, national, or government level. One common example is the research that is produced, peer-reviewed, and then sold back to the university at exorbitant prices.

It’s up to you to make contact with the leadership level of the organization. If you have a problem, put it on the agenda. Make the first move.

Shift Needed

There should a bias toward action. Stagnation is a far, far greater danger than taking measured risks.

Drive it like you stole it.

Q & A Comments

Does this reflect reality? Sometimes it is the person. – Act like it is the trend, even if it is the person. This will work better in some areas than others, but it is flexible.

Some believe that they are righteous and do not care about consensus. – Power to the people. Get enough of the staff to implement a directive.

How to deal with it going wrong? – Hard to do sometimes in formalized way, and need to do collectively.

EDIT: Bethany has now posted her version of the keynote talk on her blog.

Code4lib 2012 Pre-Conference: Digging into Metadata

The afternoon pre-conference session was Digging into Metadata: Context, Code, and Collaboration presented by:

  • Becky Yoose, Grinnell College
  • Corey Harper, New York University
  • Shana L. McDanold, University of Pennsylvania via Skype, and
  • Laura Smart, Caltech.

It was great seeing a big mix of people, many of them neither cataloguers or coders. I have put in below my annotated version of the slides (see presentation link for link to original slides).

I apologize that this is actually a set of images (WP doesn’t support embedding of PDFs and I didn’t want to put it on slideshare/issuu), but the PDF version is also available.

The links: History of ILSs and $judgement (warning, this may hurt your eyes).

The Whirlwind of Getting and Starting a New Job

I got a job! Mind you, it’s a contract and not a permanent job, but I think any new graduate will agree that even that is a feat when looking only within Canada, and being at least somewhat particular about what job to accept. In light of the whole process, I thought I would reflect a little on various aspects of getting and starting a job.

Prioritizing

I think it’s important for every person to decide on what they want in a job before applying to everything. Totally common sense I’m sure, but strangely for me, it took some time to really figure out what I wanted in terms of:

  • type of position – willing to take anything? including non-professional positions?
  • location – willing to move? what regions? urban or rural?
  • type of organization – libraries only or other information organizations?
  • salary – is there a minimum amount?

I’ll not spend time on the application and interview parts of the process as I’ve covered them before in other posts. I will only say that while it’s important to be flexible, you might think about whether you’re willing to spend money on flying somewhere if the organization will not pay for you.

My Interview

My interview was a particularly interesting situation as due to the available times, I ended up doing my interview after a 10-hour flight which I was sick on, 1-hour train ride, 20-minutes car ride, and a few hours to prepare and feel better. We also had a couple of technical difficulties, but I took them in stride (always have a back up plan!) as well as I could.

I also got asked a lot of questions about things that I honestly just did not know about. JAZZ? REST? Huh? Others I knew, but had absolutely no experience in, like AJAX, ColdFusion. I admitted to being unfamiliar with them and tried to emphasize that I am willing to learn (though I felt like a little bit of a broken record by the time I was done). Still, I think the important lesson is not to be daunted by the questions, since the questions are asked of all the interviewees.

Negotiating a Contract

As a new graduate, I was very nervous about negotiating my first professional contract. Thankfully, I had just finished my management class, so I took the advice of my instructor and inquired about:

  • benefits
  • relocation
  • vacation/sick leave
  • professional development
  • higher than minimum salary by considering my student work

Some things were a simple ‘no’ as mine is a contract and not a permanent position, but then I would never have known without asking. I think the last is especially important since many graduates may think that their work as a student will not count towards their salary, and while at some organizations it may not get the same level of consideration, that does not mean it will not be considered at all.

Starting a New Job

It’s important to know where you’re going and what time you’re expected the first day (oh and knowing what to bring for HR form filling), but beyond that,  I think it’s okay to just take your time getting into it. Certainly, I’ve been a little worried especially since there are various technical things to take care of, but thankfully, people seem very understanding of needing some time to settle in.

Getting a Job Also Means Not Always Taking a Job

So recently, many people I know (including myself) have been applying for jobs. Although it may be tempting as a new graduate to take any job that comes along (especially a permanent one), over the course of a couple of co-ops and student jobs, I began to realize that one of the most important aspects of a job is the work environment. This may seem obvious, but again, as a new graduate, most of us would be happy to even get an interview, let alone a hopes at a job.

Red Flags

Even as new graduates, I think we should have certain expectations and if something throws up a red flag, we should be careful. If something throws up two or three, remember to reconsider whether you would take the job.

Say you get an interview. Great, right? Well, yes… but then what if some worrisome things started popping up? If say it was a permanent position, I would expect a lot of libraries to fly someone in for a second stage in-person interview. If they’re not willing, you might look into why. Budget might be a reason in the current economic environment, but then you might also consider whether the job is worth paying hundreds of dollars for the interview.

How was the first interview? Did you get a good sense of how people were like? Did you like the way that they did it? Did you feel like you were wasting your time? If you get negative ‘vibe’, research more about the library, ask colleagues and friends if they know anything. Think about whether you would want to work there for a year, for five, for ten.

Prepare Your Own Questions

I think the easiest way to get a better feel is to ask your own questions at the end of the interview. Again, this sounds obvious, but some people do not seem to be willing to ask questions such as:

  • How would you describe your management style?
  • How would you describe the team dynamics?
  • What do you like most about working for your organization?
  • Is there anything that stands out as a benefit to working for your organization?
  • etc.

I’ve asked these questions before myself and have gotten some pretty good answers from some and some vague ones from others. Vague isn’t always bad since it depends who your interviewers are, but on a panel, there should be at least one person who can properly answer each question.