Things I've Learned from my Coworkers

[pinterface]

I started another post only to discover I had written this about a year ago and forgotten about it. So while I spend some time polishing up my next post, enjoy my thoughts about my current job as I had them approximately a year in.

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 application¹ 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 far²).

Me in the present here. That openness―that lack of ego about one's own code―is something I continue to greatly appreciate, and strive to attain in myself. I do have an ego, and sometimes have to calm myself down when other people touch my code. Fortunately, my coworkers provide great examples to follow in this regard.

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) {
  do_thing();
}

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.

Footnotes

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!

Comments

curry/filter

[(Anonymous)]

LOL, I get that a lot too, have to actually did a major refactoring because my code feels too lispy to others

- @Jeffrey04