Work: Some First Impressions

Regardless of how much I’ve been griping (offline) about training (it’s long, it’s occasionally ineffective and boring, it’s too detailed for some of us), work has been practically a revelation. What I’m working on is, besides being very cool, definitely Top Sekrit Company Stuff, so I can’t obviously blog about it. But I do want to note down a few impressions about the general culture of tech companies.

First off, it’s probably safe to say that the company I’m working for is large enough to merit comparisons to other major companies, and that their practices are in line with industry standards. So it means I can probably come to some conclusions about trends.

Processes, procedures, programs. I think any company that was founded as a pioneer, maverick startup that everyone wants to be a part of eventually becomes a huge monolith of an organization that needs and loathes red tape. I’m not saying I’ve seen that much red tape so far, but I can imagine how the millions of procedures would infuriate someone who really just wants to see their code in action. But my god it’s important. When you have a bunch of people working on a massive code base, code integration, revisions and build systems aren’t just convenient — they’re necessary. The sheer intricacy of this is both alarming and awe-inspiring. And important to respect.

Interconnectedness. Part of my training consisted of bug-fixing and how it works. One consistent theme of the presentation was how everything depended on everything else. I think it’s particularly true of companies that operate primarily online — you’ve got the web presentation layer, the mathematics underlying it, and below all that ultimately the hardware that keeps it going. And the best part of it all is that teams that work in domains that appear to be entirely separate will be using the same processes and hardware, and such a lot of it could go wrong. It can be a vertical (layers of applications) and horizontal (the breadth of services) nightmare. So it looks as though anyone entering the field would be very, very well served to know a little of everything, whether it’s about server technology, or XML.

Proprietary code vs. Open source. This is the most interesting, to me, because it implies an underlying philosophical debate, as well as an efficiency problem. What happens when you write all your code, ground-up, in-house, is that the learning curve becomes exponentially steeper for new hires. You’re spending so long training them that internships can only really be one long coffee-making session. ┬áThere’s also the problem of what happens when you leave: what are your transferable skills, exactly? I believe what a lot of large companies are doing now is whittling down the code that depends on home-grown solutions, and replacing them with some open source alternatives.

This has several repercussions. For one, you don’t spend months in training — you can look for enthusiastic coders, already at the forefront of technology, who can help your company adopt new tech. There’s often also a large and eager community of coders who are involved in the maintenance of this open source code, so there always seems to be someone willing to answer the questions you’ll invariably have.

Which brings us to the downside of open source. Since these programs are written by people who aim to make it available to everyone, they’re not exactly thinking of how it’ll fit into your┬ácompany. So things in the way of plugins will have to be custom made, or modified. It’s great solution… if it works!

 

I’m perfectly aware that this stuff isn’t exactly revelatory to anyone besides me. But I suppose I’ll at least get some entertainment out of it in a few years, when I come back to this post and sigh nostalgically at my naivete.