Category: Uncategorized

I used to have a problem learning new programming languages. It wasn’t that I found the syntax difficult, or that concepts eluded me. Rather, it was the idea of learning an entirely new language a fairly time consuming task. It hasn’t been until recently that I’ve come to accept that my definition of what learning a new programming language means was wrong, or at least poorly thought out.

What learning does not mean

First, let’s clearly define what learning a new language really means. For a long time, I always assumed learning a new language meant understanding the ins-and-outs of the ecosystem surrounding the language. What I mean by this is best explained in an example.

If I said I knew Objective-C, I’d most likely mean I know iOS development. Of course, one can know Objective-C without knowing iOS development, so I’d make sure to write both Objective-C and iOS development down. But when I said I knew Objective-C, it meant I also understood the tooling around it. I understood how to use Xcode, I knew the ecosystem, how to write Podfiles, I understood the various blogs and communities surrounding Objective-C. I would also use Objective-C as the implication that I knew the Cocoa Touch framework (helped along by using iOS development). The idea here is that I knew much more than just Objective-C. And learning all this stuff couldn’t happen in a few weeks.

How people can learn in a few weeks

So, using this as a standard, I always shook my head whenever someone would talk about picking up a new language in a few weeks.

“A good programmer can pick up a new language in a couple week,” was a mantra I never quite agreed with. The problem, however, wasn’t the mantra. It was that we were defining what was being discussed in different ways. A programmer can pick up a language in a short period of time. Especially in an environment where there is support for that language. Take any language you sort-of know, and put yourself in an environment where you are working alongside people you’d consider experts in the field, and you’ll probably agree that you’ll pick up the language fairly quickly.

At the end of those few weeks, you’ll be productive. You won’t be perfect, and you’ll still have much to learn, but than we can use that to describe anyone, really.

What learning a new language means

When looked at through those eyes, learning a new language is really a matter of understanding how to use the language to be productive. It doesn’t mean you understand every nitty gritty trick. Rather, it means you know enough to move forward. You have a foundation in that language.

If asked to write a program in that language, not only could you evaluate whether the language was suited for the program, but you would know where to start.

When looked at in that light, learning a new language becomes a much less daunting task.

How to learn a new programming language quickly

This is the part of my article where I make a bold claim. That claim is “quickly.” However, the idea is sound, and not originally mine.

The quickest way to learn a new language is to implement a program you already know how to build. The classic example for the web is to build a blog. You already know how to build a blog. There is a good chance if you are a web developer, you’ve built one yourself at some point. So, by building a blog in your new language, you are focused on the language, not the problem.

Now, don’t get stuck up on building a blog, as this is just an example. Your program for learning can be anything you want. It can be an IRC bot, a mail client, or your own personal image upload server. It can be a Twitter client as is popular with iOS tutorials, or it could be a game server for tic-tac-toe. The point isn’t the program. Rather, it’s that it’s complex enough to incorporate multiple technologies you’d want to know.

Going back to our blog example, you could say that the blog needs a database, thus ensuring you’ll need to learn how to connect to various databases. You’ll need to learn how to cache those results, so you aren’t connecting to the database when you don’t need to. You’ll need to handle data input, comments, and tempting. You’ll need to understand quite a bit, but it’s not difficult enough that you are caught up with what you are doing. Rather, you are focused on how to do it in the language you want.

A new year

With the new year approaching, I’m sure there will be a lot of people resolving to learn new programming languages. Instead, I’d like to challenge you to change your thinking. Don’t learn a new programming language. Rather, write a program in a new programming language.

Originally posted on the MeetMe Engineering Blog.

I enjoy speaking in front of an audience. This doesn’t mean I don’t get nervous. Oh, I get nervous enough that I really do need that drink of water. I still love it – the challenge of reacting to the audience, the desire to impart what I know into something meaningful for them.

The greatest feeling I can get from a talk is someone coming up afterwards to thank me for saying what I said. For someone quoting me to me. Hell, for rephrasing what I said more eloquently. But really, it’s about connecting.

But beyond that joy, what real benefits does it give me as the speaker? And, at the same time, what benefits could it provide you?

I want to share my recent revelation with you, something I truly discovered after my most recent talk at Atlassian Summit 13. I had submitted the talk proposal four months earlier. I proposed to talk about a project I was currently on, and about the lessons we had learned in trying to do all that we would try to do. It was a lessons-learned talk, a retrospective. At the time, I had no clue as to what I would end up talking about. I just knew that between the time I proposed the talk and the time it came upon me, I would have learned a few things along the way.

Knowledge

It was because of accepting this talk that I forced myself to really explore what was going on in the project. What I mean is that while I knew there were problems, I couldn’t just point to the problems and say, “See! Don’t do that!” I had to understand why the problems existed, and more importantly, I had to offer up solutions.

I also started going around to certain individuals to try and understand their point of view. That means discussing matters with members of QA, and the other programmers on the team. From them, I not only gained better insight, but also uncovered wonderful metaphors I could use to describe the problems we were facing.

My initial slide deck was structured in the same what that a refactoring recipe is often presented: a smell, followed by why these are problems, followed by solutions. It seemed simple enough. But this was really just the first step. When I started practicing the talk, I came to the realization that while the presentation was factual, it was also fairly negative, and focused too much on the problems. I had very specific points I wanted to make, and most of these points were small bullet points in the third slide of each Smell/Problem/Solution set. I was burying my lead at every point!

The process of practicing my speech, of doing the research to put it together, of talking to individuals drove me to the point of understanding not only the problems, but also how I could properly present the solutions.

But that’s the point. By accepting my role as a speaker, by agreeing to get in front of people to speak on a topic, I need to make sure I know what I’m talking about. So that means I’m going to research the heck out of my topic of choice. That might seem backwards, but it’s not. You see, you’ll want to speak on a topic you’re already familiar with, but once you realize you need to speak on that topic, you’ll force yourself to work extra hard, understanding the additional nuts and bolts.

In the same way that teaching something requires you to learn about it, speaking on a topic means you’ll spend that extra time. And it’s also a great way to learn something. Normally, we are trying to learn something so we understand it. However, when you have to speak about a topic, you have to learn how to describe it easily. You have to impart that knowledge onto others. That means not only understanding it, but understanding it well enough that you can share that information with your audience.

Basically, giving a talk forces you to learn more than you normally would.

Confidence

Since as far back as I could remember, I’ve never had an issue being in front of people. That’s not to say I don’t get nervous, but rather that I overcome that nervousness. I’ve been in plays, I’ve given talks on topics at local events, I’ve stood alone in front of hundreds, I’ve been a member of a panel; but a talk at a national event is distinctly different. Unlike most other cases, a talk at a conference is one where you are very much aware money was involved (usually a significant amount) and people are choosing to use some of their limited time at that conference to listen to you. You are keenly aware that they did not pay to listen to you, but rather, paid the conference in the hopes that they chose correctly when allowing you to speak.

It wasn’t until I got to Atlassian Summit that I fully realized the gravity of my decision to speak. It was far larger than I’d anticipated, and the audiences in each of the tracks easily went beyond 200 people. And not only were there a lot of people, but the caliber of these people were intimidating. Lockheed Martin, NASA, Disney and LG just to name a few. I’m pretty sure I’m forgetting even larger ones. The point for me was learning this, and knowing that I had to give a talk in front of these people Thursday morning. It’s not that I didn’t think I could give the talk. Rather, it was worry that my talk might not be worth their time. Will my talk make them feel as if that hour had been a waste?

Basically, I wasn’t confident my talk was of any value to the audience I was presenting in front of. I shouldn’t have been worried. A large company is still made up of small teams, and those small teams still have the same problems other small teams have. It wasn’t until after the talk that I truly understood that. In the end, the confidence I gained from giving that talk would help me reach higher and farther than I would normally.

I’m talking about the confidence you get after a talk. That feeling you get when you finish, several people come up to you, thanking you personally and wanting to talk further about what you just spent thirty-minutes to an hour talking about already. The thrills of having someone come up and quote you to you. Reaching people.

That confidence can’t be found any other way. You can only earn that confidence after speaking. And that confidence will stay with you far longer than other kinds. And in the end, it will help you drive yourself farther along, to push yourself further.

Friends

The opportunities to speak can also help bring new friends. I’m not speaking about the act of speaking. But speaking in front of new people means you are meeting new people. You are visiting new places. And that brings you new opportunities to make new friends that you would not have made otherwise.

And beyond just making new friends, you can also learn from other people. I’ve been lucky enough to hear interesting stories from people sharing what they’ve done. Even when what they do has nothing to do with what I’m going to talk about, I’m still learning, and making new friends.

The desire to share my knowledge, the desire to speak, gave me the opportunity to make new friends. Meeting up at local user groups and offering to share my knowledge put me in the spotlight. When I moved back to the US, the first friends outside of work that I made were those I made at user groups. Being active in the user group with talks presented me with opportunities to work with them, and in the end, become friends.

You should speak

You really should. You won’t start out in front of a large crowd. You’ll do it first in front of people you know such as coworkers at your company. You’ll branch out into local meet up groups, speaking on carefully selected topics. And maybe that’s as far as you’ll ever want to go. That’s fine. But maybe you’ll want to go farther. And you’ll love it.

You really should try. It can be scary. It is a challenge. It does take work. But it can be worth it. And it can take you places you would have never gone otherwise.

Since speaking at Atlassian Summit (of which I’ll be writing and sharing more about in the coming weeks), I’ve been following up by reading more and more about the topics that I covered. Here are a few articles I’ve come across that deal with leading a technical team and the issues and decisions those leaders must face.

On technical debt, complexity and opportunity cost

This article isn’t just about technical debt, it’s offering advice on how to approach technical debt. What to do about keeping it, or removing it. The idea that when developing a new feature that integrates with older features, keeping that older feature still requires time and effort.

it’s worth challeging the idea that every old feature is going to have more business value than the new features they are competing with.

He also goes into thinking about the cost of a feature as not just the time it takes to complete it, but rather, when it’s finished, the truth time it will take to support is only just beginning.

When you release a feature it’s not the end of the job, it’s just the beginning!

Something I’ve always encouraged and pushed for is the idea a criteria for the success of a project. But I like the idea of pushing for criteria for the success of a feature. Is a specific feature worth keeping?

it’s important to define success criteria upfront. If the feature doesn’t meet the measure of success you’ve defined, remove it. And if it does, we know the debt is worth taking on.

The one cost engineers and product managers don’t consider

This is an excellent read by someone who has taken the time to be fairly introspective in his craft. It’s fairly clear when he states the reason for discussing what he does.

For years, the two things that most frustrated me to hear from product managers were “how hard would it be…” and “can’t you just…” It took me quite a while to figure out why I had such a strong, visceral reaction to these phrases. The answer seems obvious now: The work of implementing a feature initially is often a tiny fraction of the work to support that feature over the lifetime of a product [Emphasis mine]

He also goes on to make the point that even features that have no impact to the quality of the product are still negatively impacting the complexity of the software.

If you methodically test the impact of each change you make, you can discard those that are negative, but equally relevant to complexity cost, also discard those that are neutral. A change that doesn’t hurt the key performance indicators still hurts the product because it adds complexity debt that must be paid on all future projects. [Emphasis mine]

Without even realizing it, he comes up with a couple of simple rules that, if you understand, can lead to better software, and as a result, allow you to build better products.

• Train your entire engineering department to understand complexity cost and to use data to keep it down.
• Embrace simplicity in your product and in your code. The value is in what gets used, not what gets built.

There are no small changes

I enjoyed this article because it took us through an example of how a simple requirement can lead to a lot of extra work. The idea of now limiting a product review to 140 characters.

Sandwiching this story are two keep points:

• There are no small changes when you’re committed to delivering quality software.
• Scope grows in minutes, not months. Look after the minutes, and the months take care of themselves.

What CTOs fear most

I think all software developers would do well to strive to be good CTOs, whether they are CTOs or not. A CTO does more than worry about the technology. It’s a balance of meeting the needs of the business with building good software. Allen Rohner said,

if the technical solution is 100% stable and not being strained at all, it probably means we’ve spent too much time on it.

He also says with something I wish more software developers would strive for:

What’s different about being a CTO vs something like a lead engineer?
Understanding the business model. Making technical choices that shift the business.

The software architect in me cringes at this disregard for software that was obviously well crafted, but the CTO in me understands the point. And that supports the authors opening point in the article:CTOs are worried about how to be great leaders.

After all, being a great leader means not only making that decision to not spend as much time on that technical solution despite knowing it’s not 100% perfect, but also making sure the software architects understand that you aren’t blindly asking them to accrue technical debt.

It’s really interesting to read all the challenges and thoughts that go into being a CTO. It’s not just a fancy 3-letter title. It has meaning.

These four articles cover a lot of information, and I plan on pulling from them key quotes for use later on (some of which I’ve done above). You should definitely spend some time reading through them.