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.

I got asked the other day about whether it was OK to use stub_chain when testing what turned out to be a legacy fat_model class of over 500 lines. There wasn’t much to think about as I replied it was OK if there wasn’t a lot of time in the story for refactoring since the code was already legacy, but it wasn’t my favorite tool. Even the documentation notes:

we recommend treating usage of stub_chain as a code smell

It’s a part I appreciate about Spec. It’s an opinionated BDD framework, but it allows you do use it in a way that works for you. I don’t love stub_chain or even less as_null_object, but when diving deep into badly covered code they can be a nice way to open up a seam in the code and allow you to start a big refactoring.

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.