Minority Opinions

Not everyone can be mainstream, after all.

Archive for the ‘Employment’ Category

Inconvenience Class

leave a comment »

I learned Java in college, and even preferred it over C++ for a while.  Since learning Python, however, I have barely touched it.  That might change if I get GLX working on my LFS box, so I can run the Android SDK, but I’m not exactly looking forward to it.

It’s not just the language that bugs me, though there are plenty of sharp edges to cut yourself on.  No, what really baffles me is the culture that has grown around it, full of excess verbosity.  Public getters and setters that do nothing but get and set a private variable, just in case they might sometime need to do something else.  Factory classes, because you can’t just pass a class.  Thousands of tiny methods that obscure where the real work gets done.  Hundreds of files, because each individual class needs its own.  Deeply nested hierarchies, just in case your code gets used with something that might have a conflicting name.

Read the rest of this entry »

Advertisements

Written by eswald

12 Mar 2013 at 7:35 pm

Posted in Employment, Technology

Glacial Swiftness

leave a comment »

I spend most of my time on one of two speeds: lazy or thorough.  My co-workers frequently compliment me on how fast I get things done.  Reconciling these facts takes a bit of mental gymnastics.

When I’m assigned a task, I usually figure out how to do it with the least amount of tedious busy-work on my part.  That can involve writing a program to do the busy-work for me; it may use less of my time, and will often be more accurate.  As an example, I once had a co-worker who was assigned to port a set of quizzes from MS Access to MySQL.  There were tricks involved, of course; the MySQL schema had separate tables for courses, activities, questions, and answers, where the Access database had a separate table for each course, with each question’s answers lumped into a single field.  He convinced Access to export the tables as CSV files, and wrote a PHP script to import each row into MySQL, but had trouble convincing PHP to parse the rows.  Question text frequently had quotation marks and commas, and the answer field separated answers by newlines.  He spent two weeks manually unquoting fields, replacing field separators with pipe characters, removing newlines, and placing carriage returns between rows.  (No, he didn’t use a Mac.  I’m still uncertain why he thought carriage returns were the Unix convention.)  When he left, I was asked to finish the job, and to clean up the incorrectly imported answers, so I wiped out his pipe/CR files, re-exported the Access tables, and read them with fgetcsv().  I hadn’t even been aware of the function, but it was in the top page of search results.  The entire process took less than a day.

More often, it’s the second speed that facilitates my laziness.  I have now been working on a single program for over six years, and have written, modified, or at least checked in about 85% of the code.  I’ve written all of the test cases.  I understand it thoroughly, from the interface to the database.  That makes me uniquely qualified to determine the easiest way to perform a given task.  Sometimes it’s a database query.  Sometimes it’s a code change.  Sometimes it’s handing a set of links and instructions to someone with more time for busywork.  Sometimes it’s just too complicated for the allotted budget.

That program isn’t the only thing I understand thoroughly, of course.  I enjoy figuring out the inner workings of complicated systems.  I once counted seventeen different levels to my understanding of computers, including software, hardware, and fundamental physics.  I’ve learned more games than most people are aware exist, and frequently win on my first time playing.  I’ve read about linguistics, traffic, geology, astronomy, and history simply because they were fascinating.  In fact, my laziness usually manifests itself in reading or learning something, quite possibly something tangentially related to whatever I’m supposed to be doing next.

The main areas I don’t yet understand are psychology and literature.  Those are the domain of my spouse, so I’m gradually picking up a few things; for example, I finally learned what my high school English teachers were trying to teach.  Perhaps that’s why I write: this blog was started as an attempt to communicate or at least understand my companion’s rants.  Granted, I haven’t followed through very well, probably because they’re not my own ideas; fortunately, it’s now possible to find some of them elsewhere.

In any case, that need for thoroughness might explain why I feel uncomfortable satisfying my weekly post obligation with something short.

Written by eswald

15 Jan 2013 at 6:18 pm

Beeminding Git

with 2 comments

After trying out Beeminder to get me to write more, I considered having it make sure I was getting actual work done at work.  Nearly everything we do is in a repository, lately git, so it made sense to base a graph on commits.  Sure, I could base it on time spent, but that’s even harder; I have utterly failed to get accurate counts of the time I spend on anything.  Besides, the results are more important than the process.

With that decided, there are two key metrics that commits give you: The number of commits, or the number of lines changed.  If you do anything resembling a large amount of work on a single commit, the former is grossly understated.  With any amount of copy-and-paste or other trivial changes, the latter is grossly overstated.  Together, they can give you some sort sense of what was happening, but for graphing, they’re probably more lies than reality.  They can also be easily gamed, so never, ever, use this as the basis of any sort of payroll or employment decision.

Read the rest of this entry »

Written by eswald

10 Jan 2012 at 6:42 pm

Posted in Employment, Technology

Database Lessons I’ve Learned

leave a comment »

Almost as soon as I started working at my first real full-time job, I was assigned to work on a website that was causing major concerns for the company’s largest client.  It had grown organically from supplemental material to critical information, and parts of it were so slow that it was almost unusable.  Fortunately, I had already used MySQL and PHP, the most important pieces of the site, so I was able to make some headway.  However, some of the lessons I’ve since learned would have made the whole process much simpler and faster.

Read the rest of this entry »

Written by eswald

25 Oct 2011 at 10:45 pm

Posted in Employment, Technology

Gatekeeping Nightmare

leave a comment »

I just woke up from a dream, and couldn’t relax enough to sleep again.  The big problem is that it was entirely too realistic.

The company posted on the break room wall a financial document, listing contributions to various projects and the income they generated.  (That this was a scrollable document on paper, I attribute to dream logic.  That such a document would never actually be produced, I attribute as much to the impossible accuracy and understanding required as to the culture of privacy about actual salaries.)  My supervisor then turned and named me as one of the top generators for the company, and said that upper management would like to see me in a sort of “gatekeeper” role.  That scared me awake.

I can’t dispute either statement.  I do generate a lot of code for the company: Commit logs show my name about half the time, for six- to ten-man teams.  (We do have a woman on the team, but she’s QA; her contribution is bug reports, not code.)  Granted, that’s largely because I commit in smaller chunks, probably because I treat the commit log as part of my knowledge pool, but my name also shows up on massive swaths of the annotate command.  I also have two major areas of responsibility: the “old” product line (meaning the one that makes us money while we work on the one that the sales team promised would be ready by now), and integrating our three product lines with all but one of our clients.  Combined that with a few minor responsibilities within other areas, and we get a lot of talk about clearing my plate.

Granted, there’s a wrinkle in that I don’t actually write the product that we’re selling.  I only write the delivery mechanism.  And the old creation mechanism, but it’s been superseded by a new one that I hardly ever touch due to the language it’s written in.  For very good reasons, despite the pain.  That leaves my team entirely symbiotic with the content development team, which is one very good reason the financial report could never be written honestly.

Neither can I dispute the gatekeeper part.  I can see my future in my own supervisor, who has been managing instead of coding since about the time I was hired.  What code I’ve seen from him has been good, but he’s been needed to explain technical realities to the grand visionaries who dictate the company’s future.  He also has the ability to recognize good code, which has probably saved my job on a few occasions.  I’m absolutely certain he would like me to teach what I do to the rest of the team.

I’m nearly as certain that I simply can’t do it.  I’ve tried to teach at church, at school, and at work; every experience has been closer to disaster than success.  My best teaching experiences are thought-provoking comments in a discussion led by another; even then, I have failed to comply with a request to repeat myself.  As a guide for a self-directed learner, I’ve been halfway decent, but that’s less about sharing what I do than the path that I took to learn it myself.

The worst times have been when I was asked for a “brain dump” in front of a blank whiteboard.  After a few minutes of incoherent rambling, I can sometimes elicit a real question that can only be answered by looking at the code.  Even the simple questions that I field on an almost daily basis, frequently from the help desk, usually require a code scan, because I simply don’t keep that level of detail in my head.  What I do keep in head is a basic overview of how the code flows, a set of guidelines for its ideal state, and a set of places and methods to look stuff up.

Perhaps I could be a decent pair-programmer, which would give me a chance to show what I do.  There would be some major frustration, particularly over the choice of editor, but I might possibly be able to work something out with a willing partner.  Simple delegation, however, has proven beyond my capabilities.  Either my wingman is frustrated with the lack of direction, or I’m frustrated with the lack of quality, or my supervisor is frustrated with the lack of progress.  If it’s faster to do it myself than to explain how to do it, then why exactly am I delegating?

Granted, that’s probably why I have responsibility for two major areas of the code base.  I’m the only one who knows how they work, and I don’t know how to explain it except by guiding someone through the code itself.

Written by eswald

29 Aug 2011 at 5:57 am

Posted in Employment

Support Staff

leave a comment »

As a programmer, I find it easy to get annoyed by the constant requests for timesheets.  They don’t really mean anything, and there is no good way to fill them out accurately.  However, when the same department is suddenly in charge of turning the water back on, it’s much easier to appreciate the work that you never see.

Part of that reminded me of question 4.5 in the Manager FAQ.  Several of its other questions offer helpful reminders, too.

Written by eswald

17 Nov 2008 at 1:15 pm

Posted in Employment

Tagged with