On curiosity and sharing with the world
At the end of December, I was contacted by someone I didn’t know, who asked me some interesting questions, and that led me to quite a bit of introspection.
As a Java Champion and with your career history. I wanted to ask you what you consider are the most important skills for a Java programmer to have in their toolbox, especially a Senior Java programmer? Or maybe even a better question is what skills you developed that helped you become the Java Developer/Groovy Language Developer that you are today.
In a nutshell, as I answered this person, for me it all boiled down to lots of curiosity, and the desire to share my findings with the world. It’s not really about knowing specific methodologies, technologies or languages, or which soft or hard skills to master. It’s about the core attitudes from which all the rest will derive from. But first, a bit of background about me.
A bit of history
Alright, so if I was contacted (and actually a few others as well) with those questions, it’s because I’m considered to be a visible and public person. Because I’m known for my work in the Java community and more precisely in the Apache Groovy ecosystem. I’ve been in the field for quite a number of years, along with my contributions in Open Source, and that makes me a senior developer. But how did I get there?
You’ve learned a lot during your studies, but often, not much of what you learned is immediately applicable in your daily duties and tasks. So there’s even more to learn to become a productive developer. I started working as a junior Java developer in 2001. I was lucky to have had a great mentor that helped me design and write better code. I also spent quite some time reading Java and development related news websites or blogs. I wanted to know what were the latest trends (new language features, frameworks), the best tools for the job, how developers were developing on their projects. So clearly, I was pretty curious to look beyond just what I was doing at work, but to see if I could become a better programmer by learning from others. There’s so much great content on the web, so much information that is shared, from best practices to bug fixes explanations, that you can learn a lot. That’s also more or less when I started blogging. I saw so many useful blog posts that helped me, that I thought it would be a good thing to share back things I learned that could be helpful to others as well.
In 2003, at work, I needed a way to extend an app I was working on, and clearly, some kind of scripting solution was what would allow the end-users of our app to further customize and tailor the application to their needs. So I spent some time reviewing existing Java scripting solutions, but none were really ideal. Fortunately, that’s when Groovy was born. It was embryonic, and not really ready for prime time though. But it was what I needed.
I started playing with Groovy, but quickly I encountered tons of problems and bugs. Since the code was Open Source, I started looking at its codebase, outside of work. I quickly understood where some of the bugs were coming from, and found ways to fix them. Since the community was pretty open, I participated in the mailing-lists to tell about those bugs, to help other users. It was nice to feel being part of a nice, friendly and helpful community.
I used the bug tracker to file bugs and feature requests, and when I could I even submitted some patches to fix these. My patches were accepted, and in a handful of months, I was asked to become an official committer on the project (which I gladly accepted). By working with the other committers, I learned a lot about Java, the JVM, or how open source projects worked. That was super interesting. Since the code was public, I really wanted all my contributions to be top-notch, perfectly well tested and commented. Somehow I had the impression that the scrutiny of my peers mandated that I had to produce even better code than at work! So I perfected my craft. A lot.
Since I had already started sharing my findings on my blog (and later on on social networks), I became part of the so-called “blogosphere”, and started interacting with other bloggers. I wrote about Java and Groovy, of course, but the discussions with other open source developers, allowed me to also meet them in the real world. We even started a meetup of open source developers that shared what they were working on. That’s how I did my first public presentation, to show Groovy to my peers, in 2004 or so, at our local gatherings. I came to know people working for big companies like Sun or Oracle, as well as smaller actors, from freelancers, to entrepreneurs. A handful of those companies started using Groovy, and that’s how one day, someone asked if I’d be ready to talk with them at a big conference. That was for JavaOne! My first big conference and presentation was in the US in front of 600 persons. Woh… That’s how I started sharing more widely with the world, and also started travelling to spread the word.
I spent a lot of time on Groovy and its ecosystem, and I later got the chance to both work on those technologies for a living (after doing quite a bit of consulting), as well as even creating my own company to focus on the project. At the same time, I was still continuing presenting about Groovy, and still improving the language thanks to the feedback I was getting from the many developers I was meeting all around the world. I was doing developer advocacy at the same time as product management and development. Three hats in one. And by doing developer advocacy, that’s also what landed me my current job of developer advocate at Google.
The ever changing nature of our field
From the narrated history above, there’s a theme that emerges: curiosity. But what lead me to being curious? Tons of people are doing 9-to-5 jobs, and that’s totally fine. However, as we spend so much time in our lives at work, for me, it had to be interesting and motivating. To be interesting, work has to be somehow entertaining — beside spending quality time with great coworkers. If it’s not interesting, you get bored very easily, and you don’t want to wake up every morning to go to the office. So how not to be bored? By making your job more interesting. How to make it more interesting? Well, if you’re passionate about what you’re doing, it’s much easier to go through the day and do fun and interesting things, event for a project that could appear as not being very fancy.
Programming was first a hobby, for me, as a child and teenager. It never really occurred to me it could become my job. Initially, I just wanted to be… an “engineer”. Perhaps in aerospace, or something like this. Who hasn’t dreamt of becoming an astronaut? It’s only late in my studies that I thought I could actually become a developer. So my hobby, my passion, became my job. But there’s a big difference between working on stuff you want, versus being asked to work on stuff for the company which hired you. In order to not be bored, be sure to push for improving the project in interesting ways both for you and the end-users. If possible, perhaps try to introduce and learn new technologies that can make the product better, and at the same time make you learn something new. Be passionate about improving both your projects and your skills.
Notice also that in our field, we actually don’t really have a choice but to learn. When I was a student, my current job didn’t even exist. When I started working, the languages or tools I’m using today weren’t available then yet. So in IT, in programming, etc, there’s always a new language, a new tool, a new practice, new patterns, etc, that come to light. It’s a field where we have to be in a constant learning state, in order to stay relevant. If you’re not learning, your skills will rot, you’ll be less employable, you’ll diminish your chances of having a fantastic job. So you have to be curious and learn all the time. To not be bored, but also to get better at your craft.
With all those new tools, languages, frameworks, technologies, you have to keep up with what’s going on. You have to be ready to learn something new.
Sharing is caring
We talked a lot about being curious, about learning all along, but I also mentioned about sharing. As the saying goes, sharing is caring, but it’s also about creating opportunities for you.
Sharing what I learned or worked on was helpful for others too (who encountered similar problems, for example), but it’s also how I came to meet wonderful people along the way. Even mentors and role models. If I hadn’t blogged or tweeted, I wouldn’t have been able to start making presentations at meetups and conferences. And many of the friends I have today are friends I met along the way, at meetups, conferences, working on open source projects together, and so on.
Without sharing my code, I wouldn’t have had the opportunity to meet my future employers and colleagues, as well as the co-founders of my own startup. Sharing is great to be visible, of course, but it’s a wonderful way to meet new people from whom you’ll learn a lot.
Open source is sharing too. Working on open source projects, nurturing communities and ecosystems around those, further allowed me to meet great people around the world. And it’s what lead me to get the jobs at companies I was interested in. It created great professional opportunities.
Summary
Let’s try to wrap up a bit. It’s really not about learning a particular tool or technology. It’s all about being curious and passionate about your craft, and to share what you’ve learned with the world.
Be curious!
It’ll make your daily job more interesting. You will learn lots of great new technologies. You’ll become a better developer by learning from your peers. You’ll improve your craft and expertise. It’ll increase your employability. You’ll even likely become an expert in your field!
Share with the world!
Write, blog, tweet, present about the things you’ve learned at meetups or conferences. You’ll learn a lot from others along the way. Write and share code, and/or contribute to open source projects. You’ll meet awesome peers and mentors. And will create all sorts of interesting job opportunities.