How I got my first real programming job (and how it could help you get yours)

I still get asked fairly often how I was able to get a programming job, despite the fact that I have a degree in music and didn't take any computer-related courses in high school or college. Since I think my approach was a good one, I'll post it here in hopes that someone else can use it to get theirs too.

I started by learning a low-level language

When I first realized that I wanted to learn to build web sites, I had purchased several books on the subject. They suggested that C++ was the language to learn to do web programming, so I bought a book to help me learn C++. (I learned later that that book was horribly out of date, which I'll get to in a moment.) I read the book and compiled the examples, but I also tried to bend and break the programs to try to stretch my understanding of the subject.

I then learned a "hot" programming language

As I just mentioned, that book was out of date, even 10 years ago when I first started learning to program. Few companies were hiring for it, and those that were looked for more experience than I had. I learned about the existence of C# - which is a C++-like language that was pretty popular at the time. However, since C# is essentially built on concepts from C++, I was able to pick up C# much more quickly, and have a much deeper understanding, than if I had just started with C#.

I got some experience

I had naively thought that being able to demonstrate knowledge of a language would encourage companies to hire me (or at least interview me). Not so much. I did manage to get a job at a music store, though, where I could do some programming. Luckily for me I had other skills, like knowledge of band instruments and experience selling items on eBay that they were looking for. But it was that first experience that showed me that programming in real life is not as simple as the books make it seem. I got to experience real-world programming first hand. I made sure to keep learning, though, since programming part-time wasn't giving me the experience I wanted as fast as I wanted it.

I finally got that first job - at a consulting company

Once I had some experience, I finally got a job at a consulting company. My first few projects weren't all that glamorous - I was helping implement a rather annoying CMS system for several clients - but I kept asking questions and kept learning. I also kept learning outside of work hours too, which meant that I was prepared when I was put on a more difficult project.

The advice I'd give to someone looking to get a programming job

I think that I stumbled upon a good method for creating good programmers:

1. Learn a language that is the basis for a modern language - like C++, HTML, JavaScript, etc. Unlike me, though, you should have a general idea what people are hiring for and purposefully choose a related language.
2. Learn a related language that people are hiring for - like C#, HTML5, popular JavaScript frameworks, etc. As someone trying to break into the industry, you'll probably have better luck with a language that few people want but nobody knows, than a language that has a lot of openings but a relatively large number of people to fill them.
3. GET SOME EXPERIENCE!!! Volunteer to build something for a friend if you don't luck out and find a purple squirrel job like I did.
4. Consider looking for a job at a consulting company. These companies are often constantly hunting for people who have a proven ability to teach themselves technology, since they are usually constantly learning new technologies to stay on the cutting edge themselves. You'll get a wide range of experiences with a range of projects and companies, which will help you decide where you want to be for the long term.
5. Finally, KEEP LEARNING!!! This is true for any field, but is even more so for developers. Technologies change constantly. Programmers who can learn new technologies and can adapt to them will be employed for the foreseeable future. Those who can't (or won't) adapt won't.

When it comes to software, yes you can. But should you?

One of the great things about being in the business of creating custom software is that I can generally make whatever is needed in order to solve a business problem. Need a system that consolidates previously separate systems into one to simplify cross-departmental communications? Been there. Need a system which allows you to increase product quality by enforcing some standards? Done that. Need software to improve employee morale? Well, ok, software has some limits. Software can indirectly help with company morale, but some other things need to happen, too. (That gives me an idea for another blog post....)

But with such a wide range of possibilities, it's easy to fall into the thinking that just because most problems can be helped with software, that one should solve those problems. The reality is, though, that not all problems should be solved, and of those that should, not all of them should be solved now. Here are some common mistakes that I've seen:

Trying to solve every facet of a single problem at once

When I'm trying to solve a problem, I'm rarely blessed with a simple problem with an unambiguous cause. Instead, I'm often faced with complex issues that are related or semi-related to several dozen other issues. The tendency in such situations is for people to want to solve all of the related issues at once. If you're in there fixing one issue, why not fix this other problem while you're at it? Oh, and this is related.... Whenever I've tried, or whenever I've witnessed others trying, to solve everything at once, the problem becomes too overwhelming. Find something. Fix it. Find something else. Fix it. Repeat ad infititum.

Failing to keep the big picture in mind

When you take the find it/fix it mindset too far, you run the risk of creating additional problems. I've seen this most commonly in programmers (including me) trying a bit too hard to be Agile and business leaders focusing too much on solving one particular problem. A good solution, regardless of whether it is implemented with software or not, is designed with the future in mind. Are we going to want to include other systems? Other departments? Will this process need to be repeated? If you have the future in mind, you can anticipate problems and build the solution in such a way so that it can be extended/modified in the future. If not, you will end up with an expensive integration process to build and maintain.

Trying to solve all problems at once

Whenever you are in the process of addressing an issue, there is always a temptation to address other unrelated issues in the company. My experience, though, is that most people (including me) can only accomplish so many goals effectively at once. If you try to spread people too thin, they simply won't be able to concentrate enough on any one solution. Then you run into the situation where you have a seemingly endless number of projects that never get finished. Instead, focus on a small number of important challenges. You've lived this long with the other issues - a few more months won't be so bad.

Trying to solve the hard problems first

Sometimes the most important issues to a company are the ones that are the hardest to solve. When that happens, it is easy to get bogged down in an endless series of discussions that never seem to solve the core issues. In these cases, choosing one particular aspect of the issue to solve can help give you quick wins (which will be important in keeping up morale when things get tough) and can give people an idea how the larger solution will work.

Making super-sized solutions

As I wrote about in an earlier post, programmers in general (and I in particular) have a tendency to create solutions that are more robust than the situation allows. This can include taking the time to automate a process that's done once a year, making an API for a single-use code library, or creating processes, as seen in this comic:

(photo gleefully taken from xkcd.com)

A co-worker of mine wisely said, "whenever I find myself doing something for the third time, I find a way to automate it". But make sure you wait for that third time.

Trying to shoehorn a solution into a particular software product

It's also important to note the limitations of the software that you are using. Every software product has a list of available features, but most of those have a secret list of features that are badly implemented. (SharePoint is notorious for including these, but that will have to be a different blog post.) If you find yourself in a situation where you discovered that your idea requires a feature to be differently implemented, don't hesitate to reevaluate your solution. If you don't, you'll likely have software that not only works poorly on day one, but it will be expensive to maintain.

Summary

Don't fall into one of the above traps. It's easy to think that just because everything can be done, that it should be done. Instead, make sure that you are spending time in the most efficient way possible to make the most from both your time and everyone else's.

If you can think of any other common examples of software teams creating something because they can but shouldn't, feel free to add them in the comments below.

Why Yammer is such a tough sell

I've been to several user group meetings about Yammer, and inevitably each meeting is dominated by people who don't see the need for this technology. (If you're wondering what Yammer is, you may want to start elsewhere to get an overview.) With success stories fairly common, why is Yammer such a tough sell? I think the answer lies with these issues:

1. Yammer is best good at increasing collaboration, which only indirectly meets most managers' goals.
2. As summed up in this (possibly apocryphal) Henry Ford quote: "If I had asked people what they wanted, they would have said faster horses." When managers do want to tackle issues that Yammer can solve, they think of managing e-mail or managing documents, not choosing a brand new type of tool.
3. Yammer is a tool that encourages openness and collaboration, when some organizations still operate in the communication dark ages dominated by process and control.

So if you're trying to persuade members of an organization to use Yammer more, what can you do to make Yammer an easier sell?

First, focus on how real-time collaboration helps teams solve problems more quickly and prevent miscommunication more effectively. Do NOT focus on any particular feature of Yammer, no matter how "cool" you think it is.

Try to get buy-in from managers to start a pilot program with a limited group. Have a specific reason to use Yammer in that program, such as discussing changes or replacing status documents. Don't just throw Yammer towards a group of users and hope that the software catches on.

Be prepared to monitor the use of the software, including making suggestions for improvement or nudging users away from undesirable behaviors. The line between control freak and allowing chaos can be fuzzy, so be prepared to make a few mistakes early on here. 

If you have the misfortune of working in an environment where item #3 is a problem, then tread slowly, and be prepared for some backlash. Feel free to create some closed groups to start to get people used to the idea of (somewhat) open communication, then expand from there. If done correctly, implementing Yammer can begin the process to change the organization to a more collaborative one.

Finally, if you're still having issues, attend a Yammer user group meeting. Many of the user group meetings here in the Chicago area do a surprisingly good job covering the cultural aspects of incorporating Yammer into company communications.

If you're being asked to do the impossible, maybe you're asking the wrong questions

I watched a video recently about what it feels like to be an engineer in the corporate world. I found it extremely funny in no small part because it reminded me so much of some of my interactions as a computer programmer with salesmen, project managers, and clients/business people. Before I go too much further, please visit http://www.collegehumor.com/embed/6961066/how-it-feels-to-be-an-engineer-in-the-corporate-world-sketch, then come back. (I can't embed the image in the blog - from what I can tell only embed Google-owned YouTube video in a Google-owned Blogger blog. Go figure.)

Ok, you've watched the video? Don't get me wrong - the majority of my interactions with others weren't like this. Generally people are understanding of what is possible and what is not, and generally I've been able to build something that makes everyone happy. What struck me, though, is that when conversations go sideways, they do so because they were making the same mistake that the people in this video were making. Instead of focusing on the problem at hand, they were focusing on the means by which the solution should be delivered.

This mistake is fairly common. We all want to skip the problem definition phase and jump straight into the solution. It's not hard to see why. The client/line-of-business team thinks they know the problem and merely look to the engineers (software or otherwise) to implement the solution. The engineer team all too often is focused on how to implement what is being asked. Neither side has the knowledge to evaluate the solution's ability to solve the problem at hand.

Instead, we must all focus on defining the problem. Most of the time, once the problem is defined, talking about solutions isn't filled with conversations about what's possible and what's not, but instead is filled with talking about what is worth the effort. And the latter is a much easier and more pleasant conversation.