I'm inspired to write this post because Someone Is Wrong On The Internet. Of course a more accurate statement would be "I disagree with some aspects of what someone on the internet said, even though they have an entirely valid point of view". But that's less catchy.Continue reading "Reading Code is a Skill"
Mandatory initial exclamation about how little I have blogged here lately. Over a year without updates, oh dear! But a) I have been blogging quite a lot for the IntelliJ IDEA and Upsource blogs, and b) I had another baby, which kept me quite busy.
So on that topic (more or less) I get a lot of questions about my job: what’s involved in the job, what’s it like working for JetBrains, what does a Developer Advocate do, what’s it like working remotely etc etc. Given I also rather generously1 recently offered to answer people’s questions about my job, I thought the most scalable way was to write-once-read-many, i.e. write it in a single blog post for everyone to read.Continue reading "Being a Developer Advocate at JetBrains"
So I came to the blog to update my upcoming events (at least something stays up to date) only to find it's been nearly a year since I last blogged! This is terrible!
It's not that I haven't written anything in a year, it's that a lot of my writing energy goes into stuff for the actual day job. Which is good, because that's pretty much what I wanted from the day job, but the blog makes it look like I don't write any more.
So I'm going to cheat. Here's the stuff I've written in the last 12 months.
- A whole series of articles off the back of last year's Java 8 in Anger talk: Five Java 8 Features That You Won’t Be Able to Live Without, Why Java 8?, and Java SE 8 in Practice.
- A tutorial on TDD in IntelliJ IDEA. I have video clips to turn this into a screencast as well, but that's Yet Another thing I didn't get around to.
- A tutorial on how IntelliJ IDEA helps you migrate code to Java 8. This evolved into the other thing I've been working on this year, my latest live demo presentation, Refactoring to Java 8.
- A whole series of blog posts on "What to look for in a code review". This was fun and satisfying to write.
- ...which got turned into a book. Yes, I'm finally the author of a book!
- Java 8 Top Tips, with a bunch of IntelliJ-specific tips
- I've taken over Java Annotated Monthly, so at least you get to hear from me once a month with that. I try really hard not to be too sarcastic, jokey or British when I write the newsletter. I don't always succeed.
Oh yeah, and I had a baby. I'm contemplating blogging about being a working parent, but I'm a bit concerned that Of Course a woman is going to blog about Being A Mother, when previously I just blogged about... well, come to think about it I blogged about all sorts of things, including haircuts and hangovers, so I guess I could probably get away with it.
So, I get asked a lot about how I got into technical advocacy / evangelism1, so it seems like the most cost-effective way to answer this question is to write a post about it. Warning: it's a long one!
Just over two years ago, I embarked upon a journey as a developer / evangelist for a company who was then called 10gen (who got fed up of saying "the MongoDB people", and transformed into MongoDB Inc). My goals for this role were: to learn what it was like working for a company that produced a technology product; to discover what impact working in an open source fashion has; and to level up my advocacy skills. I have met all these goals, and more - I met some fantastic people; learnt different approaches to software development; discovered my new favourite database for creating applications; moved to Spain; started both a MUG and a JUG; worked to understand the value of community and evangelism, and to help create a strategy for these areas; and my evangelism efforts and open source work earned me the Java Champion title. I'm extremely proud of what I've achieved over this period, and very grateful to MongoDB for giving me these opportunities.
But now, a new adventure is about to begin. If you've seen my live coding demo this year, you'll know of my love affair with IntelliJ IDEA, a tool I use daily (even for blogging). Well, now I'm joining the team at JetBrains, where I'm going Full Advocate. I hope this means I get to carry on doing more of what I love - presenting, writing, and working on demos to help developers become more productive. I hope this will give me opportunities to stay ahead of the curve in the Java/JVM world.
And yes, in answer to the Most Frequently Asked Question, I am staying in Spain. I've fallen in love with Sevilla and I'm not ready to leave yet.
I shall leave you with my somewhat disasterous "Top Ten IntelliJ Tips" from GOTO Aarhus, which is worth watching just to see Dan North save me from the curse of the live demo. Things can only get better from here, right?
Since I have a tendency to bang on every now and again about how we, as developers, could do better in managing our careers (for example, by creating CVs that don't suck, and by staying ahead of the curve), Dave Thomas asked me to speak for a mere 50 minutes on the subject at GOTO Aarhus, a talk I wasn't enormously happy with as there was no way to cover a lifetime of hard-fought experience in such a short time. Dave seemed to like something in it though, as he gave me the opportunity to present the topic again at YOW last December, and this time I think I managed to distill the important points into the (still ridiculously short) time allotted.
Please give me any feedback you have.
I recognise there are many many more topics I could cover, so I'd better start making a list. Suggestions?
December disappeared in a rush of vacation and a fleeting tour of Australia. It's hard to believe that it's the eve of Christmas Eve already, it's almost impossible to feel Christmassy when you're getting sunburnt on a boat and seeing people in swim-suits wearing santa hats. A mid-winter festival (complete with trees and fake snow) just feels very odd in summer.
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.
I'm at the end of my first official week doing support for 10gen. My major achievements are:
- Learning how to work the coffee machine in the Dublin office. It's taken me a week to get it, but now I can understand the machine's needs. Even if my coffee did taste a bit of cleaning fluid this morning.
- Navigating around Dublin - I led the way to the pub, followed by two people who live here. Turns out I know the most efficient routes between work venues and pubs, even in a town that I've never been to before.
- Closing all outstanding Java driver pull requests, except for the one we want to merge but needs to be updated. This is a massive win for us, now we can actually stay on top of them instead of wondering which are valid and which ones we're actively ignoring. I hope the CTO isn't peeved I closed one of his from two years ago.
- I got my highest scoring day on StackOverflow yesterday, receiving a "whopping" 67 points in one day. Be nice, I'm quite new to SO - despite being on there for over two years I'm really only just starting to feel comfortable there. One day I might actually ask a question.
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:
Customers want to be heard
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.
The Java Ecosystem is alive and well. In fact, it's a monster...
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.
Where is the problem?
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.
Having people to help you is dead important
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.
What I like about support at 10gen
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.
- Doing support is so important for developers. Getting an understanding of what your users are doing and what their pain points are can really help drive your design and your architecture, and can really motivate you to fix that stupid bug or write that overdue tutorial.
- Developers and support techies can learn off each other - I've learnt a LOT off the guys here, but I've also been able to answer a few questions about Java in general and the driver in particular.
- Scheduling time in support for developers is a very tricky balance, and probably needs to be experimented with a bit before a company finds something that works for them.
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.