StirTrek slides and examples

Just a quick update from my JavaScript Spaghetti talk at StirTrek:

• My slides are up here
• Examples can be found in my Facebook For Cats repo on GitHub here

Thank you to everyone who came to my talk. Also, a huge thanks to the folks who made StirTrek happen. Yet another awesome year.

What Makes A Good Developer?

There’s (hopefully) a good title to get attention. I’ve been spending some time thinking about this lately. Part of being involved in the hiring process at HMB is thinking about who people are, how well they will do in the role we’re considering them for, and how happy they’ll be doing it.

What makes a good programmer? Excitement. That’s pretty much it no matter if you’re talking about a junior dev or a senior architect/tech lead. The difference is: excitement about what.

Good Junior Developers

A good junior dev stands out from his or her peers because of an excitement for creating stuff. Whether websites, desktop apps, something on a phone, or whatever, a good junior developer says things like:

"OMG OMG I just made this thing turn blue. Hey guys, check thi... HOLY CRAP JQUERY!!!"

Most really good junior devs are just discovering how awesome it is to make something they can interact with. They get excited about tactical problem solving, and designing more strategic solutions, but it's definitely secondary:

 

When you're a new developer, it's all about learning new ideas by building stuff. You don't know what you don't know, and you don't know a lot! Every new concept should be exciting and feel like it's life changing.

I’m sure there are exceptions, but I’m a bit leery of someone fresh out of school who says they are excited about middleware. There is a subset of really good junior devs who are hardcore code geeks and want to build languages and databases. These devs may turn out to be awesome one day, but in most environments their first few years are going to be difficult. Be excited about building stuff!
Junior developers are great for a team that needs energy, but they need more experienced people to act as anchors.

Good Mid-Level Developers

Mid-level developers should have a wider spread of things that excite them. Part of this is just a developer getting exposed to more stuff, and getting good at new types of tasks. Another part is simple boredom; if you’ve built a widget 9 times now it’s not as exciting to build it the tenth time. A good mid-level developer sounds like:

"We took that library we figured out last year, but this year used it to build a giant killer robot. I’m sure we’ve worked out the bugs." 1

Mid-level developers start thinking about business problems and no longer see everything as a code problem. They realize solving problems is what we do, not writing code. However, code is still what they’re focusing on:

A mid-level dev shouldn’t have lost his or her passion for building things by any means, but that developer should start seeing the big picture. They’ll still underestimate how long things will take, and they'll dive down the first rabbit hole they see.

These developers are incredibly valuable to a team with a senior person who can keep them focused and engaged. Without this focus, they tend to overdo everything. A junior developer doesn't know what TDD is. A mid-level developer wants to TDD everything, all the time!

Good Senior Developers

The old gray beards (or non-beards as the case may be) of software are an extremely important group; many organizations underestimate how valuable they are or even actively discriminate against them if they’re old enough. That’s another blog post though.

That beard is full of knowledge

A good senior developer can build things and still likes to do so, but is incredibly important to a team because he or she provides direction, stability, and the occasional gut feeling that something’s not right. Sometimes the only way to see a problem bus coming is to have been hit by it in the past.

"I’m pretty sure the giant killer robot is a bad idea. We did this 20 years ago in COBOL and almost lost Canada. Let’s build a web app instead."

A really good senior developer can keep up with the youngs when it comes to coding, but really provides value when it comes to finding solutions. They live to understand systems and figure out how to align the key pieces:

A good senior developer or two on a team helps teach the juniors how to do new things, and keep the mid-level folk from going overboard smacking everything with their technology hammers. They know when to use tools, and when not to. They realize when code isn't the solution and find other ways to solve problems.

Conclusion

The big difference between a great senior and junior developer is big picture, strategic stuff. In either case, a good developer is excited about building things and solving problems. With more experience, the breadth of things they get excited about should increase.

Do you agree or disagree? Let me know how I'm wrong in the comments :)

1. You should always have 100% test coverage of target identification code. You really don't want to learn this the hard way.

Moving On

Today is my last day at Facio. That fact is a bit bittersweet. I've spent the last 18 months working alongside wonderful people, building a great product for our company, and getting to contribute in little ways to the success of the others around me. I'm going to miss the project, but I'll miss the people even more.

In that time, we've taken a concept thought up by our company's visionary founder, Dirk Knemeyer, and turned it into a powerful tool to help people better understand themselves and each other. I feel good knowing that I helped get Facio to a place where it's clear it's going to be successful. Even though I'm leaving, I'm going to keep my eye on where Facio goes. If you're interested in organizational development and better understanding those around you, then you should too.

I've also been really lucky to have the opportunity to interact with (and in a couple cases work directly with) some of the really excellent people at Involution Studios (both Columbus and Boston). While the day to day interactions are going to change, those relationships aren't going anywhere. In fact, in the next month or two I hope to blog about a little art project Scott Sullivan and I have going.

Next week I start something new that I'm incredibly excited about. Stay tuned to find out more.

Code Geeks vs Stuff Geeks

I've realized that developers exist on a spectrum between code geeks and stuff geeks. *Code geeks* are those who really enjoy the elegance and challenge of creating new bits of code (plugins, frameworks, entire languages, etc). *Stuff geeks* are those who enjoy the fulfillment of building final products that they can 'touch' and show off. Understanding where on this spectrum your teammates sit (and balancing your team around it) can dramatically improve your output.

Code Geeks

The extreme code geeks on your team enjoy the act of creating amazing code for the sake of the code. They may build awesome apps but only as a side effect. Give them a simple requirement and they'll build you a new Lisp. It will be amazing and nobody else on your team will understand it. If they aren't focused then their attention may wander off after the hard problems are solved but before the feature is finished.

Overengineering at its finest
source 

More moderate code geeks are responsible for most of the cool frameworks we use. They like to build tools but do it in the context of business problems. Their code may not be as elegant but it will actually do things. These code geeks will add a new pattern to your project rather than a new language.

Stuff Geeks

Moderate stuff geeks love to use frameworks and tools to create end products. They take pride in their code but ultimately see code as a means to an end. They will create a new library if necessary but would love to use an existing one if it's good enough.

Good enough, ship it!
source

Extreme stuff geeks will ship your project before you know you needed it by duct taping a bunch of hacks together. Code elegance to them is like abstract modern art to my kitten. They may see it but it has no emotional impact.

Balance

A healthy team will have developers spread out over this spectrum with the majority somewhere in the middle. A hardcore code geek will need to work with a couple stuff geeks who keep him or her focused on building stuff that's useful to the team. An extreme stuff geek may make a great prototyper but is going to need a lot of help to not build spaghetti.

The developer sweet spot

A team made up of only people in the the middle may be lacking a certain brilliance or not have the ability to rough out a prototype in 10 minutes. You're team may be pretty solid but only reach 90% of its potential.

Me? I'm a stuff geek but pretty close to the middle. How about you?

So You Want To Be A Technical Speaker?

I speak at a pretty good number of events (and am always considering more... hit me up) and really enjoy doing so. At Codemash this year I had a few people mention that they would find a post about how to get started speaking at technical events quite useful.

One of the bests audiences ever

Not everyone is going to love or even slightly enjoy speaking in public and that's fine. However, I think it's a valuable skill that everyone should at least try to be reasonably proficient at. I've put together a few steps that I think any person can follow to help start his or her IT speaking career.

Attend Usergroups

We're super lucky in the software development world to have a lot of usergroups available to us. I've talked to people in mechanical and electrical engineering who have nothing of the sort. Heck, even our design colleagues don't have the wealth of options available to us. Usergroups are the single best place to start your technical speaking. They are a neutral, non-work place full of awesome people.

So the very first thing you should do if you don't already is to start attending usergroups. In Columbus, OH alone we have CONDG (.NET), COCCUG (Cloud), CRB (Ruby), CbusJS (JavaScript), COJUG (Java), CBUSPass (SQL), Windowsdevug plus probably more that I can't think of offhand.

Attend for a few sessions and you'll see that these groups welcome everyone from polished tech evangelists to people who have an idea and put together their slides the weekend before. Find a usergroup that covers a topic you're passionate about, attend for a bit, and mention to the organizer(s) that you'd like to contribute.

Give A Short Talk

I've found that there is generally space for lightning talks (15-20 minutes) at most usergroups at least every few months. Try doing your first talk at one of these since you don't have to prepare as much content and if you are totally freaked out it's over quickly.

Me being absolutely terrified

One thing I might recommend is to find something new and cool that you're interested in and that nobody else knows about yet. If you present on something new like HTML9 Responsive Boilerstrap JS you don't even have to worry about anyone else being an expert and trolling you (which wouldn't happen anyway). I've given talks where I opened with "I don't really know much about this but it seemed cool so I'm going to share."

Find A Talk Based On Your Expertise

After you've given a few short talks start thinking about what you're really good at and start putting together a full length (45-50 minute) talk based on this. Polish it really well. Maybe get code examples going. Really put a lot into it. Then find someplace to give it. It can likely be at the same usergroup you were attending before but if you want to try something new email the organizers of some driveable usergroups. From Columbus you can easily get to Cleveland, Dayton or Cincinnati and they have great groups.

If Your Still Interested, Answer The Call

At this point you might be happy staying where you are, but if you want to have the real speaking fun then start submitting to various conferences when they open their calls for speakers. At this point you're a pro so you can do this like a pro. Come up with a topic and an abstract and only bother making the talk when you get accepted (Hi organizers who have picked me in the past). Heck, maybe come up with 2 or 3 different topics. Don't worry if you don't get picked at your first few conferences. Eventually you will get picked as you refine your topics and get a feel for what the conferences need.

A Quick Guide To Abstracts (Or Time To Self Promote)

I've had the best luck when I come up with an interesting concept, then craft a funny title, and finally write out what I hope to be an interesting abstract. There are going to be a lot of talks submitted to the conferences you are looking at, and probably a number on the same topic you want to speak about. The key here is to get the reviewer's attention quickly. I've had some luck with this so feel free to checkout my current abstracts that I have up as Gists. I'd prefer you not totally steal them, but if you insist good luck with that :)

Getting Started With Backbone.js

Backbone.js is one of those wonderful technologies that is flexible enough to let you solve problems in a variety of ways. It's also one of those horrible technologies that don't have any opinion about what the 'correct' way to solve a problem might be.

One big issue with backbone is the traditional 'todo list' problem of complex frameworks; namely, that all of the examples you can find are trivial applications that dont look at all like the apps you really build. There are some good resources for patterns and individual problems but when I was starting out I didn't find a good overall process guide.

Through a lot of contemplation, trial, error, and bugging my friends (thanks @larrymyers) I managed to come up with some design patterns I'm happy with. Ive been using them successfully in Facio and hopefully they'll be helpful to you. I won't be talking about how to actually write the JavaScript as there are plenty of guides to that already.

Getting started

At the very top level of a backbone app (or backbone page in a traditional app) I start with either a router or parent view. If I need page state (history, linkable urls, etc) I go with the router approach. The router then initializes a parent view or views. If the page is simple enough I might just start with the view. Quite often there isn't any real model data at this level to worry about since this view acts as a container of sorts. Then I start thinking about child views.

I figure out how many high level bits of the page I have. Often these correspond to containers on the page. Lets look at an example from Facio:

I have a nav area and a report area. These are candidates for creating children. The goals in the report are themselves children. Etc.

Pro tip: When I was first learning Backbone I had a tendency to create child views in the parent view's render action. This causes views to be created way too frequently and will cause issues. Instead, I put a method called something like createChildViews on each view. This is generally either called by initialize or an Ajax callback.

Making (code) babies

createChildViews is tasked with looking at the model and creating whatever children need to exist. Those children may have their own createChildViews method that the parent will call. This will cascade down as many times as necessary for what I'm building.

I do a couple of things that I've found helpful when creating the children. First, I keep an array on each view that contains references to all of its children. I usually call this something like childViews or xyzChildViews with xyz being some description. Second, I create a property on the children called parent that points back to their parent. Third, I (sometimes) define methods in the view that give me back the entire chain of parents/grandparents/etc. This is helpful when I need to re-render something much higher up the hierarchy when a child is updated.

Each of these children will have a model or a collection inside of them. While I generally let me views know who their parents are,  my models are unaware anything else exists.

Painting the pretty pictures

So now that I've created the hierarchy of views (with their models or collections) I'd probably like them to render out. When I implement render I have it render the current view and then iterate over all its children and call their render methods. Those children render and call their children and so on. Because I'm not creating new views all the time I can avoid the common zombie view problem.

Cleanup

One more bit of boilerplate that I generally implement is a close method on each view. Close will go through and call close on all of the views children and then dispose of itself. This lets me make sure I dispose of anything I want to get garbage collected and fire any events that need to happen. Again, having references to children/parents makes this easier.

Testing

I never test the DOM. Instead I wire up DOM manipulations into little 'private' methods and assert they are called. Then I eyeball test the manipulation worked. This seems to buy me a lot at little cost.

My JavaScript is continuously changing but these strategies have worked for me lately and hopefully provide value to you.

The Myth of Unit Test Value

I'm writing this blog post because someone on the internet is wrong...

More accurately, I saw an old comment about unit testing that I frequently hear hardcore testing advocates say. I'm not calling out the specific person since I suspect his understanding of the value of testing is more subtle than one sentence and that we may actually agree in practice. If you really want to figure out who said it here's the SO thread.

The basic comment is this:

Unit tests are just as important as production code.

I'm going to use pseudomath to explain why I think this is totally wrong. I'm going to ignore a lot of things in order to simplify.

Since I believe the point of software development is to build tools that improve the lives of the people paying for the tools (you, your boss, your customer's shareholders, etc) the basic equation for the value of a software product would look like.

CodeVal - CodeCost = NetIncreaseInHappiness

If unit tests are equally valuable to production code and we ignore everything else then the formula for CodeValue is:

ProdCodeVal + UnitTestVal  = CodeVal

If the above is correct we could simply double our unit test coverage, scrap our production code altogether and have just as good of a product! Yay!

This is totally wrong. And also bad math.

I know this is oversimplifies the argument a lot of people are making but I think that saying unit testing are just as valuable as production code is symptomatic of an unhealthy way of looking at unit tests. Unit tests are valuable for a few reasons:

• Your production code is more likely to work right (+ProdCodeVal)
• Other developers can more easily understand what's going on (-CodeCost)
• Your code is more maintainable (-CodeCost)
• You get to look down on people who don't test (+EgoVal)

All of those (and more) are great but they are all factors weighing into the value or cost and not inherently valuable on their own. Unit testing is a tool, not a end product. Like any tool, you should only use it if it helps make the end product somehow better than it would be otherwise. That's why most of us don't test our databases. That's why you might want to test that a complex function does what you think it does.

I like building things. A screwdriver is a great tool for building things when you need a screwdriver. I don't use a screwdriver when I need to hammer something or (hi @mattdarby) when I want to see if a circuit is hot.