About a year ago now I acquired a Seiki SE39UY04 37″ 4K TV as a monitor. Despite the 30Hz refresh rate and once or twice a day screen reset for 5 seconds it’s the best monitor I’ve ever worked on. A 4K display is an almost infinite amount of screen real estate. I regularly have 4 files up in vim displaying over 120 lines each. At $400 dollars it was a great way to jump into 4K and wait until the really good 4K monitors show up down the line.

Pros:

• 4 HD screens of stuff, regular have 4 1080P screens up on a single monitor.
• If you’re not gaming the 30Hz refresh rate has much less downside.
• It’s cheap enough that you won’t feel bad when you replace it a year or two down the road.
• It doubles as a 4K TV.
• After a year it hasn’t had any glitches.
• I can remote pair and still have 60-75% of my screen available.

Cons:

• 30 Hz is pretty noticeable at first and for gaming/fast updating.
• To share for pairing you generally need to drop the resolution down from 4K.
• It goes black a few times a day for a few seconds.
• It doesn’t really sleep since it’s not a monitor.
• Picture quality is fine for development work, but not great.
• It’s hard to see co-workers around it.
• If you share screens you’re constantly downsizing the resolution since almost no-one else has 4K yet.

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.

Here’s my current podcast development list:

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.