Lessons I Wished I'd Learned Earlier As An Undergrad

Having worked at a real company now for several months, I've been given the opportunity to go back to my Alma mater and participate in a lecture with some up-and-coming students. And get free food, of course, since this is a university event. I received fairly short notice (5 days) to come up with something engaging to talk about for anywhere between 5 and 20 minutes.

The topic: Lessons Learned After Graduating That Would Have Made University a whole helluva lot easier. Here's a short list of things I'm considering:

• Involvement
• Find groups that encourage development of your programming skills including user groups, tech lectures, open-source projects, and startup weekends.
• Use IDEs
• Why did this one take me so long to figure out? At my university, they taught us to use MATLAB freshman year (which hardly qualifies as an IDE without any form of auto-complete), and they showed us how to install Netbeans and Eclipse my senior year (but did not encourage us to use them. They also taught us how to use a VHDL IDE my senior year, but that's a different subject. Using IDEs greatly increases productivity, syntactical consistency, and enhances organization. A problem is that it can dumb a programmer down by not forcing them to look things up, and a dev can become lazy using auto-complete all the time.
• Reach outwards
• Don't do what you always do. Do things that you've never done before. My degree had a strong focus on C: so I did almost all projects where I was given a choice in either C or (eventually) C++. Given a distant deadline, a project could be started in any number of interesting languages, including Ruby or Perl or CoffeeScript or Scala.
• Don't do an activity just for your resume
• This one is the worst. People join a half-dozen clubs just to pad their resumes. This should not be done. Join one or two clubs that you're passionate about instead, and put a lot of time and effort into making that organization better. Companies will be far more interested in your automation of the secretary position in your Linux Club than your perfect attendance at your Rock Band Club.
• Use Office Hours
• Stuck on something? Go to office hours. It doesn't matter if it seems mundane, or the professor already explained it in class, or you skipped the lecture on this material, you will save yourself a world of time by going to office hours.
• Don't avoid lesser-known companies
• When I went to career fairs, I would be sure to visit all the companies on the list that I recognized. I would walk up to these companies, hand them my resume, walk away, and likely be offered an interview via email several days later. However, one career fair I took it upon myself to stop by several companies of which I had no idea what they were. So I stopped and I asked them if they were looking for someone like me. Some said yes, some said no. The ones who said yes took my resume, talked to me about all the information on it, and signed me up for an interview on the spot. The larger companies seemed distant and made me feel like a hamster in a cage. The smaller companies were warm to me and made me feel like a real person.
• Be "That Person"
• We won't have to worry about the project if we have "that guy" in our group. "That guy" works hard and gets the job done. Just do it. Work late. Understand things. Become an expert in whatever project you're working on. Your groupmates will respect you and any presentations you give will show off your vast amounts of knowledge.
• Use the internet
• Stuck on something that you know hundreds of other people have already solved? Use the internet. The internet knows the solution to that integral. The internet knows how to create a stack using a linked list. The internet knows how to get that program installed on your dev machine. You'd be surprised at what seemingly arbitrary things you can find answers to on the internet.
• Learn keyboard shortcuts
• Makes you more productive. I could list some, but they're on the internet.
• Write down everything
• You say you solved this problem three weeks ago but now you can't remember how to do it? The professor has your homework with the solution on it but never got it graded? You found some awesome Ruby syntax to do 10 lines of work in a single keyword? You should write these helpful things down in a notebook somewhere. Have several notebooks for several different topics. You'll thank yourself later.

Shakespeare Programming

The following lines of code group a list of customers by city and orders the groups with more than two values by key.

var custQuery =
    from cust in customers
    group cust by cust.City into custGroup
    where custGroup.Count() > 2
    orderby custGroup.Key
    select custGroup;

I dub this style of coding... "Shakespeare Coding." Why do we write code like this? This code is taken directly from the MSDN website, which implies that this is how Microsoft expects programmers to write code.

My problem with Shakespeare Coding is that it is too close to the syntax of a language near and dear to my heart. A language with weak typing, ambiguous references, poor commenting, and a rotund standard library filled with functions that rarely anyone will ever use. That language is English.

Shakespeare Programming is coding in a style which is akin to writing prose. I attest that this style of coding is not compatible with a programming mindset. Programming syntax should be readable, obvious, and terse. Prose has many nuances and intricacies that can make it ambiguous and difficult to interpret

Let's modify the code above to be a little bit more gentle on my eyes, shall we?

var custQuery = customers
                    .GroupBy(cust => cust.City)
                    .Where(group => group.Count() > 2)
                    .OrderBy(group => group.Key);

That wasn't so hard. And now what we have are three clauses, each of which has a very obvious and meaningful purpose in the main statement.

Desktop Deleted in Ubuntu 12.04

While trying to save files to ~/Desktop yesterday, I had the misfortune of saving a file as ~/Desktop. I wasn't actually aware at the time, and went about my usual business for several days. Then I restarted my computer and my desktop was loaded up with all the documents and directories located in my home directory. In addition to the items I expected to see in my home directory was a PDF named Desktop. Deleting this file and restarting one's computer is not enough to fix this problem. The fix: 1. Open up ~/.config/user-dirs.dirs 2. Modify the line XDG_DESKTOP_DIR to say XDG_DESKTOP_DIR="$HOME/Desktop" 3. Save and close that file. 4. Open up a terminal 5. `killall nautilus` Voila! Far easier than I anticipated. Note that if you're one of those people who stores non-temporary files in ~/Desktop, you will not recover those files using this method.

Why I've Grown To Love C#

I admit, I'm somewhat of a Linux programming snob. Why? Mostly ease, somewhat because it was how I was taught in school, and partially because I love the idea of FOSS.

But times change quickly, and I was thrown onto a C# project with a bunch of folks who were quite used to a Windows environment. Despite the obvious hassle of having to use Windows and deal with Visual Studio, .NET has some pretty cool things to offer.

Take the example where I have a class of students; my goal is to find their averages and get the student with the highest grade so I can single them out to the rest of the class. Let's first do this in vanilla C++:

Vector<Student> Students; // contains a short int array of test scores called Tests
...
short highestGrade = -1;
Student teachersPet;

for (int i=0; i<Students.Size(); i++)
{
    unsigned int sum = 0;
    for (int j=0; j<Students[i].Tests.Size(); j++)
    {
        sum += Students[i].Tests[j];
    }
    sum /= Students[i].Tests.Size();
    if (sum > highestGrade)
    {
        highestGrade = sum;
        teachersPet = Students[i];
    }
}

That's a mouthful. Not including intialization code, there are 7 lines of "useful" code, 5 auxiliary variables, 1 division, and a bit of array indexing. Let's perform a literal translation to C#:

List<Student> Students;
...

Student teachersPet;
short highestGrade = -1;
foreach (student in Students)
{
    int avg = 0;
    foreach (score in student.Tests)
    {
        avg += score;
    }
    avg /= student.Tests.Count();
    if (avg > highestGrade)
    {
        highestGrade = avg;
        teachersPet = student;
    }
}
</code></pre>

Pretty much the same code. We are utilizing the foreach operator, which lets us get away without any array indexing. Still 7 lines of "useful" code, still 3 auxiliary variables. Assuming the Tests property in the Student class is a array of ints, we can find the average in a much more succinct fashion:

foreach (student in Students)
{
    if (student.Tests.Average() > highestGrade)
    {
        teachersPet = student;
        highestGrade = student.Tests.Average();
    }
}

Four lines of functional code, two auxiliary variables. Why stop there? Using a LINQ-based approach and adding an Average property to the Student class, we can get rid of all auxiliary variables and find the max using the average in one line of code:

var teachersPet = Students.ForEach(x => x.Average = x.Tests.Average()).MaxBy(x => x.Average);

The same functionality in a single contiguous line of code! Not to mention these Average, ForEach, and Max functions can be better optimized by our compiler than what we had before. But is that as far down as we can squish it? What if we dropped the entire ForEach statement and just compared the averages:

var teachersPet = Students.MaxBy(x => x.Tests.Average());

And that's why I've grown attached to C#. LINQ is probably my favorite thing to ever come out of Microsoft

What's with Who Moved My Cheese?

Who Moved My Cheese?


Johnson, Spencer






Who Moved My Cheese? was a "required" book to read for new employees at my current company. Although the story is very short, the message is very straightforward: Don't get stuck in a rut. That's it. It took about 40 minutes to read through it.

I must admit I wasn't a fan of this book. It seems to have been written for a career path where getting into a rut was easy and relatively safe, but the world of software development is certainly not like that. Now that it's 2012, fewer and fewer people are still programming in COBOL, FORTRAN, BASIC, or even C for that matter. We are frequently given opportunities to learn new technologies that are more powerful and make our lives easier.

Having graduated from university recently, the message was somewhat lost on me. As students take different college courses every semester, they are frequently thrown for a loop and forced to "find cheese" for each new class in its own way.


Don't get me wrong. I don't think Cheese? is completely useless. I think a great demographic for this book would be the recently laid-off employee who may need some motivation to get back out in the work force. However, I don't think this book is a must-read for everyone. In particular, there was a line included in my version of the book which said that anyone who disregards the story is a know-it-all. I take offense to that statement; it has yet to be proven whether or not I actually "know it all."

If your coworkers have all read this book, read it because it only takes about an hour to read and no one wants to feel left out. If you need some motivation to get out of a rut, you don't need to read a book to tell you to get off your rump and do something about it; just do it.

Link: Researcher reveals how “Computer Geeks” replaced “Computer Girls”

Below is a link to an interesting article on what are called the first programmers (link courtesy r/programming). Unfortunately, women were booted out of the programming sector once the world realized how complex the job was. Now, 50 years later, we no longer tell women they can't be intellectuals and yet software development is still a male-dominated career path. Maybe the "Computer Girls" will make a comeback. Maybe Cosmo will have articles about software aimed at visionary young women. Just imagine the right answers to the sex quizzes leading you away from the brawny athlete and instead to the programming dreamboat!

Researcher reveals how “Computer Geeks” replaced “Computer Girls”

Having Read The Passionate Programmer

	The Passionate Programmer (2nd edition): Creating a Remarkable Career in Software Development
	Chad Fowler

The Passionate Programmer is essentially a book about self-motivation. It is neatly wrapped up into several sections about marketability and rekindling the passion for software development, and these sections are broken up into delightfully bite-sized chapters which make the book a breeze to go through.

This book preaches that we should be happy with our jobs but not complacent. The author, Chad Fowler, believes that, at all times, we should be looking for ways to better ourselves as professionals and as individuals. This is certainly a tall task. I've been having trouble finding time to do very many extracurricular activities lately, what with moving to a new city, starting my career, buying a car, and planning a wedding, but what this book really makes me want to do is search the internet for some new software technology I don't understand and learn everything I can about it. It's all about branching out from the norm and doing things one may be uncomfortable doing. I'm fortunate to have started a job at a company where I have the opportunity to frequently switch projects and do things that are completely different fairly regularly.

I also see it as a good thing that I was thrown into technologies I'd never had to deal with before during my first day on the job (Windows programming, .NET, WPF, TestStand, CruiseControl...).  All jobs should be like this. Companies hiring people for their potential to do anything instead of their potential to do a specific task.

Fowler also mentions being social as an important step in a passionate career. Managers, programmers from other companies, managers of managers, developers at conferences, managers of managers of managers, and even folks in online forums or blogs may be the link to an opportunity. I normally just live under the thought chain of "If I write it, it's good, and I'm efficient, I'll get noticed." But Fowler insists this is not true! Talking to these kinds of people and letting them know what you've been up to is beneficial in that it gives managers a sense of how the project's going, it may give other developers ideas or inspiration to solve problems, and it can help you feel more accomplished. It's a good mindset to be in, and it simply involves climbing out of the cubicle every once in a while and finding the right people to talk to.

This book provides good motivation to continue pushing oneself and it provides inspiration for how to better manage one's non-working life.