Monday, August 6, 2012

New job!

I started a new job last month! I'm managing my department's just-formed test engineering group. The group has eight people in both Burnaby and Montreal and we're responsible for developing and maintaining our build farm, performing integration testing, developing/implementing new (for the department) testing processes, and auditing current test coverage. Basically if it's related to testing, and it's something more complicated than running the unit tests, this group will be involved.

I'm really excited about the opportunities that are on the horizon. I started at EA over 10 years ago as a game tester and started as a developer in this group's long dead predecessor doing clear box software testing, so it's in a way like coming home. Since it's removed from the secret squirrel work that I was working on before I will also be a lot more free to talk about what I'm doing.

The first couple weeks on the job were spent getting to know the people, getting to know the work, and setting up a plan where I want the group to go over the next 12 months. As the people on the team aren't new, just repurposed from other groups, most of the work they do in the short term isn't going to change. Longer term the goal is to have detach from their old teams so that they can focus more on the work our department does as a whole.

I'm not going to give up coding quite yet. I've currently got my sights set on our build farm and its reporting infrastructure. It's been cobbled together out of a number of shell/build scripts and it's creaking. One of the more recent additions to the group, Dave, is tackling both this and the database back end to make the system more reliable and easier to report on.

I hate SharePoint.

The web dashboard is built on SharePoint. I suppose there's some sort of redeeming quality I haven't yet seen because apparently a lot of people pay a lot of money for the product but deep down I sincerely doubt it. Anyways, the rationale of our build web dashboard using SharePoint is that there is a need to keep some platforms hidden from the world while they are covered by NDAs -- but the rest of the baggage SharePoint has brought means it takes 20 seconds to retrieve the "current status" web page. If you want to filter this information -- which is pretty common for most people as our group supports 150+ libraries built in 40+ configurations, making a status table pretty useless to get your desired information -- it hits the server again, which means waiting another 20 seconds.

I despise SharePoint.

I've started the process of removing Sharepoint completely and instead use some simple scripts to pull the information from the database and authenticate it via LDAP. I moved the rendering client-side, using jQuery and Bootstrap for a little style. Page load is now down to ~2 seconds with most of it being spent in database queries, and that should remedy itself when Dave's finished his schema rework.

The site is much easier to work on now. Deploying the new pages is handled by syncing them from Perforce. Since all the UI code is in Javascript most of it can be tweaked locally on the desktop without having to setup a local server. Or find the one machine that we have a SharePoint developer environment installed on and without colliding with someone else who also needs to use it, and then package+deploy your changes to the production servers hoping that the servers don't barf on your changes leading you to get a nastygram from IT.

Have I mentioned that I hate SharePoint?

I hope to finish the web page updates this week. Once that's done I have to work on a metrics solution for our console unit tests and dig back into valgrind.

Friday, June 29, 2012

The One-on-One

Any developer worth hiring will tell you that the best meeting is the meeting that doesn't happen. Some will even be so kind as to tell you that at the beginning of every meeting they're invited to!

The one meeting that I always get value from, however, is the one-on-one. Whether or not I'm having the meeting with my manager or someone on my team I'll always come away with something that made the time invested worth while..

The one-on-one is a meeting where there may be venting, there may be difficult conversations, there may be awkward silence, but the manager's job isn't to be defensive or aggressive, it's to play the part of a good listener. If there is a slip up then the trust will be damaged, if not broken entirely, and will take a long time to repair. This isn't the trust that's related to integrity, such as failing to meet a promised deadline, but the "I won't tell you that I'm unhappy with what's going on and I'm looking for new jobs on Monster.com when you're not around" kind.

Although work status will frequently come up during the one-on-one I make it a point to never explicitly put it on the agenda. I want the meeting to be about the status of Fred, not the status of  Fred's work, which means the first question I always lead with is "How are you doing?". I'll also ask some variant of "what's getting in your way and what's on your mind?", which has a subtle, but key, distinction from being work status related as this could lead beyond a discussion of the issue that he's blocked on and into one about how he'd really like to get two days off to help his girlfriend move but he's not sure about taking it because of the amount of work that's piling up. Their response to that question leads quite naturally into "what can I do to help you?"

I've never encountered a programmer that has said "I really like that this meeting was booked in the middle of the afternoon, I really didn't need to be concentrating on finding that one rare concurrency bug." I could be wrong.


The team is being paid to do good work, and I'm being paid to shelter them from BS, so in order to shelter them from BS and allow them to do good work I try to keep meetings to a minimum and preferably at the periphery of the day. Putting a meeting in the middle of the day kills what your team members are working on, causing them to take a while to get back up to speed once it has concluded. I try to put my one-on-ones at the beginning or end of a solid work block, such as the beginning of their (not your!) day, and either before or after lunch, typically avoiding the end of the day because the end of the day can vary with whatever is going on. A good read on this topic is Paul Graham's essayMaker's Schedule, Manager's Schedule.



Wednesday, June 6, 2012

Co-routines in C(++)

A little while ago I put together a small co-routine library in C targeting x86/Windows. It uses micro-stacks of about 4kb, minus a small tax for library overhead, for each co-routine which places some constraints on the work that can be done but I figured that it'd complement Windows' fairly heavyweight fiber library.

The code sets up a new thread context, by setting esp to point to the new co-routine stack, and then uses setjmp and longjmp to yield the co-routine to the main execution context and to resume the co-routine from where it left off.

One known issue is that if you build C++ code with Visual C++'s /EH command line options the compiler will automatically run destructors on stack objects as it unwinds past them, and so any objects you create in your co-routines will be destroyed prematurely. Building without exceptions enabled will work around this.

Code: https://github.com/maxburke/coroutine

Management 102: Post shake-up stability

My last post mentioned a few points to keep in mind now that you're a fresh manager. In this one I'm going to go into the first tasks you need to accomplish in first day after the reorganization has been announced. The reorganization doesn't have to be a full company shake up, it could be something just as simple as two people shuffling around.

Hopefully you've had some advance notice that this was coming, giving you some time to plan things out, knowing who will be reporting to you, and possibly what you'll be working on. (Digression: I dislike the term "report" in the management-hierarchy-sense. I guess it comes out of industries where there's a more rigid command-and-control type of infrastructure. Like the military. But the people in your group aren't soldiers; no, you're paying them good money so that they can flex that brain of theirs, not just follow orders. The company's paying you to be their BS shield.)

Re-orgs are kept on the down-low to keep the hand wringing to a minimum, but see if you can suss out who else is in the know, and if they are currently managing some of your new group. Same goes with the new projects you'll be overseeing. The goal here is that once day one arrives you'll look like you have some clue as to what's going on and who these people are. You'll want to sort out a transition plan for your current responsibilities so that you don't appear to have bolted on your old job.

If you've got some time to kill before the big day you might want to start planning your schedule, where you'll fit in your new one-on-one meetings. Getting your one-on-one's setup is a great first step as this is where you put your finger on the pulse of the team; far beyond a face-to-face status report it's where you find out what's on their mind, what troubles may be lurking below the surface. I believe that the one-on-one is so important that I'll go into it in detail in my next entry.

It's a good idea to also have some plan of what you want them to do in the short term, until you can really start digging into the new problem space, even if the plan is to keep on keepin' on. Don't let them twist in the wind.

Once the one-on-ones have been sorted out and you've met them, it's probably a good time to get the team together for a lunch, to get away from the work and get to know each other a bit.

As the day winds down you should start seeing some semblance of routine; maybe you'll have your first official meetings with the team. Your old job should be fading from view, as you'll have plenty to do with your new team and you don't want to give them the impression that they're not the most important part of your work life.

In the end you want to make sure that there's no large clouds of uncertainty hanging over your team's heads. Don't sweat it, you're going to do great!

Sunday, May 27, 2012

Management 101

You're a lead programmer and have been for a number of months, or years, and one day your manager taps you on the shoulder and says that there's going to be a change.

You're going to be a manager!

Congratulations!

Welcome to management!

Your work life will never be the same! Well, that's a bit of an exaggeration but things will be quite different. You've had a taste of leadership and mentorship leading up to now (right? ...right?!), so the difference won't be so stark.

I'm not going to talk about management styles so much as point out a few things that may not be obvious for programmers who are new to managing people instead of software.

Obvious-yet-not-obvious point #1: Managers are information conduits.

Your primary goal is to get all the information to your team that it needs in a timely manner. You need to beat the rumor mill; every time they look elsewhere for information, their faith in you degrades a tiny bit. Think about when you go to your manager most often -- it's not to ask about your raise (well, maybe it is...), but it's to know what's going on, who needs what by when, what's coming down the pipe next month, or who should be taking care of that urgent support issue that just fell out of the sky.

Obvious-yet-not-obvious point #2: Nothing should be a(n unpleasant) surprise when it doesn't have to be.

Pleasant surprises are great. "Beer this Friday? Company's paying? Sweet!"

Unpleasant surprises aren't. Some are occasionally unavoidable -- the company often can't give advance warning about layoffs because that will wreak unnecessary havoc on morale and the share price -- but many aren't. If you're about to give someone a below target performance evaluation it should not be a shock to them. The lead up to this should have included several, possibly difficult, conversations about where things are heading and the consequences if the trend continues. Not only that but a case like that should have a plan for remediation.

Obvious-yet-not-obvious point #3: You are responsible for the growth of your people.

One of the big differences of being in a management role compared to being in a mentorship-focused lead role is that when one of your employees didn't get a promotion for which they had been hoping, you are now the first person they will ask why. And you better have good answers for them.

Every quarter I sit down with each member of the team and we put together a list of accomplishments that we want to achieve over the following three months. This list of objectives is broken down into what's expected (on target) and what goes above and beyond expected (above target/significantly above target). At the end of the quarter we go over everything that's been accomplished, and at the end of the review period it's obvious to all parties if there's been continuous, steady improvement.

Although the onus to execute lies with them, you need to coach them, guide them, find opportunities for them and help them find their way out of ruts.

Obvious-yet-not-obvious point #4: Trust is difficult to form but easy to break.

One item to keep in mind is that topics that come up in a 1-on-1 meeting should be considered confidential. If you ask your star why he seems distracted and not his usual affable self and he mentions that he's dealing with some unpleasant family issues, you'll want to keep those discussion notes private. "Jim's not on his A-game because his Mom died" is not an appropriate point to mention at the team stand-up meeting. It's also not appropriate to mention if anyone else asks why Jim seems to not be his usual self.

During that conversation, a lot of faith and trust was placed in you when that news was broken, it may have taken them a long time to work up to telling someone at work about it, and if you violate that trust you may never see it again. This may mean that you'll never be the recipient of other personal thoughts, like "I'm unhappy with my job and want to do something else, probably somewhere else."

Obvious-yet-not-obvious point #5: You'll have less time to do programming at work, but that's OK.

Much of your schedule is going to disappear to meetings, to the overhead of task scheduling, to problem solving, and back to meetings. At first I felt that I was failing because I was doing less programming work but this wasn't the case -- it just took a while to recognize that all the other tasks filling my schedule had value too.

Obvious-yet-not-obvious point #6: People aren't machines, they don't have instruction manuals.

You can't attach a debugger to one of your employees to find out what's wrong, nor can you write an automated test to prevent problems from coming up. Forming a network with your current and former managers is extremely helpful when it comes to fielding these new problems that you will run into. Failing that, you can always ask HR, they are going to become surprisingly helpful in your new role.

I hope that I didn't scare you -- you're going to do fine. Really. Some adjustment will be needed but it'll all smooth out soon enough. In my next post I'm going to talk about establishing stability after this minor organization shake-up.