In an effort to showcase what makes ReadyTalk Engineering one of the best teams to be a part of, we have decided to provide a series we are calling “Inside Edition” to give our readers an inside look as to what makes ReadyTalk Engineering click! We have selected an engineer to provide a personal description of their experiences at ReadyTalk!
Inside Edition with Matt Weaver
Describe a typical day for you at ReadyTalk
It's 8:17and I may or may not be fully "awake." My level of "awake" is inversely proportional to the level of sunlight and warmth in the morning: the longer and colder my bicycle commute (due to ice, Taun Taun traffic, etc) the more I need heart palpitating levels of caffeine. It's 8:17 and when that empty stomach, caffeine high kicks in a minute or two later, I'm working. Music on the headphones, a brisk tattoo pounded out on the poor keys of my keyboard and I have tapped the sweet mainline of productivity. My god. The thoughts are kicking, ideas are flowing, and I can't type fast enough, nor compile quickly enough to see things in action. This is prime time for productivity and, aside from a few Nerf based skirmishes (my god, the darts… the darts… orange tracers in my dreams, oh humanity!), the window between eight-whatever and noon is a smooth code jam… did I just type that? (did I just break the fourth wall of narrative?)
As the lunching hours approach, if I'm not too involved (because sometimes I am) I am faced with a use of time type quandary: if the weather's warm or, at least, not icy, I may throw a leg over my road bike and try to squeeze in a twenty mile ride, I may just ride to my favorite record shop to enjoy the fresh air or meet an associate in the park for a lunch gab session, or my coworkers may cajole me into a lunch somewhere in lower downtown. Today it was a lunch at Ted Turner's bison loving burger chain replete with work discussions, jokes, yelling, crying, and jokes. Did I mention the jokes?
Afternoons are a fine time for meetings… because even if I haven't attempted to ascend gluttony heights (e.g. I worked out and am drinking a horrible protein shake or my own sweat and tears… that is, nothing), I'm never that productive. So a meeting or two. Today a coworker has questions about a software design. We scribble on a white board and raise our voices. We lower them and agree. Ideas are fielded, white papers are read, articles are linked to, social networking sites are updated (no day is complete without the tangy smack of narcissism, you have, of course been reading this tripe…).
And the day ends. Some days, the team may go out for a cocktail or two. Others, I work into the night, not because I'm forced to, but because I've had a new surge of productivity or I've solved a problem, and riding that wave is worth the personal sacrifice. Still others, the day ends uneventfully (except for another round of Nerf darts, fired for effect… war never ends, war never begins) and I ride home to my girlfriend, my dog, and my non-work friends.
Today, I pack up my Macbook and ride home under twilight.
All this is merely evidence that my job is pleasing: a design challenge here, an obstacle there (why won't the Cocoa API actually respond to this call… grrr), and the day is over. It's a rather good thing.
(Re-read abovefor the story, but…) I work with far less process and far less constraint than in other jobs I've had (I've been writing software as a day job since my internship in 2000). I like the people I work with. Those are givens and, honestly, not enough reason to work somewhere (though they can easily be enough reason to "not work" somewhere). The real reason(s) I like my job? I ride to work in a decently sized city. I like my coworkers and I've worked here long enough to have roots in the company. I enjoy the problems I solve. I enjoy the work life balance afforded by the company. I can work from home, if I have to. I come and go as I need to. It's a job that places much trust in me and, as trite as it sounds, supports my urban-bent lifestyle.
Tell us about your favorite day at work…
This is rather a harder task than you might imagine, for I've just had too many high points to single out one. That's the problem with having a "good" job. But it's dishonest and rather cheap to just hand wave and say "they're all good days" because that doesn't really sell it, it fails to say anything useful. The qualities of a good day, a great day, involve balance: solving a long standing problem, figuring out a design that hits home in usability testing or a software design that solves many problems, affecting the outcome of a project for the better, leaving work early to meet an out of town friend for a drink in uptown… it could really be any number of things, but to strike that balance is particularly important. But, a singular day that presents itself was a demo of an Android based version of our service. I woke up early, unable to sleep. I had tried not to take the project home with me, but I did. I sat at my Eames knock off table and sipped my way through half a bottle of bourbon fixing bugs and trying to add some much needed polish to our application. Then I went to bed… and didn't sleep. So I woke before the sun rose and rode in. A coworker and I had ported much code and sketched out much of the design of a new client that was built on newer ideas and utilized newer technologies from several open source projects. We tried not to, but we coded all morning before the demo. It wasn't a product demo, it was a research project. And after that presentation, we sighed heavily. It was a sort of high, a rapturous glow in which we felt like we had done something. It had taken a few nights and a few weekends, but we had built something new from near scratch and it felt good. That, devoid of any other trappings, was one of my best days at work.
What's that joke about advice? Or no… that's opinions I'm thinking of. We all have them, etc. (Insert laughter here). My advice would be incomplete, but simple: be teachable, be curious. I forget things (I blame whisky). I learn new ones. Failure to admit my own ignorance about something stupid is a waste of my time. I'd rather look silly for a moment ("what server is the failover production db?") than get in the way of forward progress. That's more important than any other advice I can give you. If pressed about my team, the client portion of our real-time application, I'd add this, less noble sounding advice: know when to delegate. If you don't get excited by good UX or have skills there yet, there are people who can help you or do that part of a task. If you are uncomfortable with an architectural piece, either in the system or in the client code, ask someone. Bring it up. It dovetails nicely into that other rot, but it's worth noting. The best way to learn and all that.
Katie Green is part of the ReadTalk Recruiting Team (AKA the Beaphins) She has been in the recruiting industry for 10 years and has developed a strong interest in technology and technical recruitment. When she isn’t searching for technical talent for ReadyTalk you might find her at the tennis court, playing volleyball or learning a new song on guitar!