Do you really need to learn calculus?

I was talking to a friend of mine who teaches middle school math this week. It brought back all sorts of memories about my career in math, how I picked my classes over my primary and secondary schooling, and what I would tell my teen-aged self with the benefit of hindsight if such self would actually listen to an adult back then.

I come from a family of math geeks: my sibs and my parents were all good at math, and all of the kids were on the “math team” that met after school to solve problems and compete for prizes. Looking through my old report cards, rarely did I get a grade less than an A in any of my classes. When it came time for college though, I started out as a physics major, quickly changing to math when I got frustrated with all the prerequisites, and eventually graduating with a roll-my-own major that combined independent study classes in science, art and math.

What many parents don’t realize until their kids have been through middle school is that there is in most districts a separation of kids into two math tracks. One is the basic math curriculum which involves teaching algebra, trig, geometry and some statistics by the time you finish high school. The other is a more advanced series of classes that ends with students taking calculus in their senior year in high school. If you are good at math, you end up with the latter program of study.

Why does anyone need to study calculus? There really isn’t any good reason. It is more custom than necessity. In my case, getting calculus “out of the way early,” (as I look at it now) allowed me to get AP credit and graduate early from college. It also enabled me to take more advanced math classes too. I asked Arnold Seiken, one of my former college math professors, why anyone should take the class. He was mostly bemused by the question: “Calculus was always part of the requirements for graduation – students assume that it is part of the burden of life and just grin and bear it. I assume you took my courses because you liked the jokes. I can’t think of any other reason.” He was right: he was always a crack-up, in class and now in retirement. Interestingly, he told me that he got into math by accident in high school because he couldn’t do the science labs, much like I decided. “Math was a fallback for me, I was always breaking stuff in the labs.” He was an excellent teacher, BTW.

When you are a college math major, there are basically two different career paths you hear about: to teach or to become an actuary. I wasn’t all that excited about teaching (although I did dabble with teaching both a high school computer class and a graduate business class later on in life), and when I took the first exam of many to become an actuary, I got the lowest possible passing score. That first exam is calculus, and my justification for the miserable score was because I hadn’t had any calculus for several years by the time I took the exam. But it didn’t bode well for a career in that field.

But having plenty of math classes – including one on linear algebra taught by Seiken — also enabled me to have a solid foundation for graduate school study of applied math topics that were part of my degree in Operations Research. That took me to DC and to do math modeling for supporting government policy analysis, and eventually on to general business technology.

My master’s degree was issued in the late 1970s. Back then we didn’t have personal computers, we didn’t have spreadsheets, we didn’t have data modeling contests like Kaggle. What we did have was a mainframe on campus that you had to program yourself if you wanted to do mathematical models. Today you can use Excel to solve linear programs and other optimization problems, set up Chi Square analyses, run simulations and other things that were unthinkable back when I was in school – not that I would know how to do these things now if you forced me to watch a bunch of videos to relearn them.

Seiken reminded me of a part-time job that I had in college, repairing these ancient geometric string models that were used in the 1800s to teach engineering students how to draw conic sections. I didn’t need calculus to restring the models, although it helped to understand the underlying geometry to figure the string placement. It did get me started on my path towards problem-solving though.

And I think that is what I would tell my teenage self. Whether or not I took this or that math class, what I was good at is solving technical problems. Having a math background made it easier for me to pick a more technical career path. Had I not moved into the calculus track, I probably would still have been interested in math of some kind, but probably wouldn’t have been as challenged to take the advanced classes I was doing as a junior and senior in college. So yes, calculus per se isn’t really relevant to debugging a network protocol stack, or figuring out the root cause of a piece of malware, but it does train you to learn how to pick apart these problems and find your way to an answer. Now, your kids may have a different path towards developing their own problem-solving skills, but math was my ticket and I am glad I took the path that I did.

FIR B2B podcast #131: How to Run Webcasts and Video Calls

Both Paul Gillin and I have run and participated in various webinars and online meetings over the years. For this podcast episode, we share some of their best practices. There are several things you can do to have great meetings. First, is preparing your speakers and in planning for the presentation. Do you have the right kind of slide deck? With our in-person speaking gigs, we try to minimize the text on our slides and provide for more of an experience and set the mood. For a webinar where you don’t necessary see your audience, your slides are more of your speaking notes, so your audience can take away your thoughts and remember your major points.

I produce a monthly webinar for the Red Cross that has a dozen speakers and an audience of several hundred. To pull this off with minimal technical issues, my team has put together a lengthy document that recommends how speakers connect (watch for poor Wi-Fi and don’t use speakerphones) and describes the various roles that different people play during the conference call (master of ceremonies, moderator, time keeper, slide wrangler, presenter recruiter, chat and notes helpers). Paul and I both suggest using a common slide deck for all speakers, which means getting the slides in order prior to the meeting. Also, with more than a couple of presenters you should test your speakers’ audio connections too; both of us have had more problems with wonky audio than video. And settle on a protocol for whether or not to show your face when the meeting starts (and check to see if you are appropriately dressed).

Both of us feel you should always start your meetings promptly: you don’t want to be wasting time waiting for stragglers. We both don’t particularly like Skype for Business, although “regular” Skype is fine (most times) and we have also used GoToMeeting and Zoom, too.

Here is an example of a recent speech I gave to an audience of local government IT managers. I also has lots of other tips on how to do more than meetings and improve team collaboration here.

If you would like to listen to our 16 minute podcast, click below:

Good luck with running your own online meetings, and please share your own tips and best practices as comments. And enjoy the video below.

Picking the right tech isn’t always about the specs

I have been working in tech for close to 40 years, yet it took me until this week to realize an important truth: we have too many choices and too much tech in our lives, both personal and work. So much of the challenges about tech is picking the right product, and then realizing afterwards the key limitations about our choice and its consequences. I guess I shouldn’t complain, after all, I have had a great career out of figuring this stuff out.

But it really is a duh! moment. I don’t know why it has taken me so long to come to this brilliant deduction. I am not complaining, it is nice to help others figure out how to make these choices. Almost every day I am either writing, researching or discussing tech choices for others. But like the barefoot shoemaker’s children, my own tech choices are often fraught with plenty of indecisions, or worse yet, no decision. It is almost laughable.

I was involved in a phone call yesterday with a friend of mine who is as technical as they come: he helped create some of the Net’s early protocols. We both were commiserating about how quirky Webex is when trying to support a multiple-hundred conference call. Yes, Webex is fine for doing the actual video conference itself. The video and audio quality are both generally solid. But it is all the “soft” support that rests on the foibles of how we humans are applying the tech: doing the run-up practice session for the conference, notifying everyone about the call, distributing the slide deck under discussion and so forth. These things require real work to explain what to do to the call’s organizers and how to create standards to make the call go smoothly. It isn’t the tech per se – it is how we apply it.

Let me draw a line from that discussion to an early moment when I worked in the bowels of the end-user IT support department of the Gigantic Insurance company in the early 1980s. We were buying PCs by the truckload, quite literally, to place on the desks of the several thousand IT staffers that until then had a telephone and if they were lucky a mainframe terminal. Of course, we were buying IBM PCs – there was no actual discussion because back then that was the only choice for corporate America. Then Compaq came along and built something that IBM didn’t yet have: a “portable” PC. The reason for the quotes was that this thing was enormous. It weighed about 30 pounds and was an inch too big to put in the overhead bins of most planes.

As soon as Compaq announced this unit (which sold for more than $5000 back then), our executives were conflicted. Our IBM sales reps, who had invested many man-years in golf games with them, were trying to convince them to wait for a year before their own portable PC could come to market. But once we got our hands on an IBM prototype, we could see that Compaq was a superior machine: First, it was already available. It also was lighter and smaller and ran the same apps and had a compatible version of DOS. We gave Compaq our recommendation and started buying them in droves. That was the beginning of what was called the clone wars, unleashing a new era of technology choices to the corporate world. After IBM finally came out with their portable, Compaq already had put hard drives in their model so they stayed ahead of IBM on features.

My point in recounting this quaint history lesson is to point out something that hasn’t changed in nearly 40 years: how tech reviews tend to focus on the wrong things, which is why we get frustrated when we finally decide on a piece of tech and then live with the consequences.

Some of our choices seem easy: who wants to pay a thousand bucks for a stand to sit your monitor on? Of course, some things haven’t changed: the new Macs also sell for more than $5000. That is progress, I guess.

My moral for today: looking beyond the specs and understand how you are eventually going to use the intended tech. You may choose differently.

Fast Track blog: Lessons Learned From IT Asset Management

As a citizen developer, trying to manage your IT assets can be tough. Keeping track of such things as programs, servers, policies and procedures requires discipline, organization, and best practices that those of us who were raised in the IT school of hard knocks had to learn along the way. Here are a few tips from the IT pros to help you out.

You can read more on the QuickBase Fast Track blog here.

Quickbase blog: How to Make Scheduling Meetings Easier and More Productive

xk2One thing that hasn’t changed about today’s office environment is that meetings are still very much in force. Certainly there are ways to make their end product – such as linked spreadsheets poked fun of by this Xkcd comic — more productive. But there are other productivity gains to be had with meeting scheduling and tracking and online calendar technologies that can be had as well. Before you dive into any of these, realize that you will probably need more than one tool to help, depending on your needs. In my post today for the Quickbase blog I talk about various tools that you can use.

Quickbase blog: How Much Code Do You Need to Collaborate These Days?

Today we have a seeming ubiquity of the coding generation: rapid application development can be found everywhere, and it has infected every corporate department. But what is lost in this rush to coding everywhere is that you really don’t need to be a programmer anymore. Not because everyone seems to want to become one. But because the best kinds of collaboration happen when you don’t have to write any code whatsoever.

You can read my post about this topic in the Quickbase The Fast Track blog here.

Defaulting to transparency

I came across an interesting series of blog posts from employees at the company called Buffer. They make an app that allows you to concurrently post to various social media accounts. (I know, a crowded market space). What caught my attention was the use of the term “defaulting to transparency” — meaning that the corporate credo is to be as open as possible in all of its operations. I first thought, they can’t be serious. But they are and they do practice what they preach and so should you.

buff1Buffer shares its formula for calculating every employee’s salary, and even publishes and updates the spreadsheet showing you who makes what. All of their SaaS metrics are public (see the dashboard at right). While the company is private, they share which investor paid for what piece of equity, the number of customers, what their annual revenues are, and so forth. That is pretty impressive.

Transparency isn’t a new thing: Google has had its transparency report since 2010, and even links to other companies’ reports here. But that is mainly how they respond to subpoenas and other government requests for information, although there is a great report showing you how much of Gmail is encrypted to other providers. But what Buffer and others are doing is a more personal nature, more directly tied to their corporate ethos and culture. They use transparency as an asset to recruit and retain the best people working for them all over the world. Another example of their transparent culture: emails between two or more staffers get cc’ed to a special departmental group inbox, where anyone can examine their content. Each employee gets a Jawbone fitness monitor and the results are available for anyone to see how you literally live your life, including how much sleep you get every night. They have other tools that allow anyone to track other kinds of progress reports on a daily basis too.

Certainly, they aren’t alone in doing this. I asked my friend Gabe Lozano, the CEO of Lockerdome, what he thought of these ideas. He is fully on board. He told me, “In terms of transparency models, there is no one size fits all for any organization. We have found that transparency drives accountability, which drives results.” They have set up a series of reporting processes that gets communicated through a regular morning stand-up meeting (meaning no one has time to sit down, which moves things along) and a weekly meeting where written reports and product demos are shared with everyone.

The co-founder of Buffer said this a few years ago in a post: “Transparency isn’t all rainbows and unicorns. It was actually incredibly nerve-wracking to make the company more transparent. Before we made all salaries public knowledge in the company, I was terrified.” But he got over that, and now, “the power of transparency is that it drives us to be better—to create a company that’s both great and good.” You can’t argue with that.

While I wish more companies were as transparent as Buffer and Lockerdome, you can’t force it, especially if you have a CEO who isn’t a believer or who has problems with trust issues. But it certainly is a worthwhile goal.

The uneven history of collaboration

20_Options_for_Real-Time_Collaboration_ToolsThose of you who have been loyal readers of my work over the years will recognize a consistent theme where I talk about how we use computers to collaborate on projects. I came to work this morning to hear several complaints via IM from a friend who has an evil co-worker that was berating her about her ideas. “What a way to say good morning,” said my friend to me. That got me thinking.

We have come a long way on the route towards better collaboration, with fancier tools, higher-speed networks, and near ubiquitous Internet access, but the people part of the equation is still somewhat lacking. Let’s take a trip down memory lane and I’ll point out some of the things that I have seen over the years.

My most recent column on collaboration describes the British crypto program Colossus and how thousands of people worked over several years to decode German dispatches during World War II. That was collaboration with a capital C. The equipment was barely functional, and the workflows to get the job done were brutally complex. But it worked, because everyone pulled together and did their part and respected the individual roles that each had to play. So this is noteworthy because of the time period and the level of actual collaboration that took place.

But Colossus happened with everyone working in very close quarters, dictated by the wartime requirements and how the machine was constructed. In the modern era, we are more concerned about incorporating collaboration when we have distributed work teams. I had to deal with this early on, when in 1990 I founded Network Computing magazine and we hired the best editors from all around the country. Back then it was a challenge, especially as we had to build trust and help foster a sense of purpose with people that had never met face-to-face.

This is still an issue today. In this recent post for WPCurve, Don Virgillito talks about what he has seen from the best collaborative teams that were distributed geographically. He suggests that you should “consider existing remote work experience as an essential skill.” And you’ll also “have to grow as a team to continue being a team, which would involve meetings, team training, retreats to boost morale, and real-life meetings when possible to build long lasting relationships.” That is exactly what we did back in the early 1990s, and it worked so well that the magazine continued using some of these practices long after I left its helm.

As far back as 2008, I was writing about this people side of collaboration:

So, as PC processors get faster, disks get bigger, and our social networks get larger, we still don’t have the perfect collaboration solution. We still think of the data on our hard disks as our own, not our employer’s. Sharing is still for sissies. Until that attitude changes, the headphones will stay firmly stuck in our ears, blocking out the rest of the world around us.

How many of us are still stuck in a similar situation? And as more “bullpen” style office configurations are created, this only worsens the scenario.

If we look closer at the people relationships than the technology, we’ll see a lot more insights into how collaboration happens. That was the subject of this post from 2009 where a survey of collaboration habits found a key staffer way down the food chain was the glue that held things together. He worked closely with all the different stakeholders and pushed for better collaboration between departments, because the bosses of each department didn’t know how to talk to each other. Another part of this survey found that companies should focus on their least communicative employees: if they can bring them up even just slightly at being better communicators they will greatly improve productivity.

Let’s turn to the tools used for collaboration.

In 1990, we didn’t have the Internet, and setting up email meant running our own system that dialed into each of our remote offices to route messages around. IM and cell phones didn’t exist yet, so remote editors had to find payphones and RJ11 jacks for their modems. We spent a lot of time sending large graphics files around on our network because there wasn’t any other way to share them. In many ways, it was the dark ages of collaboration tools.

But as email became successful, it also brought overuse, something that we still wrestle with today. By 2009 we were focused more on cutting down on back-and-forth emails and improving remote access. In an article that I wrote for an IT publication then I talked about the various tools that were available, some of which are still being used today. (A chart that I prepared for my website is woefully outdated, but will give you a picture of what things I was looking at.)

And in this story that I wrote for Baseline magazine in 2011, I looked at other ways that collaboration happens, using screen sharing, document management and workflow management tools. For example at one after-market auto parts chain, installers can get the schematics of the car they are working on at the moment they need them, thanks to a collaboration tool that integrates into their workflow.

Since then, we have all sorts of fancy stuff to use. A recent review last year for Computerworld looks at three of them: Glip, Slingshot, and Flow. While none of the three are perfect, we have come a long way since the early days pre-Web. And if you click on that link above for the WPCurve article, you will see dozens of other suggestions of what the latest startups use for their collaboration technologies.

So yes, the history of collaboration has been one of fits and starts, making some of the same mistakes over again and not really considering the historical context. I hope you find the journey as interesting as I have.

Avoiding the IT rust belt

Living in the Midwest, I consider what life is like in the Rust Belt, where aging manufacturing companies have come and gone. When I first moved to St. Louis, all three of the domestic car makers had plants here: now we are down to just one of them. I was talking to a friend of mine who mentioned that she is seeing something similar: some enterprises are still stuck with their “rust belt” version of IT services and have yet to make their move. Whether their businesses will suffer the same fate as some of the manufacturing industry is hard to say.

So I thought I would talk to another friend of mine, who is the IT director at a Midwest steel mill and get his perspective. He has a small IT shop of six people but they are doing some interesting things to keep their plant competitive. “We can’t really innovate on our product line, but we have to do things from an IT perspective to serve our customers better and become more productive and cost effective,” he told me. Here is how he does it:

Get rid of aging equipment. While he still has a few Windows XP machines around, most of his IT gear is the latest and greatest. He is in the process of upgrading his Cisco network infrastructure, for example. Some of his most ancient computers that run his plant are connected to logic controllers, just because they don’t require much horsepower and they are on the plant floor where the environment is brutal. “Eventually, we will replace these when they break or migrate one of our older office PCs to there.”

Beware of legacy systems. “We were able to leapfrog other steel companies with our technology, because when we started the company we didn’t nave many legacy systems.” Now he has three developers who build custom apps that are used for handling their steel inventory and steel operations, along with a customer portal. For example, his team built a custom automated scheduling system when one of the two people in that department retired. Now it takes the remaining staffer just part of the day to do the scheduling, and they have cut wasted product and improved their steel yields tremendously, saving them money too.

Make use of the cloud and virtualization where it makes sense. “When I started with the company, we had a single PC server that was running everything. Now we have virtual servers and are looking at converged storage infrastructure too.” One of his first decisions was to employ Google Apps for their enterprise email. “That was a slam-dunk and one of the best decisions I ever made.”  He is looking at acquiring other cloud-based apps as well,

Vendor flexibility. Part of moving to the cloud means making use of services that don’t require vendor lock-in “I want to have options to migrate away from them if things don’t work out. That is why I haven’t gotten involved in SAP or Salesforce yet, there isn’t any easy way to walk away from them.”

Segregate production and office networks. As the stories from the German steel mill in December can testify, having totally separated networks between the office and the mill are critical. Hackers used an infected email to literally trash one of the mills. “We have different networks and vLANs so this won’t happen to us.”

Your own rust belt conditions might differ, for example, you might still be using Systems Network Architecture on your mainframes, or connecting via Frame Relay networks. So it might be a good time to reconsider these and other technologies, and start investing in your future. (The building pictured above is from an old automotive plant that has been renovated into condos, by the way.)

Computerworld: Peak vs. Tibbr, two communication tools reviewed

peak activity graphs1If you are trying to have more effective team communications, you are probably looking at products or services that go by names like “social CRMs” or “team engagement tracking apps.” Regardless of what they are called, these apps can connect to a variety of social networks and email accounts and make it easier to manage your communications, track what your team has posted, understand what other team members are working on and improve workflows and productivity by avoiding interruptions or massive amounts of email.

I tried out two of these tools, Peak (shown above) and Tibbr. Both are browser-based: Tibbr also has mobile and desktop clients. You can read my review in Computerworld here.