Developer Alumni

It’s not unusual for a developer to change jobs every two or three years or even more often. Up until 2004 I had never thought of a company keeping up with you after you left or having an ‘Alumni’ concept. The consulting outfit I left had instituted an alumni program and sent me out a tiny flash stick with the company logo on it about a year after I left. It was a small thing, but I was kind of impressed they bothered with any effort at all. In addition they sent out an email every month or so with an update on how their business was going. About 6 years later I ended up back at the same company, partially because they had maintained a good relationship with me, and realized I left not so much because of them, but more for an opportunity to manage a development teams.

I came across this practice again in the most recent episode of The Front Side Podcast where they explained they were trying to build the company culture that allowed you to just tell your manager you were going on an interview. This is exactly the sort of thing to get you escorted out in many big companies, but they seem to be experimenting with having a very open and honest culture that admits, especially in consulting that many of your developers will leave at some point sometimes even over to your clients. They wanted an environment where a developer could admit they wanted a new experience the consulting business couldn’t provide and they left the door open down the road as Alumni to welcome them back.

I think it’s a great experiment and I’m honestly impressed if they can produce a company culture where an employee feels safe admitting they’re going on an interview. I love that companies are experimenting and blogging/podcasting on how it’s going. I also think the alumni idea is a great way to keep people motivated and maintain a good relationship with your local development community. I know some of the best recruiters I had were former employees who could explain why they left the company, but how it was a great opportunity if you were a good fit.

Dipping Toes in Other Development Communities

My dad, even with a serious head injury that ended his working life, regularly attended a computer club where he could chat with a community of fellow geeks who accepted him head injury and all. I was always glad he had somewhere he could be accepted, but I never realized I’d end up attending and helping to run programming user groups in my own career.

I first went to a Java Users Group in Sacramento, SacJUG. I had been getting deeper into Java and figured it was time to see what the local community was like. I found a home with some fellow geeks and I attended regularly for the next ten years or so. I even eventually hired multiple developers I met at SacJUG and I appreciated being able to geek out on the language and share war stories. A few years later I got deeply into Ruby in my spare time with the advent of Rails and eventually helped setup the Sacramento Ruby Meetup. It would be a few more years until I got paid to do Ruby, but met some great developers along the way and I still regularly attend. Only a year or so later I helped found the Sacramento Groovy User’s group which continues today as essentially a JVM languages group.

All this experience with user groups has led me to experiment with visiting other user groups from time to time. A few months ago I showed up for an Angular group and met a lot of front-end specific developers I don’t mix with regularly.

If you haven’t tried out attending a user group I encourage you to try it. It only costs you an hour or two and the benefits are worth it. Things like:

  • Seeing the size of say the node.js community in your town and getting a sense of how a new language or toolset is catching on.
  • Getting exposure to something new with a group of programmers.
  • Meeting fellow developers who are trying to come up to speed or stay on top of technologies.
  • Finding a great new candidate for your shop. The developers who regularly attend user groups tend to be more motivated and engaged employees and you can get a pretty good sense of their skills just from chatting.
  • Getting out of the house since many of us are introverts. With the shared context it’s much easier than say the annual holiday party.
  • Practice speaking if you work up the nerve in a low stress atmosphere.
  • A sense of whether a particular language/community is on the rise or fall.

Dev Lunch as a Power Tool

At my current company I’ve been going out to lunch pretty much every day I’m in the office. I know a lot of developers bring their lunches and like to eat alone in silence, but I’m probably less on the introvert side. I’ve always made it a point to have lunches with developers on a regular basis, but my current standing lunches with have been an evolution of that.

Breaking bread and catching up on stories, families, etc are a great way to bond with developers you don’t work with on a regular basis. Most of the engineers I go to lunch with work on another team, so I’m constantly keeping up to date with their current work and letting them know about what my team is doing. As a bonus I get out of the office and eat some hot food, though not necessarily the healthiest fare. Sharing and communication between teams really helps even in a flat startup organization like ours. I know some companies have meals catered in the office which works as well, but if you’re at a regular place, lunch out can work just as well.

As a suggestion if you tend to eat your lunches alone or at your desk, try to make a habit of eating out with some other devs or even other employees at least once a week.

Dotcom Junior Devs 2.0

In case you don’t remember the crazy gold rush days of the first dotcom boom, let’s just say that this was a defining image of the times:

At the time you could land a well paying job at pretty much any dotcom with no more than some basic HTML skills and a willingness to learn. A wave of people swept in and made up a large part of the dotcom workforce. Having a background actually programming was really nice to have, but became almost an afterthought as VCs helped push the rush to bring in warm bodies. If you were in another field at the time and wanted to try out life as a developer, project manager, tester, system admin it was a great time to jump in. There was low risk and plenty of reward.

I worked for a director who had been a bartender until 1999. On a project in 2000 one team had a former translator, an office administrator, and a lawyer. All of them had bootstrapped up on books and built a few static HTML sites before they found their first jobs as developers.

I noticed early on that the talent pool had completely dried up when I opened up an office for a dotcom in 2000 in Las Vegas. Our main office was in SF and I was amazed at the number of hires they’d made that really didn’t have any coding skills. Vegas at the time had a pool of solid developers, but we’re not Silicon Valley and the hometown university is UNLV. Still on average we were able to get better developers typically with real experience. I remember my first time visiting SF in 2000 and noting that 90% of all the billboards in the city were advertising doctors, many focused on recruiting. I’d never seen anything like it.

The bar was almost absurdly low for developer in the dotcom boom. This time the bar has moved up a bit. Now the default entry into the field is a Code Academy or Dev Bootcamp experience. Having survived the dotcom boom and bust I think it’s a good thing that the really junior dev coming from non-science or engineering backgrounds actually has done some real coding before starting their first job.

We’ve dipped our toes into these waters in the past year hiring two junior devs who had gone through dev bootcamps. We’ve been pleasantly surprised by several things that we didn’t get from junior developers in the dotcom days:

  • They have pair programming experience
  • They actually write unit tests without prodding or coaxing
  • They understand that they’re on a steep learning curve and embrace it
  • They don’t have a lot of bad ingrained habits
  • They understand the basics of putting together a web site
  • They are used to source control, commit early and often, and open source

So the new Dotcom 2.0 junior developers have a leg up from the early 2000s. I think more of them will stay in the field. They put some real time and effort into switching or starting a new career an possibly a decent sum of money and they’re more likely to stick it out. And their baseline is a lot better. They’re all feeling really underprepared even in their first paying dev jobs, but they are far better off then the wave that came in the late 90s.

One Language Resumes

Reviewing resumes as a manager, tech lead, or even just a developer is no one’s favorite activity. Resume’s are inefficient, misleading and so often boring. If you’re a prospective hire boring is bad.

A simple case is the standard corporate style J2EE developer resume. There are host of bullet points claiming skills I already expect them to have with 10+ years of development experience.

  • Spring
  • Hibernate
  • Tomcat, JBoss, Weblogic, or WebSphere
  • A smattering of design patterns from Singleton to Template Method
  • Javascript and some JQuery
  • Some selection of Java’s innumerable web frameworks.
  • Oracle/SQL Server/MySQL

At this point they’ve done nothing to distinguish themselves from the pile of already screened and rejected resumes beside them. You’ve developed on the JVM for 10+ years and you’ve never looked into alternative JVM languages. No Groovy, Scala, or Clojure. Not even some adventure off the JVM into Ruby, Go, Elixir, Python.

Java is by design a simple if verbose language with a huge amount of libraries and IDE tooling. It has never been the best solution for almost anything. Luckily there’s been a “Get out of Jail” free card option for a long time now. You can pull out a JVM language that better fits the problem space solve the problem more elegantly. All that and still produce compatible byte code and interop easily with existing Java libraries. It’s a career limiting to ignore that opportunity.

For the brave there’s always the option of leaving the JVM entirely and trying something like Ruby, Python or Go. It may require adjusting to life outside a familiar IDE or dealing with a new set of libraries, but it’s not a very difficult step to make.

So fair or not let me explain the conclusions I make when I see a J2EE developer resume with many years of experience and no mention of a second or third language experience:

  • Not very interested in learning in an engineering field that is constantly changing.
  • Did the majority of their learning by working on an existing Java codebase, and aren’t interested in spending any time coming up to speed on anything that isn’t currently required for the job.
  • Don’t enjoy development as a pursuit other than the fact that it’s fairly well compensated.
  • Are OK with doing things the hard way because they have one hammer in the toolbox.
  • Think they know a second language because they hack some javascript when required.
  • Copy and Paste is their most common approach to gaining code refuse.
  • Won’t be able to come up to speed quickly.
  • Are going to bomb out in a phone screen, so no point in scheduling one.