I recently read the book The New One Minute Manager by Ken Blanchard and Spencer Johnson, and I had some really interesting takeaways for my own job. I expected to learn about being an effective manager, but I actually learned even more about how to be an effective employee and start the journey of self-managing.

What is a One Minute Goal

A one minute goal is very simple and has helped me work effectively,  focused and cut down on my wasted time these last few months. A one minute goal is a written down goal that should take no longer than a minute to read. The point of having it written down and being short to read is two fold.
1) You have to keep it focused since you have limited space to write the goal.
2) They can be easily refer back to at anytime, and remind you the bigger picture and goals by and large.

Why One Minute Goals?

Working in any job can be complicated, and staying focused on your goals can be challenging when work life gets frantic. As a QE consultant I have definitively worked on something I thought was important to my project when in actuality it wasn't important at all. Creating one minute goals and having a manager review them can minimize this risk.

A one minute goal ideally should be created by yourself and reviewed with your manager/lead. You can easily check all of your one minute goals every day to ensure you are constantly working towards your goals, and minimizing time spent on unimportant tasks.

My Use of One Minute Goals

I have been using one minute goals on my latest consulting project, and this has helped me immensely over the past few months. The project is very large and has so many moving pieces that context switching became a real issue. I was trying to create checklists and take notes about my progress but everything just didn't work out well. My checklists became huge as putting a checklist item was either over simplifying it making it very large and hard to read.

I switched to 3-5 one minute goals a sprint, and I have been way more effective and happy with my work output. I share my goals with my test lead on the first day of sprint, and begin creating my estimated tasks around them. Every task I make can be tied directly to one of my one minute goals allowing me to refence back to a larger goal easily.

Final Recommendation

I would recommend not only reading The New One Minute Manager, but also trying out one minute goals. They have improved my day to day work output, and helped me stay focused on the bigger picture. One minute goals has saved me lots of confusion and time wasted on evaluation. One minute really does go a long way.

1 hour ≠ 10 hours. This is a simple fact, yet myself and many others have spent 10 hours or more automating a solution that could have been completed in just one hour. Sometimes this is a good thing as the code is better and more resilient, but other times we follow this drive to optimize when it's just overkill.

No this isn't inherently a problem as code written with time and purpose should be better, but what makes some automation better than others? When does efficient and scalable code go too far? I have asked myself all these questions over the past couple of years as I have worked very hard to restrain myself from over-engineering. I began by trying to learn what made automation great.

Maintainability and Resiliency

There is a big difference between good automation and great automation in my eyes. Automation should be readable, clean, concise, following best practice, and maintainable. As programmers we generally are already used to creating maintainable code, but automation should be hyper-considerate about maintainability. For the purpose of this post:

Maintainable Automation - Automation that is easy to update, understand and maintain during the lifetime of a project.

I call attention to this because I feel like good automation I've seen is already maintainable, but what makes automation great is being resilient.

Resilient Automation - Automation that requires little changes when unexpected changes impact the application.

The difference between the two is pretty simple at the end of the day. Maintainable automation is easy to change for all expected changes like adding new automation for a new UI element from the latest user story. Resilient automation should handle the unexpected changes such as a massive page rework that changes all selectors for UI elements. UI selectors for Selenium shouldn't have to be updated every time the page is changed by dev.

Automation shouldn't require massive rework and hours of updates with every deploy. If a large portion of your time is spent updating automation, there is likely room for improvement.

Where's the Line?

Automation should be great, but being a software consultant has taught me that time should be considered with every action you take. I, as a consultant, should never be wasting my client's time and it is morally wrong to knowingly waste it. I began my career thinking that it's very simple to not waste time,  just work and don't watch cat videos!

In reality I started out wasting time fairly regularly while still being diligent and focused. The time waste would slip in whenever I began a new task, as I would begin trying to make the automation as efficient as possible. I would try to mix in every single trick I could to cut down on memory and reduce by Big O runtime. I would begin every task with the goal of efficient automation.

This wasted hours of time and provided little value, but how could faster automation provide little value? It's very simple, my basic workflow to open a mobile app, login and check the welcome message took over 40 seconds to run. The automation was already slow as we were tasked to use Appium on an outdated mac, and any standard optimizations would provide no value to my client. The tests would still take a very long time to run.

The line is really drawn when your time is better spent elsewhere, because when it comes to automation it's largely better to test more workflows and scenarios sooner with less optimized code as long as it's still just as resilient and maintainable.

The Balance

Eventually I realized my time was better spent on actually providing value to my project and the client. I stopped pre-optimizing and instead started populating data for all prerequisite screens in the database before a test would start. This cut down a test from 13 minutes to only 5. I started using the basic framework I created to test more scenarios for negative testing instead of making the acceptance criteria testing more optimized. My bugs created by automation skyrocketed when I changed my approach, and the UAT team really appreciated getting better builds as the automation was finally providing strong value outside of stock acceptance testing.

Your time is valuable so everything you automate should in some way have value. And the value provided should be worth the time investment, because without time as a factor every test and line of code should be perfect. Programming is a great iterative task, and creating automation is no different. Start with the basics and improve as you go. There are plenty of reasons to optimize for performance, but save that for when it's needed or every other task provides less value.

Simple tests and problems should always begin with simple answers. The time and effort is better spent on larger problems so keep the automation simple where it needs to be.

When Over-Engineering Goes to Far

I was brought into a new client to help this client's internal QA lead improve their existing automation. The existing project was a perfect example of over engineering. Someone at the client started this solution and wanted to make the automation highly efficient and to this day some of the most complex code I have ever seen.

This solution was near unreadable and was neither resilient or maintainable. Every deploy took multiple days to update the solution to basic changes but it ran very fast and to my knowledge was highly memory efficient. The problem quickly becomes that time and memory saved by the computer running the code or on the cloud is trivial compared to real hours spent by a human to maintain it.

The entire solution could have been a fairly straightforward solution but over engineering brought it to the point of wasting thousands of dollars. This is a real life example of 1 hour  ≠ 10 hours.

Final Thoughts

Simple problems should require simple resilient and maintainable solutions. Optimization can always be done later, as pre-optimizing can waste more time than it saves. Every moment you put into creating automation has a cost, and in a professional position that cost is money, as every second spent has a monetary cost to it. Make sure you and your project are investing that cost into great automation.

Some text editors today have multi-cursor features and at a glance these features seem pretty useless. Why would I ever want to type in two places at once? Well let’s dive into that….

What

A multi-cursor is just allowing you to have more than one cursor active in your text editor. Some notable editors that have this are Sublime Text and VS Code.

Why

Your initial reaction to a multi-cursor might be "It's as useful as typing with two people on the same keyboard." But if used properly this could be very beneficial. Look at the following simple game code:

public string Name { get; protected set; }
public int Level { get; protected set; }
public float CurrentHP { get; protected set; }
public bool IsGrounded { get; protected set; }
public double EXP { get; protected set; }

This code is missing the 'very' important summary tags, and we can add them very quickly with multi-cursor!

This is just a very simple example that saves a lot of time for anyone that can not auto-generate these docs strings. But wait let's look at another example:

public void foo { ... }
public static void bar { ... }
public void spam { ... }
public void ham { ... }
public static void eggs { ... }

For this example we will use multi-cursor searching. I will be using Sublime Text as it has a find all feature that works well with multi-cursor. Let’s assume we want to move all the static single line methods to the top to better maintain our code. Well multi-cursor has the perfect answer here.

Find all with the following text:

Then it's a simple copy and paste job. An easy trick to quickly move code around.

Want more?

This is just diving into the basics of multi-cursor editing and its uses. If you want to learn more see the sublime text documentation on muli-selection with the keyboard.

In 2019, Microsoft announced that Visual Studio 2019 will be the last major version with load testing functionality. They have depreciated their load testing tools and have shut down their cloud-based load testing services on Azure Pipelines/Portal. The simple reason Visual Studio Load was depreciated is because the tool wasn't growing in popularity and the market has numerous other options. I imagine Microsoft's time and resources would be better spent elsewhere, especially for cloud-based testing.

I personally used the tool on 3 separate consulting projects, and became very comfortable with the tool. Visual Studio Load was a clunky and rather limited tool compared to the market, but it was built into the .NET tech stack and has some of the easiest integrations I have ever seen for a project already utilizing Azure and Azure Dev Ops. I was able to spin up load testing on the cloud and have performance metrics report directly to an Azure Dev Ops dashboard for live and easy reporting.

I had to deal with the impact of losing Visual Studio Load, and learn how to better prepare for this moving forward. This post is not centered around performance testing, but rather the unique issues that arise when a technology is marked for End of Life.

The Impact

The immediate impact will be small as most technologies marked for End o Life will remain supported for some time. But new innovations, questions, features and bug fixes will slow down. The user base will slowly start moving away from a dying technologies and try to find something new. Some companies or user bases will decide to use this technology long term despite its deprecation. You will then have to decide if the short term gains of using a dying technologies are worth it.

There are a few questions you should ask yourself when one of your technologies becomes obsolete:

1. What do I have the depends on this tech?
This is probably the most important question you need to consider when a tech is End of Life. Is this a central technology for your architecture? Have many hours and resources been devoted to this tech? Will my system have to be written from the ground up after loosing this technology? Is it so vital no other tech will do?

Begin by understanding every integration and map these dependencies so you understand the actual impact. It's never overkill to document exactly how your systems or projects integrate and work together.

2. What other technologies exists that share a similar purpose?
Hopefully the market has a similar tool that could fit your use case. Look everywhere for alternatives and don't focus solely on the popular option. Keep your eye towards the future and see if the cutting edge might have the best tool for your job. Gather a list of strong options and scour the market for any news on the 'replacement' of your technology.

3. What makes my technology better and worse than the alternatives?
As you research alternatives, you will likely spot differences. For me one of the biggest pain points when switching technologies is losing out on your favorite features. Keeping a running list of differences will help make your decision easier as you review the alternatives.

Along with the bad should come some good. Find those new exciting features and theorize how helpful they might be within your system. Think critically about each feature and weight the pros and cons. This will help you balance out your options while keeping it focused on your specific use case. If a certain feature sounds nice but has no use for you, then looking elsewhere is advised.

4. What will the larger picture look like without this technology?
Looking at the larger picture along with the low level integrations is very important. How often are these alternative tech updated? Is there a large cost when switching to these new techs? Are there people skilled in these other techs, be it for hiring or question answering on forums? How new are these techs and will they stay relevant?

There are hundreds of possible questions, but the important thing is to think big after you start to narrow down the list. The best technologies out there will stand out when you consider the big picture.

5. How does the migration process look?
Some technologies make it very easy to migrate an existing system, and others make the process a nightmare. Easy migration and simple integrations are vital for some techs such as Application Security Tools and DevOps tools.

The impact from a tech reaching its End of Life can be big or small, but these questions should help you recover. There is a question that remains, "Can we prevent this impact?"

Going Forward

As technical people we all should know that our tools, and to some degree skills, depreciate in value. David Thomas and Andrew Hunt put it well in The Pragmatic Programmer, "Unfortunately, they're expiring assets." Andrew and David also dive into the idea of having a technical portfolio.

Andrew and David thought any technical person should manage their skills and tools like a stock portfolio, for which they call a technical portfolio. So what exactly is important for a tech portfolio?

You should follow these guidelines when managing your tech portfolio:

• Serious investors invest regularly
  You should be managing your skills, tools and technologies frequently. Set S.M.A.R.T. goals to improve and add to your tech portfolio on a regular bases. Commit to learning a new programming language each year. Decide to get a certificate in a new Dev Ops tool every couple years. Both of these are just some examples that will help you invest in your own tech portfolio. You should try to add to your tech portfolio frequently to make sure you are always current.
  
• Diversification is the key to long-term success
  Learning a wide array of languages and technologies will set you up for long-term success. Putting all of your focus into a limited technical space is not ideal and could lead to stagnation. Learn multiple tools and technolgies and find their perfect use case.
  
• Smart investors balance their portfolios between low and high risk investments
  Just like stocks you want to have your technical assets spread out. The cutting edge often has risky and unexplored techs, but learning these risky techs can benefit you greatly if they become widely adopted. The converse of that is ignoring the highly popular and adopted technologies would be foolish.
  
• Portfolios should be reviewed periodically
  No technology is safe from becoming obsolete. Very few technologies stand the test of time and have a long life cycle. Your tech portfolio should be reviewed and old assets deprioritized. A portfolio full of out dated techs and skill is taking a major risk.

Doing each of these will not only build a personal tech portfolio, but also prepare yourself for End of Life announcements. If you consistently managed your tech portfolio an End of Life announcement is only a small inconvenience.

Final Thoughts

The 'death' of Visual Studio Load was a major impact for me, but I was already dabbling in other tools such as Jmeter and Load Runner. I decided to compare both Load Runner and Jmeter to the soon obsolete Visual Studio Load and find my preferred performance testing tool. I devoted time to adapting my current skills and knowledge, and now I am just as proficient on Jmeter.

Every tech will have an End of Life date, and it's up to us to prepare for that date by being connected and current. My colleague Robert Wroblewski and I recently gave a presentation on Improving Your Technical Portfolio if you would like to learn more.