Developer Champion
InfoQ has posted the video of Dan North and I opining on the subject of hiring. Most of the talk is spent on how to be a good interviewer, and touches on how to market your company to prospective hires. We spend less time on how to do well as an interviewee, but in theory if you know what's going through the interviewer's mind, you should be in a much better position to take control of the interview and shine.
Continue reading "Life on both sides of the interview table"
I'm at the end of my first official week doing support for 10gen. My major achievements are:
In all seriousness though, I learnt a LOT this week. I've been with 10gen for about 9 months now, so although I feel like I should be a fully fledged member of the team there's still a lot I don't know about. In particular, as I hadn't used MongoDB before working here, and as I'm head-down on delivering the new Java driver (more to come on that later, I promise), I don't see a lot of how people actually use the database.
I've been lucky because this wasn't a heavy week for customer support, so I've been available to pick up "free" support - basically take a look at questions people are asking on StackOverflow and the MongoDB Google Groups and see if there's anything I can answer. Obviously I focussed on the Java side as this is the area I'm most comfortable (and there are only a few of us to answer those questions, and plenty of others to pick up more general questions).
So here are my Lessons Learnt:
Responsiveness is almost more important to (paying) customers than detailed answers. They want to know that you've seen their problem, and you're on it. So sometimes it's best to answer a problem with a question or questions, asking for clarification on their situation and explaining any assumptions you have. It turns out that writing that long and detailed explanation of the steps they need to take isn't really necessary when you've figured out what they're really trying to do and response with "this is going to require production downtime". Suddenly it's not as urgent for them to fix this right now.
There really are a remarkable number of libraries/third party apps that people are using on top of our basic Java driver. This week, I've been trouble-shooting people using Morphia, Spring Data, Jongo, Grails GORM, as well as a lot of people who are using the driver directly. I've learnt a lot about installing and using all these things, as I've had to do that to reproduce people's issues and suggest solutions1. I've learnt that some of those things make life quite a lot easier, especially for the happy path of Java developers who simply want to save Java pojos into the DB and query for them afterwards.
I've also learnt that querying is quite inconsistent across all the libraries, and I'd say the main problem that users have is turning an understandable query from the shell into something that the library they're using understands.
Also, Dates get people every time, particularly in Java.
Related to the previous point, when a query returns nothing it's difficult to work out: if you're using the library incorrectly; if the Java driver doesn't support various options; or if the database isn't doing what you expect it to. More often than not the problem is not understanding how to use the tools (and the onus is on us, the library developers, to make it as easy and unsurprising as possible for developers), but sometimes it's a bug. Tracking down the root of the issue is important, because if it's a bug we should log it in the correct place, and if it's working as designed it suggests a lack of documentation or possibly a design flaw.
I could have done this from home, from the London office, or even from the beach if I'd wanted to. However, I opted to come to our Dublin office where we have our EMEA support, because I knew that alone I'd try and dodge the work. Not because I don't want to do it, but because I don't know our processes, I don't know if we have a knowledge base I can use, I don't know if my answers are correct, and so on and so on. When you're uncertain, sometimes the easiest option is to run away. But when you're embedded in the team that does this every day, you can ask the stupid questions and get help rather than sit and feel stupid.
It's also nice to be part of a daily standup so you can hear what other people are up to, and it puts a (good) subtle pressure on you to do something so you have something to report.
I've done support before. In fact, during my last year at LMAX I worked out I spent the same amount of time on the production support team as I did working on a team delivering new features. But since I've never worked for a product firm before, I haven't done this sort of support. 10gen makes its money by selling support contracts, so not only is it important to keep the SLAs with the paying customers, but it's also important to provide excellent quality support for them - with any luck they'll keep paying. It's also important for us to support those who don't pay - it's kinda like a teaser of the great quality they'd get if they paid us.
So the support organisation here is absolutely key to our bottom line.
The driver developers (of which I am one) are "strongly encouraged" to do a week of support every three months. We used to do days here and there, but blocking out a whole week to be part of the team, to be excused from your day job, and to leave your e-mail (and sometimes meetings) alone because you're busy doing support, works really well. I've felt very focussed on the support role during this week, and I've been motivated to do a good job. If I had been seconded to the team for a period of weeks, I would have dreaded the whole thing and have plodded along doing my time until my escape. Alternatively, doing it for a day at a time the support issues leak into the day job and the day job is hard to put down during your support hours.
I've learnt a lot this week. I have been lucky, I've had fairly straightforward issues to address and it hasn't been a busy week. But next time I see the support week looming in my calendar, I won't fear it as much. I'll probably do the next one from home, but my week here in Dublin has prepared me for what's in store. Most importantly, I've got to know the people who are part of my team here, so I'll be more comfortable asking the stupid questions.
Although I'm never really going to love being on support, I still like being encouraged to work on support regularly - it's been so important for my understanding of our product and of our users.
1 I found Grails BY FAR the most difficult to get started with - all I wanted was to write a unit test to prove the issue, and I had to not only create a whole application using the grails command line, but I had to install a whole host of plugins and uninstall all the stuff for hibernate that gets put in there magically. I never did find the solution to the Grails problem I was looking at.
I was flattered a couple of weeks ago to be interviewed by Google as part of their women techmaker's series, as it moves over to Europe. In this video I talk about going to Mars, education, planning your career, being a developer, and the impact of technology on our lives. So, not much...
Continue reading "GDL Presents Women Techmakers with Trisha Gee"
I had an interesting discussion last night at the LJC developer sessions, and it's a topic that comes up again and again:
My next few talks are where I finally start speaking about MongoDB. After 4 months working for 10gen, I still feel completely under-qualified to speak with any authority on the subject. It's very different joining a company with an established and growing product, to joining a very young company and being in on the development since practically day one. But I've been working on designing the Brand New Java Driver, so that's what I'm going to talk about.
Continue reading "Upcoming Events (and Trisha Freaks Out A Bit)"
Yesterday I had the nerve-wracking dubious alarming great pleasure of presenting my first official MongoDB-shaped talk. This was in the form of a webinar, which is an interesting and different format.
The time has come, and I'm moving on from LMAX. I've had an incredible (nearly) four years working for one of the most radical finance firms in the world, during which time I feel I've learnt more than the rest of my work experience put together, and had the pleasure to work with some of the smartest and most interesting people I've ever met.
When you're applying for a job at LMAX, your CV (or résumé, for our American readers) usually comes through me and I decide whether to call you for a technical phone screen.
I'm going to let you into a secret.
The last two weeks, actual work has conspired to keep me away from the blog. How rude. I miss "the beach" already.
It seems only fair to summarise the lessons I have learnt whilst masquerading as an architect on a short consulting stint with Marc McNeill. Simon Brown at Coding the Architecture is much better at talking about this stuff than I am, but I need to update the blog with something!
Continue reading "For those who might want to make the leap from Developer to Architect"