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.
Monday, August 6, 2012
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 essay, Maker's Schedule, Manager's Schedule.
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 essay, Maker'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
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!
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.
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.
Thursday, December 15, 2011
A Non-Exhaustive List Of Things That Xcode Sucks At
I do a lot of cross platform development, ranging from PC to consoles to Mac/iOS, and as a result I've used a lot of terrible tools before. Some were early in the development cycle of a new platform so they were understandably rough around the edges. Xcode, however, is a whole new level of terrible. Device registration and provisioning is a pain but this is mitigated by not having to do it all that often.
- It crashes. A lot.
- No mixed source/assembly debugging. Having source interspersed with assembly makes it much easier to find your bearings and orient yourself with respect to your code. Mind you mixed listings shouldn't replace either source-only or assembly-only debugging, but should complement them.
- Registers view is at the bottom of the watch window. If I'm in assembly land I don't want to see my symbolic locals, I want to see my registers. Allow me to put my registers front and center!
- Focus moves from debugger command window when "step instruction" commands are issued from outside my own code. I have to re-click on the debugger command window every time I punch in "si". On what planet is this acceptable?
- The debug menu says that control-F7 will step one instruction. Pressing control-F7 on my keyboard (ultra thin USB) does not step one instruction. In fact, it doesn't do anything.
- Hovering over the debug icons say that pressing control and clicking "step into" will step a single instruction. But this isn't a sticky setting, so if I press control and click "step into" twice, the first time will step an instruction and the second will perform a source line step. Mondo fail.
- It would be nice if the callstack window was separate from the thread selection control. This way it's quick to cycle among multiple threads to get an idea of where each one is without having to expand, and contract, multiple drop-downs.
- Tabs with source files would be *super* *handy* for switching back-and-forth between multiple files when debugging. Often I find my self changing (enabling/disabling) breakpoints in separate files regularly as execution progresses and it's a huge pain to have to go back to the folder view to find my file.
The principle of least astonishment is a good guideline for putting together a good user experience, unfortunately whenever I have to use Xcode in anger it consistently astonishes me.
Monday, January 10, 2011
HlslDom: An Overview
HlslDom is a .NET library for programmatic HLSL shader program creation, inspired loosely by Microsoft's CodeDOM.
When using HlslDom you first create a Program, the top level container for all functions, user defined types, and global variables.
Types that are intrinsic to HLSL, like scalars, vectors, and matrices, are managed by a type registry. These intrinsic types, save samplers, are heirarchical in that vectors are considered a number (1..4) of scalars, and matrices are considered a number (1..4) of vectors. These basic types can then be aggregated by the user into a structure, with semantics set for each field.
HlslDom supports most of the intrinsics that are included up to Shader Model 3.0. Intrinsics can be called like any other function and polymorphic versions will correctly validate parameters and determine return parameters.
The concept at the centre of HlslDom is the expression. Expressions are used to represent everything from arithmetic (with BinaryExprs), to variable declaration (DeclExprs), to program flow (IfExpr/ForExpr/TernaryExpr). Expressions may or may not have a value. Those without values are usually syntactic constructs like if/for/while expressions, while those with value are expressions that evaluate to something that can be used, like a call to another function or a struct member access.
Variables at all scopes can be automatically named, or given names. Expressions that may be expensive to evaluate, like calls to functions or large mathematical constructs, can be assigned to local variables with DeclExprs (declaration expressions), and optionally set to "const", to keep the amount of generated code down.
User-created functions are a collection of at least one expression. That one expression that a function has to have, at a minimum, is a ReturnExpr representing a return value. The returning type of the function is automatically inferred based on the types of its contained ReturnExpr.
Once all the desired user defined functions are created, the program can be emitted. Currently HlslDom supports emitting straight up HLSL or emitting a DirectX effect definition.
HlslDom can be found on GitHub (https://github.com/maxburke/HlslDom).
When using HlslDom you first create a Program, the top level container for all functions, user defined types, and global variables.
Types that are intrinsic to HLSL, like scalars, vectors, and matrices, are managed by a type registry. These intrinsic types, save samplers, are heirarchical in that vectors are considered a number (1..4) of scalars, and matrices are considered a number (1..4) of vectors. These basic types can then be aggregated by the user into a structure, with semantics set for each field.
HlslDom supports most of the intrinsics that are included up to Shader Model 3.0. Intrinsics can be called like any other function and polymorphic versions will correctly validate parameters and determine return parameters.
The concept at the centre of HlslDom is the expression. Expressions are used to represent everything from arithmetic (with BinaryExprs), to variable declaration (DeclExprs), to program flow (IfExpr/ForExpr/TernaryExpr). Expressions may or may not have a value. Those without values are usually syntactic constructs like if/for/while expressions, while those with value are expressions that evaluate to something that can be used, like a call to another function or a struct member access.
Variables at all scopes can be automatically named, or given names. Expressions that may be expensive to evaluate, like calls to functions or large mathematical constructs, can be assigned to local variables with DeclExprs (declaration expressions), and optionally set to "const", to keep the amount of generated code down.
User-created functions are a collection of at least one expression. That one expression that a function has to have, at a minimum, is a ReturnExpr representing a return value. The returning type of the function is automatically inferred based on the types of its contained ReturnExpr.
Once all the desired user defined functions are created, the program can be emitted. Currently HlslDom supports emitting straight up HLSL or emitting a DirectX effect definition.
HlslDom can be found on GitHub (https://github.com/maxburke/HlslDom).
Subscribe to:
Posts (Atom)