How to Take Good Notes

Photo by Startup Stock Photos on Pexels.com

 

It is important that you can review what you’ve been told as quickly as possible, particularly in a technical position where things can get very complicated.  You might be tempted to memorize a list of requests or even recall a technical discussion from memory, but I’m going to tell you right now that you will not always be successful.

I have been in the IT field for many years, and I’ve seen too many people rely on memory to recall technical details and they are just never 100% accurate. You need to write down everything, and even that will not be 100% successful, but your success rate will be higher than using just your memory. It is also helpful in disputes about what was actually said during a meeting. You say they asked you to do “x”, and they say that they told you to do “y”. If you pull out your written notes and they say “x”, you will probably win that argument.

Steps to Note Taking

1. Buy a notebook – No matter how you want to store your notes, you need a notebook. Even if you plan to electronically store your notes for easy searches and printing, you want to start with a paper notebook. This will give you a platform for quick notes, drawing diagrams, etc. Never cross your personal notes and business notes. One notebook for work, and if it isn’t related to work it doesn’t go into that notebook. This can be a simple composition notebook, spiral notebook, cheap ruled pad of paper, etc.
2. Blog your notes – Once you have completed the work day, or even the next morning, copy your notes to a private blog site. You want this private blog to be blocked from public access, but this blog will allow you to easily search through your notes and find keywords. This is also the perfect time to clean up your notes and add details you might not have thought important during the actual meeting. You want to do this while the events are still relatively fresh in your mind.
3. Structure – As the meeting starts, you need to be prepared for the meeting by having turned to a blank page in your notebook. Write the subject of the meeting at the top of the page, along with the date and time of the meeting. Note who is attending the meeting, including people connected remotely. Take notes about questions asked, answers provided, and action items assigned to each person. Take notes like you might be asked to recreate the meeting by a police investigator a year from now. You want to take enough notes that you can speak intelligently about what was discussed, who was asked to do which tasks after the meeting, the names of everyone attending, and any unresolved items from the discussion. Never assume you will remember all these items 1 week later, much less a year from now.
4. Listening – By listening to everyone else in the meeting, you should be able to pick up on important items for that person. If it seems important to them, maybe because they are stressing the item, you should probably write it down for your notes. Even if nothing important is discussed, your notes should say that.
5. Write Neatly – You will probably need to read these notes again really soon, especially if you later move them into an electronic format, so make sure you write in a way that you can read the notes at a later time. When possible, write in complete sentences and use bullets and numbers to note important items. Don’t be afraid to underline important notes, using stars to point out assigned tasks or questions that you need to answer later. Use diagrams or sketches to illustrate important concepts or to copy whiteboard discussion notes.

Once you get into the habit of taking useful notes, you will develop a system that works best for you and the way your brain works. As your responsibilities grow and you are expected to manage more complex and expensive projects you will want to have already developed the skills to keep track of those projects without getting lost in the details. Start early and develop a system now that allows you to record all the important information, and it won’t be so difficult later. People will quickly lose confidence in your abilities if you forget assigned tasks from your meetings, can’t remember what was discussed from week to week, or can’t remember who made important decisions from 5 meetings ago.

 

 

Best Practice Guidelines for Documentation

Documentation can be one of the most difficult parts of a project. You might find it is difficult to get your team to spend the time required to get the documentation completed. Having an effective strategy to keep your documentation effort useful, efficient, and done on time will help you keep your project on time and focused on long-term results.

According to general best practices you should focus on:

• Branding – Don’t be afraid to create a standard template so all your relevant documents have the same general appearance and sections. This should include a table of contents, page numbers, and corporate logos. This will also give the documents an “official” appearance which can help sell the idea that everyone should be reading and following procedures in the documents.
• Schedule Time – Effective documentation doesn’t just happen, you have to schedule the time for the team to create the documents. Put the time on your calendar and force the team to spend the time required to write good documentation. There should also be periodic scheduled times on your calendar for allow you time to review existing documents and determine the required updates to keep the existing knowledge base useful.
• Include Details – Write as detailed documentation as you think you will need, and summarize the data in a second version of the document if you need an executive summary. You need to determine the right level of documentation for your audience, but details are usually only available during the project and fade over time unless they are written down. Things that seem obvious today will be lost to time if they aren’t written down for future audiences.
• Location, Location, Location – Good documentation will only be read if it can be found. Documentation is worthless if no one can find it when they need it, so make sure it can be easily located. Make sure the proper infrastructure is in place to help users access the documentation.
• Knowledge Sharing – People generally don’t like writing documentation but find good documentation very useful. Make sure you put your documentation in a place where the people who need to read it can get to it without any issues. You might create different types of documentation (printed, electronic, Wiki, video, etc.) based on the target audience.
• Up-to-Date – Keeping documentation current is one of the hardest thing for people to do well. Selling your team on the need to create the original version will be difficult enough, but asking them to review the documentation months or years later will be a hard sell, especially if the team already feels overworked with other projects. Using a version control will help you to manage the various versions of the documentation so you keep the latest version available and backed up.

How to Take Good Notes

It is important that you can review what you’ve been told as quickly as possible, particularly in a technical position where things can get very complicated.  You might be tempted to attempt to memorize a list of requests or even recall a technical discussion from memory, but I’m going to tell you right now that you will not always be successful.

I have been in the IT field for many years, and I’ve seen too many people rely on memory to recall technical details and they are just never 100% accurate. You need to write down everything, and even that will not be 100% successful, but your success rate will be higher than using just your memory. It is also helpful in disputes about what was actually said during a meeting. You say they asked you to do “x”, and they say that they told you to do “y”. If you pull out your written notes and they say “x”, you will probably win that argument.

Steps to Note Taking

1. Buy a notebook – No matter how you want to store your notes, you need a notebook. Even if you plan to electronically store your notes for easy searches and printing, you want to start with a paper notebook. This will give you a platform for quick notes, drawing diagrams, etc. Never cross your personal notes and business notes. One notebook for work, and if it isn’t related to work it doesn’t go into that notebook. This can be a simple composition notebook, spiral notebook, cheap ruled pad of paper, etc.
2. Blog your notes – Once you have completed the work day, or even the next morning, copy your notes to a private blog site. You want this private blog to be blocked from public access, but this blog will allow you to easily search through your notes and find keywords. This is also the perfect time to clean up your notes and add details you might not have thought important during the actual meeting. You want to do this while the events are still relatively fresh in your mind.
3. Structure – As the meeting starts, you need to be prepared for the meeting by having turned to a blank page in your notebook. Write the subject of the meeting at the top of the page, along with the date and time of the meeting. Note who is attending the meeting, including people connected remotely. Take notes about questions asked, answers provided, and action items assigned to each person. Take notes like you might be asked to recreate the meeting by a police investigator a year from now. You want to take enough notes that you can speak intelligently about what was discussed, who was asked to do which tasks after the meeting, the names of everyone attending, and any unresolved items from the discussion. Never assume you will remember all these items 1 week later, much less a year from now.
4. Listening – By listening to everyone else in the meeting, you should be able to pickup on important items for that person. If it seems important to them, maybe because they are stressing the item, you should probably write it down for your notes. Even if nothing important is discussed, your notes should say that.
5. Write Neatly – You will probably need to read these notes again really soon, especially if you later move them into an electronic format later, so make sure you write in a way that you can read the notes later. When possible, write in complete sentences and use bullets and numbers to note important items. Don’t be afraid to underline important notes, using stars to point out assigned tasks or questions that you need to answer later. Use diagrams or sketches to illustrate important concepts or to copy whiteboard discussion notes.

Once you get into the habit of taking useful notes, you will develop a system that works best for you and the way your brain works. As your responsibilities grow and you are expected to manage more complex and expensive projects you will want to have already developed the skills to keep track of those projects without getting lost in the details. Start early and develop a system now that allows you to record all the important information now, and it won’t be so difficult later. People will quickly lose confidence in your abilities if you forget assigned tasks from your meetings, can’t remember what was discussed from week to week, or can’t remember who made important decisions from 5 meetings ago.

 

 

Working Together for Better Development

Even through the tech world is moving to a Cloud environment, in many places the invisible wall that separates developers and network engineers is still pretty present. Communication between both of these business teams is necessary to make sure your application or database is deployed correctly and achieves high availability for end users. There are some basic recommendations for improving that relationship:

Improved Documentation

Documenting a well-defined list of dependencies is one of the most important things you can do when handing off your application or database. Make your documentation as specific as possible, including Operating System requirements, service packs, database drivers, etc. as well as system configuration expectations on CPU, memory, drive space and speed, network connectivity, etc. Don’t assume the network guys understand anything about your testing and development environment.

Request and Provide Descriptive Logging

Having detailed logs is one way to help network engineers quickly diagnose and fix a problem when an alert comes in. If there is an issue during or after rollout, the troubleshooting team will request any logging you can provide to help isolate the issue, and you will be expecting them to share their logging with your efforts. Overcome this issue by ensuring that any logs your application generates adequately describe the errors that the app is encountering.

Fully Tested Code

As amazing as it sounds, fully test the code to help mitigate any surprises on launch day. Testing should extend beyond the typical unit testing that happens in most basic testing environments and extend your testing to include all processes as they will exist in the production environment. Be certain to verify the integration points between your code and other applications as much as possible before moving anything to production.

Rollback Plan

While we understand your code has minimal errors, you have to make the assumption that something could go wrong. Even with days or weeks of testing, you have to be prepared to react quickly to production issues. If you already have a written response to production issues, which may include removing the change, you have managed expectations before the issue has actually occurred. It is best to create a rollback plan, which not only mitigates the risk of a bad deployment but also minimizes the amount of downtime.

Communicate Expectations

There is a difference between 99.99 percent and 99.999 percent uptime, and you should communicate your expectations in advance of it becoming an issue. Communicating this expectation to the network team can help ensure that the hardware is architected to achieve the required level of uptime.

Improved communication between everyone involved will help improve the development environment, which we all want as it should streamline development and shorten rollout schedules.

Technical Writing

Are you contemplating or beginning a career in technical writing? Have you been asked to create the user guide for your company’s software application? Have you been asked to hire and manage a writer? Where do you begin? You need to know what technical writing is and what it takes to be good at doing that job.

Technical writers translate and organize complex information into user guides that most any person can understand and use with ease. Recently there seems to be less emphasis on good technical writing, but writers who do not really know how to write manuals or use the software won’t write really good documentation. Sometimes you will have to clean up a documentation mess left behind by a previous writer. Some companies see technical writers as a high-cost, low-value drain on the company’s bottom line, so they don’t invest in really good technical documentation.

To get a job as a technical writer, you must be a good writer first and able to understand technology second.

• Create an error-free resume – Make sure you check your resume 3-4 times for any errors.
• Write grammatically correct – You won’t get a job creating documentation if your are prone to errors
• Document writing experience – List all previous writing experience
• Understand Software – Understand existing software documentation and the general format
• Create Samples – If you are trying to get a job for a specific company, provide samples of how you might write their technical documentation
• Work for Free – You could do some volunteer work to gain experience and demonstrate ability

Being a really good technical writer is an important skill, and not very obvious to the average software user.

As technical writers, it is our job to translate the complex and puzzling into something that everyone and anyone can understand. You and I represent Joe User. If you don’t understand something, it is a sure bet that Joe User won’t understand it either. Never repeat verbatim the words of the SME. Always ask for clarification.

There is some online help if you are interested in this specific career choice.

How to Document the Process

Generally speaking, personnel in the information services field should have the basic ability to document what they do each day, as well as document changes as they occur to production systems. Working on documenting a process can be difficult. You will find that often the process isn’t designed well, and as a result people didn’t create a documents to describe the process or don’t even use the finished documents if they do exist. It’s like writing a huge business plan when you know it will just be changed tomorrow. This can be incredibly frustrating for the writers and the users.

So why don’t we just do away with process documents entirely? Because, at least conceptually, they have the potential to improve the way we work. Good documentation will offer insight into the inner workings of a company, and they can be used as tools for teaching new employees when you have the appropriate organization.

If these documents were created with their end purpose in mind and used by people in the company, then they won’t become a relic of some lofty meeting goal once upon a time.

You can work to create meaningful and useful documents that enhance your company’s efficiency and performance by following these steps:

• Make them (internally) public and highly visible. The purpose of a document is the dissemination of knowledge. When access is restricted, it sends a message that the information is only relevant to a certain group of people. Remember that these documents are intended to reach readers and employees. Publish documents on a platform where your team will see them daily. Maybe you just email the Word document or PDF to all the interested users, but you must make periodic updates and keep the process moving forward.

• Make them easy to edit and search. Process documents are for the company to use, so feedback and new input can be incorporated to make them more effective. Hold meetings, as required, to give interested parties access to changing the documents, asking questions,and making recommendations.

• Be concise. A good process document doesn’t distract you with excess information. Provide only as much guidance as needed. Clear and concise communication is your goal.

• Be flexible. Processes change and evolve over time in a company, and they only work when the steps in the process come naturally to everyone involved. If you’re trying to force employees to adopt a process and they’re pushing back, ask them to identify the friction points. Identify solutions for those points and build around them.

Who Edits The Documents?

Everyone should have access to the documentation. Maybe every employee should have editing rights to all of your process documents. It might make sense to restrict editing privileges to department heads or other appropriate employees.

Process documentation should be driven by feedback from your employees — even in the most command structured companies. Collaboration and listening are critical aspects of effective process-building. These documents are for the team, in most cases, and you need to make sure they’re communicating the intended message.

When changes occur to how the team works you should be proactive and make regular edits to the documents to ensure they are up-to-date and applicable to your company’s current mission. When something about a process is no longer working, it’s time to make changes.

What The Documents Reveal

Though they may seem boring, process documents reflect fundamentals about your business philosophy. For example, if your documents are barely accessible, out-of-date, and poorly written, they’ll be a source of frustration for any employee who reads them. The message communicated to them becomes, “We don’t care much about institutional knowledge, and we’re not interested in making life easier for our team.” This mentality is a drain on morale in the long run.

On the other hand, consider the impact of a great document that is succinct, informative, and current. When an employee needs guidance and views a helpful document, they will be thankful and educated. If that same employee can amend the file with their own insights, they’ll feel a sense of pride and ownership.

Documenting process is a way of empowering your team to do more, faster. Treat documentation as an asset — not as a source of dread — and it can do great things for your company.