pixel (pinterface) wrote,

  • Mood:

Things I've Learned from my Coworkers

The job continues to go well. Yay! I've even managed to pick up a few lessons.

It's not bad code, it's just different
As someone who has been historically quick to declare code crap, it's a refreshing change of pace to pick up on the attitude that maybe this code isn't crap, maybe I just don't understand it very well yet. And I'm trying to take that to heart: there's plenty of things in the code base that aren't the way I'd have written them, but that doesn't make the way they're written any less valid.
It's okay to go home
In spite of working at a start-up, all of my coworkers are older than I am, and nearly all of them have families. That means they go home; they understand being sick and prefer you stay home and not infect everyone else; they get that sometimes you need to call a plumber and will be working from home that day.
Bring up issues, then fix them
Being a lone developer for so long, I got used to "see thing I think is problem, fix thing I think is problem". I'm still trying to get the hang of when I can just do something and when I need to discuss it with other developers first.

Of course, my coworkers aren't perfect

Sometimes they worry about micro-optimizations

Is it better to use autoloading, or explicit requires? That leads to the question of which is faster, and regrettably, I fall into the same trap and respond in kind "Well, X is faster because of Y.". The real answer, of course, is that it's a micro-optimization which is entirely irrelevant to the speed of our application1 and we should be worried about which is easier to maintain.

(NB: We've since switched entirely to autoloading for code maintenance reasons.)

Limited experience "at scale"
Nearly all the other developers worked together at a prior company building a C++ application where each installation served maybe a hundred users. Naturally, this affects their perception of how to structure a program and what things are efficient, so there's a lot of functions which do things like return a resultset instead of a data structure to avoid the extra loop. Much of the code passes around row ids, rather than objects or arrays of data, so the db gets queried for the same data a lot. (We are making progress on this front, but new features tend to take priority.)
Limited web experience
I've found and either closed, or built tools which help avoid, numerous classes of web-specific security vulnerabilities.

But overall, I have the distinct privilege of working with some intelligent people who are passionate about their work, have strong opinions formed through years of experience, who nonetheless still maintain an openness to trying new ways of doing things (and that's no platitude: I've spearheaded at least half a dozen major changes thus far2).

But then, neither am I

Have yet to fully assimilate the formatting convention
The biggest annoyance to my coworkers is probably my habit of doing
if (condition) do_thing();
rather than
if (condition) {
But it's certainly not the only formatting difference I haven't managed to avail myself of. And even without formatting differences, I tend to write code in a very different style―if you ever come across the words 'curry' or 'filter' in our codebase, there are very good odds I touched that code.
Or, really, any of the existing conventions
Lowercase file names was the convention, until I introduced a lib/ directory and started filling it with mixed-case filenames which matched the case of the class names.
Accidentally co-opted the name of the mobile API
The API used by the phones was referred to as "the mobile API", or often just "API" for short. I introduced a new convention for routing AJAX requests to controller methods, and called it the "web API", or usually just "API" for short. This caused enough confusion that the mobile API was renamed "services". I still wince a little whenever somebody says "services" because it's my fault.

Of course, liking work does have some downsides

Because work is fulfilling, it's much easier to spend time working on work, rather than taking the hit of context-switching to a side-project on the weekends. I sometimes manage to not work on weekends, but that's very different from working on something else. So the various projects I maintain, or have plans to write, make no progress.


  1. Our deployment servers have APC turned on and configured to not even bother checking the filesystem for updates. That's a bigger performance win than any quibbling over autoloading-vs-require_once we could do, and even that is a pretty negligible difference.
  2. Our most recent hire has begun to spearheading a few, as well. Hooray for new hires not yet being numb to the pain points!

Don't you just love it when people move to a new blog? I'd 301 redirect you if I could, but since I can't you'll have to click through to read comment count unavailable comments or leave your own.

Tags: programming, work
Comments for this post were disabled by the author