Step 1 - Find a problem that plagues everyone but everyone just kind of puts up with it because that's the way things are and fix it.
Step 2 - ???
Step 3 - Profit!
Today we had a bit of a network outage in our building. It was there, there and there some more. Then it was gone, gone, gone! Since most geek socializing happens over some kind of instant messenger or Facebook wall, this is a major disruption in our otherwise movie-star like popularity.
Also, there’s the work thing.
Next to electricity, a network connection is the life blood of a developer. User accounts are on domains which have to be accessed to log into machines, you need to make connections to source control servers and most communication is through electronic mail. Unfortunately, the Outlook guys haven’t gotten around to implementing smoke signals yet.
When the network is down, everything comes to a halt. Which is then as good an excuse as any to party in the hallways.
The Microsoft hallway party comes in a variety of stages:
- Congregate in the hallway
- Bring beverages
- Bring food
- Find out who has some kind of gaming console
- Hook it up to a projector in a conference room.
- Discover you can connect to Xbox Live
- Suggest we start some Halo 3 matches and pwn some n00bs!!
- Sudden sinking feeling that this means you can probably check your email again.
Alas, my Smash Brothers skills exhausted, it looks like it’s time to go back to work.
For those of you at RIT, be sure to stop by the career fair on Wednesday. I’ll be the guy gloating over how awesome his job is compared to the guys in the next booth.
Are you a good developer? It’s not just the code you’ve checked in, it’s the code that you’ve allowed to be checked in too.
When someone sends you code for review, it is your duty to make sure it’s up to the quality bar set for your team. Compromise on this will and you will set yourself back farther in the future than the time it would take the sender to fix the code in the first place.
Be insistent. I have argued with developers more senior than I am on how a particular change should be made and the weaknesses in what they have sent out for review . This has landed me some particularly pointed emails. It's tough love. Not everyone will deal with criticism well so be prepared for a boxing match sometimes.
But let me say that the worst that can happen in a code review is the other developer forwarding your email to your manager and complaining about how you were such a jerk when it came to reviewing their code. “Chris insisted on this and that and wasted a bunch of my time. By golly, back in my day…”
Now review how this is a huge win for you: your manager has proof that you were thorough and didn’t stand down when faced with the choice to compromise quality or save time.
Most importantly, you have prevented the code base from degenerating. Bad coding is infectious: newer developers will base their code on what’s already checked in. Bad designs propagate into newer features, sloppy coding standards lead to a growing sloppy code base and quick hacks suddenly become standard practice for achieving behavior. It is ten times harder to back out a faulty coding standard that was seeded from a bad check in than it is to prevent it from being checked in in the first place.
By refusing to compromise, you will make a name for yourself as a good code reviewer. People will avoid sending you code for fear of retribution but their managers will insist that it get reviewed by you. Suddenly you’re an important person, and right out of college.
Any large company will have a variety of positions opened at any one time. This means that when you fly out and interview, you may be assigned to the team that needs head count the most. Or the team that the recruiter thinks you’re a best fit for. Or the team that the recruiter’s dart happened to hit.
I don’t know if any of these things are actually true, but what can happen is that you show up and interview with a team you have little interest in. The first time I interviewed here at Microsoft, I ended up talking to two teams that made me shudder as soon as the recruiter mentioned them. I’m sure some people were born to do backend SQL server work, but others are born to be awesome PowerPoint graphics developers.
Needless to say my interviews didn’t go very well, and I wasn’t offered an internship.
Later that year when I applied for fulltime, I made sure to emphasize to my recruiter ahead of time that I was interested in graphics. I ended up interviewing for Visio and a new secret project called “IGX” (later to be named SmartArt).
Oh the bliss. One interviewer showed me a screenshot of the new Office 12 rendering engine and how it was going to have all these great 3D features. “Man, that must be a pain to develop a user interface for” I commented, noting that moving a camera in 3D space with a mouse is neither intuitive or easy to get good results. His face lit up “Yah, it is!”
If I hadn’t found a team near my interest, I wouldn’t have nailed the interview and I wouldn’t have a job in an area that I love so much.
When you get an interview for a large company, ask who you will be interviewing with. You may get boiler plate “Oh, we don’t know until the day of, blah blah”. Push back and list your interests and ask if any of them can be met. If you know of a specific product you want to work on, be sure to mention it. If you just have this insatiable itch to work on Internet Explorer and you impress this upon a Microsoft recruiter before you fly out, the chances are infinitely better that you’ll get an interview there than leaving it to the day of.
While waiting for my latest change to compile, I discovered the “preview” option for TV episodes on Xbox Live is a great way to find out more about a series. I don’t really keep track of when new stuff is on, in general I’ll rent a TV series on DVD instead of waiting for it to show up on cable. Using Xbox Live in this way is 10x faster than digging through the Internet trying to find out what shows are interesting and video clips of said shows.
Now on the interesting list:
· The West Wing
· Jericho
· MacGyver
Now unfortunately on the “going to skip” list:
· Pimp My Ride (why is this under “Drama”?)
· The Surreal Life
· I Hate My 30s
It’s important that as a new developer you do not succumb to a mind numbing repetitive task.
One, you’ll look like an idiot when someone else does the same thing with a script or a tool but in 1/100th the time.
Two, you could have tons of time to slack off if you’d only used the tools at hand!
Things that are very handy that you should know:
Regular Expressions – Find and replace complex patterns of text. Many IDE’s, such as Visual Studio have an implementation you can use.
A scripting language, such as Perl – Take some kind of input, process it (using regular expressions), spit something out.
Excel – Generate number sequences from formulas and sorting data.
These things have saved me countless hours. I had to generate a templated class with a bunch of repeated typenames from T1 through T120. I wrote a quick Perl script to do my bidding for me:
$i = 120
printf( " template< " );
for( $j = 1; $j <= $i; $j++ )
{
printf( "typename T%d", $j);
if( $j != $i )
{
printf( ", " );
}
}
printf( ">\n");
What’s great about regular expressions and scripts is that if it turns out you have to change the formatting or the number of values you want to write out, it’s a simple change.
Plus it’s fun to write throw away code that only has to work once.
An Intern Story
When I worked as an intern for a nameless blue company, another intern was given the [fun] task of porting a database to a newer version. The work came down to taking this huge definition text file and making it work with the new system.
The changes were mainly comments now used slashes instead of apostrophes and some keyword differences.
For two days he chugged along hitting backspace and / repeatedly.
When I had finished my project, I was asked to help him. I copied the entire file into Word, did a couple of find/replaces and was done.
“Chris, the savior of the database!” they cheered [in my head].
Of course, now neither of us had anything to do for the rest of the week.
A Microsoft Story
We have some code which gets auto-generated based on some input data files. If you add new data, but don’t update certain helper headers, you’ll get a list of linker errors like the following:
Unresolved external GenClass1::s_id in gen.obj
Unresolved external GenClass24::s_id in gen.obj
Unresolved external TempClass1::s_id in gen.obj
Unresolved external GenClass8::s_id in gen.obj
Unresolved external GenStruct4::s_id in gen.obj
... (600 more lines)
So we have a handy dandy macro which will define the IDs for these classes:
DEFINE_ID( GenClass );
I could have spent all day copying and pasting the class names in. Or I could load the error output into Visual Studio and use its great find and replace tool which allows for regular expressions:
Find .*external and replace with DEFINED\_ID\(
Find \:\:s_id.* and replace with \)\;
The result:
DEFINE_ID( GenClass1 );
DEFINE_ID( GenClass24 );
DEFINE_ID( TempClass1 );
DEFINE_ID( GenClass8 );
DEFINE_ID( GenStruct4 );
... (600 more lines of code
I didn't have to write)
Tada! [........It’s the final countdown…]
As a new hire, you will mess up. But don’t sweat it, it's to be expected. You will learn more from a mistaked because you will be forced to find a solution when someone points it out.
Indeed your success as a new hire isn’t a question of how few mistakes you will make, but what you do to resolve those mistakes and prevent them from happening again.
I’ve learned a great deal about how to avoid common regressions or build breaks in the Office code base. It had been about 6 months since I’d caused the build lab to trip on one of my changes (and in the mean time I’d fixed numerous other build problems).
Of course, there’s always a new level of problem that you can cause. In fact, the longer you work, the more obscure the problem you cause will be (since you're so well versed in preventing more obvious problems).
Last week, I caused a problem.
The Problem
Two weeks ago, I checked in a change that looked like the following:
class Helper
#ifndef Project2
: public INewInterface
#endif
{
...
};
The idea is that INewInterface is not defined in Project2 , so I #define it out. We build two separate lib binaries, one that is linked by Project1 and one for Project2. There are several other places that do this exact same thing with INewInterface, so at first glance, this should work.
It compiled, it linked, I shipped it.
The problem that I didn’t see is that the definition for the Helper class lives in a seperate shared library. Which means that we get one binary that both Project1 and Project2 link against.
Now the problem is that Project2 expects the size of the Helper class to be one thing but in the compiled code it’s another. Miraculously (or disastrously) this links without error (for reasons I’m still not sure of)
The Result
Last Friday a bunch of dreary eyed people from Project2 came into my office bearing a post it note with a number on it; my change list number. It had taken them nearly two weeks to track down the problem that I caused. "TWO WEEKS!!" their eyes said.
It had some weird behavior: you’d step across a specific function call and all of sudden all the member variables of Helper get messed up. It's like the fundamental laws of the coding universe were thrown out the window.
In the end, someone went through all the recent changes and came across my code.
The Solution
So what did I do now?
Aside from dying a little inside since I had killed the productivity of practically an entire team, I went through my build process for the things that could be improved:
- Headers built into shared libraries are in the same folder as those that aren’t, we should separate them out.
- Change our “build verification test” script to run changes against Project2 by default.
- Brief our team on the dangers of changing this shared code and its headers.
- Talked to those involved and asked how they traced the bug back to my change.
- Wrote a blog post detailing my harrowing experience so others could learn as well.
The end result is our changes are now less likely to cause such a regression and future devs who are less aware of the project dependencies do not make the same mistake I did.
Things_learned_from_messing_up++;
Something to be prepared for when accepting any new far away job is the culture shock. While I’m sure it’s more of a thing for people who leave their country, it can still happen when changing states.
One thing that got me about Redmond was the snow. I grew up in Colorado and went to school in New York so I’m a big fan of snow. Sledding, being snowed in, attacking snow goons, the works! But Redmond, sadly, gets about one dusting of snow a year.
Unfortunately, my "shock" didn’t stop there. As it turns out, whenever there’s a hinting of snow, Redmond drivers will throw caution into the wind…
…and replace it with extreme, relentless paranoia. Not only will people drive like their grandmother’s, they will go so far as to pull over and put their blinkers on to wait out what in their eyes must be the storm of the century.
I patiently* drove home today behind a car at 10 MPH, counting the pairs of blinking hazard lights on the running, unhazarded cars that dotted the side of the road. After two and a half years, it’s safe to say I was still culture shocked.
So just be prepared. Culture shock can come out of nowhere, make a slow turn into your lane and never let up on the brakes.
*Read, “patiently”
While on vacation, there were many holiday moments that were highlighted by their streaks of geekdom. Such as my mother going into tears after seeing LOLCATs for the first time or me hooking up a router so my brother could play Xbox live (and now has a way higher Halo 3 rank in the two weeks I was there verses the months I’ve had the game).
But none compares to the Mac incident.
My mother loves to point out how she uses a Mac and not a PC when I’m around. Even though I work in Microsoft Office, I get asked why I didn’t add some feature to Windows Vista that Leopard has (not to mention the temporal difference in release dates).
None the less, it’s quote “easier to use”. So along comes the time when we need to burn a CD. After trying to get the free software that comes with my dad’s PC to work and failing, we decided to try the Mac.
The CD slides into the side of the screen and up pops a message about a blank CD and if we’d like to burn to it. A few clicks later and the CD is burning. “Well I’ll be!” I thought, “that was darn easy”. We leave the room for a while and come back to check if it’s done. “Operation Complete” it exclaims! I couldn’t see their expressions, but I’m sure there was a smug look of “Try that on for size, PC guy.”
Then comes 45 minutes of my parents trying to get the CD to eject from the drive being there’s no eject button on the side of the machine. Look in Finder, no CD drive, can’t find the icon on the desktop. Finally they manage to bring the burning software back up, but the Eject button is disabled. Some internet searches later points to the eject button on the keyboard. A quick press of this button that's been there the whole time and....nothing.
Reboot holding the eject button on the keyboard, reboot holding the mouse down, reboot doing both, do a dance to appease the Mac gods and then hit the eject button. Nothing comes out of the CD drive.
They leave the room, dejected and heartbroken that their so easy to use Mac has let them down.
I peek over and see a freshly burned CD-R laying on the desk next to the side of the Mac right below the vertical slit that is the CD drive. I walk out of the room and present the CD to shocked faces.
“How did you get it out?”
“Magic”
Since starting work, I’ve been exposed to a bunch of different pillars of software requirements. These can include security, performance, localizability, etc.
One big one that is hard to see (no pun intended) is accessibility. How does a blind user use the product? Can a color blind or “high contrast” user use the product? Exposure to this has changed how I view just about any software application, including games.
Many games are playable by those who are deaf using subtitles, and some are playable by those who are color blind. I’m not sure how people who are completely blind play video games, as a lot of work goes into screen readers on an operating system to enable software for the blind, but I don’t think such software exists for PC games or console systems.
Color Blind Issues
For color bind users, there are some interesting engineering puzzles to solve for games that are dependent upon matching colored items.
Take for instance, Zuma:
You must shoot and combine colored balls to win the game. How do you tell which balls to shoot at if they were all colored the same? Above, of the first five balls, which are the same color? (Answer)
Zuma is an interesting example because the balls roll, so even though there's a different texture per color, it's not a perfect fix. Unless all balls rolled in the same phase, two balls of the same color can end up looking significantly different from each other. Plus there’s the “powerup” balls which always have the same symbol no matter what their color (see the “pause” ball above?)
Another example is Mutant Storm Empire where combos are rewarded on shooting all the guys of the same color first:
How would you go about making this game accessible to a color blind user?
“Color Blind” Mode
Some games do have a state for color blind users. For example, Astropop has a symbol mode you can turn on to differentiate the colored blocks.
Boom Boom Rocket can show the button symbol along with the button color:
Future Gaming Accessibility
I have yet to find a game which explicitly had settings for users who require a “high contrast” or “large type” setting to play. Not all games are designed with these users in mind, some companies may not see the user base as a high priority or the game play simply doesn’t work.
Casual games however tend to target a variety of audiences (all of the above are Xbox Live Arcade games) and so we may see future games which try to be playable by a larger audience. My guess is the console will need to lead the way and support these kind of things in the dash before game makers being to implement them as well.
For some reason, every major airport loves to charge "7.99 for 24 hours of access!" which really means "7.99 for the 30 minutes you're going to be here!" (Really, who is willingly in an airport for 24 hours?)
Rochester International Airport, however, has free wifi. Thank you, Rochester. Another plus to coming here to offset the bitter freakin' cold.
Also, the Xbox tournament went great. I however have sadly come to realize that the 30 hours I've spent playing Halo 3 mean jack squat when it comes to playing against college students who have nothing better to do finished their studies and spent their beer time free time playing Halo.
Of course, that didn’t stop me from basking in my amazing fame and celebrity.
Here’s a bug I came across that earns the “phase of the moon prize”. See if you can pick it up:
class Storage
{
public:
Storage() : valx(0), valy(0)
{
}
Storage( int x, int y ) : valx(x), valy(y)
{
fValid = x != 0 && y != 0;
}
FGetValues( int& x, int& y )
{
if( fValid )
{
x = valx;
y = valy;
return true;
}
return false;
}
private:
int valx;
int valy;
bool fValid;
};
See it? Neither did I for a while. Until someone found that everyonce in a while, we’d return 0’s for valx and valy. “That shouldn’t happen!” I thought.
The problem of course, is that fValid isn’t initialized in all the constructors, so if you called that specific constructor and then the phase of the moon is right (aka the memory located where fValid is is still set to 1), you’d get incorrect behavior.
The key to debugging this was finding out where the value fValid came from. I started at the constructors and noted it wasn’t passed in. Then I traced through where it was used to see if it was modified anywhere, the only place being the constructors. Since it can’t be change anywhere else, it's very likely an initialization problem.
In line with this post, writing in a manner that best shows your message in your work environment will help improve your communications with coworkers. Plus you won’t annoy them.
However, more importantly is knowing what’s appropriate to send to a discussion alias and what’s not.
Ignoring obvious “this will get you fired” kinds of emails, there are some key differences between what content is expected on a business alias and what’s expected on a “fun” alias.
For example, I’m on a business alias, and I get an email with the following:
Aw, he’s so cute! And he has nothing to do with what we were talking about. The discussion quickly degenerates into “cake” and why it’s a “lie” and how “pie is better than cake OMG can we add pie to the next version!?”
Freakin’…useless.
Worse than useless is that it distracts from actually getting work done because it dilutes the topic of conversation.
There are aliases meant for posts with cute cats (I’m sure there’s a LOLCATS alias at Microsoft somewhere). Lacking that, there is the great wide Internet full of MySpace and Flickr and icanhascheezeburger where you can look at cute cats doing all sorts of grammatically incorrect shenanigans. But believe me when I say no one will care to see it on their product’s customer alias. It reflects poorly on you, on your judgment and on your team.
If you’re a new hire at large company, be aware of the difference between aliases and avoid the embarrassment (and potential tongue lashing) of sending stuff unrelated to your job.
That Whale of an Email
Everyone has seen at least once where someone at school or at work decided to expand the “All Employees” alias in the To line. Now everyone in the entire company can reply all and say things like “Oh my gosh, not again!” and “There goes the mail server!”
Don’t be one of these guys. I’m guilty of it back in college, you shouldn’t make that mistake, especially at work.
Why? Back to the first sentence: it will annoy people. Not just some people, but EVERYONE who receives the email. “Great, another thing I have to delete from some random person”. Plus everyone now has record of who you are and that you’re annoying. Plus if it ends up causing pain for the mail administrators trying to manage this huge amount of email being sent, you will hear about it later. And not in an “Aw, thanks for stress testing our servers!” way.
Ageless Words of Wisdom
Don’t be annoying.
Kids of Microsoft employees have it quite easy. Not too long ago I had to run from house to house out in the cold only to discover half the time no one was home or it was the old lady who only gave out dimes or it was a “Can’t college students just buy their own candy?” house.
Now the spawns of full time employees get to hop 5 ft from office to office in a heated environment and pick out whichever candies they want from a big bowl. I swear you could come out with your own weight in goodies if you “Pac-Man”-ed it up and down the halls in such a way as to never overlap. Graph theory at its finest hour.