Looking for informative and thought-provoking content on various topics related to new media? Look no further than the Samples & Tests blog! As a companion to the popular Samples & Tests YouTube channel, this blog offers insights on the impact of new media on social interactions, as well as other relevant topics. With a focus on SEO optimization, you'll find relevant and engaging content to keep you informed and up-to-date on all things new media.
Showing posts with label information technology. Show all posts
Showing posts with label information technology. Show all posts
Saturday, August 24, 2024
C Programming for dummies
There is always something new to learn (or is there).
I am currently reading "C Programming for Dummies" 2nd edition by Dan Gookin. I decided to take it out of my local library. mainly because I had it on my wish list and I don't have anything else to read at the moment. I have books on C that I have had since the 90's. I read through them when I am trying to figure something out. Usually, it has to do with pointers. I have not had any formal training on C. I have taken a class on C++. and that did cause some confusion as I assumed certain things I learned about C++ were inherited from C. While, one thing I discovered is function overloading is not in C. So I am reading this book to find things I did not already know about the C programming language. It has been 2 days and so far I am up to chapter 7 (of 27) and have not discovered anything of note yet. I have come across a few things that are simplified for the sake of not having to go down the rabbit hole on what may be edge cases. sort of like how teachers in grade school said "A sentence can't start with because" As I discover new knowledge I will write it here and post it when I am done with the book (and have edited the blog of course).
So, the first thing that catches my attention is in chapter 7. I don't often use the getchar() function, so it did catch me off guard that it returns an int and not a char. I assume there is a reason, such as that in some languages/character sets a single character is more than 1 byte. and I need to check the sizeof(char) but I think it varies, but an int is almost always more than 1 byte. off the top of my head, I believe the standard is at least 4 bytes but can vary depending on architecture. I have not done any coding on this (yet) . I am just free-writing as I read the book. I have had issues when I needed a data type to be exactly 1 byte and tried to use char with differing results depending on the system and compiler. The more reliable way is to use uint8_t. I will try later to see if that data type works with getchar(). This goes for putchar(int) instead of putchar(char).
Also in chapter 7, it does what several other books I have read when it comes to pointers. it introduces functions like scanf() before explaining pointers. it just says put a & in front of the variable without explaining why. When I first started teaching myself C, I just followed the syntax without questioning why. I think pointers are confusing to new programmers (and experienced programmers) partly because pointers are generally taught as an afterthought. The chapter on pointers is 18; I will see if they are mentioned before then. and as soon as I wrote that last sentence I turned the page and there is one line that said "Part 4 of this book covers pointers" Chapter 18 is in part 4 by the way.
in chapter 8 which deals with decision making the author discusses the ternary operator. I did know of the ternary operator from a video by Jacob Sorber (https://www.youtube.com/watch?v=PfMV_wa0KY4), but I have not used it myself.
something I had not used in C but thought existed was until loops. While reading chapter 9 on loops I thought it was something they omitted at first, but I checked the keyword list and man documentation (or lack thereof) and discovered that I was getting syntax mixed up between languages (probably MS Basic and VB). An until loop is just a negated while loop so including it would be redundant to some degree. I assume a macro could be made so that they until(expression) equals while(!(expression)). I wonder if this book goes into macros.
In chapter 11 (the math chapter) something sounded familiar but I am not fully sure if I knew it. and this involves trig functions. I have used trig but I don't know if I used it in C (or any programming language) in C trig functions use radians and not degrees. This is kind of important to know. 90% of the time when I do use trig I am doing it in degrees, so I would need to make a conscious effort to use radians.
Another of these mathematical equations is with order of precedence. When you are writing literals it is easier to keep track of the order of operations. When you have variables and constants I like to add parentheses () to make things clearer on what happens first.
I read through chapter 12 (arrays) wondering when they will address pointers. and it was like the final paragraph. and they just said that it would be addressed in a later chapter. I don't understand why arrays are always taught that way after the fact. just pull the bandaid off and get through it. It makes things clearer.
On another note, I don't think I have used multidimensional arrays beyond 2 dimensions.
ok so in chapter 13 which deals with text manipulation, they say the "functions" in ctype.h are not functions but are macros. I mentioned before that they did not mention macros in the chapter on functions or when discussing #define. Now that is not going to confuse anyone. But, now I do want to read ctypes.h to see what the macros are doing.
The functions in string.h do give me issues and I tend to use the man pages often when dealing with string manipulation. and sometimes sprintf() is your friend, but snprintf() could be a safer path.
ok halfway through, nine days until I need to return (or renew) the book from the library.
Chapter 15 was on command line arguments using argc and argv depending on the compiler and os there could be others but this book does not discuss them and I am not sure if they are standardized. but if you are designing a program to be executed by a script or other processes then command line arguments are important. and without dealing with pointers (yet) and coping with argv as just an array and not a pointer aspect can get confusing down the line.
I am about to start chapter 16 on variables, let's see if they discuss pointers... halfway through the chapter and I don't see pointers mentioned. but I do want to talk about typedef and structs. For a while, I thought if you used something like "struct qwerty..." in C you could use qwerty as a data type like you can in C++. In C++ structs and classes are usable by the class name right away without using typedef.
again a perfect point to even just mention pointers... when discussing global variables and passing by value they could mention passing by reference and using pointers.
Chapter 17 is on binary/bitwise manipulation. This is a topic I know of but I need to look it up each time I use it. If you have seen my Raspberry Pi Pico video series on my YouTube channel you will see me using it in Python. but even then it was limited and I had to keep looking up the documentation. and That was a while ago so I need to recheck the code to see how I did it. I do know that when I went to reprogram it in C/C++ I didn't get that far. First, it is written in C++ because the SDK for the pico is set with C++ classes, but I code C++ like C with classes most times and stuff like that drives C++ programmers nuts. and I really need to get back to that project.
In the book they say XOR is pronounced "zor" . I have always heard it as "ex or". from programming classes to logic (philosophy) classes to YouTube tutorials. I am pretty sure Ben Eater says "ex or" when dealing with digital logic chips. and for those that don't know XOR is exclusive OR in logic.
I wish the book went more in-depth with hex. I don't know if they will but Chapter 17 sort of glossed over it. it does come in handy when dealing with binary with something like register flags.
chapter 18 and we finally get to pointers. it only took 269 pages (of 409 not counting appendixes). so I didn't start to understand pointers really until I started looking at assembly. I understand assembly at the concept level but I have coded basic stuff in 6502 and x86 assembly but I don't know any variant of assembly to program something from scratch in it. but when you understand what assembly is doing you understand that all variables are pointers. A variable name is just a reference to a place in memory where the value is stored. C adds a layer of abstraction to it and like all C instructions it is broken down into multiple assembly instructions. In assembly, the variable name is just a label. I would use the goto command as an example but I don't think this book even mentions goto besides listing it as a C keyword. Let's say we have a C variable X and X is an int. Let's say in this case an int is 4 bytes. So if we need the value of X what C does is it gets the value in memory of where X points to and the next 3 bytes (4 bytes total) this chapter did not really cover pass-by-value and pass-by-reference. I will guess the next chapter (also on pointers) will.
chapter 19 starts out with pointer arithmetic and comparing it to arrays. and then goes into strings are char arrays (which was mentioned earlier in the book) but then goes into strings are char pointers. Again once you understand how assembly treats memory (because this is how the computer handles memory) you can understand this better.
then it introduces the double-pointer. not to be confused with a double pointer. are you confused a double-pointer (**name) is a pointer to a pointer basically a 2-dimensional array (name[][]) where a double pointer is (double *name). so what is (double **name) is this a double-double-pointer? and with 2 pages left in the chapter they cover passing a pointer to a function (pass by reference)
Chapter 20 and now we have malloc(). I am speed-reading this. otherwise, I would be falling asleep on each page. and it is not because of the way it is written but because I know most of this already. Do I remember it verbatim? no. that is why I use man pages and other tools (stack overflow, google, etc) when I am programming. That being said it talks about casing when using malloc() but it does not mention that malloc() returns a void pointer. and in turn, does not discuss void pointers. I just checked the index and of the 3 pages listed for the void data type, only one has a sentence that mentions void pointers.
now to linked lists. something else that I am aware of but don't think I have used. Not much is new to me but if this was a book I owned and not a library book that I need to return in 3 days I would put a permanent bookmark on this chapter (like a piece of tape or dog-ear). I do think I will renew it so I am not rushed with this blog.
On a side note my library app has decided that it won't show me books I have checked out and in turn, I can't renew them via the app. so I will need to login to the website to do that. so that is new.
We are at chapter 21 so it is time for time. I would like to see how deep the book goes into time. Timing on a computer is very system and hardware-dependent. I wonder if it will dive into RTC (Real-Time-Clocks). This book does not mention embedded systems and that is a use case where how timing works is important because of the low-level nature of it.
They kind of gloss over how time works at the machine level. and to be fair C is a multi-platform programming language so everything may be different. That is the beauty of the C Standard Library: it does all that under the hood so you have a consistent performance and code can be used across platforms. they did mention the Unix epoch and that is important to know (and something I kind of forgot about). and they discuss how time can be used to seed a random number with srand(). In the future, I plan on using the Raspberry Pi Pico to use a hardware sensor to generate a random seed. look for that on this blog or my YouTube channel. The time chapter was short but it did express what needed to be said...or written...or read....you know what I mean.
chapter 22 introduces files and how to save, write, append, edit...etc them. The book uses the library function/file pointer method fopen() to open files as opposed to the system call/file descriptor method of open(). and the library function may be more consistent. I think I used open() with my ffmpeg project. Unfortunately, that laptop needs some love and care and I did not put the source on github. I was in the process of making a GitHub video and making a repository for the project, but I waited too long.
So along with file manipulation, we need to deal with file management which Chapter 23 covers. One of the things is directories. and this is definitely needed when a user needs to select a file or you need information on a file. if you saw my c/c++ work on my FFMPEG project I used a relative path when accessing files (../dir/dir/file, ./file, ./dir/file, etc) I could have used an absolute path, but that would make it less portable because everything would need to be in the exact same directory. Now here is a question: do you call them directories or folders?
Something I have difficulty in C is using multiple source files. my brain wants to say that as long as I use #include it is all good. and that is fine for the header (.h) files but for some reason you need to use the linker for multiple "source"(.c) at least that is my experience with compilers I have used. That is why I have been trying to learn more about Makefiles. and I just checked the index to see if Make is covered and it is not. probably because they expect you to use an IDE, another way is to use build scripts with bash (or your shell of choice). so using multiple files is what Chapter 24 covers. so the book puts the function prototype in the header file (ex2403.h) but puts the code for the function in main.c just under the main() function. If you are going to put the code for the main.c file why bother putting the prototype in a header file? That just seems worthless to me. I know the book is trying to teach how to put prototypes in the header and how to put code in a separate .c file, but why not culminate it with the prototype in the header file and the code for the functions in another .c file and show it working all as one.
There are bugs and bugs and bugs. As the book says, everyone writes bugs in their code. In Chapter 25 they start out by saying to use printf(). and yes I do that all the time, but many will tell you using printf() can obscure bugs, cause bugs, or negate what is causing the bug. A better way is to use tools like GDB. let's see if the book mentions that (I am only on page 1 of the chapter)
ok, something I didn't know was the __LINE__ macro. This macro displays the line number of the code that it is in. It is useful in debugging. and they do mention the GNU debugger but the book goes into the IDE Code::Blocks debugger. I don't use Code:Blocks often so I am just skimming this part. it does talk about breakpoints, I need to see if they have GDB for Dummies.
on to part six, which is called the parts of tens and chapter 6 is 10 common boo-boos. Before reading this I assume I have made all 10 multiple times. The first one is messing up conditionals and yes I do that all the time. especially using = instead of ==. the second one I don't think I have done. that is adding a semicolon ; instead of curly braces { }. if you don't use the curly braces to encapsulate the code block the loop does not know what code to run. missing the break keyword in a switch case, yup I have done that one. I do understand that you may want the switch case to roll over to the next case but that is an exception (to my knowledge). so missing braces is common for me. on this keyboard in particular because the close brace button is temperamental. ok, they added ignoring warnings. if it lets me compile I am guilty of this one. I will run it and see if it works. most of the time I will glance at it. Most of my warnings tend to be declaring a variable and not using it. This is because when I plan out something I try to add all the variables at the beginning. sometimes I am doing code in stages and don't need the variable. Other times I will use a variable for debugging and comment out the debugging code and not the variable definition. I will even use this with GDB because sometimes I want to see if a calculation is being computed correctly. generally to make sure the order of operations is going how I think it should. so they put endless loops, but I think they covered that already. I think they are forcing it to be a list of 10 things. and scanf() part of this is not knowing that you need to put pointers as arguments, and forgetting the ampersand (&). The funny thing is I know Ampersand from the show Wheel of Fortune. I think it was the category “same name” where they introduced the ampersand. so that was chapter 26
now 10 reminders and suggestions, that is chapter 27 the last chapter. So the first thing it says is to maintain good posture. This is funny because as I am typing this I am reaching over the book and my tablet to type this. not good posture at all. it says to use creative names for things like variables and functions, but I would argue creative is not the right word. Use descriptive names may be a better wording. I agree with the book you should write functions when doing repetitive tasks. The key is to not overdo it. I have seen code where almost everything is in its own function and main() is just the caller for them. In this case, you better know how to use pointers. The next reminder is to make little changes in your code, so if you are adding a feature or debugging you have a clear path of what to change or not to change. Making several changes in several parts of the code will make the map to how you got from part a to part b difficult. but sometimes you make a significant change to a function, like changing the arguments and you need to fix every place the function is called. A good example is say you have a code that takes a string (char array) and you discover you need to add an int for the string length for security purposes to avoid string overruns. you need to change the function, but now you need to find every place you called the function. One crude way is to compile it and go through the error messages one by one. and if you are doing it from the terminal and don't know where the function calls are this may be the quickest. if you are in an IDE that checks for syntax errors that may be another way. it tells you to know what a pointer is. After spending half the book avoiding pointers, now the author wants to make sure you know what they are. It talks about adding whitespace. If you are the only coder on a project use the white space to make it readable to you. If you are part of a bigger project there may be style guidelines for white space that you will need to follow; be flexible. it suggests to read your code out loud. I am not sure how well that would work for me, but it may work for you. For writing (like this blog) I run it through a text-to-speech website to make sure it sounds correct. I don't think that will help with code.
Finally the Appendixes. The first one (Appendix A) is the ASCII codes (0-127) there are -255 to -1 but this book does not cover that or utf-8 and utf-16 that may also apply so look this up. for nothing else so you know what they are if you come across it (utf-8 is common in HTML). appx B is the C17 keywords. As I am writing this C23 is due to come out. and it does give some of the C++ keywords (I guess for context). appx C is the Operators. This is a good thing to review from time to time. Appx D are the built-in data types but you may want to look into custom data types like uint8, uint16...etc. Appx E has the escape sequences (for use in functions like printf()). F is a conversion chart and G is order of precedence.
so that is the book. I had not planned on doing a chapter-by-chapter review. But that is what I did. Now I need to return this to the library. so I may not have it during editing (if I don't edit this soon).
.
Check Out My YouTube Channel https://www.youtube.com/@samplesandtests/
Tuesday, May 3, 2022
Post-Covid World
In the Covid / Post-Covid world, there are many changes. Some of these changes are temporary (hopefully). Others may become permanent. In the workforce / business world some of these changes may be for the better; at least in the long run. I say in the long run because in the short term there are growing pains. Some of these changes may be good for businesses but not for workers. Others will be good for workers and not for businesses. Yet some will benefit both workers and businesses. Only time will tell.
The idea / concept of remote work / telework / work from home is not new. The scale of workers working remotely is new. As of 2022 the amount of workers that work from home has contracted from the peak in 2020. Information Technology plays a large part in how effective telework is. Almost every industry can utilize remote work, but many need to be creative. A plumber can’t work from home, but their support staff can work remotely. All a receptionist needs is a computer and a phone to get service requests from customers and potential customers.
This notional plumber could just say: “use your own computer and we will forward calls to your cell”. This may work as a temporary fix until a functional system can be put in place. The upfront expenses to get a remote worker setup don’t need to be very high. Each company needs to balance what their employees need to complete their work against the cost to get them the tools they need. Proper planning is key.
Let's take two office based businesses in the same field and see how their choices in tools made a difference. Let's start in the spring of 2019. Both companies decide to upgrade their computers and network. Company A decides to get all their employees new Windows 10 desktop computers. They decided that laptops are too expensive, harder to maintain, and need docking systems to work well in an office environment. They decide to replace their aging standalone server with a similar but newer model. They decided that the server will have limited access to the internet; mainly for system updates. They feel that adding VPN access to the server and routing ports to the server leaves it open to security threats. And they decide to just add a few more extensions to the company's hardwired PBX phone system.
Now Company B took a different approach. They noticed that they tended to have several call-outs any time the weather acted up. So, they decided to give their workforce more flexibility and mobility. In the spring of 2019, they also upgraded their systems. They decided to replace the existing desktop computers with laptops and docking stations. To defer costs they decided to do this in stages over the next 18-24 months. The oldest computers were switched out first. They also decided that their server should have VPN access and the ability to remote print. They decided their existing server just needed a memory upgrade and one of the hard drives needed to be replaced, but their server could not easily be upgraded to allow for VPN access. It was decided that a dedicated VPN server would be added to the network. A dedicated device also allowed for greater security. In December of 2019, a large ice storm came through. Even Though they could work remotely, they had a hard time forwarding calls. Right after the new year of 2020, they decided to switch to a VOIP phone system. They carefully chose a system that was not too pricey and had the features they needed. Initially, the expense was mainly the cost of all new VOIP phones. Luckily they were able to find some price-sensitive phones for under $60 each for most employees. The receptionist and some of the owners need more expensive phones. On average the new phones were cheaper than their old PBX phones. And they did not need to maintain their PBX hardware. Because of their careful consideration, their new monthly bill was slightly less than their old phone bill. By late February 2020 they had all the phones replaced, the server was upgraded, the VPN was set up, and 60% of the desktop computers had been replaced with laptops. Then came March.
They say March comes in like a lion and leaves like a lamb. March of 2020 came in like a wrecking ball, and as of 2022 still has not left. In the flurry of march madness, both these companies faced obstacles they never imagined. As the world stood on its head, companies around the world had to figure out a way, or close shop. No company was positioned to ride out the storm right out of the gate. Some companies did find a way to thrive while others faltered. Many of the technology companies found they had more customers almost overnight. App delivery companies found that more and more people choose to have their food (and other essentials) delivered and not leave the house. And these app companies found drivers as the gig economy received an influx of new workers as other parts of the economy collapsed. Restaurants that could no longer serve customers on-premises offered takeout and eventually delivery either with their own staff or with one of these apps. These delivery apps did not offer much help to company A and company B.
Productivity was a main concern with both company A and company B. Company A had a hard time moving forward. They decided to have their employees use their own computers to remote desktop into their work computers. This lead to various problems. The biggest one is security. The company and its IT team had little control over the employees’ personal computers. They also did not have time to make sure all the personal computers had all the security credentials they needed. And each computer was different. That was the second problem. There was no standard. Some employees had personal computers that were similar to the companies. But most had older computers or none at all. It is difficult to do work from a tablet. Some employees chose to purchase computers with their own money. While other employees refused (or were unable to) pay out of pocket for something the company needed. With the decline in business, the company chose to furlough these employees. Not every employee needed to have access to their office phone. But those that did had a major problem. There was almost no way to transfer an individual extension to a cell phone with their existing phone system. They ended up purchasing prepaid cell phones for the receptionists to receive calls and forward them to the other employees’ personal cell phones. This was a disaster; they started losing the few customers they had left.
Company B lost business too, but their productivity was higher. They were able to get most of their employee’s setup from home with some headaches. They scrambled to get laptops to replace the remaining desktops. Unfortunately, supply was down and demand went up because pretty much the whole world was in the same boat. There was not so much price gouging as there was a lack of deals for computer equipment. They did not need the full 40% of the remaining computers right away. Due to related issues with the pandemic some employees took a leave from the company. With the help of government assistance they did not need to lay off or furlough employees. Their new VOIP phone system allowed employees to take calls through an app or website on their computer using a headset or they could forward calls to their cells. They next looked for productivity and workflow tools. Over the next few months, they went through several. With the exception of the loud family member in the background, most of their clients did not even notice a difference. Internally they were issues, but nothing catastrophic. They did need to hire some part-time workers to help with the transition. Mainly digitizing paper documents that were needed. The building management set up strict rules for entering the building. So they decided to have 5 key people go in when needed. It was almost always 1 person in the office at a time. And if the office was visited 3 times a week, that was standard. Sometimes they did not need to go into the office. They just went to the bay door by the mailroom. Called and picked up the mail contactless. And once a week someone would pick up documents from the office and deliver them contactless to one of the new part-time employees who would scan them and upload them to the document management system.
Company A had the same building management company in a different building with the same restrictions. Unfortunately, they had an added issue. Since their employees used remote desktop, if the computer (in the office) locked up, someone would need to go in person to reboot it. This happened about twice a week. The company was too busy dealing with other IT issues that they did not realize (or could not bother with) they did not have a document management system. Each employee kept their files on their own network drive. They did have a great deal of paper documents. Initially what they would do is each day an employee would go into the office, retrieve any documents that were needed, reboot any computers, and deliver the documents to the employee. They would also pick up any documents that the employee was done with to be returned to the office the next day. This was made worse by the fact that several employees lived over an hour away. Sometimes they would meet at a rest stop halfway. This was not productive.
Once restrictions were lifted company A immediately started having employees come back to the office. With required distancing still in place, this meant they needed to redesign the office to meet health regulations and guidelines. Company B had to redesign their workspace too but they decided to only have a reduced staff report back to work. Even though it was not perfect, Company B had a decent work from home workflow. Some employees preferred to be back in the office so for the most part, they were the ones that came back.
Companies around the world need to decide how they are going to handle their workforce. Some companies have discovered that they can have workers operate remotely with a decent amount of productivity. A key part is the tools they decide to invest in. being able to know if an employee is being paid to surf the internet may be of concern. But office employees have found ways to mask their lack of productivity for decades. Additionally, having too many restrictions and policies may restrict the way the employees work. Many companies did not have a reliable way to gauge employee productivity prior to the pandemic, while others had convoluted metrics that employees learn to manipulate.
The idea / concept of remote work / telework / work from home is not new. The scale of workers working remotely is new. As of 2022 the amount of workers that work from home has contracted from the peak in 2020. Information Technology plays a large part in how effective telework is. Almost every industry can utilize remote work, but many need to be creative. A plumber can’t work from home, but their support staff can work remotely. All a receptionist needs is a computer and a phone to get service requests from customers and potential customers.
This notional plumber could just say: “use your own computer and we will forward calls to your cell”. This may work as a temporary fix until a functional system can be put in place. The upfront expenses to get a remote worker setup don’t need to be very high. Each company needs to balance what their employees need to complete their work against the cost to get them the tools they need. Proper planning is key.
Let's take two office based businesses in the same field and see how their choices in tools made a difference. Let's start in the spring of 2019. Both companies decide to upgrade their computers and network. Company A decides to get all their employees new Windows 10 desktop computers. They decided that laptops are too expensive, harder to maintain, and need docking systems to work well in an office environment. They decide to replace their aging standalone server with a similar but newer model. They decided that the server will have limited access to the internet; mainly for system updates. They feel that adding VPN access to the server and routing ports to the server leaves it open to security threats. And they decide to just add a few more extensions to the company's hardwired PBX phone system.
Now Company B took a different approach. They noticed that they tended to have several call-outs any time the weather acted up. So, they decided to give their workforce more flexibility and mobility. In the spring of 2019, they also upgraded their systems. They decided to replace the existing desktop computers with laptops and docking stations. To defer costs they decided to do this in stages over the next 18-24 months. The oldest computers were switched out first. They also decided that their server should have VPN access and the ability to remote print. They decided their existing server just needed a memory upgrade and one of the hard drives needed to be replaced, but their server could not easily be upgraded to allow for VPN access. It was decided that a dedicated VPN server would be added to the network. A dedicated device also allowed for greater security. In December of 2019, a large ice storm came through. Even Though they could work remotely, they had a hard time forwarding calls. Right after the new year of 2020, they decided to switch to a VOIP phone system. They carefully chose a system that was not too pricey and had the features they needed. Initially, the expense was mainly the cost of all new VOIP phones. Luckily they were able to find some price-sensitive phones for under $60 each for most employees. The receptionist and some of the owners need more expensive phones. On average the new phones were cheaper than their old PBX phones. And they did not need to maintain their PBX hardware. Because of their careful consideration, their new monthly bill was slightly less than their old phone bill. By late February 2020 they had all the phones replaced, the server was upgraded, the VPN was set up, and 60% of the desktop computers had been replaced with laptops. Then came March.
They say March comes in like a lion and leaves like a lamb. March of 2020 came in like a wrecking ball, and as of 2022 still has not left. In the flurry of march madness, both these companies faced obstacles they never imagined. As the world stood on its head, companies around the world had to figure out a way, or close shop. No company was positioned to ride out the storm right out of the gate. Some companies did find a way to thrive while others faltered. Many of the technology companies found they had more customers almost overnight. App delivery companies found that more and more people choose to have their food (and other essentials) delivered and not leave the house. And these app companies found drivers as the gig economy received an influx of new workers as other parts of the economy collapsed. Restaurants that could no longer serve customers on-premises offered takeout and eventually delivery either with their own staff or with one of these apps. These delivery apps did not offer much help to company A and company B.
Productivity was a main concern with both company A and company B. Company A had a hard time moving forward. They decided to have their employees use their own computers to remote desktop into their work computers. This lead to various problems. The biggest one is security. The company and its IT team had little control over the employees’ personal computers. They also did not have time to make sure all the personal computers had all the security credentials they needed. And each computer was different. That was the second problem. There was no standard. Some employees had personal computers that were similar to the companies. But most had older computers or none at all. It is difficult to do work from a tablet. Some employees chose to purchase computers with their own money. While other employees refused (or were unable to) pay out of pocket for something the company needed. With the decline in business, the company chose to furlough these employees. Not every employee needed to have access to their office phone. But those that did had a major problem. There was almost no way to transfer an individual extension to a cell phone with their existing phone system. They ended up purchasing prepaid cell phones for the receptionists to receive calls and forward them to the other employees’ personal cell phones. This was a disaster; they started losing the few customers they had left.
Company B lost business too, but their productivity was higher. They were able to get most of their employee’s setup from home with some headaches. They scrambled to get laptops to replace the remaining desktops. Unfortunately, supply was down and demand went up because pretty much the whole world was in the same boat. There was not so much price gouging as there was a lack of deals for computer equipment. They did not need the full 40% of the remaining computers right away. Due to related issues with the pandemic some employees took a leave from the company. With the help of government assistance they did not need to lay off or furlough employees. Their new VOIP phone system allowed employees to take calls through an app or website on their computer using a headset or they could forward calls to their cells. They next looked for productivity and workflow tools. Over the next few months, they went through several. With the exception of the loud family member in the background, most of their clients did not even notice a difference. Internally they were issues, but nothing catastrophic. They did need to hire some part-time workers to help with the transition. Mainly digitizing paper documents that were needed. The building management set up strict rules for entering the building. So they decided to have 5 key people go in when needed. It was almost always 1 person in the office at a time. And if the office was visited 3 times a week, that was standard. Sometimes they did not need to go into the office. They just went to the bay door by the mailroom. Called and picked up the mail contactless. And once a week someone would pick up documents from the office and deliver them contactless to one of the new part-time employees who would scan them and upload them to the document management system.
Company A had the same building management company in a different building with the same restrictions. Unfortunately, they had an added issue. Since their employees used remote desktop, if the computer (in the office) locked up, someone would need to go in person to reboot it. This happened about twice a week. The company was too busy dealing with other IT issues that they did not realize (or could not bother with) they did not have a document management system. Each employee kept their files on their own network drive. They did have a great deal of paper documents. Initially what they would do is each day an employee would go into the office, retrieve any documents that were needed, reboot any computers, and deliver the documents to the employee. They would also pick up any documents that the employee was done with to be returned to the office the next day. This was made worse by the fact that several employees lived over an hour away. Sometimes they would meet at a rest stop halfway. This was not productive.
Once restrictions were lifted company A immediately started having employees come back to the office. With required distancing still in place, this meant they needed to redesign the office to meet health regulations and guidelines. Company B had to redesign their workspace too but they decided to only have a reduced staff report back to work. Even though it was not perfect, Company B had a decent work from home workflow. Some employees preferred to be back in the office so for the most part, they were the ones that came back.
Companies around the world need to decide how they are going to handle their workforce. Some companies have discovered that they can have workers operate remotely with a decent amount of productivity. A key part is the tools they decide to invest in. being able to know if an employee is being paid to surf the internet may be of concern. But office employees have found ways to mask their lack of productivity for decades. Additionally, having too many restrictions and policies may restrict the way the employees work. Many companies did not have a reliable way to gauge employee productivity prior to the pandemic, while others had convoluted metrics that employees learn to manipulate.
Labels:
business world,
businesses,
Covid-19,
creativity,
growing pains,
industries,
information technology,
IT team,
PBX,
phone system,
productivity,
remote work,
telework,
VOIP,
VPN,
wfh,
workforce
Subscribe to:
Posts (Atom)