J.D. Meier's Blog

Software Engineering, Project Management, and Effectiveness

March, 2007

  • J.D. Meier's Blog

    New Prescriptive Guidance for Visual Studio Team System

    • 20 Comments

    Our patterns and practices team has just released new prescriptive guidance for Visual Studio Team System!

    Since my previous post we've made significant updates with the addition of the following content:

    This puts us on course to deliver on these main outcomes we have in mind for our Visual Studio Team System Guidance Project

    • The single best repository of Visual Studio Team System guidance
    • Practical and insightful scenario-based guidance for roles (PMs, developers, architects, testers ... etc.)
    • Thoroughly engineered and tested set of recommendations
    • Great entry point through videos, roadmaps, and task-based How Tos
    • Breadth and depth coverage

    Project Overview
    While Visual Studio Team System provides powerful new tools, customers are asking "where's the guidance?" ... "where do I start?" ... "how do I make the most of the tools?"  In response, our team is building a definitive Body of Guidance (BOG) for Team System. This includes How Tos, Guidelines, Practices, Q&A, video-based guidance, and more.

    We’re helping customers walk before they run, so we’re starting with the foundation.  On the code side (for developers) – this includes source control, building your dev and test environments and setting up a build process.  On the project side (for PMs) – this includes work items and reporting.  Once we have the foundation in place, we can move up the stack to making the most out of Team System for the various roles (tester, architect, developer … etc.)
     
    We're framing out the tough problems using Scenario Frames (for an example see Source Control Scenario Frame).  We then identify where we need guidance and perform solution engineering.  This involves building out reproducible customer scenarios, vetting potential solutions, and sharing the ones we can generalize enough to be broadly useful, yet still specific enough to be actionable.
     
    We're partnering with customers, product teams, support, field, MVPs, and subject matter experts.  We’re working closely with Jeff Beehler to synchronize efforts with the VSTS Rangers, such as the Branching Guidance.

    Related Posts

  • J.D. Meier's Blog

    The Secret of Time Management

    • 14 Comments

    The secret to time management isn't more time management hacks at all.  Here's the keys I've found:

    • Manage energy not time.
    • Make room for your big rocks.
    • Use anticipation to drive versus react.

    I often here the argument, "if I had more time for this or that, I could ..."  Well, unfortunately, having more time doesn't always mean getting more done.  It doesn't guarantee getting the right things done either.  Sometimes I get more done in an hour than I can sometimes get done in a week.  Why is that?  For me, it's actually about energy.  There's only so many hours in a day.  While I can't make more hours in a day, I can use my energy better.  Sure there's lots of interesting little time savers, but there's plenty of time wasters too.  I find the force that makes the most measurable difference is the energy and engagement I bring to the table.

    Assuming I have all my energy ready to tackle my day, I need to distinguish between urgent and important.  If I'm only reacting to urgent, then I'm missing out on opportunity to deal with important, whether that's job impact or personal growth.  The moral of the story is, if I don't make time for the big rocks, the fillers in my day won't leave room.  I like Steven Covey's perspective on urgent vs. important in his First Thing's First book.  Here's a nice summary of the popular Make Room for the Big Rocks story.

    Anticipation is a actually a skill that I haven't worked on as much as I should.  I actually plan to do a 30 Day Improvement Sprint, when the time is right.  It's funny how many recurring things happen each year, that take me by surprise.  Birthdays.  Holidays.  Reviews.  Events.  Geeze!  You'd think I'd see the patterns ;)

    Well, I do.  I've seen the pattern of me reacting to events I don't anticipate.  While the corporate ninja expects the unexpected, I also find that with a little anticipation, a stitch in time saves nine.  If I make project plans, and there's a major event I didn't account for, I shouldn't be surprised when suddenly nobody's around.  At the same time, I'm sure I can find a way to leverage the sudden spurt of energy some folks have right after mid-year discussion.

  • J.D. Meier's Blog

    Structuring Projects for Team Foundation Server

    • 14 Comments

    I've seen a few customers asking how to structure projects for Team Foundation Server.  I don't blame them.  Finding a structure that works well for you can be tricky, particularly if you don't have the benefit of hind-sight or a bunch of reference examples to draw from.

    My team spent some time this past week evaluating various approaches and lessons learned from various projects  We boiled it down to something that seems to be working well, and distills what's worked for some teams.  With the caveat that we're still evaluating, here's what we learned ...

    Solution
    Local File System

    C:\MyApp
    	\MyApp.sln
    	\Source
    		\MyAppWeb
    		\ClassLibrary1
    


    Source Control (Team Foundation Server)

    /Main
    	/Build
    	/Docs
    	/Source
    		/MyApp
    			MyApp.sln
    			/Source
    				/MyAppWeb
    				/ClassLibrary1
    			/UnitTests
    				/MyAppWebTests
    				/ClassLibrary1Tests
    	/Tests
    


    Key points
    Here's a few highlights about this approach:

    • On the client side, we explicitly creat our solution file up front instead of rely on defaults
    • The project folder containts one master solution. 
    • The project has source and unit tests.  Loading the solution for the project, loads the source and unit tests
    • The Main folder in TFS holds the project assets (Build, Docs, Source, Tests).  Using Main lets us create other folders for potential branches (Development, Production, Maintenance ... etc.)

    Repro Steps
    Here's a brief walkthrough to test using a file-based Web:

    1. Create a blank solution in VSTS
    2. Create a source folder on the file system (C:\MyApp\Source)
    3. Add new Web project (C:\MyApp\Source\MyAppWeb)
    4. Add new Class Library (C:\MyApp\Source\ClassLibrary1)


    Verify your folder structure on your File System:

    C:\MyApp
    	\MyApp.sln
    	\Source
    		\MyAppWeb
    		\ClassLibrary1
    


    Adding to TFS

    1. Add your solution to source control
    2. Create a Main folder
    3. Create a Source folder beneath Main

    Verify your folder structure in Source Control Explorer

    /Main
    	/Source
    		/MyApp
    			/MyApp.sln
    			/Source
    				/MyAppWeb
    				/ClassLibrary1
    

    More Information
    You should know that while I talked through the single solution scenario, there are additional patterns.  Here's the key patterns we see:

    1. Single solution
    2. Partitioned single solution
    3. Multi-solution

    You can find more on these patterns at Team Development with Visual Studio .NET and Visual SourceSafe.  You should also know that we have a few How Tos on structuring your projects coming your way.  We'll post them to our VSTS Guidance Project.

    Share Your Story
    If you've got lessons learned the hard way or practices to share, I'd like to hear them.   Now's a great time to share since we're actively building guidance.  Either comment here or write a post and leave a link. 

  • J.D. Meier's Blog

    30 Day Improvement Sprints

    • 12 Comments

    I'm using 30 day improvement sprints as a way to sharpen my skills.  I pick a focus to work on and I committ to improving it for a 30 day timebox.  Committing to 30 days of improvement in a focused area, is easier to swallow than changing for life.  However, improving an area for 30 days, is actually life changing.

    With 30 days, persistence and time are on my side.  It's a big enough time box that I can try different techniques, while building proficiency.  Using 30 days makes working through hurdles easier too.  A lot of the hurldles I hit in my first week, are gone by week 2.  Little improvements each day, add up quickly.  I look back on how many things I tried for a week and stopped thinking I hadn't made progress.  The trick was, I didn't get to week 2 to see my results.  Lesson learned!

    Related Posts

  • J.D. Meier's Blog

    New Video: How To - Personalize Team System Guidance with Guidance Explorer

    • 10 Comments

    If you are a hunter and gatherer of guidance, you'll want Guidance Explorer.  Watch Video: How To - Personalize Team System Guidance with Guidance Explorer to see how you can use Guidance Explorer to build a custom collection of guidance from our Visual Studio Team System Guidance project.  If you haven't used Guidance Explorer before, or it's been a while, you're in for a surprise.  Seriously.

    Guidance Explorer is a free tool to help you browse, find, organize, or even create your own guidance. When you launch Guidance Explorer, it synchronizes with our online store.  For example, today's additions include a number of brand new Team System guidance items:

    My favorite Guidance Explorer features include:

    • Create collections of your favorite guidance (custom views)
    • Browse by checklists, code examples, how tos, guidelines (view by type)
    • Filter for just security, performance or Team System (Filter by technology, topic or category)
    • Share guidance among your teams (UNC share scenario)
    • Build a customized guide or whitepaper on the fly with exactly the parts you want (Save to Word, HTML or XML)
    • Create new guidance libraries and write your own personal guidance or checklists.

    Keep in mind that Guidance Explorer is actually a diamond in the rough.  It has its flaws, but it also has unique powers.  For example, I could use Guidance Explorer to inform you of brand new, emerging security practices.  I could also flag the top performance issues using the priority field.  Imagine the alternative of hunting through a whitepaper or article, instead of organized collections and lists of actionable, guidance nuggets.

    I know consultants that literally save themselves many hours per week by using Guidance Explorer as a personal knowledge base and for tailoring guidance for customers.  I also know of customers using Guidance Explorer as a light-weight and effective way to share guidance among their development teams.  It's actually the type of tool where customers surprise me what they use it for.

    While Guidance Explorer has nearly 1100 guidance nuggets at last count (across security, performance and .NET 1.1. and 2.0), you can quickly shrink the haystacks to find the needle that you need (Ed and I call this our Shrinking Haystack pattern).  You can also discover relationships among the guidance, because related items are linked.  Don't take my word for it though, test drive it for yourself.  Did I mention it's free?  Oh yeah, I should also mention it comes with source, so shape it to your heart's content.

    Go ahead and watch Video: How To - Personalize Team System Guidance with Guidance Explorer and then download Guidance Explorer.  If you do use Guidance Explorer and you have a story you'd like to share, please leave a comment in this post. 

  • J.D. Meier's Blog

    patterns & practices Security Videos

    • 8 Comments

    We did a focused set of security videos with Keith Brown a while back.  The problem is they're not very findable (most customers I talk to aren't aware of them).  I added them to soapbox and listed them below to see if it helps (note soapbox may prompt you to log in):

    Input and Data Validation Videos

    They're designed to help you get key concepts behind some of our security guidance.   I also wanted to use somebody that was recognized in the field as somebody you could trust.  Keith's proven himself for a long time in the security community.  He also has the aura of an experienced trainer, which I think comes across in these videos.

  • J.D. Meier's Blog

    Making 30 Day Improvement Sprints More Effective

    • 7 Comments

    In my 30 Day Improvement Sprints post, a reader asked, what tips do I have to make 30 days sprints more effective.  Here's my short list

    • Buddy up.  Seriously.  One guy's hurdle, is another girl's breeze.
    • Don't beat yourself up.  If at first you don't succeed, tell yourself you just learned another way how NOT to do something.
    • Count your improvements, not your blunders.  It's a pick you up vs. put you down approach.
    • Make each session count.  Keep your sessions short and sweet.   Slow and steady wins the race.
    • Focus on your improvement process vs. the result itself.  Make the process your reward.  I enjoy learning again for learning's sake.       
    • If you're churning, change your approach.  Don't mistake churn for awkwardness. Growth feels awkward and is a precursor to proficiency. 
    • Find experts you can model and learn from.  Success leaves clues.  If you can find somebody who does a great job at what you want to do, you have a head start.  I leverage lots of mentors.  I used to just see an amazing pool of people around me.  Now I see an amazing team of coaches.
    • Journal your lessons learned.  Each day, reflect on distinctions you made.  What's one little thing you learned you didn't know the day before.  You'll be surprised how simple notes can shine a spotlight on your gains.
    • Repetition is your friend.  Remind yourself that repetition is the mother of skill.  World class experts master the fundamentals through repetition and refinement.
    • Set your own bar vs. follow others.  Don't compare yourself to others; compare yourself to you.  Be your personal best.  I remember a point John Wooden made some time ago.  He didn't think his team should gloat over wins, or beat themselves up over losses.  His point was, if you won, but didn't play your best, did you really deserve to win? ...  If you lost, but you played your personal best, did you really lose?
    • Focus on the thinking, feeling and doing.  Sometimes the inner dialogue is more important than what you see or hear.  While something might seem purely physical, sometimes, there's a lot of self-talk an expert does that might not be obvious.  What do they think about when they perform the technique?  When they mess up, how do they get back in the zone?  What's their decision tree?  For example, when I do a customer arch and design review, they see me put stuff on a whiteboard.  They hear me ask precise questions.  What they might not know is the matrix of questions and reference examples I draw from.
    • Be your own best coach.  Use questions to shape your improvement.    
    • Ask for feedback.  Find those you trust to point out things you might otherwise miss.  

    Few problems withstand sustained focus.  There's a bit of captive genius in everyone that just needs to be uncorked.  30 days of focused improvement seems to be a great way to pop the cork.  I'm finding improvement sprints refreshing because I now have a schedule for exploration.  I can rotate through more interests.  Most importantly, rather than tackle everything all at once, I just wait for my next 30 day focus.  It's easier to put something aside for the moment, if I know I'll have a chance to immerse myself in it in the future.  If I enjoyed something so much and I want to continue, I just do another 30 days.

    Hope that helps!

    Related Posts

  • J.D. Meier's Blog

    MUST vs. SHOULD vs. COULD

    • 6 Comments

    Whether I'm dealing with software requirements, or I'm prioritizing my personal TO Dos, I think in terms of MUST, SHOULD, COULD.  It's simpple but effective.

    Here's an example of some scenarios and usage:

    • getting a quick handle on my day - what MUST I do today?  what SHOULD I do?  What COULD I do?
    • prioritizing my personal backlog - what MUST I do today?  what MUST I do this week?  What should I do? What could I do?
    • focusing my teams - what MUST we release this week?  What SHOULD we release this week?  what COULD we release this week?
    • brainstorming sessions - what COULD we do?  What SHOULD we do? what MUST we do?
    • determining an incremental release - what are the MUSTs for this software release?  What are the SHOULDs?  What are the COULDs?
    • helping a customer identify their security objectives - What security constraints MUST be met for this software?
    • helping a customer identify their performance objectives - what performance constraints MUST be met for this software?

    It's easy to get lost among SHOULDs and COULDs.  I find factoring MUSTs from the SHOULDs and COULDs helps get clarity around immediate action.

  • J.D. Meier's Blog

    Performance vs. Load vs. Stress Testing

    • 5 Comments

    This conversation (er, debate) comes up a lot.  What's the difference between performance, load and stress testing?  I'm sure there's tons of *official* definitions.  At the end of the day, I think about them like this:

    • Performance - is about response, time lapses, duration ... etc.
    • Load testing - is about test behavior under normal/peak workload conditions.  Load is more about characterizing / simulating your actual workload.
    • Stress testing - is about surfacing issues under extreme conditions and resource failures.

    I could say more, but sometimes less is better.  If you want to read more, check out our patterns & practices Performance Testing Guidance Project on CodePle  or browse through Scott Barber's exhaustive collection of performance testing articles.

  • J.D. Meier's Blog

    Video-Based Guidance for Visual Studio Team System Now Available

    • 5 Comments

    As part of our Video-Based Guidance Experiment, we've released an initial set of  VSTS Guidance Videos.

    Source Control Videos

    Test drive our videos and help shape our experiment by either leaving your comments here or sending your feedback to vsguide@microsoft.com

    Enjoy!

  • J.D. Meier's Blog

    Code Sharing in Team Foundation Server

    • 4 Comments

    How do you share code in Team Foundation Server?  That's what our team is working through at the moment.  We're looking at what's working, what's not working, and what should customers be doing.

    Here's how we're basically thinking about it so far:

    • There's two main code sharing paths: source and binary.
    • Within source code sharing, there's two approaches:  workspace mapping on the client and branching on the server.
    • The key issues are how to deal with parallel development and how to share across projects

    Here's what seems to be our emerging guidance:

    • If you're coding in parallel, and you need real-time updates, start with workspace mapping.
    • If you need periodic snapshots, or if you need isolation from the changes, then consider a branching approach.
    • If the source you need to reference is relatively stable, then consider using the binary.

    The problem with workspace mappings is that they're developer specific.  Each developer will need their own mapping.  You'll also need to lock down permissions to avoid accidental changes.  Branching has the advantage that you can be explicit about taking changes, so you have stable builds but with the overhead of merging.  You can branch within the same project or cross-project.  A separate project might make sense if you have multiple projects consuming the code.

    I need to still look across more customer sets, but so far I mostly see binary reuse.

    I'm particularly curious in any lessons or insights those of you would like to share.  I think this is an important area for effective source control practices.

  • J.D. Meier's Blog

    30 Days of Living Foods Ends Today

    • 4 Comments

    Today ends my 30 day experiment eating living foods.  I'm a burger and pizza boy at heart, so this was a big change.  Friends and family noticed my slimmer look and healthy glow.  A friend of mine said I found the Fountain of Youth.

    Here's what I noticed:

    • dropped 12 pounds
    • had enough energy to start working out again
    • shed my skin
    • eliminated sinus issues I had for a life time
    • stayed healthy while others got sick
    • maintained peak performance throughout my days
    • got the eye of the tiger back

    I didn't expect to shed my skin so that surprised me, but I liked what was underneath.  I was also surprised by how some issues were dietary vs. natural.  Nature vs. nurture strikes again! 

    Friends asked me what practices I'll carry forward:

    • more water over soda
    • balance my bad foods with more good foods (I'll eat my veggies - Mom will be proud)
    • raw vegetables over cooked
    • stick with my workouts (again to balance my bad foods)
    • more frequent meals

    Most importantly, I learned how to effectively do living foods for 30 days.  This means, I can choose to do 30 day tune ups throughout the year.  What I walk away with is a better idea of how foods affect me, how to balance my bad foods with good, and how to tune my body when I get run down (or need to fend the flu season).

    We're such thinking, feeling, doing creatures at heart and food has such a big impact on the way we think and feel.  I'm going to explore more options.  A friend of mine suggested testing intuitive eating, where you eat what your body craves, not what you mind thinks it wants.

  • J.D. Meier's Blog

    Guidance 2.0

    • 3 Comments

    Imagine what a Guidance 2.0 world might be like ...

    • browse tag clouds of reusable "architecture nuggets"
    • subscribe to "guidance feeds" that give you the latest practices and recommendations
    • share your "guidance" playlists with friends (share your favorite collections of how tos, guidelines, checklists)
    • build guidance mashups from your favorite trusted sources of information
    • rate the guidance and rate the raters (think Amazon or EBay)
    • browse a federation of guidance Wikis in your company and in the community

    I think next-gen guidance is about bringing together a lot of key concepts:

    • context-precision (using context to organize information)
    • personalization (create your own views, tailor it for your needs, ... etc.)
    • community type ratings (expose the thinking and rate the raters for the guidance)
    • guidance types (evolvable schemas for guidance types, such as how tos, guidelines, checklists, patterns ...)
    • Folksonomy over taxonomy

    A lot of today's guidance lives in blogs.  Part of the problem (and beauty) of blogs is that every end node is a blob of information.  What if there were RSS end nodes that contained "collections" or "lists" of how tos, guidelines, patterns ... etc.?  From a very practical standpoint, I would love to subscribe to the latest MS (or any company) recommendations and view those in a type of my choice (patterns, guidelines, how tos ... etc.)  The mashupability is endless.

    Those are the ideas that drove and shaped Guidance Explorer.  Guidance Explorer was just one small step towards a world of more effective and efficient guidance.

  • J.D. Meier's Blog

    Requirements Perspectives

    • 3 Comments

    Here's a simple set of perspectives I use for rationalizing requirements:

    • User
    • Business
    • Expert / Technical
    • Industry/Standards

    Believe it or not, simply identifying these perspective helps a lot.  You'd be surprised how many debates happen simply because nobody explicitly identified the source or perspective of the requirement.  You'd also be surprised how quickly this helps you make more deliberate decisions and understand what you trade. 

    How does this help?  Your business goals might be a n orders per hour.  Meanwhile, your user wants sub-second response time.  Well, that's what your users want, but what will they tolerate?  Can your business afford the resources for an idealistic experience?  Design is always about trade-offs.

    In practice, I generally see industry/standards trump business trump expert/technical, trump user.  Unfortunately, a lot of software has unconsciously catered to the expert/tech/business at the expense of it's users -- making a lousy experience.  On the flip side, some software has catered to users at the expense of the business or industry goals.   See the dilema? 

    You can make a difference.  If you build software, know the perspectives, know the goals, and know the scenarios.  In some contexts, some tech/expert reccomendations simply do not make sense.  Know what you're optimizing.  In some scenarios, industry/standards reign, while in others user experience is king.  Make sure you have the right representation at the table.  Don't ask your patient to prescribe the medicine, or your doctor to rate the taste.

  • J.D. Meier's Blog

    Driver's Guide vs. Owner's Manual

    • 3 Comments

    One of the metaphors I use to explain the distinction between documentation and guidance is Driver's guide vs. Owner's Manual.  While I could go into the finer details, it's a good starting point.  From an owner's manual, I expect to see how things work and how they're intended to be used.  From a driver's guide, I expect "how to get the most out of it."

    I see the two bodies of information as very complimentary.  I also see them as distinct.  I wouldn't want to mix my driver's guide with my owner's manual.  However, I do want to be able to seamlessly go from one to the other, when I need to.  I also want my owner's manual written by the people that built it and I want my driver's guide written by the people who use it in action.

    In practice, I use my owner's manual when I care and tune my RV.  When I take a cross country trip, I use my driver's guide.  Knowing this distinction helps me choose the right tool (information set) for the job, as well as set my expectations about the type of information I'll find.

    I think finding the right metaphors is important because it helps illustrate a distinction that's not always obvious or hard to explain.  I don't think guidance is yet a pervasive part of our technical landscape, and yet I see it as a key differentiator between success and failure.  By pervasive, I mean I can use any product or technology and easily find the driver's guide.  I mostly see owner's manuals.  

  • J.D. Meier's Blog

    Team Foundation Server Branching Guidance Now Available

    • 3 Comments

    The Team Foundation Server Branching Guidance whitepaper is now available!  It's a comprehensive whitepaper that covers strategies, patterns and anti-patterns for branching and merging with TFS.  You can view the branching guidance online or you can download the PDF version.

    Branching Guidance Index

    • Introduction
    • Parallel Development
    • Branching Defined
    • Creating Isolation in Team Foundation Server
    • General Branching Structure Guidance
    • Branching Strategies
    • Broad Areas of Branching Isolation
    • Creating Your Branching Strategy
    • Defining Your Code Promotion Model
    • Feature Crews: How Microsoft Does It
    • End-to-End Implementation Scenario
    • Appendix

    My team works closely with Graham and Mario of the Branching Guidance team as we build out our patterns & practices VSTS Guidance Project.  We're sharing learnings and synchronizing recommendations as we go along.   We'll be adding more cross-references to the Branching Guidance Project and VSTS product documentation on MSDN from our guidance so you can easily hop for more information. 

  • J.D. Meier's Blog

    Why 30 Day Improvement Sprints

    • 3 Comments

    Why 30 Day Improvement Sprints?  I get asked this often enough that I think I should distll the keys:

    • I can commit to something for 30 days.  Starting something without an end in sight, can be daunting.
    • It helps me deal with the now.
    • It's a timebox to deliver value to myself.
    • If I only do something ad-hoc now and then, I don't create an effective technique.  If I do a little each day, I find a way to reduce the friction.
    • It lets me parking lot things I want to work on.  I can put something on the backburner if I know I have a way to pick it back up.
    • It gives me a system to build a portfolio of improvements instead of cling to one-hit wonders here and there.
    • If it's daily, it becomes a habbit.  If it's something I do a few days a week or only for a week, I don't build a routine.
    • It's a long enough duration to see improvement or change approach.  I wonder how many things I tried in the past for a week, then stopped because I didn't see improvement?  If I'm not getting results, I have enough buffer to change my approaches or strategies.  Put it another way, 30 days gives me enough buffer to mess up.
    • It's easier to buy into incremental, daily improvement versus big up front improvement or change.
    • I'm a sprinter by nature.  While I've learned to pace by nurture, I prefer to put my all and do bursts.  It's when my energy is peak.

    Because my 30 Day Improvement Sprints are so effective for me, I have to resist the urge to bite off too many areas at once.  In general, I try to balance between mind, body, career, financial, and relationships.  My scannable outcome lists help me checkpoint.  As a pattern, I do tend to focus heavily on career, but now that I see it, I can change it, if it makes sense.

    Related Posts

  • J.D. Meier's Blog

    Video-Based Guidance Experiment

    • 3 Comments

    We're piloting some video-based guidance.  Here's what I want to accomplish for the videos:

    • Factor "What Is" from "How To" type videos (i.e. reference vs. action)
    • Do more, smaller videos vs. a few larger videos (modular vs. monolithic)
    • Show me how vs. just tell me how
    • Outcome-based videos (walk away with actionable insights)
    • Share strategies and approaches that sometimes don't across in just text

    For the user experience:

    • Ability to quickly browse an index of the videos
    • Ability to preview the videos inline
    • Ability to download and watch the videos at your convenience

    I'd like the videos to complement our text-based guidance modules (how tos, guidelines, checklists.)   While doing video is nothing new, I think the tough part for my team is figuring out:

    • How to balance prose-based guidance with video-based guidance
    • How to figure out the most useful videos to avoid signal to noise ratios
    • How to figure out the most effective channels and mediums

    I think a lot of our guidance can be more consumable in video form.  At the same time, I think some things aren't as useful in video.  I see video as a supplement to augment baking knowledge into plaintext (where we can efficiently search it, share it, tag it … etc.).

  • J.D. Meier's Blog

    Life's an Experiment

    • 3 Comments

    It's amazing how much the metaphors we use can be enabling or disabling.  For example, I used to think "in life there are no second chances" or "you never get a second chance at first impressions."  Once I adopted, "life's an experiment", it was much more enabling.  It means, changing from getting everything right up front to boxing my risks, trying more, and learning and adapting as I go.

    My manager is very much into experiments around impact and improvement.  He's got a research background, but he's into applied research.  That works great for me because I'm a fan of learning what works over theorizing endless possibilities.

    For me, the keys to metaphors are knowing which ones I use, and which ones are limiting.  I always need to ask, what's the most enabling metaphor for the situation I'm in.  What will make me more resourceful?  For example, in a group like patterns & practices, experimenting and continuous improvement come with the job.

    I'll have more to say on metaphors another day, but in the meantime, I'll leave you with this ... do you know your 3 most enabling metaphors? ... do you know your 3 most limiting?  (hint - limits and opportunities are in the eye of the beholder ... whether you think you can or can't, you're right)

  • J.D. Meier's Blog

    Worst Things First

    • 2 Comments

    This a practice I learned long ago and it's actually helpful whether it's day to day or building software. It's doing worst things first.

    It's human nature to move away from pain.  Sometimes I have a meeting or a conversation or even just a task for the day that I'm not looking forward to.   I'm not talking about the stuff I can ignore forever.  I'm talking about stuff that needs to happen sooner rather than later, that I won't enjoy doing.

    If I push those things to the end of the day or the end of the week, they loom.  Why loom longer than necessary?  That's draining.  Somebody long ago gave me the tip worst things first and I didn't realize it's actually become one of my most effective habbits.

    One of my mentees is going to combine worst things first with a 30 day improvement sprint to see how much energy they get back and how much more they get done.  I think this is a great experiment and I look forward to their results.

  • J.D. Meier's Blog

    Prioritizing Scannable Outcomes

    • 2 Comments

    How do I efficiently and effectively prioritize my day ... my week ... my life?  In an earlier post, I talked about using Scannable Outcome Lists.  For a quick reminder, this is simply a flat set of lists.  I name each list by project or area I'm working on (e.g. mind, body, career, project X, project Y, projec Z).  Inside each list, is my list of key outcomes.  Think of these as a list of lists -- a bird's eye view of the big picture, and then a drill-down view in each list. 

    I use this to quickly scan across my areas to remind me of what's important to work on.  This is the lowest overhead approach I've found so far to keep a wide radar scan, yet be able to drill in as needed.

    When I first started, it was easy to simply sort my list by area.  Now I find it helps me to sort this list by priority 0, 1, 2 and 99.  Priority 0 is for my continuous categories: mind, body, career, financial, relationship, personal dev, professional dev, and recurring.  I use recurring to remind myself of things like doing backups.  Priority 1 is for my most critical projects or most important areas, compared to my priority 2s which might be ideas I'm somewhat working on or starting to build momentum for, but not critical for success.   99 is on deck or backburner.  Collectively I think of this as managing action similar to Maslow's Hiearchy of Needs.

    To do this in Outlook, I have a single folder called Queue, to hold all my scannable outcome lists.  I drag a short-cut to Outlook's "favorite folders" for fast access.  I create a single post for each scannable outcome category.  I add priorities by assigning "Categories" to each post -- I tag each one with a 0, 1, 2 or 99.  I "Arrange" this older by "Categories", and then I custom sort by Subject.  This gives me a very fast sequenced view grouped by P0, P1, P2, P99 and then sorted alphabetically within each group.

    I start my days by scanning or updating my scannable outcome lists, then carving out the most important actions into my daily dos list.  The entire process generally takes me 5 minutes or less each day, except on Mondays where I have to spend a little more time to figure out outcomes for the week. 

    Related Posts

  • J.D. Meier's Blog

    New Video: What Is - New in Team Foundation Server Source Control

    • 2 Comments

    We added Video: What Is - New in Team Foundation Server Source Control to our Visual Studio Team System Guidance Project.  Watch this video if you want a brief highlight of some of the differences between Visual Source Safe and Team Foundation Server:  It's one of our first "What Is" type videos as part of our Video-Based Guidance Experiment.

  • J.D. Meier's Blog

    5 Tips for Blogging

    • 2 Comments

    Here's some quick blogging tips I shared with a colleague, that they found helpful:

    1. Have a purpose or a theme -- I find having a simple purpose helps.  For example, my one-liner for me is to journal my Microsoft adventures.  Within that, I'll tend to focus on shaping software, project management, and effectiveness.
    2. Know what you want from blogging -- if you don't have a compelling why, you'll lose the path.  Your's might be *share insights and lessons learned*, or *build a sounding board* or *influence change one reader at a time* ... etc.  It's whatever is compelling for you, and remind yourself when you need a boost.  For me, it's personal growth and sharing what I learn with others.
    3. Schedule your blog time -- it's not tough to write stuff; it's tough to sit down to write it.  Make the time first, and the creativity will happen.
    4. Post "good enough" vs. fit and finish -- if you always aim for the long-shot, you'll miss great posting opportunities along the way.
    5. Do a blogging 30 day improvement sprint -- Seriously.  You'll learn a lot up front, that you can use over a life time.  While a piecemeal approach over time works too, I think this is a case where you can learn a lot in batch. There's a lot to be said for little improvements for 30 days.  Even if that means asking and finding one good blogging question per day.  Most importantly use this sprint to find your rhythm.  Start off more frequently to become more efficient, then choose whether you want to do daily or weekly.
  • J.D. Meier's Blog

    3 Tips for Branching in Team Foundation Server

    • 2 Comments

    One of my readers asked me if I could provide a bit more insight on branching.  I think the best thing I can do here is summarize a few tips and then point to some useful resources.

    Key Tips

    1. Don't branch unless you need to.  You can always label a release build and branch later.  Use branching for isolation while doing parallel development.
    2. Know the common branching patterns.  These include branch by feature, branch by release, and branch by team.
    3. Use a common folder structure for your branches.  While your branching can be organic and evolve over time, a thoughtful folder structure can help. 

    Here's an example starting point.

    /Main
    	/Source
    	/Build
    	/Docs
    	/Scripts
    	/TestCases
    /Development
    	/FeatureBranch1
    	/FeatureBranch2
    /Maintenance
    	/Release 1
    	/Release 1.1
    	/Release 1.2
    

    In this case, Main is your main source tree and project assets.  Development is a root level folder for isolating your features or teams (branched off your Source folder in Main).

    More Information

  • J.D. Meier's Blog

    Thinking About Career Paths

    • 2 Comments

    I'd like to share some of the insights that others have shared with me over the years about choosing paths.  My favorite insights have always been guiding questions that help me choose my own adventure.

    Mentor #1

    • Do you want more fame, fortune, time, or love?
    • Do you want to be a thought leader or a people leader?

    Mentor #2

    • What are you doing that you currently enjoy?
    • What do you want to do more of each day?
    • What do you want to do less of each day?

    Mentor #3

    • What problems are you working on?
    • Who are you working with?
    • What impact are you making?

    As more folks ask me about their careers, I've found myself talking about three things  

    1. Your network helps you.  It's a small world.  Don't burn bridges.  The best networkers I know, balance their weaknesses through strengths in others.
    2. Your career is a portfolio of experiences.  What do you want under your belt?  A twist on this is, what are the unique experiences you can have, where you are right now?  For example, what sort of things can I do at Microsoft that I wouldn't do anywhere else and how do I make the most of it?
    3. Your approach sustains you.  Knowledge is very transient.  It's how you learn and how you adapt that carries you forward.
Page 1 of 2 (48 items) 12