I love building new things, and coming up with new ideas. The ability to create new products and solutions has always been great fun. One of the things I wanted to do since early in my career was to have a patent in my name.
At my first professional software job at Kodak back in 1997, I remember closely working with a lot of really brilliant engineers. One engineer in our team who’s name I sadly cannot remember had over 100 patents issued. His entire job was to come up with radical new ideas and see if he could make them work. He had no other responsibilities which at that time was quite rare. At the time I thought it was pretty incredible that was his only job. Since then, I always wanted to be a patented inventor.
Well, today I can say that I am officially a patented inventor!
So What is the Invention?
During my work at Pleiotek, I was a co-inventor on a series of ideas that resulted in Patent 10786395: “Apparatus for Processing Healthcare Data and Storing and Transmitting Large Amounts of Data via a Bandage or Sticker”. Yeah that doesn’t roll of the tongue I know.
In short, this patent captures the idea behind storing patient medical data on the patient itself. Imagine a soldier injured in a battle, or someone hurt in a mass protest. In these urgent and tense situations, timely patient care is critical. But in these types of scenarios, the patient will need to be made safe, and ultimately moved to higher echelons of care.
We must retain records of patient injuries and care. Incorrect or incomplete patient records can cause mistakes. For example, a patient in pain may be administered a dose of morphine. Morphine can be fatal in high doses. So it is critical that providers know if a patient has already received the medication.
The current state of the art for tracking patient data in these situations is weak. Patient data is written on very small cards, or on the patient via sharpie. Yes really. In some cases mobile devices are used to track data, but it is rare in the theatre of war or in mass casualty situations.
The system that we invented helps care givers both track medical data and provides a way for the data to easily travel with the patient. We invented various techniques for embedding data storage in bandages or very small patient worn devices. This allows care givers to record the patient’s medical information directly on the smart bandage or device on the patient. Now patient data follows the patient wherever they go. This ensures their medical record is complete and accurate. It also ensures care providers have all the information they need to provide the best care.
The idea and technology is great. Although I am no longer part of Pleiotek, I am hopeful that they can bring this technology to market. This idea can be a great help to our military as they treat soldiers who sustain non-combat or battle injuries. It will also help our local emergency healthcare teams as they treat large events with lots of patients and hand offs between providers.
“Pseudocode” is a powerful way to write and document software. Put simply Pseudocode is just plain english text describing what the code should do – it is not actually code itself. I found this old-school screen cap on Google that describes nicely a few of the reasons why Pseudocode is great:
The following is an example of what a good use of Pseudocode looks like. In this case I’ve written out the basics of a function to handle user logins:
* The purpose of this function is to attempt to login a user.
* User record: On successful login or
* false: On error or failed login
function login(username, password)
// TODO: Check for valid inputs to this function:
// TODO: Get the user from the database:
// TODO: Check the user is valid:
// TODO: Check the user is not locked out:
// TODO: Validate the user's password:
// TODO: If the user passes all above checks and has a valid
// password, then return their user record, otherwise
// return false:
As you can see we haven’t written real code. We really only wrote the skeleton of a function and then wrote out in plain english comments what our code will do.
The Benefits of Pseudocode
Why would you write out Pseudocode instead of just writing the code? Well there are a few reasons:
Breaking Down the Problem: By writing out the basic steps to implement our function we have to think about the entire problem to be solved by the function. This helps us break down how the code should work and how it must work when there is bad input or an error.
Specify the Interface: Pseudocode can help us to define the input and output of our function, class or code blocks. In the case of the example above we have to handle two cases – a successful login and a failed login, so we need to have returns for both. It also allows us to share our planned interface with other developers before we have written the code.
Identify Opportunities for Reuse: For each of the high level steps of the function, we have a TODO line. In some cases we can identify through these steps items that could be made separate functions that could be reused. In the case of this example, there are at least 3 items that should be separate reusable functions.
Find Gaps in Understanding: The final benefit of Pseudocode is that it can help you determine what you need to know that you don’t know right now. In our hypothetical example, after writing out the function it is clear we don’t really have a strategy for error handling and that needs to be addressed. Returning “false” when a login fails is OK – but does not communicate errors, or reasons why a user could not login. We won’t address it here, but proper error handling is definitely a topic for the future.
Actually Writing the Code
Taking into consideration our four points above we can actually write out or code by filling in the TODOs. We will do this with some basic operations and calls to external functions/libraries we either write or have available:
* The purpose of this function is to attempt to login a user.
* We've made some changes based on our thoughts so far.
* User record: On successful login or
* false: On error or failed login
async function login_v2(username, password)
// Check for valid inputs to this function.
if ((username != undefined) && (username != '') &&
(password != undefined) && (password != ''))
// Get the user from the database - this should be
// a reusable function:
var the_user = await users_service.get_user_by_username(username);
// Check the user is valid and is not locked out:
if (the_user == undefined || the_user['status'] != 'VALID')
// Validate the user's password:
var valid_password = await users_service.validate_password(the_user['password'], password);
// If the user passes all above checks and has a
// valid password, then return their user record,
// otherwise return false:
if (valid_password == true)
A lot changed between our initial Pseudocode and what we have now. But, the key take away is that the code we added just filled in the pieces we created with our Pseudocode.
Creating/Using Reusable Functions
Most of the above is pretty simple code. It may or not be an optimal solution or example, but it is instructive. One key concept shown in this example is how Pseudocode can help you identify reusable code.
The “users_service” is an example of what I mentioned above. Pseudocode helps you find places where you will need to do something in other places – and the user operations in this function are exactly that. You will need to get user records frequently so write the code to do it once and reuse it. Similarly password checks may need to be used in multiple places, so write it once and reuse it.
Often times when I build code, I will define services to handle various pieces of functionality. One very common one I use is a “users_service” that handles all user operations – get, create, update, delete, search, and validate operations will all be part of the service.
Finding these places where you will want to create reuse-able code is one of the strong benefits of the exercise of Pseudocode. It will become very clear when you go through what code will be something you would want just here in this function vs. something you can use over and over.
Added Benefit: Code Documentation
Another great benefit of writing Pseudocode first before you write code is now you have code documentation already written. It’s already written as part of your Pseudocode. You just need to tweak it to match the actual code you have written as needed.
Some may say that the comments above are trivial and unneeded. To some extent that is true, but in this case we’re providing a simple example so the comments help.
Self Documenting Code is a LIE
I hold the VERY STRONG opinion that code comments are required and you can never have too many code comments.
I absolutely HATE the idea that code is “self documenting”. It’s not. Stop lying to yourself and your team.
Let me repeat myself. Your code is NOT self documenting. You, the original author of the code may have a complete understanding of it at the time. You or the poor bastard that comes behind you 18 months later will have no clue what you meant or what business rules you were using.
I’ve seen and had to work on code that is more than 10 years old many times. I’m talking about code running enterprise applications at billion dollar companies. Very rarely do these ancient applications have any code comments.
The worst example I can think of was a 21 year old PHP applicaiton. This code was initially written 5 major PHP versions ago. It has been heavily tweaked, changed, and refactored over the years. No one ever added code comments and so no one knows how it really works. Working on new functionality or making bug fixes takes forever because you have to read through a ton of code to figure out what is even going on.
This is the nightmare you create without code comments. Nightmares for whoever the poor bastard is that has to work on your code down the road. That poor bastard might be you by the way.
But by writing Pseudocode first, you already have a basis for code documentation and code comments. So, I advise that you do so, and continue to comment your code as it grows and evolves. You will thank me later. Your colleagues and folks who come behind you will thank you too.
If you don’t already make a habit of writing out code in Pseudocode – try it out today, or the next time you are writing code. It will help you better understand and structure your code – plus it comes with the added benefit of having already written code comments to help you and any future developers who have to touch your code.
I’ve decided to add a new topic area to my blog – Finance and Investing. I’ve made PLENTY of financial mistakes over the years, and I’m happy to say I’ve learned quite a bit from them.
One of my goals for most of my adult life is to be able to be financially independent so that I could retire early. I am proud to say I’m close to achieving that goal. I’m only 43 and I could retire in the next 2 or 3 years if I wanted to. I’m not sure I will ever want to stop working entirely because I enjoy it too much – but having the option is very nice.
Anyway, I hope to share some of the financial lessons, tips and tricks I’ve learned over the years here so that others may benefit.
Earlier this year, I started working with Springboard as a Software Engineering Mentor. Springboard, for those who don’t know is an online learning platform that offers courses in a number of areas such as: UI Design, Data Science and of course Software Engineering.
I was drawn to Springboard because I liked their overall approach to teaching students, and the fact that they partner with students to help them find work when they complete the program.
I have mentored a few dozen students through the Prep program. Almost all of the students I’ve worked with have enjoyed the course and found it really rewarding. There have been a few who learned that software is not something they understand and/or enjoy – and that is OK too. Writing software is not for everyone. It is much better to find out software is not the career for you after a small time and financial investment vs spending thousands of dollars or years of time only to realize you hate it.
Springboard Full Software Engineering Career Track
The second offering Springboard has for Software Engineering is the full Software Engineering Career Track. This is a much longer course meant to be completed over about 10 months.
Like the Prep program the full course starts out simple but quickly builds upon each lesson. After the first few weeks each student will be designing complete fully working web applications. Around the end of the first month, students will have built out a substantial web application that works well and mirrors a popular web site’s functionality.
Most students who complete the Prep program want to move on to the full Career Track and I encourage them to do so. Springboard has some flexible programs to make the course affordable and they really do care that you succeed. That is what drew me to work with them – the genuine desire and structure to ensure every student is successful.
Springboard is not just another code boot camp that’s a money grab operation. They are the real deal – they actually care about your success and they are offering a great program to teach you how to develop quality software.
Learn More about Springboard
Are you are interested in writing software as a career? If so it is well worth the time and financial investment to try a Springboard course.
I’ve had a blog site online for quite a while. I think it’s been something like 10 years now. I never spent a lot of time writing here, and really only used it to showcase some of my mobile app projects.
Well, that’s going to be changing. Starting today, I will be focusing this blog on sharing some of the things I’ve learned over decades of developing software.
One key benefit to sharing my past work is that I can start to have a nice demo portfolio online for folks to see. One of the challenges of interviewing today is that everyone wants to see your code online. Some short sighted interviewers don’t realize that there is a LOT of software written that doesn’t end up being used by the general public. Or software that was online at one point and has since been removed. The vast majority of the software I’ve ever written is internal corporate software. Or, it’s the guts of a system that powers a public facing system. So, there’s nothing to “show”, really.
For example, one such system I wrote years ago at Southwest Gas was a system integration between their Interactive Voice Response (IVR) call system and their backend mainframes and databases. My code was used to connect callers to their accounts so they could get their payment, balance and other information via the phone. This system handled ~2 million requests per month flawlessly. So, yeah its a cool system, but unless you’re a natural gas customer in the US southwest, you’d never be able to see or use it.
Anyway, more to come in the future. I am going to do my best to make this a useful blog for developers and folks curious about software in general. Stay tuned!
Privacy & Cookies Policy
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.