Git is a command line focused tool with hundreds of options. You can even visually see a graph of commit history in the terminal using git log with –graph. The default visual git tool is gitk which makes a reasonable GUI client for digging through history or doing ad-hoc code reviews.

A few years ago someone suggested looking at Atlasssian’s SourceTree as a better option. I’ve used Atlassian tools in the past and generally found them to be well designed a useful. As it’s a free tool it was an easy option.

SourceTree has been marketed in many ways as a visual tool for users new to git. I think it’s probably a bit dangerous to use in this way. You’re better off learning the simple workflow through something like Try Git and sticking to the command line. SourceTree can be a a great supplement showing you in a visual way exactly what’s going on.

I use SourceTree in an entirely read-only mode. It’s easy to see the various branches and merges and walk through history. Since we currently don’t use Gitlab or a similar tool for git I use it for ad-hoc code reviews. It’s easy enough to step through commits fairly quickly. When I have comments I simply screen capture the view from SourceTree and attach it to a simple email. It’s primitive, but effective enough. Other than that my most common use case is perusing stashes as I sometimes let things stack up there and I can quickly bring them up to see if there’s anything worth keeping.

After three years it still serves my purpose much better than gitk and I find the layout more efficient and powerful.

Not to be left behind in hipster group chats, we migrated from Campfire to Slack a few months ago. It’s a slick, simple group chat system with a few elements of fun including custom emojis. We added Carl and Paul from Llamas with Hats to our custom set. We’ve also livened up things with a custom Hubot. Still there is one very sad missing feature Sound Effects.

A bit of research shows the team at slack has had sound effects on its backlog for a long time:

Slack custom emoji but for sound effects. Make it happen, guys. +@SlackHQ

— Nathan Peretic (@nathanperetic) April 5, 2014

@SlackHQ Can Slack do sounds like Campfire ("/play soundname")? Silly as they may be, it's an essential feature for team camaraderie.

— John Pray (@LouieGeetoo) February 27, 2014

We’re more than a year later and still no sign of adding sound effects. We really relied on getting audio notifications of broken builds. Now things slip by for a while as the email or text notifications get lost amid the clutter. And sometimes you just need to play PushIt while deploying. Please Slack get this done.

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.

I love writing expectations like the following:

account.balance.should be_zero

It was one of the reasons I first fell in love with RSpec and had a reason to move from dabbling in Ruby to diving in. This was hard and clear evidence that Ruby crushed testing syntax of Java in a way it could never compete with. Just a beautiful DSL with a single little word ‘should’.

Expect has come along to replace and it accomplishes the same thing with a bit more syntax and parens:

expect(account.balance).to be_zero

It reads well, but I still like ‘should’ better and I’m not as upset as some about object purity and polluting objects with an extra method. Our development team concluded as much for the last few years. We’d put a quick vote up every 6 months or so to keep should() or bite the bullet and move onto expect. Should always won, but over time the objections became more mild and newer team members had gotten adjusted to expect elsewhere. When the vote came up again a few weeks back, we finally voted to default to the new expect syntax.

My vote had changed from preferring should to being neutral on it. Over time most of that came from working on newer Ruby open source projects and following the new expect syntax when adding tests in a pull request. Idioms and styles evolve and I’d seen enough adoption to justify retiring my old friend should(). The small benefit has been with Jasmine with its very similar expects now doesn’t lead to accidentally writing a should() in a Jasmine spec. I still miss should(), but having everyone use the same assertion approach is better for the group.

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.