Yearly Archives: 2014

2014 Developer Learning Guide: Part 1

Software Career, Software Development, Software Engineering, Technology Career, Training, , , , ,

Background

This is part 1 of a now complete series of blog posts. Be sure to read 2014 Developer Learning Guide Part 2 and Part 3.

I originally wrote on the subject of developer training in 2010. It was with the idea that I would convince management of the importance of training technical employees. I wrote an internal document for my boss and we implemented a couple of the ideas. My boss was understanding although his boss was less so and that limited some of our options. One year (and one move to Texas) later and I was back in the same boat; I was handing a document off to my boss and trying to convince him of its validity and importance. We eventually started some great traditions at that company and I ended up publishing my Guide To Developer Training For Managers on my blog around the same time. As I started looking into moving back to Utah in late 2012, I was despairing that I would forever have to sell leadership on the value of developer training every time I came to a new company… can you say facepalm?

facepalm

It occurred to me that I might be taking the wrong approach. As I ramped-up  on interviews I noticed that a couple of companies stood out because they already had begun to establish a culture of learning. I’m happy to say that I chose one of those companies and today I enjoy a work environment where leadership not only “gets it” but is an active promoter of learning and training. Ideas that are brought up to improve training are not only appreciated but are also seriously considered. And I don’t even have to write a long and windy proposal first.

What a difference!

I’m still going to talk briefly about a few of the reasons developer and technology employee learning is important. Convincing managers will no longer be the major focus of the article. As you may have noted from the updated title, I’m refocusing to list learning options that are possible, valuable, and current. I’ll also post an updated list each year.

Importance

The anecdote I’ve heard several time goes like this:

Decision Maker 1: What will happen to our company if we train our technology employees and they leave to find better jobs elsewhere?
Decision Maker 2: What will happen to our company if we do not train our technology employees and they stay?

Two varying points of view obviously.

On a team where learning is not important, developers tend to stagnate or move on. Will the best talent stay in an environment like this? I’ll spare you the A, B, and C-Player talk. It should be sufficient to say that a lack of learning isn’t healthy for development culture.

Ultimately, it is the responsibility of the developer to seek learning and the best developers know this. Are the best developers going to be working for companies without a great learning culture? That scenario seems unlikely to me.

Learning Options

What if I told you that a classroom isn't always the best learning environment?
Developer training doesn’t necessarily begin or end in the classroom.

There is a wide spectrum of cost among differing methods of learning. A good mix assures plenty of coverage without completely breaking the bank.

This list is meant to be only as inclusive as I could make it given my current knowledge. Please leave a comment or contact me if you know of options I’ve missed.

Online/Print

Videos

This is usually one of the best places to look for technology-specific and implementation-specific training. There are multiple options and they are growing all the time.

Free – YouTube, Vimeo, Egghead.io, Channel9, etc.
The quality of free videos varies. The only advice I can give, is to avoid wasting time with something that doesn’t seem valuable pretty quickly.

Subscription – Pluralsight, Wintellect Now, Lynda.com
Subscription-based video training tends to be pretty well curated by the company selling the subscriptions. They rely on ongoing subscriptions for revenue so new high quality content is constantly being released (or the model is not successful). Pluralsight (http://pluralsite.com/) in particular has an enormous and constantly updated library… and no, we aren’t affiliated. Pluralsight has purchased several of the smaller players to help build out their library over the past couple of years. Subscription may cost as much as $499 per year, and is a good return on investment if you learn well this way.

Purchase – Udemy, Cleancoders.com, etc.
These tend to also be of higher quality than the free options in my experience. There are some great sources out there… but you may have to hunt for them. Word of mouth has been valuable to me here.

Social Media/Blogs/Podcasts

If you enjoy this blog, follow me on Twitter.
If you enjoy the blog, follow @dubmun on Twitter.

There are a wide variety of options here. Find people who talk about things you are interested in and subscribe to their blogs or follow them on Twitter/Google+. In my experience, many of the thought leaders in the developer community are on Twitter. This has the added benefit of allowing interactions if you have a question about someone’s latest tweet or blog post.

Podcasts can also be very, very good as long as they aren’t too sales/technology focused. Choose wisely. I find them particularly useful for long commutes. HerdingCode (http://herdingcode.com/), Ruby Rogues (http://rubyrogues.com/), and Writing Excuses (my SF/Fantasy writing guilty pleasure) are among my personal favorites. A good podcast app is a must as well… downloading all the episodes manually can get tedious.

This is where the cutting edge lives and breathes. If you want to know what is really happening you should be reading and hopefully contributing to this kind of content.

Open Source Repositories

This is the section for Github, Codeplex, Google Code, and Sourceforge. Github is definitely the current leader and you can find awesome and interesting code in any of these repositories.

Looking at how other people code is a great resource for learning. Additionally, submitting a pull request to an open source project can be the fast track to learning (albeit a potentially humbling one). Humility is a good thing, it lets us know where we can improve.

Books

I’ve heard a lot of varying opinions on books as a training resource. Yes, technology-specific books are often outdated before they are printed. I generally avoid the latest C#, Java, Clojure, Javascript, etc. books (with a few exceptions). The flip side of this is… if you do choose to read tech-specific books, be sure to get the latest version.

What a library!
Some options here…

My thought is that when you are really looking to deepen your knowledge on something specific, books are a great resource.

There are also many classics that are as close to timeless as you can get in this industry. I highly recommend books like The Pragmatic Programmer, Clean Code, The Art of Unit Testing, Design Patterns, and Domain Driven Design as examples of excellent resources for learning practices and patterns or as reference material.

Books are available in several formats as well: hard-copy, ebook, and subscription.

Hard-copy and ebooks are basically just a matter of preference. I find that I like having a hard copy of books I might lend to others, but nothing beats the convenience of an ebook that you can read on multiple devices. When I have the option, I get both.

Subscription to a service that provides ebooks can be really handy as well. Particularly if you find yourself reading a lot of technology-specific books. Safari Books (http://www.safaribooksonline.com) offers hundreds of titles on technical subjects for $199 or $460 annually.

Remember…

…to read 2014 Developer Learning Guide Part 2 and Part 3.

I’d love to see your thoughts and comments below or on Twitter (@dubmun).

When To Quit Your Job

Career, Software Career, Technology Career, , ,

A friend asked for my advice on this subject recently:

I’m kind of thinking about changing jobs. I’m doing good at [COMPANY] so no concerns there. I would honestly rather be working in the software and technology space, instead of the financial industry. […] The other factor is that I’m not in an area where I can attend conferences and be involved in a good development community. I’ve only been at [COMPANY] for [less than 12] months. What do you think?

While I was flattered to be asked for such personal advice, I’m not really qualified to say what’s best for anyone. Maybe not even myself. Remember this.

The following is the philosophy that I try to follow in terms of changing jobs in case helps anyone.

When To Leave

First, as anyone I’ve talked with about this will tell you, I’m a big proponent of changing jobs at least every 3-4 years.

Departures

In our profession, this helps us remain fresh and exposes us to new tech/architectures/ideas in a way that is hard to ignore. This is a good thing. My general rule holds unless there are special circumstances. For example: vesting concerns, when nearing retirement, or another important life event. I’ll also interview every year or two in order to keep my interviewee skills honed and because it helps me to be a better interviewer when I’m performing interviews at my current company.

When To Stay

As for a shorter end of the tenure spectrum, I usually will stay a minimum of 1-2 years.

Again, this is a rule of thumb. I’m not going to cover all of the exceptions here. If circumstances like a hostile work environment or an amazing new opportunity came up, I would consider breaking it. I have a friend who left a company after a couple months once because it ended up being hostile. I can’t imagine any decent future employer who would fault him for this. However, it is the only instance like this in his career. An established pattern of “hostile” work environments is a read flag all by itself.

If you are making an immediate decision, sleep on it. One more night can help organize your thoughts and shouldn’t hurt anyone involved.

Regrets
Don’t make a hasty decision you might regret.

As for my recommendations, the first year is basically for resume purposes… taking a full-time employee position and then quitting before a year is up might make some employers question the value of going through the cost and effort of bringing you on. It may even be “interview prohibitive”.

The second year and beyond is often when I find that I learn the most about a business, can contribute the most (due to knowledge, trust/influence earned). It is also when I solidify relationships with people I work with.

Contracts

MercenaryAll of this is basically thrown out the window for contract positions. Contractors are expected to be mercenaries, to an extent, and might switch companies/projects every month without much scrutiny. I think there are some interesting things to be learned from that as well but I don’t have a lot of personal experience. I’ve considered joining a firm similar to Catapult or StG that sends contractors out to multiple companies and has a bench program for downtime. I believe it would be a valuable experience.

Summary

So the short version is: except for contracts, aim for a 1-4 year stay whenever starting a new job. Commit to this mentally, or don’t accept the offer. An exception could definitely be made in either direction under the right circumstances, but don’t plan on it. In practice, I have stayed at each of my gigs for 2-3 years without exception.

In my friend’s case, his company/team doesn’t match the values he wished they had and isn’t working on anything terribly interesting. Also, he is considering leaving the area. Not an emergency per se, but not great either.

My advice to him was to stick it out until a year is up while doing his best to influence change at the company. If things don’t start to improve in that time-frame, (i.e. if he felt he wasn’t having a positive impact) start looking.

Again, I’m not really qualified to advise anyone on their particular situation. I do believe these ideas have value and should be discussed.

 

Legacy Dependency Killer

Software Development, Software Engineering, , , , , , ,

As promised, here are the slides for my hands-on coding session at Utah Code Camp. Thanks to everyone who attended the session. I had a lot of fun and I hope you did as well.

Also, the code is on Github: https://github.com/KatasForLegacyCode

I’d love to get it translated into Java, C++, and any other language that would be reasonable. I could probably do either of those myself, given past experience, but it’s been so long I couldn’t guarantee that the code I produced wasn’t legacy as well. If anyone is interested in helping out here I’d be very appreciative.

Hopefully, I’ll be creating other katas for legacy code in C# using other common patterns and publishing them here as well.

I Like Food

Career, Random, Software Career, Software Development, Software Engineering, Team, Technology Career, , , , ,

Hopefully this article isn’t as banal as the title suggests. “I like food” is what I say when someone in the office asks me to join them for lunch (usually).

Why?

food-question-mark-628x363

 

Because I like my teammates? Sure.

Because I’m hungry? Usually.

Because I like food? Also true.

Because want to enhance my relationship with my coworkers and build camaraderie among the group? Getting warmer but not quite. The familiarity that comes from knowing someone outside of work does tend to humanize them and help with relationships and camaraderie (and all those touchy-feely things we engineers aren’t supposed to care about because we’rerobotswhoonlyknowhowtowritecodeanddrinkmountaindewandurinateinemptybiggulps).

In my experience, the real benefit is in improvements to communication and cohesiveness. It’s in the ability we gain to understand each other as people, to know our strengths and weaknesses, to use shorthand in communication, to avoid causing or taking offense, and to just be more effective working together. Whenever possible, I like to participate in non-work activities with my brothers-and-sisters-in-code (and sometimes with others at the company as well) because it makes us more effective. Good companies/managers understand this concept and go out of their way to engage teams in “teambuilding”. This can be a dirty word in the wrong environment. Don’t work in that environment!

ready_to_eat

So unless I have an important errand to run or previous plans, invite me to lunch. I like food.