An aspect of teaching I haven't yet consciously appreciated is the ability to hide the extent of your own knowledge. The human mind has a limit to how much new information it can absorb, and if you want to teach effectively you need to plan around that limitation. I don't teach often enough to know what that limit is.
This limiting of information is challenging for me for a few reasons. First, I want to show off. When I know a lot about the subject, I get a kick out of explaining as much of it as I can at once. I need to stop myself so that my informal students have a chance to internalize the material, but often I don't. It's too much fun showing off.
As an example, I know a lot about chess that's worth teaching to other amateurs. I'm chalk-full of opening wisdom, tactic names, endgame basics, ways to dissect a middlegame position and book recommendations. The key for me is to slow down and deliver it in manageable chunks. The four-sentence rule applies here.
Monday, January 9, 2012
Monday, January 2, 2012
Goal setting
I love Amazon. I love my team. You have to push yourself. If you’re hitting more than 70% of your goals for the year, you’ll get scolded for not pushing yourself enough. It’s an interesting rule of thumb and I love how that contributes to challenging ourselves constantly.
How about this: The first year on the job, commit to goals of a certain value. Maybe even hit these 100%, you sandbagger. Next year, commit to delivering double the value. Hopefully now you’re in the 70% zone. For the next year, commit to delivering double that 70% value (140%).
You should hit about 70% of that value (we’re at 1.4 * .7 = 2 * .7 * .7 = .98). .98 / .7 = is a 40% year/year growth in the value you can deliver, which makes sense in your first few years at a company between early ramp-up and increasing ROI from early tool development.
If you’re automating anything repetitive, if you’re constantly soliciting customer feedback, you’ll be working much faster on more of the right things. Since 6/7 of software projects fail and the #1 reason for project failure is building the wrong thing, you won’t be doing 1.4x the work every year but you may still yield 1.4x the value. And if you can do that, nobody cares if your actual effort increases. J
Tags:
career
Drop the T already
Which T? This T:
The title of Software Development Engineer in Test arose when Microsoft saw a need to have more technical staff involved in testing software than the Software Test Engineer (STE) army it maintained. Managers and recruiters lured candidates to these open positions with assurances that, while there might not be as much coding in these roles as an Software Development Engineer (SDE) would have, SDETs really are just SDEs on the Test team. Some teams got the memo and actually used their SDETs as SDEs on the test team. Others changed their STEs' titles to SDET and told them to learn to code. Others simply changed their STEs' titles to SDET.
Microsoft and Amazon maintain that hiring guidelines for technical skills for SDEs and SDETs are identical. There is an entire discipline devoted to software testing (STEs/Quality Assurance Engineers (QAEs)), so SDETs are expected to master that job as well as their own. This is somehow seen as special, even though SDEs should become very familiar with the business domain of the products they product anyway.
In spite of having an identical coding bar on paper, seeing SDETs as second-class developers is still the rule rather than the exception. This is true wherever SDETs are not expected to deliver as much functionality through building software as their SDE peers, which is also the rule rather than the exception. That SDET you hired in part because he could code at the SDE level? He won't be nearly as valuable to your company in three years if you don't support him in his efforts to add value through building software.
Software Testing/QA teams provide specific services for the products they support. Some of those services, (e.g. tooling, automated test suite creation and maintenance, integration testing libraries to export to other teams, load testing) require good software developers. Developing test plans, traversing exploratory testing checklists, designing test passes to maximize ROI, filing and advocating for bugs and communicating a level of risk assessment with a software product are important disciplines, but they don't require the high computer science technical bar that large software companies demand of SDET job candidates.
Expectations for SDETs don't just vary from company to company; they even very within large companies such as Microsoft and Amazon. Everyone knows that SDEs write code and that SDEs at Microsoft/Amazon/Google/Facebook need to be really good at writing code. They don't know what to expect from candidates with SDET experience.
Your smartest, most valuable SDETs are keenly aware of when their technical skills are growing and when they are not. Your smartest, most valuable SDETs are so smart and so valuable not just because they have talent but because they have spent countless hours perfecting their arts of software development, software testing and software project management. Your smartest, most valuable SDETs will fight tooth and nail to protect these investments in themselves and in their careers, and your smartest, most valuable SDETs will not have any trouble finding employment on teams that can promise the growth they desperately need. And even your smartest, most valuable SDETs need this growth, and need it especially, or else your smartest, most valuable SDETs will fail to measure up against either their QAE or SDE peers since they are spending less than half of their time in one of those roles.
Think about how you treat your SDET interns. SDET internship projects are almost always tool development SDE projects. This is both because you want the intern to have a positive experience and because current full-time SDETs are too bogged down in project delivery (test planning, test plan execution, test plan result reporting, regression test failure troubleshooting) to write tools that would help themselves and their peers. I've seen it over an over again: Teams recognize the need for a tool, think of it as an "intern project" and recruit for the summer while they continue to support customer-facing projects. The summer intern is a sharp kid and delivers a working version of a tool that looks great in the demo. Demand for the tool spikes since the team was correct when they identified the need, and the intern's toy becomes a valuable asset to the team. The problem is that while the tool works as a proof-of-concept, the implementation is awful and the tool needs to be refactored or rewritten to address future needs. "Maybe that's a good project for next summer's intern."
At the end of the day you've lost a valuable technical growth opportunity for your best SDETs who are dying to write more code for you as their job, you've tricked an intern into thinking that SDETs really are just SDEs on the test team (which they should be if you're going to title them SDEs in Test) and you've racked up technical debt with a bunch of rookie mistakes embedded into your new business-critical tool. Any gains you make in the space of a full-time hire for next year will evaporate as the former intern realizes that he liked his internship because he was an SDE, not an SDET and seeks employment elsewhere.
Drop the T for your team's sake. Look at each of your directs. Give them a choice. If their expertise has focused mainly on test planning and how to find the highest-severity bugs in the shortest time possible, they will benefit in a prestige-enhanced QAE or STE role. If they can't measure up as SDEs then they need to know now. If you, as a QA manager, run a team that doesn't have enough value to add through building software, you need to know now, and the SDE+QAE bastardization that is the SDET job title only adds chaos and confusion to the mix. You don't need SDETs; you need QAEs and SDEs on the test team.
The title of Software Development Engineer in Test arose when Microsoft saw a need to have more technical staff involved in testing software than the Software Test Engineer (STE) army it maintained. Managers and recruiters lured candidates to these open positions with assurances that, while there might not be as much coding in these roles as an Software Development Engineer (SDE) would have, SDETs really are just SDEs on the Test team. Some teams got the memo and actually used their SDETs as SDEs on the test team. Others changed their STEs' titles to SDET and told them to learn to code. Others simply changed their STEs' titles to SDET.
Microsoft and Amazon maintain that hiring guidelines for technical skills for SDEs and SDETs are identical. There is an entire discipline devoted to software testing (STEs/Quality Assurance Engineers (QAEs)), so SDETs are expected to master that job as well as their own. This is somehow seen as special, even though SDEs should become very familiar with the business domain of the products they product anyway.
In spite of having an identical coding bar on paper, seeing SDETs as second-class developers is still the rule rather than the exception. This is true wherever SDETs are not expected to deliver as much functionality through building software as their SDE peers, which is also the rule rather than the exception. That SDET you hired in part because he could code at the SDE level? He won't be nearly as valuable to your company in three years if you don't support him in his efforts to add value through building software.
Software Testing/QA teams provide specific services for the products they support. Some of those services, (e.g. tooling, automated test suite creation and maintenance, integration testing libraries to export to other teams, load testing) require good software developers. Developing test plans, traversing exploratory testing checklists, designing test passes to maximize ROI, filing and advocating for bugs and communicating a level of risk assessment with a software product are important disciplines, but they don't require the high computer science technical bar that large software companies demand of SDET job candidates.
Expectations for SDETs don't just vary from company to company; they even very within large companies such as Microsoft and Amazon. Everyone knows that SDEs write code and that SDEs at Microsoft/Amazon/Google/Facebook need to be really good at writing code. They don't know what to expect from candidates with SDET experience.
Your smartest, most valuable SDETs are keenly aware of when their technical skills are growing and when they are not. Your smartest, most valuable SDETs are so smart and so valuable not just because they have talent but because they have spent countless hours perfecting their arts of software development, software testing and software project management. Your smartest, most valuable SDETs will fight tooth and nail to protect these investments in themselves and in their careers, and your smartest, most valuable SDETs will not have any trouble finding employment on teams that can promise the growth they desperately need. And even your smartest, most valuable SDETs need this growth, and need it especially, or else your smartest, most valuable SDETs will fail to measure up against either their QAE or SDE peers since they are spending less than half of their time in one of those roles.
Think about how you treat your SDET interns. SDET internship projects are almost always tool development SDE projects. This is both because you want the intern to have a positive experience and because current full-time SDETs are too bogged down in project delivery (test planning, test plan execution, test plan result reporting, regression test failure troubleshooting) to write tools that would help themselves and their peers. I've seen it over an over again: Teams recognize the need for a tool, think of it as an "intern project" and recruit for the summer while they continue to support customer-facing projects. The summer intern is a sharp kid and delivers a working version of a tool that looks great in the demo. Demand for the tool spikes since the team was correct when they identified the need, and the intern's toy becomes a valuable asset to the team. The problem is that while the tool works as a proof-of-concept, the implementation is awful and the tool needs to be refactored or rewritten to address future needs. "Maybe that's a good project for next summer's intern."
At the end of the day you've lost a valuable technical growth opportunity for your best SDETs who are dying to write more code for you as their job, you've tricked an intern into thinking that SDETs really are just SDEs on the test team (which they should be if you're going to title them SDEs in Test) and you've racked up technical debt with a bunch of rookie mistakes embedded into your new business-critical tool. Any gains you make in the space of a full-time hire for next year will evaporate as the former intern realizes that he liked his internship because he was an SDE, not an SDET and seeks employment elsewhere.
Drop the T for your team's sake. Look at each of your directs. Give them a choice. If their expertise has focused mainly on test planning and how to find the highest-severity bugs in the shortest time possible, they will benefit in a prestige-enhanced QAE or STE role. If they can't measure up as SDEs then they need to know now. If you, as a QA manager, run a team that doesn't have enough value to add through building software, you need to know now, and the SDE+QAE bastardization that is the SDET job title only adds chaos and confusion to the mix. You don't need SDETs; you need QAEs and SDEs on the test team.
Happy New Year 2012!
My resolution: Handle injecting nerdy tidbits into conversations differently.
I'll explain: My natural inclination, when adding an obviously nerdy relevant fact to a conversation, is to say it in a really nerdy voice. The voice at that point becomes the focus of attention rather than the fact. So, an experiment! Say the thing that happens to be nerdy, but if I'm not using a normal voice, use a sexy, seductive voice. Something either in the Barry White register or from merry old England.
I'll explain: My natural inclination, when adding an obviously nerdy relevant fact to a conversation, is to say it in a really nerdy voice. The voice at that point becomes the focus of attention rather than the fact. So, an experiment! Say the thing that happens to be nerdy, but if I'm not using a normal voice, use a sexy, seductive voice. Something either in the Barry White register or from merry old England.
Don't trust anyone under 30
While saying my goodbyes at my mom's-side's Christmas party 2011, my Grandma took me aside and said she felt obligated to impart some words of wisdom for life and the new year. She didn't have anything in particular, so she asked if I, perhaps, had some Young People wisdom for her. It's humbling to hear such a request from my mom's mom.
At the tender age of 25, I turned to my grandmother and said, "Young people words of wisdom, eh? Hmm. Okay, got it: Young people don't know anything. Don't listen to them."
At the tender age of 25, I turned to my grandmother and said, "Young people words of wisdom, eh? Hmm. Okay, got it: Young people don't know anything. Don't listen to them."
Tags:
life
Subscribe to:
Posts (Atom)