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.

For many developers despite some of the node.js hype, Javascript is a language we’ve been stuck with by an unfortunate decision by Netscape to bundle a language tossed together in 10 days. It wasn’t even called Javascript at the time, it emerged originally as LiveScript. They even tried to market a server side version bundled with Netscape Enterprise Server in the days when you could sell web servers for real money.

Dave Winer’s recent blog post on Why aren’t the BigCo’s Converging on Javascript? argues that Javascript has arrived and is dominating even while the big Companies like Apple and Google try to push newer languages. I agree that these companies have some of their own agendas in building out new languages, but if Javascript were truly so great and dominant why does everyone build a transpiler from ClojureScript to Opal to avoid having to write in plain old Javascript. My answer is because Javascript is a terrible language if you have a choice.

Look at any newer modern language and you’re going to find a nicer language with many fewer warts than Javascript take your pick of many:

• Ruby
• Scala
• Clojure
• C#
• Go
• Rust
• Elixir
• Python
• Swift
• …

Javascript would have died off very quickly without its’ continued support as the only way to script browser clients. Even now many are turning to transpiling to take the pain out of supporting large javascript code bases. It may eventually turn out that Javascript becomes just a readable intermediate language that your favorite language compiles down to much like byte code on the JVM. Or maybe the browser vendors start supporting a new VM on the browser and languages can target that.

My daughter’s FFL Lego Club is over for the year, but I wanted to two helpful debugging things I learned along the way, that were especially helpful for newer kids.

This was the first year for a group of 5th and 6th graders and I noticed many of them ended up with some long procedural blocks of code to navigate the robot through obstacles across the board and back to the base. A really common problem was they’d make some progress, and then come back to the table only to discover the robot didn’t do what they expected after a “small change.”

The first fix for this was actually saving a copy off before making significant changes, just giving it a new name. The Lego LabVIEW environment didn’t make this easy as you have to cut and paste the blocks by hand into a new program, but it saves a lot of time with the kid’s longer programs. I’ve used Git for the same effect, but source control isn’t the focus here.

A second quick win was testing with the robot connected. Our boys and girls were very set on the program, download, run to the table loop, but I eventually had a few of them persuaded to test with the robot just connected via USB. The best part of this is you can select a single block and then run just that block with the robot. We used this several times to troubleshoot issues with arms that swung back too far and got stuck on lego pieces, which halts further execution and doesn’t give much feedback on what’s wrong.

Finally was the one I had the most fun with. Many kids’ programs had dozens of blocks connected. Often they would forget where they added tweaks to turn left, spin, or adjust the shooting arm. As a lover of sound effects I suggested adding sound effects before and after they added their tweaks so they’d know several things:

• Did my changes actually get loaded on the robot?
• Did my changes improved the program?
• Exactly where to tweak the program again if it just needed another adjustment.

The sounds were fun on their own and they can easily be deleted when the program is ready to go.

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.